HL7 FHIR Implementation Guide: SHR Core, Release 0.6 - US Realm (Draft for Comment 1)

HL7 FHIR Implementation Guide: SHR Core, Release 0.6 - US Realm (Draft for Comment 1) FHIR Profiles - Local Development build (v0.6.0). See the Directory of published versions

This is a preliminary version of the Standard Health Record Core Module Implementation Guide, based on Health Level 7 (HL7) Fast Healthcare Interoperability Resources (FHIR).

Background

The goal of the Standard Health Record (SHR) Collaborative is to provide a high quality, computable source of patient information by establishing FHIR implementation guides (IG) in a number of high-impact clinical areas. SHR has an explicit goal of promoting semantic interoperability by creating horizontally consistent IGs that share common data structures and profiles. This goal is realized though unique distributed modeling environment and tooling that allows multiple projects to share the same basic logical model framework, which is then automatically converted into FHIR.

SHR standards are intended to encourage and facilitate reliable and repeatable collection and aggregation of a wide range of patient-focused data. Through the SHR, we realize greater transparency, empowerment, and clinical interoperability that supports patients, caregivers, clinicians, researchers, scientists, and public health organizations.

For more information see the Standard Health Record Collaborative .

The SHR Core Module

SHR Core ("shr-core") is the basis for all SHR-based profiles and implementation guides. It contains class definitions that are used across all clinically-focused modules. It contains class definitions closely aligned to FHIR, but in a class hierarchy. Using the CIMPL language, the user can extend that hierarchy using class-based inheritance, specialization, extension, and constraints -- paralleling the capabilities of FHIR profiling. SHR provides far greater consistency, abstraction, inheritance, and re-use than any other FHIR-based environment.

SHR Core can be described as object-oriented version of FHIR. The classes closely correspond to FHIR R4, but they differ in carefully considered ways that increase consistency and reusability. Attribute names in SHR Core may differ from FHIR (usually in obvious ways). SHR names are chosen so they are meaningful outside of the context of a single class. Hypothetically, an attribute named 'date' in a FHIR resource lacks context (date of what?); so to be reusable, we might rename it OccurrenceDate, if it represence the date of occurrence of some event.

BROWSE THE SHR CORE CLASS HIERARCHY or SEE THE EQUIVALENT FHIR LOGICAL MODEL.

In addition, FHIR attribute names sometimes change from one FHIR version to the next. SHR protects you from these changes. By using SHR Core, the naming is independent of the FHIR version. You model in one environment, and SHR tooling automatically translates to all the major releases of FHIR (DSTU2, STU3, and R4). The DSTU2 version is fully compatible with Argonaut Data Query Implementation Guide Version 1.0.0; the STU3 version is fully compatible with US Core Implementation Guide STU 2 (which confusingly is based on FHIR STU3).

SEE THE SHR CORE PROFILES

The other intentional divergence from FHIR is designed to achieve greater consistency and clinical accuracy. For example, in FHIR R4, of 148 resources, 30 resources lack an identifier attribute, only 101 have a status attribute, and only 23 have an author. In SHR, through the use of class inheritance, we assure that the right attributes appear consistently on the right classes.

This IG defines FHIR profiles, extensions, value sets, and code systems necessary to implement other SHR IGs. The profiles in this IG are based on FHIR 3.0.1 (a.k.a. STU3), but the classes are consistent with FHIR R4. An R4-based version is coming soon.