Clinical Data Model
The Clinical Data Model is the FHIR-aligned set of standard objects, fields, and relationships in Salesforce Health Cloud that represents a patient's clinical information.
Definition
The Clinical Data Model is the FHIR-aligned set of standard objects, fields, and relationships in Salesforce Health Cloud that represents a patient's clinical information. It covers encounters, conditions, observations, medications, allergies, procedures, immunizations, and diagnostic results, and links each record back to the patient stored as a Person Account.
Health Cloud builds this schema to align with HL7 FHIR Release 4 (version 4.0.1), the open standard for exchanging healthcare data. The model currently maps 26 FHIR R4 resources across administration, clinical, medication, diagnostics, and workflow domains. Because the object shapes follow FHIR conventions, customers can connect electronic health record systems and health information exchanges without building a bespoke mapping layer for every field.
How the Clinical Data Model represents patient health
The standard objects that hold clinical data
The model is a collection of standard objects, each storing one kind of clinical fact. ClinicalEncounter records a visit or interaction between a patient and a provider, from pre-admission through discharge. HealthCondition holds a diagnosed problem or concern. CareObservation captures measurements such as vital signs and lab results. MedicationStatement records what a patient is or was taking, while MedicationRequest holds prescriptions and PatientMedicationDosage holds the dosing instructions. AllergyIntolerance records allergies, PatientImmunization records vaccinations, and Procedure records clinical and surgical procedures. DiagnosticSummary groups results into reports, and HealthcareProvider represents the clinicians involved. Every one of these objects has a lookup back to the patient, so a care team can assemble a full clinical picture from a single Person Account. Because these are standard objects rather than custom ones, they ship with the Health Cloud managed package, get release upgrades from Salesforce, and come with documented FHIR field mappings. That saves the build effort an admin would otherwise spend designing a clinical schema from scratch, and it keeps the data model consistent across every Health Cloud org.
Why the model aligns with FHIR R4
FHIR (Fast Healthcare Interoperability Resources) is the dominant open standard for moving clinical data between systems. Health Cloud aligns its objects with FHIR Release 4, specifically version 4.0.1, so each Salesforce object corresponds to a known FHIR resource. The Encounter resource maps to ClinicalEncounter, Condition maps to HealthCondition, Observation maps to CareObservation, and MedicationStatement, AllergyIntolerance, Procedure, and Immunization map to their matching objects. This alignment is the practical reason the model exists. An EHR that emits FHIR can hand data to Salesforce with predictable field-by-field correspondence, and a downstream consumer can read it back the same way. The mapping is close but not identical. Some FHIR attributes that a typical Health Cloud user never needs are left out. A few Salesforce entities, such as Identifier and Code Set, carry more attributes than their FHIR counterparts because that extra data makes the records more usable on the platform and supports specific Health Cloud features. Salesforce documents every mapping in the Health Cloud Object Reference, so integration teams can see exactly which FHIR field lands in which Salesforce field.
Handling one-to-many relationships with child objects
FHIR resources frequently hold lists. A single condition can carry several identifiers, a single encounter can reference several providers or diagnoses, and a medication can have multiple codes. The Salesforce platform does not support one-to-many or zero-to-many values inside a single field, with the narrow exception of multi-select picklists. The Clinical Data Model solves this the platform-native way. It uses child objects whose records each reference the same parent. To represent the several identifiers on one HealthCondition, the model creates multiple Identifier records, and each one carries a reference field pointing back to that condition. The same pattern repeats across the model. ClinicalEncounter is supported by child objects such as ClinicalEncounterDiagnosis, ClinicalEncounterProvider, ClinicalEncounterFacility, and ClinicalEncounterReason. Each child row holds one item from what FHIR expresses as a list. This design keeps the schema relational and queryable. You can write SOQL across the parent and its children, build report types that join them, and apply sharing rules at the object level. It does mean an integration has to fan a single FHIR resource out into a parent record plus several child records, which is worth accounting for when you size the work.
Integrating EHR data into the model
The Clinical Data Model is most valuable as the landing zone for data that originates somewhere else. Most clinical information lives in an EHR such as Epic, Cerner, Meditech, or athenahealth, and Health Cloud sits beside that system as the relationship and care-coordination layer. When the source speaks FHIR, the alignment pays off directly, because each resource has a documented Salesforce target. Health Cloud also ships a packaged EHR data model and connectors that help bring records in, and integration tools like MuleSoft are common in larger programs that need transformation, queuing, and error handling at scale. The hard part of any clinical integration is rarely the field mapping. It is identity. The same person can exist in several source systems under different record numbers, and matching them to a single Person Account takes deliberate identity resolution. Get that wrong and you create duplicate patients, which corrupts every downstream count and care decision. Plan the matching logic, the merge rules, and the survivorship policy before the first record flows. With FHIR alignment handling the structure and a sound identity strategy handling the patient, the model becomes a dependable single view of clinical truth.
Care Plans and Programs built on clinical data
Clinical data on its own is a record store. It becomes operational when care workflows sit on top of it. Health Cloud Care Plans and Care Programs reference the Clinical Data Model directly. A chronic-care Care Plan tracks goals and interventions against the patient's HealthCondition records. A medication reconciliation effort reviews MedicationStatement and MedicationRequest data to confirm what a patient should actually be taking. A vaccination outreach program targets patients whose PatientImmunization records show an overdue or missing dose. The Patient Card and timeline surfaces in Health Cloud read from these same objects, so a care coordinator opens one record and sees active conditions, current medications, allergies, and recent encounters in a single working view. This is the payoff of a shared, standards-aligned schema. The clinical facts the integration brought in are the same facts the care team acts on, with no second copy to reconcile. Reporting follows the same path. Standard and custom report types let you build condition-based patient panels, medication-adherence cohorts, and immunization-gap lists, then feed those into outreach. The data model and the workflow stack are designed to reinforce each other rather than live in separate silos.
Privacy, consent, and governance
Clinical data is among the most sensitive data any Salesforce org will hold, and it sits under HIPAA in the United States, GDPR in Europe, and equivalent rules elsewhere. The Clinical Data Model is built with that reality in mind, and access to it is deliberately conservative by default. Health Cloud provides consent objects and sharing patterns that help enforce minimum-necessary access, so a user sees only the clinical records their role actually requires. None of this is automatic at the field level. Object permissions, field-level security, sharing rules, and restriction rules on the clinical objects all need explicit configuration before go-live, and they should be reviewed against the program's privacy requirements rather than left at install defaults. Consent itself is data. Capturing which patient agreed to which use of their information, and honoring it in process, is part of operating the model responsibly. Volume governance matters too. A large patient population can generate millions of CareObservation rows a year, so storage, archival, and large-data-volume query patterns deserve a plan from day one. Treating privacy and scale as launch requirements, not later cleanup, is what keeps a clinical deployment both compliant and performant.
Standing up the Clinical Data Model in Health Cloud
You do not create the Clinical Data Model object by object. The standard objects arrive with the Health Cloud managed package. The real work is enabling Health Cloud and getting the clinical objects ready to receive and surface data. These steps cover the configuration an admin does to stand the model up.
- Enable Health Cloud and its data model
Install or enable the Health Cloud managed package in the org. This provisions the standard clinical objects (ClinicalEncounter, HealthCondition, CareObservation, MedicationStatement, AllergyIntolerance, Procedure, PatientImmunization) and the packaged EHR data model alongside Person Accounts.
- Set object and field-level security
Grant the relevant profiles and permission sets access to the clinical objects, then tighten field-level security so each role sees only the clinical fields it needs. Defaults are intentionally restrictive, so plan the access matrix before opening anything up.
- Map your source data to FHIR resources
Using the Health Cloud Object Reference, map each incoming EHR field to its Salesforce target. Confirm where FHIR lists become child objects (for example several Identifier or ClinicalEncounterProvider records under one parent) so the integration writes the right shape.
- Configure identity resolution
Decide how source patient records resolve to a single Person Account. Define matching keys, merge rules, and survivorship before loading data, so multi-system feeds do not create duplicate patients.
- Surface the data and validate
Add the clinical objects to the Patient Card, timeline, and relevant Lightning pages, build a few report types, then load a sample and verify that records land on the right patient with the right access.
The package that delivers the standard clinical objects and the EHR data model. Required before any Clinical Data Model record can exist.
The account model that represents an individual patient. Every clinical record links back to a Person Account.
The documented correspondence between FHIR R4 resources and Salesforce objects that your integration relies on for predictable loads.
The consent objects, sharing rules, and field-level security that enforce minimum-necessary access to clinical data.
- The model aligns with FHIR R4 (v4.0.1) but is not a one-to-one copy. Some FHIR attributes are omitted and a few Salesforce entities carry extra fields, so always check the official mapping.
- FHIR lists become child objects. A single resource can fan out into a parent plus several child records, which changes how you size the integration and write SOQL.
- Identity resolution is the top cause of duplicate patients in multi-EHR programs. Define matching and merge rules before the first load, not after.
- Clinical object access is conservative by default. Field-level security, sharing rules, and consent all need explicit configuration to be both usable and compliant.
Prefer this walkthrough as its own page? How to Clinical Data Model in Salesforce, step by step
Trust & references
Cross-checked against the following references.
- The Clinical Data Model and FHIRSalesforce
- Mapping FHIR v4.0 to Salesforce Standard ObjectsSalesforce
Straight from the source - Salesforce's reference material on Clinical Data Model.
Hands-on resources to go deeper on Clinical Data Model.
About the Author
Dipojjal Chakrabarti is a B2C Solution Architect with 29 Salesforce certifications and over 13 years in the Salesforce ecosystem. He runs salesforcedictionary.com to help admins, developers, architects, and cert/interview candidates sharpen their fundamentals. More about Dipojjal.
Test your knowledge
Q1. Which set of objects belongs to the Health Cloud Clinical Data Model?
Q2. Why does the Clinical Data Model mirror FHIR resource shapes so closely?
Q3. Which standard is the Clinical Data Model aligned with for healthcare interoperability?
Discussion
Loading discussion…