Electronic Health Record Templates



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 represented projects 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 approaches to explore the 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 many current 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.

[pic]

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

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 the design 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: |Visual modeling tool for designing RIM based models using structural |Design Time: Schema |

|RMIM Designer |and non-structural constraints |Design |

|Rose Tree |Repository for RIM and RIM derived models | |

|Schema Generator |Generates schema used to validate message/document instances | |

|DMSP MIF Enhancements |Speeds Refinement Process with notation about when a design element is |Design Time: |

| and can not be further refined |Distribute |

|ex.html | |Constraints |

|Charlie McCay’s DeBug Tool |RSXML test: VB shell that validates message instance against a list of|Run Time: Debug |

| |schema validaters (e.g. WC3) and collects errors in output | |

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 |Develop CCR CDA that supports Template extension for |Seek funding to assist in the CCR/CDA |

|templates for EHR referral documents |clinical information. Current v.3 tooling and |project under the HL7/ASTM MOU |

| |methodology supports this in part (in theory), but | |

| |has not been tested with CCR or CDA. | |

|Need an agreement on and automated way of |Pursue ‘XML-Forms’ like proposal originated at |Build proof-of-concept document instance |

|enforcing semantic alignment between domain |January HL7 WG meeting. Enhance methodology to |showing what an instance derived from two |

|models used for messaging and content sent |support documents derived from two D-MIMs (CDA and |domain models would look like. Fast-track |

|using CDA. |‘semantic’ technical committee). |tooling changes to allow validation of such|

| | |models. |

|Near-term need to create and use, design and |Current v.3 tooling and methodology supports this. |Use Charlie’s Strategy discussed in Section|

|validate templates from existing balloted CDA |Demonstrate use in UK NHSIA DMSP (Disease Management |#. Seek funding for Charlie’s proposal |

|using “hand coded” constraints |Systems Program) project and Canadian referral | |

| |document project | |

|Vocabulary Congruence required to ensure that |Common Terminology Services available at Design Time |Seek funding to develop Design Time |

|independently authored Templates are | |“Vocabulary Aware” validation tools |

|interoperable | | |

|Validates semantic interoperability of |Common Terminology Services available at Run Time |Seek funding to develop Run Time |

|Templates | |“Vocabulary and Template[1] Aware” |

| | |validation tools |

|Need to ballot Template formalism, CCR |Bring proposals through HL7 ballot process |Seek funding to expedite Template ballot |

|Template and CDA Release 2 | |and CCR as an implementation |

|Once basic templates are established, use OCL |Develop a user friendly OCL authoring tool that can |Seek funding to develop OCL authoring tools|

|instead of human readable/coded constraint |be validated as producing proper UML output | |

|language fro what can’t be expressed using RIM| | |

|structural and vocabulary constraints | | |

|Harmonization of operational constraint |Develop implementation time specifications for |Seek funding to develop Implementation Time|

|languages in and out of OCL |mapping OCL to operational constraint languages [OWL,|OCL mapping to operational constraint |

| |Gello, ADL] |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]

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 editing using the WC3 based OWL language; 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 [see informatics.mayo.edu ]  As a 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 environment from the Stanford source.  As an exercise, we have also embedded the entire protégé suite within the LexGrid editor application.

We propose a formal merger of the LexGrid editor functionality into the Protégé suite of services which would result in the best available terminology authoring and editing environment yet developed.  It would synthesize the frame nature of concept classes, avail itself of description logic capabilities where appropriate, and leverage the lexical and semantic normalization features that are part of LexGrid.  Additionally, with a well-integrated CTS backend, the transparency of source format and export would be complete.  The LexGrid suite supports multiple client environments, as well as the major terminology content formats (OWL, Protégé, Apelon DTD, HL7 tables, etc).  While a merged tool would primarily be a terminology authoring environment, it could be configured a customized quite easily to serve the needs of HL7 vocabulary facilitators and table authors.

Additional Thoughts

|Steps for Deriving a CCR Template |

|1 |RIM+MIF gives CDA HMD |

|2 |CDA HMD+XML ITS=CDA document |

|3 |CDA document + CCR MIF = CCR Template |

|4 |CCR Templates+CTS+OCL=runtime validation |

Charlie McCay

Lloyd McKenzie: Decision needs to be made on when CDA is appropriate (we care about the presentation and/or encapsulation characteristics) and when messaging alone is sufficient.

This paper was initiated during the HL7 July 04 Interim meeting for Templates SIG. Members of that group drafted content that is now in the Overview and to contribute, as they are able. Currently, contributing authors are Kathleen Connor (Cochair – HL7 Financial Management Technical Committee), Chris Chute (Mayo), Liora Alschuler (Cochair - HL7 Structured Documents Technical Committee), Alschuler.Spinosa Consulting), Craig Parker (Intermountain Health Care), Lloyd McKenzie (Lloyd McKenzie Consulting) and Charlie McCay (Ramsey Systems, co-chair XML SIG and Implementation TC), and overseen by Jane Curry, MnM TC Co-Chair.

[pic]



-----------------------

[1] Note that rsXMLtest does not currently validate MIF expressed template constraints so there is a task to be done to either create “black-box” template validation tooling, or a transform plus schema approach for validating the structural rules.

[2] Craig Parker contributed this section.

[3] Lloyd McKenzie’s comment has not been resolved with the author of this section yet: Binding is (and must be) independent of the artifacts themselves. This allows the same artifact to be used in multiple realms when the only difference is the terminology binding. Without this approach, the number of artifacts will multiply substantially, with no added value. It also opens the door to the same concept using different code systems within the same domain for different messages.

[4] Charlie McCay contributed this section.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download