Note: This release is in preview. Features described here don’t become generally available until the latest general availability date that Salesforce announces for this release. Before then, and where features are noted as beta, pilot, or developer preview, we can’t guarantee general availability within any particular time frame or at all. Make your purchase decisions only on the basis of generally available products and features.
Patient data and healthcare records are important in the healthcare industry. Without
accurate information, performing and managing care becomes 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’s 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.
| Available in: Enterprise and Unlimited Editions |
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 Clinical Data
Model org pref.
Some of these objects are available in your org even before enabling this org pref because
they’re part of other data models in Health Cloud and Life Sciences Cloud.
To use the Clinical Data Model objects on an Experience Cloud site, community users need the
FHIR R4 for Experience Cloud Sites permission set.
Here’s the list of objects that need the org pref to be enabled versus a list of objects that
don’t require the org pref.
- 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
- Medication Administration
- Medication Administration Detail
- PersonLanguage
- PersonName
- Problem Definition Relationship
- Specimen
|
And here’s the list of 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 Spring ’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 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.
j