HL7 Templates and the Electronic Health Record

Overview

HL7 has had a Templates Special Interest Group for a number of years exploring the opportunities that being able to construct very detailed information structures to express the enormous variety of information required to meet both clinical and administration needs while still being able to share such information among multiple applications. While different modeling strategies are being explored to be able to productively develop tools to author, store in an EHR system, send in a message, refine a Clinical Document and perform automated inferencing, the common standards interest is to be able to express the semantics of the information in a way that retains its integrity as the information moves for one use to another.

At the July HL7 Interim Meeting in Indianapolis a number of individuals got together to determine the current state of expressing Templates in a common way. These individuals representedprojects focusing on different types and uses for HL7 Templates to further the objectives of Electronic Health Record (EHR) initiatives and are collaborating on the use of HL7 Templates for semantic interoperability. These Templates will meet the health community’s immediate needs for:

  • Continuity of Care Record (CCR) using Clinical Document Architecture (CDA)
  • Specifications for Referral and Consult Reports based on the CDA
  • Order Sets representing common groupings of orders to support clinical workflow and decision support
  • Common Terminology Services and HL7 Terminology editing
  • Using
  • Conformance criteria for the HL7 EHR-S Functional Model DSTU
  • Certification that Electronic Health Record Systems (EHR-S) can share clinical data.

HL7 Developers and health informatists from:

  • Mayo Clinic LexGrid Project
  • May Clinic Project to align OWL and ADL
  • Intermountain Health Care Medical Informatics interest in Clinical Decision Support and ongoing terminology management
  • The Canadian Vancouver Island Health Authority eMS(Electronic Medical Summary) project
  • The ASTM/HL7 CCR CDA project

met during the HL7 Indianapolis Interim meeting during the week of July 12 to discuss their various approachesto explorethe requirement for adding additional purpose specific constraints to existing HL7 V3 specifications. HL7 methodology supports the concept of Templates expressed as constraints on balloted RIM derived Model Information Format (MIF) expressed static models. HL7 Common Terminology Services (CTS) also have a role to play to ensure semantic interoperability.

In addition, they mapped a future strategy for enhancing current tooling to express additional constraints essential for more the complex EHR-S functionalities that require co-dependencies and logical functions not expressible directly in static models. The group agreed, however, that manycurrent needs to coordinate multiple EHRs during an episode of care do not require constraints beyond what can be expressed in the model, with binding to appropriate vocabulary domains representing controlled terminology.

Initial current efforts have focused on referral documents that provide pertinent clinical information about a patient to specialists and peers. The EHR documents will conform to the HL7 Clinical Document Architecture (CDA), the same specification that HIPAA Claims Attachment regulations are likely to require, thereby leveraging providers’ IT investments. The documents will be designed in CDA based HL7 Templates that capture semantically interoperable “snapshots” of a patient’s medical record.

The collaboration will share development challenges and best practices, and will map their capabilities to the HL7 EHR-S DSTU functions. For example, the DSTU requires support for Common Terminology Services, support for problem lists such the CCR, and interoperable technologies, such as CDA. Since electronic referral documents are critical for the Ambulatory Care Setting, the projects’ findings will illustrate some of the minimum functionalities required for structured documents required by Ambulatory EHR-S. The goal is to contribute to a standards profile that could form the basis for Ambulatory EHR-S conformance claims.

Diagram depicts current and critical path requirements in order of difficulty, not priority. These requirements could be developed concurrently

Templates Development: What We Have and What We Need

1.HL7 Models = RIM Derived MIF Expressed Models constrained by OCL

Templates and Archetypes = Types of HL7 Constrained Static Models

  • Templates and Archetypes share many structural characteristics when expressed as HL7 Models, differing primarily on the intent that Archetypes represent recognized clinical knowledge at its most specific level and Templates represent a more flexible constraining capability applicable to documents or messages as a whole, or in part.
  • HL7 CDA V2 will likely be balloted as an ANSI standard early 2005. Templates formalism is under development. Both efforts need focused resources in order to expedite their approval as standards. This is critical for vendor commitment to product development.
  • Improved HL7 V3 Tooling is critical for developers and implementers.
  • HL7 has adopted the premise that OCL be used as thedesign time constraint expression language. Efforts are underway to demonstrate that OCL that can be transformed to appropriate, alternate constraint languages such as OWL, Gello (similar to OCL), ADL, VB, C etc. for other purposes.
  • Current V3 tooling does not support OCL validation and non-structural constraints must be hand coded. Current tooling allows the use of OCL or any other constraint language. However, it doesn’t allow any validation or confirmation that the OCL is structurally valid.
  • Current V3 tooling is available for implementation and for validation against balloted CDA structures. Description and range must be human readable at design time. In the future, we will be able to enforce additional constraints at design time with MIF and OCL authoring tools.
  • CDA documents should be derived from underlying domain models (D-MIMs) from the HL7 committees responsible for that business area (e.g. referrals = Patient Care; drug profiles = Pharmacy; etc.)
  • Fortunately, the percentage of non-structural constraints is small and hand coding is practical for templates used for basic document generation. (Based on experience in the UK and Intermountain Health Care, the group estimates that the v.3 UML constraint process covers 95% of constraints.)
  • In future, more complex Templates will require automated OCL authoring tools. However, development of automated OCL authoring tools should proceed only after the basic Template requirements have been addressed.

Tool Category / Tool Description / Tool Use
v.3 Development Tools:
  • RMIM Designer
  • Rose Tree
  • Schema Generator
/
  • Visual modeling tool for designing RIM based models using structural and non-structural constraints
  • Repository for RIM and RIM derived models
  • Generates schema used to validate message/document instances
/ Design Time: Schema Design
DMSP MIF Enhancements
/ Speeds Refinement Process with notation about when a design element is final and can not be further refined / Design Time: Distribute Constraints
Charlie McCay’s DeBug Tool / RSXML test: VB shell that validates message instance against a list of schema validaters (e.g. WC3) and collects errors in output / Run Time: Debug

2) HL7 CTS Manages the terminology selection process for “safe templating” by ensuring congruent vocabulary semantics

  • Design time support of terminology services ensures semantic interoperability a priori
  • Independently designed templates must use semantically interoperable terminologies
  • Templates with different business purposes, such as financial or public health templates that input or output data from clinical templates, will be semantically interoperable
  • Requires “vocabulary aware” validation tools at design time
  • Requires Run time support as well

3) Problems and Solutions

Problem / Solution / Action Plan
Immediate action: Demonstrate CDA support of templates for EHR referral documents / Develop CCR CDA that supports Template extension for clinical information. Current v.3 tooling and methodology supports this in part (in theory), but has not been tested with CCR or CDA. / Seek funding to assist in the CCR/CDA project under the HL7/ASTM MOU
Need an agreement on and automated way of enforcing semantic alignment between domain models used for messaging and content sent using CDA. / Pursue ‘XML-Forms’ like proposal originated at January HL7 WG meeting. Enhance methodology to support documents derived from two D-MIMs (CDA and ‘semantic’ technical committee). / Build proof-of-concept document instance showing what an instance derived from two domain models would look like. Fast-track tooling changes to allow validation of such models.
Near-term need to create and use, design and validate templates from existing balloted CDA using “hand coded” constraints / Current v.3 tooling and methodology supports this. Demonstrate use in UK NHSIA DMSP (Disease Management Systems Program) project and Canadian referral document project / Use Charlie’s Strategy discussed in Section #. Seek funding for Charlie’s proposal
Vocabulary Congruence required to ensure that independently authored Templates are interoperable / Common Terminology Services available at Design Time / Seek funding to develop Design Time “Vocabulary Aware” validation tools
Validates semantic interoperability of Templates / Common Terminology Services available at Run Time / Seek funding to develop Run Time “Vocabulary and Template[1] Aware” validation tools
Need to ballot Template formalism, CCR Template and CDA Release 2 / Bring proposals through HL7 ballot process / Seek funding to expedite Template ballot and CCR as an implementation
Once basic templates are established, use OCL instead of human readable/coded constraint language fro what can’t be expressed using RIM structural and vocabulary constraints / Develop a user friendly OCL authoring tool that can be validated as producing proper UML output / Seek funding to develop OCL authoring tools
Harmonization of operational constraint languages in and out of OCL / Develop implementation time specifications for mapping OCL to operational constraint languages [OWL, Gello, ADL] / Seek funding to develop Implementation Time OCL mapping to operational constraint languages

4) Vocabulary[2]

Problem

Templates are constraints on RIM derived artifacts. These constraints can be of a number of different types including structural constraints on the artifact, numeric value constraints, co-occurrence constraints, and terminology constraints on coded values. Following HL7 methodology for deriving artifacts in the RIM, coded values in a derived type may not have a broader range of possible values than what was allowed by the parent type. The current tooling allows for some binding of terminology to RIM artifacts, but it is not connected to live terminology services to assist in the proper creation and enforcement of appropriate terminology subsets.

Solution

A solution to this problem is to provide a mechanism to assist in the binding of vocabulary domains to RIM artifacts during the process of artifact derivation. Since this binding follows the same rules at all levels of artifact derivation, the mechanism should not be specific to the creation of templates, but should be the same as what is used when creating other artifacts such as RMIMs or HMDs. (This should also hold true for the mechanisms used in applying other types of constraints.)[3][LRM1]

In addition, when attempting to validate templates in a run-time environment, a complimentary mechanism could validate that instances of coded values are valid for a given template. This would be just one aspect of a run-time template validation mechanism and would need to be well integrated with other aspects of template validation. For example, the constraints defining a template may be such that a particular coded value is appropriate only if some other condition is met.

Tooling

HL7’s Common Terminology Services (CTS) provide a robust mechanism for interfacing a terminology aware tool with underlying terminology services. A future HL7 modeling tool could use CTS to assist in creating and validating terminology constraints at design-time.

A separate, CTS-enabled, template validation tool could use live terminology services in concert with template definitions to validate template conformance for data instances.

5) MIF expression of template constraints[4]

The current HL7 V3 Message Development Framework provides a way to maintain a set of message designs that are all restrictions from the RIM. This process is made scalable and maintainable by defining a hierarchy of ever more constrained models, from DMIM, through RMIM, HMD and finally to the message type. It is the message type that is used to determine the XML element names that are used to convey the information.

HL7 has recently developed the MIF as an XML structure to represent these model definitions, and the relationship between them. Alongside the development of the MIF, the strict five level hierarchy is being relaxed so that there can be any number of refined models between the RIM and the message type.

Problem: Receivers don’t understand the template

To what extent can this same refinement approach be used to express constraints on an HL7 message type (such as the CDA level 2 document structure) where a receiver of the message may not have access to the template that was used, but does understand the message type?

Solution

The class name and model identifier from the MIF template are conveyed as attributes in the message, which uses XML element names from the message type. Thus the message will be safely processed as a CDA document by systems that ignore the templateId attribute, but may be validated and processed more precisely by systems that take note of it.

Problem: Structures can have multiple parent models

There may be a requirement to collect and send information that conforms to a number of different constraints – for example there may be a generic discharge message that conforms to constraints to suit the specialty (Cancer) requirements and the Hospital / Regionally agreed pro-forma.

Solution

Since the MIF representation allows a model to have multiple parents, a combined template could be generated and referenced in the instance. Alternatively the instance could include references to both templates in the instance. Both solutions would convey the conformance claim to the two separately maintained sets of constraints. The MIF representation of the constraints provides a consistent form that can be used to develop comparison and model maintenance tooling that can be used across both message and template development activities.

Problem: Fully explicit HL7 constrained models are verbose

Particularly, once the constraints are at the level of listing the disease-specific data items to be included in messages, the HL7 model representation (RMIM and HMD) is very verbose, since many attributes and associations are required in the same combinations repeatedly within a single model.

Solution

The proposal is to be able to define some attributes and associations as final in HL7 models, such that these are inherited into any refinement of the classes that contain them, without having to make them explicit in the designs. This has been piloted as an approach within the DMSP project, and demonstrated to be an effective way to reduce the amount of repetition in the specifications. There is further work to be done to provide a good way to present these information-rich representations of the constrained models. However it is expected that this approach will reduce the effort both in developing the specifications, and in implementing them.

Opportunity to Enhance Methodology and Tools with Common Terminology Services

The Protégé authoring environment developed at Stanford over the past 15 years affords the best-of-breed authoring tool for Frame-based classes and their associated attributes. [See ] It has also emerged as the de facto leader for ontology editingusing the WC3 basedOWLlanguage; this is made all the more artful by Stanford's recent integration of a powerful description logic classifier.The entire project suite has been available for the past several years as an open-source community effort. Many organizations including the NCI and some government intelligence agencies continue to support the resource and regarded as the best of its kind. It has stated its intention to migrate toward an Eclipse development environment.

The Mayo development team has persisted with its outline of a standard approach for terminology integration and deployment, manifest in the overarching LexGrid model [seeinformatics.mayo.edu ]Asa component of this effort, we have developed the LexGrid editor in Eclipse, with a strong emphasis on lexical normalization and word-level semantic normalization. Another subset of the LexGrid suite is the common terminologies services (CTS) specification (now a balloted HL7 standard) and its reference implementation. This is been tightly integrated into the LexGrid editor, and we have developed a CTS backend to the Protégé environment. This CTS backend enables Protégé terminology content to be imported from the HL7 terminology space (Protégé as a client)orto act as a server responsive to CTS inquiries from remote applications.Furthermore, we have demonstrated an implementation of Protégéwithin the Eclipse environmentfrom the Stanford source. As an exercise, we have also embedded the entire protégé suite within the LexGrid editor application.