Newer Version Available

This content describes an older version of this product. View Latest

Clinical Data Model

The new Clinical Data Model enhances Health Cloud to make it more interoperable. Developed to be aligned with FHIR v4.0, the new data model is built almost entirely on core. The Clinical Data Model is meant to be the successor to the older packaged EHR Data Model.
Available in: Enterprise and Unlimited Editions

Patient data and healthcare records are very important in the healthcare industry. Without accurate information, performing and managing care becomes extremely difficult. These records are readily available if a patient seeks care from the same provider every time. However, in reality, a patient’s healthcare journey takes them to multiple providers and hospitals at different times. Because the patient’s health hinges on the accuracy of their medical records, it is crucial for the systems used by different providers and hospitals to be interoperable. And to make this interoperability possible, it’s vital to have some industry-recognized standards for how these records are structured, stored, and transferred. That’s where the standards defined by Health Level 7 (HL7) come in. Two standards defined by HL7 for this purpose are the Fast Health Interoperability Resources (FHIR) v4.0 and HL7 (the standard) 2.3. The Clinical data model is built from the ground up to align with FHIR v4.0, and also supports many of the HL7 v2.3 message types.

To enable these objects in your org, go to FHIR R4 Support Settings in Setup and enable the FHIR-Aligned Data Model org pref.

Some of these objects will be available in your org even before enabling this org pref because they’re part of other data models in Health Cloud.

Note

Here’s the list of objects that are part of the general Health Cloud permission set, and the ones that need the org pref to be enabled before you can use them.
Org Pref Required Org Pref Not Required
  • AllergyIntolerance
  • CarePerformer
  • ClinicalAlert
  • ClinicalEncounter
  • ClinicalEncounterDiagnosis
  • ClinicalEncounterFacility
  • ClinicalEncounterIdentifier
  • ClinicalEncounterProvider
  • ClinicalEncounterReason
  • ClinicalEncounterSvcRequest
  • ClinicalServiceRequest
  • ClinicalServiceRequestDetail
  • DiagnosticSummary
  • HealthCondition
  • MedicationRequest
  • MedicationStatement
  • PatientHealthReaction
  • PatientImmunization
  • PatientMedicalProcedure
  • PatientMedicalProcedureDetail
  • PatientMedicationDosage
  • CareObservation
  • CareObservationComponent
  • CareProviderFacilitySpecialty
  • CodeSet
  • CodeSetBundle
  • HealthcareFacility
  • HealthcarePractitionerFacility
  • HealthcareProvider
  • Identifier
  • Medication
  • PersonLanguage
  • PersonName

And here’s the list of Health Cloud fields added to standard objects when you enable this org pref.

  • ContactPointPhone.PreferenceRank
  • ContactPointPhone.UsageType
  • ContactPointEmail.PreferenceRank
  • ContactPointEmail.UsageType
  • ContactPointAddress.PreferenceRank
  • ContactPointAddress.UsageType
  • Account.IsActive
  • Account.EffectiveDate
  • Account.SourceSystemIdentifier
  • Account.SourceSystemModifiedDate
  • Account.EndDate
  • Contact.MaritalStatus
  • Contact.Gender
  • Contact.DeceasedDate
  • Contact.SequenceInMultipleBirth
  • Starting with the Winter ’23 release, new customers won’t be able to create records in the packaged EHR objects that have counterpart standard objects in the FHIR R4-aligned data model.
  • All future development in Health Cloud will be built on the FHIR R4-aligned data model. The packaged objects in the EHR data model won’t be used for future development.

Note