HL7 Conformance User Guide
HL7 Conformance
User Guide
Draft
Conformance SIG
Thursday, June 28, 2001
This document is being presented to interested parties. It is a status report that is periodically published to solicit the involvement of the broadest possible group of participants as this methodology is being put into use. Comments are solicited on all aspects of this Conformance Framework.
This effort is expected to yield an informative balloted standard that is open to all who
· develop healthcare data processing systems
· implement healthcare data processing systems, including consulting on compatibility
· develop message profiles
· do certification testing of message profiles
Within the context of the HL7 Conformance User Guide normative or informative specifications pointed towards compatibility can be developed. As soon as these specifications have been put into production, experience can be gained and can be reflected in a new revision.
Editors: / Bas M. van Poppel,Ioana Singureanu,
Mary Ann Juurlink,
Preface
This document is a first working draft, it has been written with the intention to be reviewed by HL7 Technical Committees and Special Interest Groups developing standard products which, may be subject to conformance verification and certification.
Note that MDF Conformance Chapter (chapter 9) addresses Technical Committee Conformance process. This document will address end-user conformance.
*** indicates that additional information will to be inserted.
The final chapter contains a list of terms. The definition of term needs further participation of a broad audience.
Table of Contents
Introduction 5
1.1 Dynamic profile development 6
1.1.1 The Problem 6
1.1.2 A Solution 6
1.1.3 The Message ProfilingSpecification template 7
1.1.4 Message Work Bench 7
1.2 Validating DTD 8
1.2.1 Registration of profiles at HL7.org 8
1.3 Certification 10
1.4 why a dynamic process… 10
Conformance Methodology 11
1.5 Introduction 11
1.6 The Concept of profiles 11
1.7 Profiles for Standard Conformance 12
1.7.1 ACR/NEMA, DICOM and IHE 12
1.7.2 Andover Working Group 13
1.7.3 e-Commerce, ebXML and BizTalk 13
1.7.4 Committé Européen de Normalisation (CEN) 13
1.8 Conformance Profile Specification 13
1.9 Hierarchy of Profiles 13
1.10 Conformance Statement 15
1.11 Profile Identification 15
1.12 Certification 16
1.13 profiling Tool 16
1.14 Profile REgistration and Repository 16
Version 2.X Conformance 18
1.15 Event Initiated Version 2.X messages 18
1.15.1 Shareware Tool: Message Workbench 18
1.16 Conformant queries V2.4 18
1.17 V2 XML 19
1.18 Outstanding Issues 19
Version 3 Conformance 20
Clinical Templates 22
6. Document Ontology 23
7. Vocabulary 24
8. Clinical Document Architecture 25
Terminology 26
References 28
1. Introduction
Over the past decades HL7 has specified a large number of standards targeted to minimize the efforts for both vendors and users in interfacing applications in health care. These standards are widely used in Health Care across the globe.
Interfacing (Health Care) applications turned out to be a complex task. Currently, most HL7 standards cannot provide plug-and-play compatibility. The main reason is that, at present, we do not have the means to express the semantics of interoperability sufficiently. By explicitly describing the differences in the various interpretations of the standard, it is expected that deployment will be eased, resulting in a further decrease of the costs of interoperability. Besides, because of the increasing number of applications, and the evolution towards component-based development, we believe that measures for increasing compatibility are a prerequisite for the years to come.
As HL7 matures and the healthcare industry gets more experience implementing HL7 messages, conformance profiling becomes more important. Within the HL7 organization today, committees are developing conformance profile mechanisms such as V2.4 conformance queries, submission of vocabularies, clinical templates, and level 2 CDA.
The purpose of this paper is to describe the HL7 Conformance User Guide that can be shared across the entire HL7 organization. At present, many committees are creating diverse mechanisms for handling the implementation issues caused by the presence of optional message constructs and extensions in the HL7 V2.x Standard. The Conformance SIG strongly believes that conformance profiling should be the mechanism used to increase compatibility. This document provides the necessary definitions and facilities for successful application of conformance profiling. While this paper is pointed towards the currently most widespread used HL7 V2.x messages, it can be easily ported to meet the needs of compatibility in other domains like HL7 V3.
It is expected that this HL7 Conformance User Guide, which starts as a first step with explicit and uniform description of each specific interpretation of the Standard, called conformance profile, will have many advantages. Providers will benefit from better specification of interface products, and vendors can show the unique selling point of increased compatibility. In addition, implementation will become easier -less costly- as differences become more visible. An increase in the number of semantic elements, such as use case models, interaction sequence diagrams, and information models, can be expected the coming years. This will greatly ease the discussions between vendors and providers on interoperability. Using internet technology like XML schemas (DTD) for describing profiles will, we expect, greatly accelerate the application of the profiling approach as off-the-shelf tools become available for inspecting and comparing profiles.
The HL7 V2.x messaging standard is highly interpretable leading towards different, incompatible message implementations. Rather than narrowing down the optional elements in the HL7 standard itself (which is historically one of the key elements of the HL7 V3 approach), the profile concept is pointed towards explication of the differences. Well-documented profiles of existing interfaces will identify the differences and thereby diminish the implementation efforts. Besides, well-documented profiles can be re-used by others. Also profiles might be used as a starting point for further harmonization of the Standard.
The HL7 Development Framework is aimed towards development of the HL7 Standard. This HL7 Conformance User Guide is pointed towards deployment of the Standard in practice. Because the characteristics of HDF and HCF are different in nature, and for practical reasons, we propose both frameworks be separate documents.
1.1 Dynamic profile development
1.1.1 The Problem
Essentially the problem is that the current state of HL7 is so complex that potential users are unable to ascertain compliance with HL7 against their specific needs.
To encourage uptake of the standard in the early days, everyone’s requirements were accommodated. In other words all use cases were combined which resulted in a hugely complex master message specification. This makes the interfacing of various systems laborious and costly.
It has also proven near to impossible to measure the compliance of HL7 V2.x interfaces by relying only on the base standard. It provides little more than a starting point for vendor interface “negotiations” and terms like “HL7–like” or “HL7-ish” are frequently used to describe HL7 interfaces. HL7 is a guideline and as a result, there are many possible interpretations. Another major issue is that vendors often claim HL7 compliance without substantive documentation or the even ability to substantiate.
1.1.2 A Solution
Message profiling adds specificity to existing messages and identifies scenarios/Use Cases by providing a template for documenting particular uses of HL7 messages. It indicates precise, unambiguous uses of message constructs (segments, fields, data types) for exchanging information. The message profile is based on the HL7 messaging standard where optionality (not enough specificity for any given implementation) is disallowed and repeatable constructs are bound by maximum cardinality specifications. An example of repeatable constructs is allowing next of kin (NK1) to repeat only 3 times. With consistent and complete message profiles, interfacing partners explicitly understand what data will be passed, the format of the data, and the acknowledgement responsibilities between the sender and receiver.
Message profiles would be developed by vendors to completely describe all aspects of how to interface with their applications and also by healthcare users to describe their interoperability needs. The registration of profiles with HL7 would enable clinical sites to better evaluate the capabilities of various software products, and therefore to make informed purchasing decisions.
A conformance statement or claim is used to describe the overall HL7 interoperability requirements and include a number of conformance profiles along with their OIDs. This claim would provide the basis for certification. The Australian Healthcare Messaging Laboratory is currently doing work in this area and could act as a third party to provide compliance and certification testing services.
The purpose of this discussion it to emphasize the need for a dynamic process to develope conformant, implementable message specifications. The following steps and tools are outlined with URL addresses and the readers are encouraged to obtain the tools and test them in their specific environments:
- The Message ProfilingSpecification template
- Message Work Bench (MWB)
- Validating DTD
- Registration at HL7.org
- Certification
1.1.3 The Message ProfilingSpecification template
The Conformance SIG, building on work carried out by the Andover Working Group (AWG), prepared this document based on the experience of vendors and healthcare providers who have defined and implemented various message profiles. The updated HL7 Version 2.x, November 30, 2000 document can be found at http://www.hl7.org (® Special Interest Group ® Conformance ® documentation).
The purpose of this template is to describe and recommend a specification to facilitate a user defined interpretation of the standard, thereby reducing interface analysis time.
The Message Profile specifies the following:
- Use Case model (using UML)
- Vocabulary (field semantics, code sets, user-defined value sets)
- Static message profile
· Message, segment, field, data type
- Dynamic interaction
· Initiating message, response message
- Unique identifier
1.1.4 Message Work Bench
The Message Work Bench (MWB) automates the development of a HL7 version 2.x conformance profiles. Originally developed by Peter Rontey (US Dept of Veterans Affairs), it supports the Message Profiling Specification as discussed above and provides the following application features:
o Automation of message profiling
o Reverse engineering of existing message profiles
o Reconciliation of message profiles across versions
o Comparison of message profiles – i.e. across vendors
The MWB creates an XML document that represents the message profile. It is this XML document, which will be validated and registered with HL7.
This application can be downloaded directly from http://www.hl7.org (® Special Interest Group ® Conformance ® documentation). In order to support the longevity of the MWB, work is in progress to create an open source group that manages this free tool.
1.2 Validating DTD
In addition to the required minimal HL7 set of fields, a message profile indicates fields required by an application. In validating a message profile an application verifies that a message meets its specific data requirements. In other words, the profile and the application are consistent. This will greatly facilitate the interfacing of different systems.
Message profiles will be validated against the Conformance Profile DTD before it is registered with HL7. At http://www.hl7.org (® Special Interest Group ® Conformance ® documentation) you will find the following files, diagram of document type definition doc, the DTD itself and a parsed example.
Please note the DTD referred to relates to a conformance profile document (i.e. the message specification, not the message instance[1]). It formats a message profile into an XML document for registration. This can be automatically generated by the MWB as an “XML spec” report.
1.2.1 Registration of profiles at HL7.org
For cataloging message profiles HL7 has developed a tool for registering conformance profiles. A conformant message profile is assigned a unique identifier (OID – ASN.1(American Symbolic Notation) Object Identifier) and is then registered. The following XML document, produced by the MWB, is a message profile example that has been registered.
The Profile Registration Tool is a prototype and is still under development. Only test message profiles are currently being registered.
There are varies functions within the registration tool itself. For example the user can define a search criteria to list members who currently use a specific message profile. To test the tool, go to http://www.hl7.org/memonly/conformance/cfsub.cfm. Remember to be logged in as a member. For Canadians go to the HL7 Canada Main Login Page http://hl7canada.cihi.ca/login.asp
What are the benefits in documenting and registering message profiles? For a vendor it describes their applications’ interoperability therefore less negotiation time at integration time. Also Healthcare providers can use it to describe their interoperability needs.
Generally, registration promotes reuse and scalability of messaging. It is not fully “plug and play” but it is moving the standard closer towards integrating applications interfaces more easily. Creating proprietary HL7 messaging seems contradictory, as HL7 is a standard and non-proprietary. Many vendors, institutions, and the international community come together to create a standard on a volunteer basis.
1.3 Certification
The Certification process is the part of conformance, by which an application’s conformance claim is analyzed, tested and verified against the actual application implementation.
A third party certification service, such as the Australian Healthcare Messaging Laboratory (AHML), provides independent assurance that a specified electronic message conforms to the HL7 standard. It also provides healthcare organizations and other stakeholders’ confidence that the software or application message is compliant and brings formal recognition to products and systems. The AHML Message Testing Engine supports the latest releases of various standards, specifically HL7 (V2.1, 2.2, 2.3, 2.3.1, and soon 2.4), UN/EDIFACT X12, and XML-encoded messages.
For more information please see www.ahml.com.au
1.4 why a dynamic process…
The need for a dynamic process in creating conformance profiles in Healthcare are two fold: firstly it’s the nature of the beast, Healthcare requires flexibility in practice and in communicating messages. Secondly HL7, which reflects the Healthcare domain, is broad. The standard HL7 base is not implementable in of itself. In using the HL7 standard as a guideline and marrying it with user requirements, an implementable message specification is created. The benefits of conformance message profiling are: consistent documentation, reuse of specifications, lower cost of integration and finally creating order out of chaos.
2. Conformance Methodology
1.5 Introduction
1.6 The Concept of profiles
A nut and a screw will fit only when the screw thread of the nut matches the thread of the screw exactly. The nut and the screw each have their interfaces: namely, their respective screw threads. Compatibility of nuts and screws is limited to describing the screw threads, which can be done by mathematical parameters. Conformance can then be measured against the mathematical parameters. Moreover vendors can be certified when they match these parameters.