Background
One of the primary goals of HL7 Version 3 is to deliver standards that enable semantic interoperability. Semantic interoperability is a step beyond the exchange of information between different applications that was demonstrated by earlier versions of HL7. The additional requirement is that a receiving application should be able to retrieve and process communicated information, in the same way that it is able to retrieve and process information that originated within that application. To meet this requirement the meaning of the information communicated must be represented in an agreed, consistent and adequately expressive form.
Clinical information is information that is entered and used primarily for clinical purposes. The clinical purposes for which
information may be used include care of the individual patient and support to population care. In both cases there are requirements
for selective retrieval of information either from within a single patient record or from the set of records pertaining to
the population being studied. Meeting these requirements depends on consistent interpretation of the meaning of stored and
communicated information. This requires an understanding of the varied and potentially complex ways in which similar information
may be represented. This complexity is apparent both in the range of clinical concepts that need to be expressed and the relationships
between instances of these concepts.
Delivering semantic interoperability in this field presents a challenge for traditional methods of data processing and exchange.
Addressing this challenge requires an agreed way to represent reusable clinical concepts and a way to express instances of
those concepts within a standard clinical record, document or other communication.
The HL7 Version 3 Reference Information Model (RIM) provides an abstract model for representing health related information. The RIM comprises classes which include sets of attributes and which are associated with one another by relationships. Details of the RIM can be found in the Foundation section of the HL7 Version 3 Publication (see RIM).
Documentation of RIM classes, attributes and relationships and the vocabulary domains specified for particular coded attributes
provide standard ways to represent particular kinds of information. The RIM specifies internal vocabularies for some structurally
essential coded attributes but also supports use of external terminologies to express more detailed information.
SNOMED CT is one of the external terminologies that may be used in HL7 communications.
The RIM is an abstract model and leaves many degrees of freedom with regard to representing a specific item of clinical information. The HL7 Clinical Statement project is developing and maintaining a more refined model for representing discrete instances of clinical information and the context within which they are recorded.
Should we rethink whether we want to tie the Terminfo guidance so extensively to the Clinical Statement model (formerly pattern)? It may still be appropriate to do so, but with the change from pattern to model I think it's a little unclear exactly what the role of CS is or will be going forward (especially as we begin to possibly move toward FHIR). So to tie Terminfo too tightly to CS may be unwise. RH
The HL7 Clinical Statement model is a refinement of the RIM, which provides a consistent structural approach to representation of clinical information across a range of different domains. However, neither the RIM nor the Clinical Statement model place any limits on the level of clinical detail that may be expressed in a structured form. At the least structured extreme, an HL7 Clinical Document Architecture (CDA) document may express an entire encounter as text with presentational markup, without any coded clinical information. An intermediate level of structure might be applied when communicating a clinical summary with each diagnosis and operative procedure represented as a separate coded statement. Requirements for more comprehensive communication of electronic health records can be met by using the Clinical Statement model to fully structure and encode each individual finding and/or each step in a procedure.
The Clinical Statement model is the common foundation for the CDA Entries in HL7 Clinical Document Architecture release
2 and for the clinical information content of HL7 Care Provision messages. Details of the Clinical Statement pattern can be
found in the Common Domains section of the HL7 Version 3 Publication (see clinical statements).
Even within the constraints of the Clinical Statement pattern, similar clinical information can be represented in different
ways. One key variable is the nature of the code system chosen to represent the primary semantics of each statement. The other
key variable is the way in which overlaps and gaps between the expressiveness of the information model (clinical statement)
and the chosen terminology are dealt with.
The scope of clinical information is very broad and this, together with the need to express similar concepts at different levels of detail (granularity), results in a requirement to support a huge number concepts and to recognize the relationships between them.
Several candidate terminologies have been identified at national and international levels. HL7 does not endorse or recommend
a particular clinical terminology. However, HL7 is seeking to address the issues raised by combining particular widely-used
terminologies with HL7 standards.
Add LOINC and V2, relax CS reference.
This guide focuses on the issues posed by using SNOMED Clinical Terms® (SNOMED CT) with HL7 clinical statements. It includes specific advice on how to specify communications that use SNOMED CT to provide the primary source of clinical meaning in each clinical statement.
Although this guide is specifically concerned with SNOMED CT, it is likely that similar issues will be encountered when considering
the use of other code systems within HL7 clinical statements. Therefore some of the advice related to general approaches to
gaps and overlaps is more widely applicable.
SNOMED CT is a clinical terminology which covers a broad scope of clinical concepts to a considerable level of detail. It is one of the external terminologies that can and will be used in HL7 Version 3 communications. SNOMED CT has various features that add flexibility to the range and detail of meanings that can be represented. These features summarized below are documented in detail in documents listed in SNOMED CT Reference materials.
Each SNOMED CT concept is defined by relationships to one or more other concepts. The following example illustrates the type of logical definitions that are distributed as part of SNOMED CT.
[ 71620000 | fracture of femur ] is fully defined as...
116680003 | is a | = 46866001 | fracture of lower limb | ,
116680003 | is a | = 7523003 | injury of thigh | ,
116676008 | associated morphology | = 72704001 | fracture | ,
363698007 | finding site | = 71341001 | bone structure of femur |
Note: This example and many of the other illustrations in this document are expressed using the SNOMED CT compositional grammar. Where relevant this document also uses proposed extensions to this grammar to represent constraints on use of SNOMED CT concepts and expressions. The extended grammar is explained in SNOMED CT Compositional Grammar - extended, together with references to the SNOMED CT source material.
When a SNOMED CT concept is used to record an instance of information, it can be refined in accordance with the SNOMED CT Concept Model to represent more precise meanings.
- For example, it might be necessary to record a "compression fracture of the neck of the femur".
- SNOMED CT does not contain a concept identifier for this specific type of fracture at this precise location. However, the post-coordination rules allow refinement of the "finding site" and "associated morphology" attributes in the definition of the concept "fracture of femur" (see above example).
- Therefore the required information can be recorded by refining the concept "fracture of femur" with the site "neck of femur" and the morphology "compression fracture".
The result of a refinement is referred to as a post-coordinated expression. A post-coordinated expression conforms to an abstract logical model specified the "SNOMED CT Guide to Abstract Logical Models and Representational Forms" (see SNOMED CT Reference materials). The same guide also specifies a compositional grammar for representing these expressions in a way that is both human-readable and computer-processable (see also SNOMED CT Compositional Grammar - extended). The example below uses this grammar to represent a post-coordinated expression for "compression fracture of neck of femur".
71620000|fracture of femur|: 116676008|associated morphology|=21947006|compression fracture| ,363698007|finding site|=29627003|structure of neck of femur|
The composition grammar illustrated above is only one of the possible representational forms for a post-coordinated expression. These expressions can also be accommodated within the HL7 Concept Descriptor (CD) data type which may be applied to various coded attributes in HL7 specification. For example, the SNOMED CT expression indicating a "compression fracture of neck of femur" can be represented as shown in the following example:[[]]
<code code="71620000|fracture of femur|:116676008|associated morphology|=21947006|compression fracture|,363698007|finding site|=29627003|structure of neck of femur|"
codeSystem="2.16.840.1.113883.6.96"/>
SNOMED CT "clinical finding" and "procedure" concepts have assumed (default) contexts which apply if they are used in a record without an explicit context.
- The default context for a [ <<404684003 | clinical finding ] is that the finding is asserted to be present in the person who is the subject of the record at the current time (or at a specified time).
- E.g. When the concept [ 233604007 | pneumonia ] is used in a clinical record it is assumed to mean that pneumonia was found to be present in the subject of the record either at an explicitly stated effective time or at the current time when the statement was made.
- The default context for a "procedure" is that the procedure is asserted to have been done to the person who is the subject of the record, at the current time (or at a specified time).
- E.g. When the concept [ 80146002 | appendectomy ] is used in a clinical record it is assumed to mean that an appendectomy was done on the subject of the record either at an explicitly stated effective time or at the current time when the statement was made.
The default context for a [ <<404684003 | clinical finding ] can be overridden by an explicit representation of context. Alternative contexts include:
- Finding contexts such as: present, absent, unknown, goal, risk, etc.
- Subject relationship contexts such as: family member, mother, father, sibling, contact, etc.
- Temporal contexts such as: past, current, recent, etc.
The default context for a [ <<71388002 | procedure ] can be overridden by an explicit representation of context. Alternative contexts include:
- Procedure contexts such as: requested, planned, in progress, done, not done, not to be done, etc.
- Subject relationship contexts: as above for findings
- Temporal contexts: as above for findings.
Explicit context may be represented either in a pre-coordinated form using a concept that is a subtypes of [ <<243796009 | situation with explicit context ] or by using a post-coordinated expression.
- The following concepts provide examples of pre-coordinated concepts that include explicit context:
- [ 297243001 | family history of pernicious anemia ]
- [ 160274005 | no family history diabetes ]
- [ 399211009 | past history of myocardial infarction ]
- [ 168748001 | mammography requested ]
- [ 165017002 | lung function testing not done ]
- The following expressions illustrate ways in which in post-coordination can be applied to represent explicit context:
- [ 281666001 | family history of disorder | : 246090004 | associated finding | = 84027009 | pernicious anemia ]
- [ 417662000 | past history of clinical finding | :246090004 | associated finding | = 22298006 | myocardial infarction ]
- [ 413350009 | finding with explicit context | : 246090004 | associated finding | = 282144007 | able to walk | , 408729009 | finding context | = 410518001 | goal ]
SNOMED CT expressions can be compared by applying "normal form" transformations that make use of logical concept definitions. These transformations generate the same normal form when applied to two expressions that logically have the same meaning.
- When the transformation rules are applied to either of the following two expressions:
- [ 297243001 | family history of pernicious anemia ]
- [ 281666001 | family history of disorder | : 246090004 | associated finding | = 84027009 | pernicious anemia ]
- the following normal form is generated
- 243796009 | situation with explicit context | :
{246090004 | associated finding | = 84027009 | pernicious anemia | :
,408729009 | finding context | = 410515003 | known present | ,
408731000 | temporal context | = 410512000 | current or specified | ,
408732007 | subject relationship context | = 303071001 | person in the family | }
- 243796009 | situation with explicit context | :
The expressivity of SNOMED CT is one of its strengths. However this also leads to cases where overlaps may occur with semantics that may also be represented by an information model such as the HL7 RIM. For example:
- a single SNOMED CT coded expression can represent a meaning that the HL7 RIM could also represent using a combination of several coded attributes or related classes;
- HL7 RIM semantics may modify the default assumptions about the meaning of a SNOMED expression;
- HL7 RIM semantics may contradict the meaning expressed by a SNOMED CT expression.
There is a requirement for clear rules and guidance on these overlaps to minimize the risk that alternative representational forms, may lead to duplication, ambiguity and erroneous interpretation.
The guide identifies gaps between these models and areas in which they overlap. It provides coherent guidance on how these gaps can be bridged and the overlaps managed to meet the common goal of semantic interoperability.
The guide identifies options for use of SNOMED CT concepts, in both pre and post-coordinated forms in various attributes of
HL7 RIM classes. The primary focus is on the RIM class clones used in the HL7 Clinical Statement pattern. However, the general
principles of the advice are also applicable to many RIM class clones used in constrained information models that form part
of other HL7 specifications and standards.
In some situations, the features of HL7 Version 3 and SNOMED CT dictate a single way to utilize these two models together.
Where this is true, the guide contains a single recommended approach which is normative, based on referenced pre-existing
standards.
In other situations, there are several possible ways to combine HL7 and SNOMED CT to resolve a gap or overlap. In these cases,
the advantages and disadvantages of each option are evaluated. The next section explains the criteria used in this evaluation.
