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.