Findings related to developing implementation specifications for the use of SNOMED Clinical Terms (SNOMED CT) in both HL7 and openEHR information models are summarized and compared. Common themes from this work, including overlaps between the expressivity of structure and terminology, are identified and discussed. Distinctions are made between aspects of meaning that are most readily represented by distinct structures, others where terminology offers greater flexibility and a 'gray-area' in which the relative merits are more balanced. Focusing on particular stages in the clinical information life cycle may suggest different points of balance and may lead to different approaches to integration. However, greater consistency is essential if clinical information is to be used effectively in electronic record systems. Consensus guidance documents of the type developed by the work described are only a first step. Mutually aware evolutionary refinement of structural and terminology standards is suggested as an enhancement to independent development.
The last few years have seen the emergence of SNOMED Clinical Terms®1 as the leading candidate for a controlled clinical terminology suitable for use in electronic health records2. In the same period, two structural information models have been advanced as standards for representing clinical information. The HL7 Reference Information Model has been used as the basis for a standard model of Clinical Statements3 which is used in message specifications and in the HL7 Clinical Document Architecture, Release 2 (CDA)4. Meanwhile, the European standard for Electronic Health Records (EN13606) has been utilized by the openEHR Foundation5 as a basis for developing a range of highly-constrained clinical statement and record composition models (called archetypes and templates).
These developments have been followed closely as part of the development of national specifications for capture and appropriate sharing of clinical information in the National Health Service (NHS) in England. NHS Connecting for Health (NHS CFH) chose SNOMED CT as the common clinical terminology to be used by all computers in the NHS in England. It also chose to utilize other relevant standards, including HL7 Version 3 for communications. More recently, openEHR-based archetypes and templates have been used to assist the specification of clinical data capture in regional NHS health record application projects. This required us to consider how SNOMED CT should be used with a combination of openEHR data models and existing HL7 Version 3 based models, as part of coherent ‘end to end’ system design specifications.
This paper draws together some of the findings of this work. It suggests general principles that may have wider applicability to when integrating terminologies with standard structural information models.
In 2004 it became apparent that there was widespread interest in the use of SNOMED CT in the HL7 community. The majority of the interest focused on how to integrate SNOMED CT with the emerging HL7 Version 3 standard. Following an initial meeting hosted by NASA, the HL7 Vocabulary Technical Committee launched the TermInfo Project to address this. The project was also supported by SNOMED International through an Associate Charter Agreement with the HL7 Board. The project has discussed a wide range of issues and prepared detailed guidance. After several ballot cycles, involving formal review and evaluation, the Guide to Use of SNOMED CT in HL7 Version 36 was accepted as a 'Draft Standard for Trial Use' in September 2007.
During 2007, activities in the UK placed greater emphasis on the engagement of clinical experts in specifying content requirements for electronic health records. To facilitate this, the NHS in England has used openEHR archetype and template design tools. The underlying EN13606 architecture, like HL7 V3, is based on a fairly generic reference model. However, the openEHR tools for archetype and template design follow a paradigm that is similar to the design of a structured data collection form. This approach seems more familiar to clinical users than the design of HL7 message models. While this familiarity encourages greater clinical engagement, it does not guarantee consistency and reusability of the captured information. To address this, decisions need to be made about how the captured information is to be represented. This poses questions about the way in which SNOMED CT should be used in association with openEHR archetypes and templates. While the ways in which these questions are addressed may in some cases be specific to the archetype methodology, the underlying issues arising from combining structure and terminology are similar to those encountered by the TermInfo Project.
In addition to the theoretical similarities, there are practical reasons for considering the relationship between this work and the TermInfo Project. Health record content specified using this approach may subsequently be communicated using HL7 messages or documents. Consistent approaches to the integration of terminology with information models are likely to simplify any necessary transformations between these different structures.
The TermInfo Project started by considering specific questions about how particular items of clinical information should be represented. In several cases, more than one option was found and discussion centered on which of these was the 'correct' or 'best' option. In each of these cases, the alternative approaches arose from the ability to express the same meaning, using either a structural element or a facet of the terminology. Therefore, the focus of the work shifted to identification of the areas of overlap between the semantics of HL7 Version 3 information models and SNOMED CT. The HL7 Clinical Statement Pattern3, a common model for clinical information representation within HL7, was used as the practical point of reference for examples. This allowed systematic analysis of alternative solutions to particular types of issue, leading to more consistent resolution. Where overlaps were identified, the options shown in Table 1 were considered.
Depending on which of these options is chosen different rules are required to derive one form from the other or to validate the consistency of dual representation. If both representations mean precisely the same, then either option is equally acceptable. However, in many cases there are differences in the precise nature of the information or level of detail. Ambiguity may also arise when both representations are permitted because the second representation could be interpreted as a restatement or a combinatorial factor (e.g. "a request to request …", "finding … not absent", "family member has family history of ...").
The TermInfo recommendations address the most common overlaps with specific guidance on preferred representations that resolve these ambiguities.
In some cases, neither the information model nor the terminology may offer a way to meet a particular requirement. In theory, a gap is easier to address than an overlap because it simply requires a decision on which component should be extended to meet the requirement. However, requirements for resolution to meet an immediate business need may force the use of an interim measure or work-round. More detailed analysis, by those responsible for the relevant standard component, may lead to a different recommended approach. The end result may be to turn a gap into a future overlap as the work-round is replaced by a more appropriate solution.
To minimize the risk of short-term decisions turning into new legacy issues, gaps were documented and passed to the relevant organization or expert for rapid evaluation. Even where the release cycle for contributing standards makes a short term fix essential, this type of approach reduces the likely impact of future substantive correction.
The NHS work took detailed openEHR templates specified by clinical groups as a starting point. The objective was to identify appropriate ways to bind elements of SNOMED CT to information model nodes in order to represent the intended meaning. There was an urgent business requirement to apply codes to a set of pre-existing templates. However, the need for a more consistent approach was also recognized. To facilitate this, the short-term exercise of coding specific templates was augmented with a more systematic review to identify the types of issues encountered and to propose a more systematic and scalable approach for future NHS development.
This section summarizes some common themes arising from the activities described. Our intention is to highlight some key findings rather than to provide an exhaustive list of all the issues encountered.
A general challenge for using a terminology with an information model is aligning classes and attributes in the model with the expressivity supported by the terminology. There is a requirement to match the semantic granularity of coded expression from the terminology with the slots in the structural model. If the information model provides a single coded attribute to represent a particular concept, this assumes that the terminology contains a code to represent that precise concept.
SNOMED CT allows codes to be post-coordinated to create expressions representing more specific concepts. The model for these post-coordinated expressions is described in 'SNOMED CT Abstract Models and Representational Forms'7 and approved domain and range constraints are published in the 'SNOMED CT Technical Reference Guide'8. SNOMED documents also specify transformation rules that can be applied to normalize expressions to enable computation of equivalence and subsumption9. Post-coordination can only be used if the information model provides a structure that can accommodate this type of representation. Similarly, the rules for normalization have a dependency on any semantics embedded in the surrounding structures.
In most cases, each class in the HL7 Clinical Statement pattern represents a unit of information that can be readily coded using a single SNOMED CT expression. Furthermore, the HL7 coded data types support post-coordination. Thus the level of coding granularity was relatively easy to align with the classes in the model. Some HL7 classes also contain additional coded attributes which, while necessary when using other code systems, duplicate information present in a single SNOMED CT expression. Most of these attributes are optional and can be refined out of specific models to minimize potential confusion.
In contrast the openEHR related work involved review of specific archetypes and templates. The intention of this work was to assign appropriate terminology bindings to each coded node in the template. Initial review of these identified a wide range of different structural granularities. As a result, the appropriate SNOMED CT expression may depend on the values entered in three or more separate but related nodes in a branch of the template. This presents a significant problem for terminology binding, since, if the individual slots in the template are coded independently, similar types of information may be coded quite differently. More importantly, these different representations would not be amenable to normalization without a clear understanding of the semantic relationships between the separate coded slots. It may be possible to apply more rigorous semantics to the design process to preemptively reduce these variations. However, for the purposes of the current work, the chosen approach was to retrospectively identify the units of clinical meaning that could be appropriately captured by SNOMED CT expressions. The co-dependencies between different nodes in the archetypes and templates were captured and linked to the appropriate SNOMED CT constructs using XPATH.
Alternative representations of contextual information were another common finding from both activities. The SNOMED CT concept model includes attributes that allow representation of various clinical situations such as family history, past history and current findings. The objective of this part of the model is to clearly distinguish between the same finding in difference contexts. For example, to ensure that 'family history or asthma' is subsumed by 'family history of respiratory disorder' but not by 'past medical history of asthma'.
Both HL7 and openEHR provide structural conventions for representing these types of contextual information. Structural options include the use of a document section, a specific entry in a template and references to the subject to whom the information applies.
Each of these approaches has distinct merits. A section-based approach matches the way many clinicians work when capturing and reviewing data. Structures that allow references to specific family members are more flexible for representing genetic information. The SNOMED CT approach allows a single coded expression to unequivocally represent family history.
The key to managing these differences seems to be to allow them to be safely combined by ensuring that the way terminology is bound to the structures facilitate transformation to a common normal form. If a family history section is used, this must be bound to the SNOMED CT representation of family history so that the disorder concepts listed within the section can be reliably transformed into appropriate SNOMED CT expressions for analysis. Similarly, if a structural model is used to represent relationships to specific people, the types of relationship (e.g. parent, brother, sister, etc.) should still be represented using SNOMED CT.
Structural models for representing clinical information may include assumptions about the level of detail captured. For example, some models assume different structures for the detailed story of presenting complaint, a summary of past history and a general review of symptoms affecting body systems. This approach aligns with the way that paper records are written and with the design of data collection forms for specific types of condition or consultation.
In contrast, SNOMED CT provides concepts at different levels of detail that can be used in a range of situations. The structure of the terminology allows more detailed refinement to be added where this is appropriate. This approach assists with retrieval for decision support or analysis, as the way in which the data is recorded is not specific to the way in which it is captured.
It is possible to combine these approaches by binding lists of summary values in a template to relevant concepts in the terminology. However, in both the HL7 and openEHR related work, this raised important questions about the intention behind a chosen data collection paradigm and information model structures that mimic it. These issues, which apply to many types of structured data collection, are seen most clearly in relation to check-lists.
There is a clear consensus that check-lists are a useful or even essential tool for effective data collection. However, in both pieces of work it was evident that there are different views about the representation of the information captured using check-list. These views can be characterized as: a) Representing the information as captured. b) Representing the information independently of the way in which it was captured.
View (a) represents each entry in the list as the name of the check-list item (i.e. either text or a linked code) and a value (e.g. 'true', 'false', 'not known') based on the response given. This approach is concerned with capturing information about the completion of the check-list and also ensuring the reviewer knows how the data was acquired.
View (b) represents the meaning implied by each entry in that same way, as if that information was captured in another way (e.g. by selecting a code from a terminology search). This approach seeks to ensure the information can be used to return reliable answers to questions irrespective of the nature of the user-interface. View (b) can be seen as a representation of what Rector10 describes as the 'model of meaning' while view (a) is a specific 'model of use'.
Strong arguments can be advanced for meeting both sets of requirements. However, the balance between them depends on the rationale for using a check-list, and the value of reusing the captured data.
Further investigation of the use of check-lists identified a range of reasons for specifying requirements using check-lists: x To remind the clinician to ask or consider a question. x To record whether a question was asked or considered. x To allow rapid entry of common significant information without recourse to searches. x To provide an example of the type of information that should be recorded – presuming that other entries can be added as needed. x As a single place to look for and maintain key information – assumes that the check-list may be populated from previously collected data. Even within the same NHS openEHR template, the reasons for using check-lists varied. These differences may influence decisions on terminology binding. Depending on the reason for using a checklist approach, there may also be a requirement to represent view (a) to audit the process of care and/or data collection. Irrespective of the process, if the information is to be reusable for clinical purposes, the consistency offered by view (b) also needs to be supported.
As noted earlier in this paper, there may be differences in semantic granularity between structural and terminological components. These differences mean that in some cases multiple nodes in the structure need to be considered to generate a single SNOMED CT expression. However, this is only one of the types of interdependency noted during this work.
The value applied to one node may constrain the potential range of coded expressions that can be applied to another node.
An example of this is the case where the structural model provides separate attributes for 'disease', 'site', and 'laterality'. Depending on the specified disease the site may either be superfluous (e.g. appendicitis) or essential (e.g. 'fracture') and the relevant of 'laterality' may depend on the selected site. Even in the case of disorders without a fixed site, a postcoordinated expression might contain the site and/or laterality.
Many interdependent constraints may be expressed by reference to the SNOMED CT concept model. However, this depends on the assumption that the specific nodes in the structural model are aligned with the relevant attributes in the concept model.
In other cases, the existence of a preferred or mandatory form or representation in the structural model may indirectly constrain the use of terminology.
The HL7 Pharmacy models represent the action of administering a substance in one class (Act) and the substance administered in another associated class (Entity). Both the nature of the action and the entity can be represented using SNOMED CT concepts. However, SNOMED CT also supports expressions that include the substance administered as a refinement. To avoid conflicts with the models, coded expressions that incorporate the substance may need to be prohibited.
For example, the concepts 'subcutaneous injection' and 'insulin' might be used in the two associated classes but the concept 'subcutaneous injection of insulin' might not be permitted.
Electronic health records offer a range of potential benefits. Many of these depend on being able to consistently process meaningful clinical information within those records. Two distinct threads have developed to address this requirement – a structural thread and a terminology thread.
The structural thread places emphasis on the set of specific items of data that express a particular class of clinical information. In contrast, the terminology thread seeks to provide reusable codes or labels for events or ideas. These two threads have developed and work together in almost all areas in which information is processed. This symbiotic co-existence is apparent at all stages in the life cycle of an item of clinical information - data entry, display, storage, communication and retrieval. Different approaches to the use of structure and terminology have developed in proprietary clinical systems and efforts to develop standards have tended to separate terminological and structural aspects.
Previous work on binding between information models and SNOMED CT reported by Sundvall11 noted the value and limitations of simple equivalence binding between a node and a terminology concept. It emphasized the need for a powerful constraint binding formalism to address these limitations.
Different approaches to representing clinical information often arise as a result of perspectives that are influenced by particular stages in the life-cycle of that information (see figure 1). All three components considered by the work described in this paper have the broad ambition of representing meaningful clinical information. However, each of them has a significantly different perspective. The focus of HL7 Version 3 is on interoperable communication and thus it specifies static and dynamic models related to interaction between discrete applications. SNOMED CT takes a retrieval perspective; by representing subsumption and interrelationships between the different concepts, it enables effective subsequent retrieval for multiple purposes. EN13606 archetypes have a similar role to the classes of the HL7 RIM. However, openEHR archetype and template design, are more directly influenced by the data capture perspective. Each template reviewed walks through the typical process of collecting data during a particular type of clinical encounter. As shown in Figure 1, these perspectives are interdependent. The primary rationale for binding SNOMED CT to structured clinical information is to enable selective retrieval and reuse of information. The process of integrating terminology with structure may also involve some normalization of the structure to address the anticipated retrieval requirements. Structural differences may obscure semantic similarities and binding a code to a field will not necessarily deliver the full potential of the terminological component. For example, a template may structure some items of current and past clinical history in the form of a checklist, some as codes chosen from a picking list, and others as more detailed collections of coded and textual data items. A degree of normalization may be essential to ensure that the record can be used to answer questions such as, 'does the patient have a past clinical history of respiratory problems?'
Both structural and terminological approaches have specific strengths and weaknesses. Those wishing to exploit the strengths of a particular structural or terminological approach may differ in their perception of the appropriate balance between these components. However, there is general agreement that some facets of clinical information are best represented using structure, while others are more effectively expressed using terminology.
Figure 2 summarizes a consensus position agreed in the openEHR related terminology binding project. Different facets of clinical information were identified and assigned to one of five categories indicating whether a terminological or structural approach was recommended and the strength of that recommendation. The two outer categories encompass facets that can only be effectively represented using one of the approaches. Two further categories include facets for which one approach has a clear advantage but the other approach is also possible. Between these is a 'gray area' in which the relative merits of the two approaches are more finely balanced or may depend on a specific use case.
The following principles are suggested as a basis for detailed recommendations on integration between any combination of a terminology and a structural model. These principles are based on those agreed by the HL7 TermInfo Project. They have been revised and extended to take account of more recent practical experience summarized in this paper.
The recommendations must be understandable by implementers who are familiar with the use of the terminology and structural models being integrated. The integration recommendations need not repeat general advice on the underlying components but should not require other pre-existing knowledge.
The recommendations should be tested on members of the intended target audience of implementers to ensure they are interpreted and applied consistently.
The recommendations need not cover all possible use cases but should cover all the most common scenarios encountered in the intended scope of use.
Representations that can be reused consistently in many contexts should be recommended in preference to those that are specific to a particular context.
For example, the representation of a finding should follow a similar pattern whether recorded as a problem, a new diagnosis, an item of past medical history, detailed documentation of presenting complaint or a discharge diagnosis.
If alternative representations are permitted, rules should be specified to unambiguously transform these into a common representation.
Terminology model only Specific concepts:
For example, diseases, symptoms, signs, procedures, drugs, etc.
Semantic relationships between concepts
For example, relationship between 'viral pneumonia', 'lung', 'virus', 'infectious disease'.
Representation of constraints on use of terminology For example, concept model and value-set definition formalism.
Terminology model preferred (structural model deprecated) Constraints on combination of concepts in instances including abstract model of post-coordination and permissible attributes and ranges for refinement of concepts in specified domains: For example, restrictions on 'finding site' refinement of 'appendicitis', conventions on representing laparoscopic variants of a procedure.
Gray area (preference unclear or use case dependent) Representation of contextual information related to instances of clinical situations
For example, family history, presence/absence, certainty, goals, past/current, procedure done/not-done.
Representation of additional constraints on post-coordination of concepts for specific use cases
For example, constraints on terminology use specific to immunization and related adverse reaction reporting. Structural model preferred (terminology model deprecated) Representation of relationships between distinct instances of record entries and other classes
For example, assertions of causal relationships between entries, grouping of entries related by timing, problem or other organizing principles.
Structural model only Attributes with specific data types
For example, dates, times, durations, quantities, text markup.
Identifiable instances of real-world entities
For example, people, organizations, places.
Overall record and/or communication architecture
For example, EHR extract, EHR composition, openEHR reference model, CDA documents, HL7 messages.
Representation of constraints on use of particular classes or attributes in given use cases
For example, formalism for templates applied to constrain openEHR archetypes or HL7 CDA documents.
Figure 2 – Strengths of structure and terminology
Requirements for tooling to transform or validate instances that conform to the recommendations should be computational tractable.
Existing tools and applications, either in their current form or with reasonable enhancements, should be able produce the recommended instances.
Recommendation should not require a combinatorial explosion of pre-coordinated concepts.
For example, the model should not require the creation of the cross product of "Allergic to" and all drugs and substances.
Optionality should be restricted where possible to limit arbitrary variations. Where more than one approach appears to be equally valid based on other criteria, a single approach should be recommended to avoid unnecessary variation.
If one approach has already been successfully implemented and the other has not, the approach that has been implemented should be selected.
If two or more approaches have already been implemented, one should be recognized as the preferred form. Other approaches that are already in use may be permitted but should not be recommended for new implementations. 10. Responsive participating standards The participating structural and terminology standards should provide prompt mechanisms to enable notification and correction of gaps and inconsistencies. These mechanisms should be used rather than local work rounds, to avoid increasing the number alternative representations. Implemented systems and participating standards should be sufficiently agile to allow rapid and reasoned development of effective compositional solutions.
The principles outlined in this paper are only a foundation. Practical implementation requires detailed specific guidelines for integration between SNOMED CT and an information model. The first detailed guide on use of SNOMED CT with HL7 Version 3 is now available as a Draft Standard for Trial Use6. Detailed guidance related to a trial set of openEHR archetypes and templates is under review but has yet to be finalized and more widely published.
An original design goal of SNOMED CT was usability in applications with different information models. Likewise, the standard information models of HL7 Version 3 and EN13606 were designed to enable use of different terminologies. Thus HL7 specifications include coded attributes that need to be bound to specific value sets before implementation. Similarly, openEHR (a development based on EN13606) states5 that its fundamental building blocks (archetypes) are 'terminology neutral' and that a single archetype can be 'bound to more than one terminology'.
This mutual openness between alternative code systems and information models seems an attractive proposition. However, we contend that the extensive overlaps and interdependencies demonstrated by the work described in this paper point to a requirement for closer mutually aware development of information models and terminologies. While tools and guidelines for binding are necessary to address the interface between current information models and terminologies, they are unlikely to be sufficient unless future development of information models and terminologies take due account of the need to work together rather than as independent variables.
The HL7 TermInfo Project was facilitated by Health Level 7 of Ann Arbor, USA. The work described in on binding terminology to openEHR archetypes and templates is related to models under development at NHS Connecting for Health.