Patient engagement with Customer Insights – Journeys in healthcare

Hospitals and health systems already send appointment reminders from their electronic health record. So the first question for a patient-engagement project on Dynamics 365 Customer Insights – Journeys is not "can it send reminders" but "what should it do that the EHR does not". Answered well, Journeys becomes the outreach layer for population health, care-gap closure, service-line growth, and post-discharge follow-up. Answered badly, it duplicates the EHR's reminders with a second consent problem. This guide covers the use cases that justify the product in healthcare, and the constraints that PHI imposes on how it is used.

Use cases that earn their place

• Preventive care and care-gap outreach. Patients due for a screening, a vaccination, or a chronic-condition check, identified from claims or EHR data, receive a sequence of messages with a scheduling link. The EHR can generate the list; it is poor at multi-step, multi-channel sequences with response handling.
• Post-discharge and post-procedure follow-up. A journey triggered by a discharge event sends instructions, checks in at intervals, and escalates a concerning response to a care coordinator's queue in Customer Service.
• Service-line and access marketing. New clinic openings, telehealth availability, and health-education content to consenting community members — closer to conventional marketing, and where the healthcare-specific rules bite hardest.
• Referral and provider engagement. Outreach to referring physicians is a B2B journey with none of the PHI constraints, and often the fastest win.
• Patient experience follow-up. Surveys after visits through Customer Voice, feeding a satisfaction measure and an alert on low scores. This is not a substitute for regulated patient-experience surveys such as CAHPS, which have their own vendors and rules.

Appointment reminders belong in the EHR unless the organisation has a specific reason — multi-channel preference handling, integrated rescheduling in Customer Service — to move them.

The Cloud for Healthcare layer

Microsoft's Cloud for Healthcare includes a patient-outreach capability built on Customer Insights – Journeys and the healthcare data model, plus the connectors that bring FHIR data into Dataverse through Azure Health Data Services. It adds patient, encounter, and condition tables with their healthcare semantics, and templates for common journeys. It is worth adopting for the data model alone, because it prevents each project inventing its own patient table. The Cloud for Healthcare guide covers what it adds and what it costs.

Consent is not a checkbox

HIPAA's marketing rules and state laws distinguish treatment and care-coordination communications (permitted without authorisation) from marketing (generally requiring authorisation, with narrow exceptions). The TCPA governs automated SMS and calls separately. Journeys' consent centre models consent by purpose and topic per contact point, which maps well onto this if the purposes are defined properly:

• A treatment and care communications purpose, defaulted on for patients, covering follow-up and care-gap outreach.
• A health and wellness marketing purpose, opt-in only, for service-line and education content.
• Channel-level consent for SMS separate from email, with the SMS keyword opt-out handled by the platform.

Compliance and legal decide which journeys fall under which purpose; the marketing team should not be making that call at journey-design time. Encode the decision as a required field on the journey's approval.

PHI in messages, segments, and triggers

The presence of a diagnosis in a message, a segment name, or a trigger payload makes it PHI, and the organisation should treat the whole Journeys environment as a PHI system under its business associate agreement.

• Messages reference the action, not the condition. "You are due for your annual eye check" is better than a message naming the reason.
• Segment names and descriptions are visible to every marketer in the environment. A segment called by its clinical criteria has just disclosed those criteria to everyone with access. Name by campaign, keep criteria in a governed field.
• Custom triggers carry attributes into the journey. Send identifiers and the minimum needed to branch, and keep clinical detail in the source system.
• Dynamic content from patient records is a common leak: a personalised block that pulls a condition field into an email body is PHI in transit through the email provider.
• Attachments and links should point to the patient portal, where authentication protects the content, rather than embedding results or documents.

The HIPAA-aware Customer Service guide covers the security roles, auditing, and retention that apply to the same environment.

Channels and triggers

Email and SMS are the working channels. SMS in Journeys runs through supported providers — Azure Communication Services and third-party carriers — and the organisation needs a compliant sender registration in its country. Push notifications require a mobile app. Voice is not a Journeys channel; outbound calls are Customer Service or a contact-centre product.

Triggers come from Dataverse events (a discharge record created, a care-gap record updated) or from custom triggers raised by integration — a FHIR subscription on the EHR firing an Azure Function that raises the trigger. Batch-based journeys from segments refreshed on a schedule are simpler and usually good enough for care-gap outreach; event-based journeys are for the follow-up scenarios where timing matters.

Measurement

Journeys reports opens, clicks, and goal attainment. For healthcare the goal is downstream: the screening booked, the follow-up completed, the readmission avoided. Closing that loop means the outcome event flowing back — an appointment created in the EHR, a care-gap closed — either into Dataverse for the journey's goal or into Power BI joined on patient identifier. Without it, the programme reports engagement rates to a clinical leadership that does not care about engagement rates.

What stays with partners and the EHR

Patient portals, appointment self-scheduling, and clinical messaging are EHR functions or specialist products; Journeys links to them. Identity verification for patients accessing content is a portal or Entra External ID problem. Consent capture at registration usually happens in the EHR and flows into Journeys, which means an integration that keeps consent in sync in both directions — the part of these projects most often left until last and most often the cause of the first complaint.