Patient 360 vs EHR: Where Engagement Data Should Live

A patient 360 is a healthcare version of a single customer view: one person's contact details, preferences, consent and outreach history, linked to clinical context and assembled from many systems. It does not replace the electronic health record (EHR). The EHR stays the system of record for clinical and billing data, while engagement, preference and consent data belong in a governed CRM or customer data platform (CDP) layer that references clinical data without duplicating it.

Who this is for: data, marketing, CX and privacy leaders who are being asked to "build a patient 360" and need to know which data goes where. You get the system-of-record logic, a data-class table, FHIR basics, a comparison of EHR, CRM, CDP and analytics roles, and a governance checklist. The healthcare hub lists related guides.

The EHR is the system of record, and the designated record set matters

HIPAA gives people a right to inspect and obtain a copy of their PHI in a designated record set, and the covered entity must act on a request within 30 days 2. The designated record set is defined in 45 CFR 164.501 as medical and billing records kept by or for a covered provider, enrollment, payment, claims and case or medical management records kept by or for a health plan, and any group of records used in whole or in part to make decisions about individuals 1.

Is engagement data PHI?

Assume yes once it is tied to a known patient. Individually identifiable health information includes demographic information collected from an individual by a provider or plan that relates to the provision of care or payment 4. A patient's phone number, appointment reminder history and channel preferences, held by the provider, meet that description. Anonymous visitors on public pages are a different case (see pixels after the HHS guidance).

FHIR: how data moves in and out

Fast Healthcare Interoperability Resources (FHIR) is the HL7 standard for exchanging health data through web APIs. The US federal certification rules adopt FHIR Release 4.0.1, with US Core 6.1.0 and SMART App Launch 2.0.0 (the earlier US Core 3.1.1 and SMART 1.0.0 entries expired on 1 January 2026) and FHIR Bulk Data Access for population-level export 8. HL7 describes R4 as mixed normative and trial-use and lists R5 (5.0.0) as its current published version, labelled a standard for trial use 9. In practice most EHR connections you will build in 2026 are R4.

Two R4 resources map directly to this topic. Consent records a person's choices, and only the privacy use is modelled today. Communication records a communication even if it is planned or failed. Both sit at maturity level 2, trial use 10. Expect to map them to your CDP's consent and outreach models rather than assume a drop-in fit.

EHR, healthcare CRM, customer data platform and analytics: four different jobs

CRM or customer data platform?

A CRM is usually enough when you run a single EHR with an embedded CRM, outreach is led by the contact centre, and nearly all data originates in the EHR. A CDP earns its place when signals come from many non-EHR sources (website, app, call centre, payer and pharmacy feeds), when you must resolve identity across them, when consent must be enforced across several activation channels, or when volumes are high. A SaaS CDP is a reasonable answer if the BAA covers the product, you send only preference and consent attributes, and no residency rule applies. A customer-owned deployment fits when identity and engagement history are PHI-linked and you want key custody, an audit ledger and exit control. See customer data platform vs CRM vs DMP vs MDM vs data warehouse and identity resolution.

Governance checklist

• Name one system of record for every data class in the table and publish it.
• Have the privacy officer decide, record by record, whether engagement data is in the designated record set; map the right-of-access process accordingly 12.
• Treat engagement data linked to a patient identity as PHI by default, and host the CDP or CRM under a BAA or in your own boundary 4.
• Sync from the EHR through a field-level allowlist; send flags, not clinical detail.
• Keep one consent and preference store that every channel checks, with a defined time limit for propagating a revocation. See consent withdrawal and suppression.
• Tag each segment with its purpose; marketing uses of PHI need authorization (see HIPAA marketing rules).
• Log identity-resolution merges and every outbound message.
• Feed analytics from de-identified data or limited data sets under a data use agreement 7.
• Segregate Part 2 records 6.
• Collect the BAA, covered-products list and sub-processors from every vendor (the BAA checklist helps).
• Test exit: export the identity graph and consent history in an open format.
• Review quarterly, and after any change to HIPAA or ONC rules.

Checked 2026-10-17 unless noted.

If you are mapping a patient 360 onto a customer-owned architecture, HIPAA-ready explains how PrivyCDP scopes PHI workloads. Return to the healthcare hub for related guides.