STU3 Candidate

This page is part of the FHIR Specification (v1.8.0: STU 3 Draft). The current version which supercedes this version is 5.0.0. For a full list of available versions, see the Directory of published versions . Page versions: R5 R4B R4 R3 R2

7.5.2 HL7 v3 (and ISO 21090)

FHIR Infrastructure Work GroupMaturity Level: N/ABallot Status: STU 3

HL7 v3 was intended to be the next generation of HL7's messaging standards. It introduced a common Reference Information Model (RIM), data type model and set of vocabulary as well as a formal standards development methodology. In addition, it introduced the use of "documents" as an alternative architecture to messaging for sharing healthcare information (see the CDA comparison). While nominally covering both, the term "v3" is typically used to refer to "v3 messaging". The data types used as a basis for v3 have also been adopted by ISO as ISO 21090. The HL7 RIM has also been adopted as an ISO standard.

v3 messaging has been adopted by a number of large projects, particularly in the electronic health record area, though it has not achieved the market penetration of HL7 v2 . The HL7 RIM and the ISO 21090 data types have also been used by other SDOs and projects that have not leveraged the full HL7 v3 methodology. Most of the comments and guidance provided here will apply to those solutions as well.

7.5.2.1 v3 Similarities and Differences

Reference model: The use of the HL7 RIM is a core aspect of the HL7 v3 methodology and it is front and center in the specification and the wire format. All data elements in HL7 v3 instances are derived from either the RIM or the ISO data types. In FHIR, this is true of most resources and data type elements, but not all. Some resources (StructureDefinition, CapabilityStatement, ValueSet, etc.) deal with content that is outside the RIM's scope. And in a few circumstances, adjustments have been made in the FHIR data types that are not yet supported in the HL7 v3 data types model. The expectation is that these changes will be supported in the next version of the v3 data types model. The main difference is that the wire format of FHIR is not driven by the RIM mappings. This results in considerably more concise and intuitive instances. It is possible to implement FHIR with absolutely no knowledge of the HL7 RIM.

Codes: v3 places considerable reliance on coded attributes to convey the meaning of instances. Examples include classCode, moodCode, determinerCode, etc. The allowed codes for these attributes are strictly controlled by HL7. FHIR also has attributes that are limited to codes defined in the FHIR specification - those using the code data type. However, these are generally limited to attributes with business meaning - status, contact types, etc.

Both FHIR and v3 make use of value sets to define the sets of codes that can be used for attributes in particular contexts. However, in FHIR, a ValueSet is just another type of resource, meaning it can be sent as part of an instance just like any other piece of data. (The same is true of StructureDefinition, CapabilityStatement and other meta-level resources.)

Granularity & referencing: HL7 v3 models are broken into 3 main types - wrappers, payloads and Common Message Element Types (CMETs). These are combined into interactions to define the set of content that can be sent over the wire at one time. In some cases, the granularity of each of these models will exactly align with the granularity of FHIR resources, but not always. v3 models are divided based on the expectation of re-use. FHIR models are divided based on whether the objects they represent are considered to be able to "stand alone". In HL7 v3, numerous models can exist to represent the same essential underlying healthcare information construct. For example, at the HL7 International level, there are 10 different CMETs for the concept of "Patient". In addition, some payload models represent patient directly without using CMETs. Further variation exists in the v3 models created by HL7 affiliates and other v3 implementers. Each of these different CMETs has their own schema and may use different element names, different levels of nesting and different constraints. With FHIR, there is only one Patient resource. Many profiles can be created on that resource, but all of them will use the same schema and support the same wire format.

Design by constraint: The design methodology in v3 is one of "design by constraint". The idea is that all data needed for any sort of healthcare communication is represented in the HL7 RIM. All other data models simply constrain the RIM to reflect the needs of particular domain spaces. This starts at the international level with further refinement happening in individual countries, projects and finally specific implementations. As models become closer to the implementer, they become less abstract. The result is a tendency for v3 models to be extremely broad in their coverage and capability and also somewhat abstract. They need to be this way in order to ensure that all possible implementations in the space covered by that model can be properly constrained. As well, each model produces its own schema and, in most cases, constrained schemas are not strictly wire-compatible with the schemas of the model being constrained.

FHIR takes a different approach. FHIR resources do not attempt to represent all data elements that could possibly be used in a space. Instead, only those data elements that are expected to be used by "most" implementations within the scope of the resource are considered part of the core resource definition. (This is sometimes referred to as "The 80% rule" - if approximately 80% of systems maintaining the resource will support the element, then it is part of core). All other data elements are expected to be handled using extensions. Profiles are used both to constrain resources and to define extensions appropriate to narrower implementation spaces. Wire format interoperability is retained across all profiles on a given resource.

Context conduction: When conveying healthcare information between humans, much data can be inferred from context. For example, if a report has an "author" noted on a cover page, it is generally inferred that each statement within the report is authored by that same person. This inference grows more challenging when data needs to be analyzed by computers, whether for query, decision support or other analysis. Thus far, the HL7 v3 methodology has provided three distinct mechanisms to allow data models to define how "context" should propagate through models, making explicit for computers what humans would normally understand intuitively. FHIR has chosen a different path. In FHIR, no context is conducted - everything is explicit. If a report about a patient contains 100 observations all about that same patient, each observation will include a reference to the patient. However, this is relatively painless because it's only a reference - an id and possibly a short display value. One of the benefits of this approach is that each resource can be safely consumed and examined without concern for the context in which that resource was communicated. The meaning of each resource instance is fully self-contained.

Null flavors: In healthcare, it's quite common for data to be unknown, unavailable, have an exceptional value or otherwise fall outside the bounds of a "normal" value. To deal with this, v3 introduced the concept of "null flavor" on almost every attribute and data type property in its models. These coded null flavors could be sent in place of or in addition to the data that would typically be sent for the attribute, association or data type property. Examples include the ideas of "Unknown", "Not asked", "Positive infinity", "Trace amount", "Masked", "Other", etc. Unless an element was explicitly marked as "mandatory" - meaning no null flavors were permitted, these null flavors could appear absolutely anywhere.

FHIR approaches the problem differently. Null flavors are only introduced in the core specification in those circumstances where it is expected that most systems will need them. Where needed, the flavors are constrained to those relevant to that element.

7.5.2.2 v3 Interoperability Considerations

Using RIM mappings: Most resource elements and data type properties include mappings to the RIM. These mappings serve two purposes. They help to define FHIR semantics in terms of HL7's reference models, helping to ensure that the Work Groups defining the data elements have a good and consistent understanding of the meaning of every element. They also provide guidance for implementers of v3 specifications that may be looking to migrate to or map between v3 and FHIR. However, for the latter use it's important to understand some limitations on the RIM mappings. The RIM is a language which allows the same "idea" to be conveyed in a number of different ways with varying granularity and expressiveness. Thus it's entirely possible for a RIM element to map to a core FHIR element even though its RIM representation is somewhat different than described in the mapping. In addition, not all v3 models adhere to good modeling practices, so some data elements that would appear to map to a FHIR element might not map if the information has not been well represented. Therefore RIM mappings should be taken as a guide, not an absolute, and mappings must be done in the context of the v3 specification being mapped. (Also see Abstract models below.)

v3 extensions: While the core of the v3 methodology is "design by constraint", it still makes provision for the use of extensions - either in a foreign namespace or denoted by a special attribute. When converting between v3 and FHIR, the use of such extensions will need to be taken into account. As a rule, most v3 extensions will map to FHIR extensions, as the v3 design-by-constraint principle suggests that anything that would qualify as "core" in FHIR would already have been part of the base v3 specification.

Abstract models: As previously noted, many of the v3 models created at the HL7 International level are quite abstract. As a result, the models can be used to say a wide variety of things, often in a wide variety of different ways. This makes defining a mapping between those specifications and FHIR (or any other specification) quite tricky. For practical v3 <-> FHIR interoperability, mappings will need to be created at the level of message specifications, implementation guides and/or templates that are more concrete and closer to the implementation level. For example, mapping all of CDA to FHIR would be impossible given the expressive capability of the right-hand-side of the CDA model. However, mapping the Consolidated CDA (CCDA) templates to FHIR is quite possible.

Context conduction: As discussed above, HL7 v3 models rely on context conduction - either implicitly or explicitly controlled. When converting to FHIR, the context will need to be propagated into each resource.

Update mode: In HL7 v3 instances, updates are generally handled in snapshot mode, similar to the FHIR approach - if any information changes, the entire record is sent, including the modified data elements. However, the v3 methodology does support the introduction of an "updateMode" property to allow only the changes to be sent for all or part of an instance. Each element repetition is flagged with an updateMode to indicate whether the element is to be added, removed, updated, etc. Additional updateModes allow further control over updates. As with the V2 discussion above, implementers will need to generate a full snapshot of each resource or or consider using the Patch Operation instead.

Additional considerations: Most of the implementation considerations for interoperating between FHIR and HL7 v2 also hold with v3. Specifically: Extensions, Independent vs. Contained resources, Resource Identification, Merging references and resources and Generating human-readable content.