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, bvpoppel@hiscom.nl
Ioana Singureanu, ioana@eversolve.com
Mary Ann Juurlink, juurlink@killdara.com
HL7: Conformance User Guide
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.
Page 2
Health Level Seven, HL7 Conformance User Guide © 2000 All rights reserved.
.
HL7 Conformance User Guide
Table of Contents
INTRODUCTION .......................................................................................................................................................4
1.1
DYNAMIC PROFILE DEVELOPMENT ..................................................................................................................5
1.1.1
The Problem...........................................................................................................................................5
1.1.2
A Solution ..............................................................................................................................................5
1.1.3
The Message Profiling Specification template.......................................................................................6
1.1.4
Message Work Bench .............................................................................................................................6
1.2
VALIDATING DTD ..........................................................................................................................................7
1.2.1
Registration of profiles at HL7.org ........................................................................................................7
1.3
CERTIFICATION ...............................................................................................................................................9
1.4
WHY A DYNAMIC PROCESS… .......................................................................................................................... 9
CONFORMANCE METHODOLOGY ...................................................................................................................10
1.5
INTRODUCTION .............................................................................................................................................10
1.6
THE CONCEPT OF PROFILES...........................................................................................................................10
1.7
PROFILES FOR STANDARD CONFORMANCE ...................................................................................................11
1.7.1
ACR/NEMA, DICOM and IHE ............................................................................................................11
1.7.2
Andover Working Group ......................................................................................................................12
1.7.3
e-Commerce, ebXML and BizTalk .......................................................................................................12
1.7.4
Committé Européen de Normalisation (CEN) .....................................................................................12
1.8
CONFORMANCE PROFILE SPECIFICATION ......................................................................................................12
1.9
HIERARCHY OF PROFILES..............................................................................................................................12
1.10 CONFORMANCE STATEMENT ........................................................................................................................14
1.11 PROFILE IDENTIFICATION ..............................................................................................................................14
1.12 CERTIFICATION .............................................................................................................................................15
1.13 PROFILING TOOL ...........................................................................................................................................15
1.14 PROFILE REGISTRATION AND REPOSITORY ...................................................................................................15
VERSION 2.X CONFORMANCE ...........................................................................................................................17
1.15 EVENT INITIATED VERSION 2.X MESSAGES...................................................................................................17
1.15.1 Shareware Tool: Message Workbench ................................................................................................ 17
1.16 CONFORMANT QUERIES V2.4 ........................................................................................................................17
1.17 V2 XML.......................................................................................................................................................18
1.18 OUTSTANDING ISSUES ..................................................................................................................................18
VERSION 3 CONFORMANCE ............................................................................................................................... 19
CLINICAL TEMPLATES ........................................................................................................................................21
6.
DOCUMENT ONTOLOGY .............................................................................................................................22
7.
VOCABULARY.................................................................................................................................................23
8.
CLINICAL DOCUMENT ARCHITECTURE ............................................................................................... 24
TERMINOLOGY ......................................................................................................................................................25
REFERENCES ..........................................................................................................................................................26
Health Level Seven, HL7 Conformance User Guide © 2000. All rights reserved.
Draft White Paper
Page 3
2001-02-07
HL7: Conformance User Guide
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.
Page 4
Health Level Seven, HL7 Conformance User Guide © 2000 All rights reserved.
.
HL7 Conformance User Guide
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
1.1.1
DYNAMIC PROFILE DEVELOPMENT
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:
1.
The Message Profiling Specification template
2.
Message Work Bench (MWB)
Health Level Seven, HL7 Conformance User Guide © 2000. All rights reserved.
Draft White Paper
Page 5
2001-02-07
HL7: Conformance User Guide
3.
Validating DTD
4.
Registration at HL7.org
5.
Certification
1.1.3
The Message Profiling Specification 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:
1.
Use Case model (using UML)
2.
Vocabulary (field semantics, code sets, user-defined value sets)
3.
Static message profile

4.
Dynamic interaction

5.
1.1.4
Message, segment, field, data type
Initiating message, response message
Unique identifier
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
Page 6
Health Level Seven, HL7 Conformance User Guide © 2000 All rights reserved.
.
HL7 Conformance User Guide
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 instance1). 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
1
To create an XML message instance from a profile, refer to the HL7 Informative Document: Using XML
as Supplementary Messaging Syntax for HL7 Version 2.3.1. This document published in 1999 recommends a
specific XML format for HL7 messages. This work has been extended since publication and will be published
as a normative document sometime in 2001 or early 2002.
Health Level Seven, HL7 Conformance User Guide © 2000. All rights reserved.
Draft White Paper
Page 7
2001-02-07
HL7: Conformance User Guide
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.
Page 8
Health Level Seven, HL7 Conformance User Guide © 2000 All rights reserved.
.
HL7 Conformance User Guide
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.
Health Level Seven, HL7 Conformance User Guide © 2000. All rights reserved.
Draft White Paper
Page 9
2001-02-07
HL7: Conformance User Guide
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.
The more technical interoperability aspects of electronic data interchange can be captured quite well with a
compatibility model that assumes one standard that can be expressed in mathematical terms. Examples are the
TCP/IP protocol, the HL7 Minimal Lower Layer Protocol, or the HL7 enhanced acknowledgement protocol.
Interoperability on the non-technical level, the prime domain of HL7, cannot be approached in such a mathematical
way. Currently we specify the interfaces of the applications using natural language and at best referring to code
systems built on natural language also. A more formal methodology such as described in the HL7 Development
Framework will increase precision, but will not, at this point in time, be of mathematical exactness. Therefore it
cannot be expected that HL7 interfaces of applications will have plug-and-play capabilities at present.
Although plug-and-play interoperability cannot be reached, we can decrease interface deployment costs using the
conformance profile approach. The basis of this approach is the acceptance and recognition that each application
interface will be different and they may not be compatible. If each message implementation fully describes its
interpretation of the Standard, it becomes easier to identify incompatibilities and subsequently solve them or
minimize the problems imposed by them. By explicit identification of differences, translations and workarounds are
facilitated.
The process is further facilitated when the profile descriptions are in the same format. The healthcare industry will
achieve common interpretation only by publishing profiles and making them available to all parties. Using these
processes, we anticipate a reduction of the number of interpretations, eventually leading to one profile, the ultimate
promise of plug and play. This evolutionary process is quite opposite from an approach in which the one and only
profile is defined beforehand. We believe that a convergence process is the most feasible way to enhance
compatibility and reduce costs. Healthcare providers will play an important role in this profile convergence process:
they must ask their vendors to describe their profiles in the HL7 agreed-upon format.
Page 10
Health Level Seven, HL7 Conformance User Guide © 2000 All rights reserved.
.
HL7 Conformance User Guide
HL7
Development
Framework
HL7
Compatibility
Framework
HL7 Standard
HL7
Profile Description
Format
Developers
Implement
Standard in
software
Profile
Description –1
Developers
describe
Interpretation
Identification of
Differences
Profile
Description – 2
Enhanced
Compatibility
Interface –1
Interface –2
Figure 1. Enhanced Compatibility by the Concept of Profiles.
Figure 1 summarizes the profile concept for enhancing compatibility. HL7 Standards like V2.X, V3.X, CDA and
CCOW all have conformance criteria. Software developers implement interfaces that comply in their certain way
with the Standard. Guided by the HL7 Conformance User Guide description, templates are developed for HL7
Standards. Examples are the Specification for Message Profile Content, Version 2.1, Vocabulary, or the Conformant
Queries, Version 2.4. Vendors and providers use the Conformance Messaging Specification as a template to
describe their implementation of the HL7 Standard. Providers can get a better feeling about the product by these
uniform descriptions that ensure a certain level of quality. At the start of an interface connection project, the profile
descriptions are used to indicate differences and to propose solutions for missing functionality.
1.7
1.7.1
PROFILES FOR STANDARD CONFORMANCE
ACR/NEMA, DICOM and IHE
In the mid eighties, when PACs was still in a laboratory phase, ACR and NEMA published a standard for
the exchange of image data between modalities including some alphanumeric interchanges with RIS/HIS.
The first version of the ACR/NEMA standard did specify everything into detail, even a 128-pin connector.
This ACR/NEMA standard was not a success but its successor DICOM was. DICOM limited itself to the
application layer only, and perhaps more importantly DICOM introduced conformance statements. Vendors
obliged themselves not only to implement DICOM interfaces in their software, but also to specify to what
extent their interface is compatible with the DICOM standard. DICOM became a success.
PACs became affordable in the mid-nineties. One of the major obstacles became the interfacing with RIS
and HIS. HL7 was widely used in RIS and HIS. The solution came from profiling. In the IHE project a
limited number of HL7 and/or DICOM standards were interpreted (profiled). The vendors of the IHE group
committed themselves to use these IHE identified profiles only. As far as we know, IHE being in its third
year of development year now, is a success.
Health Level Seven, HL7 Conformance User Guide © 2000. All rights reserved.
Draft White Paper
Page 11
2001-02-07
HL7: Conformance User Guide
1.7.2
Andover Working Group
Due to the fast-spreading use of HL7, the market asked for solutions that would enhance compatibility. In the midnineties a number of health care parties started the so-called Andover Working Group (AWG). AWG was aimed
towards out-of-the-box plug-and-play. During the first project phase, in which the technical framework was
developed, the AWG was moving fast. Standardizing the semantics of the interfaces became a cumbersome task. The
objective of AWG was to define one and only one profile; otherwise plug-and-play could not be reached. It became
clear that it was/is not feasible to declare or define just one and only one semantic profile. A major result of the
AWG is evidence that a profiling concept, in which the market will decide which profiles are dominant, is much
better suited than an approach based on the assumption that a perfect standard for semantic level can be defined
beforehand.
1.7.3
e-Commerce, ebXML and BizTalk
Quite recently the loosely coupled paradigm, applied for years in the Health Care domain, has been adopted for
business-to-business interoperability, driven by web technology. Within at least two developments, i.e., ebXML and
BizTalk, message definitions (DTD) as defined by the interface developer are supposed to reside in a repository. The
idea is that the DTD is retrieved from the repository upon receipt of the message and interpreted subsequently. We
expect that the idea of a repository to be powerful; however, we do think that a DTD alone is not sufficient to
describe the semantics needed to interpret the message.
1.7.4
Committé Européen de Normalisation (CEN)
*** Methodology of CEN to be inserted
1.8
CONFORMANCE PROFILE SPECIFICATION
One of the key aspects of profiles is that it should be possible to compare the various profiles easily. This requires a
standard way of documenting profiles. Once profiles are described in the same way they can be exchanged and
compared more easily. Currently, we expect that XML DTD will be the most appropriate specification format. As
XML schemas become more widely used, it should be possible to move to that technology.
Currently, there are a number of profile description templates available for various HL7 Standard concepts and
constructs. One of them is the template for version 2.X messages: “Specification for Message Profiling”
The Conformance SIG intends to specify an XML DTD (and XML scheme as soon as they are available) that states
how a 2.X message profile should be documented. Please note that this DTD does not specify the messages
themselves; instead, this profile-DTD specifies how a particular use of a message has to be specified. (It is metadata
for the metadata).
We encourage other profile defining initiatives to specify schemas as well.
Using a standardized template will be facilitated by a (shareware) profiling tool (Messaging Workbench). Simply
using that tool ensures the correct template.
1.9
HIERARCHY OF PROFILES
A message specification as it is implemented on site can be considered as the most specific profile, called level 3
profile. The message specification in the HL7 standard can be considered as the least specific profile, called level 0
profile. In between two categories can be identified. Firstly, the profile as implemented by the vendor. In many cases
Page 12
Health Level Seven, HL7 Conformance User Guide © 2000 All rights reserved.
.
HL7 Conformance User Guide
the site profile will be similar to the vendor profile, however there are decisions that can be made on site only, e.g.
vocabulary binding and specifics related to the other application. Secondly, a certain profile of the standard that is
agreed upon by a group of interested parties. Examples include community health projects, and regional variances.
Such a group profile will be less specific than a vendor profile, but will better specify those elements defined as
optional by the standard.
HL7 Standard
Level 0 Profile
N
Level 1 Profile
Specificity
Interest
Interest
Group
Group #1
N
Vendor#1#1
Vendor
Implementation
Implementation
Level 2 Profile
N
Site#1#1
Site
Set-up
Set-up
Level 3 Profile
Figure 2. Hierarchy of Profiles
In Figure 2 the concept of the hierarchy of profiles is depicted. On the top appears the Standard specification that we
consider the level 0 profile. At the bottom appears the most specific interpretation of the Standard, the site
implementation specification, or instance of the vendor's configuration possibilities, the level 3 profile.
Only profiles in which optionality has eliminated are considered to be implementable. Profiles that have optional
elements by design, e.g. interest groups, are not aimed towards implementation.
The hierarchy rule is that a profile at a certain level must conform to the level above.
We believe that there is a need for both the vendor-profiles and the interest-group profiles. The distinction could be:
Vendor profile

implementable, no optionality allowed
Interest group profiles

non-implementable, with optionality, constraining the standard to a certain level as it pertains to a whole
group’s needs (TC, SIG, national organization)
Health Level Seven, HL7 Conformance User Guide © 2000. All rights reserved.
Draft White Paper
Page 13
2001-02-07
HL7: Conformance User Guide
1.10 CONFORMANCE STATEMENT
When discussing conformance we need to distinguish between implementable and non-implementable conformance
profiles. An implementable profile can be conformant with its software implementation. Non-implementable and
implementable profiles can be conformant against some other profile, with more optional elements, only. In the
following we elaborate on implementable profiles only.
A Conformance Statement is a declaration of a software vendor that its software complies with one or more
conformance profiles. The vendor, e.g. the profile owner itself declares the conformance and not some third party.
This is analogous with the DICOM practice of conformance statements. The vendor can declare conformance to
various profiles. Moreover the profiles to which the vendor declares conformance need not be of the same
conformance level. Firstly it will declare conformance to its own profile, i.e., it declares that its interface is
conformant to its own specification formulated in an HL7 defined template for profile description. This will enhance
the quality of specification, and hence lower analysis costs at implementation time. Secondly the vendor can declare
conformance to one or more interest groups profiles. Finally the vendor can declare conformance with the Standard
itself.
Message instances will reference the OID of the message profile to which they conform. The profile identifier may
be used by publish/subscribe systems to determine identify the precise message profiles they support.
However, we expect that most profit will come from the development of quality specifications and not from
declaring profile-ids at run-time. Maybe later on tools will be available that associate the proper profile description
for parsing a received message/document at receive/processing-time.
Limitation: We believe that at this point in time it is possible only to describe rather technical aspects of
conformance, e.g., absence or presence of fields. The major problems are, however, in the semantic arena. We can
encourage only that people pay attention to carefully annotate their semantic interpretations. Such interpretations will
appear as implementation notes in the conformance profile specification.
1.11 PROFILE IDENTIFICATION
Once a profile has been described, it should receive a unique identifier. We propose to use OIDs because they can be
globally unique and do allow localization. As pointed out in previous sections, a message/document instance may
conform to one or more profiles. This requires a header field that allows for registration of more than one profile.
The profile identifier will be assigned at the time when the profile is registered with HL7.
HL7 has assigned an OID root to Conformance SIG for Registered Conformance Profiles: 2.16.840.1.113883.9
ASN.1
component
2
16
840
113883
9
Meaning
ISO
Country
USA
HL7
Conformance
Each registered profile will receive a sequential number as follows:
2.16.840.1.113883.9.1
2.16.840.1.113883.9.2
2.16.840.1.113883.9.3
2.16.840.1.113883.9.4 …
Page 14
Health Level Seven, HL7 Conformance User Guide © 2000 All rights reserved.
.
HL7 Conformance User Guide
At runtime, a message will provide the appropriate references to the message profiles it supports and indicate their
message profile identifiers (OID) for verification/validation.
1.12 CERTIFICATION
Certification, or measurement of conformance to a certain profile, will be offered by certification-testing
organisations. We identify a need for certification testing for:
1.
certification of a vendor profile towards the standard
2.
certification of a vendor profile towards an interest group profile
HL7 provides the compatibility and certification framework that can be the basis for contractual agreements and
certification. HL7 will not, however, audit, validate, certify or otherwise enforce compliance. Other organizations,
authorized by HL7, will take on that responsibility. Hence, the task of certification will not be done by HL7 or by
one of the interest groups.
Certification of profiles of interest groups against the HL7 standard is an outstanding issue.
Some standards fit a mathematical description better than others. We believe that within the certification process
these differences should be taken into account. For example: Compliance to the MLLP is much easier to test than
semantic interpretation of the information carried in messages/documents. It is emphasized that the semantic issues
are dominant but at present hardly measurable.
Conformance profile testing of optionality, cardinality, and code domains can be completely automated for
comparing to other profiles by applying the conformance profile tool (Messaging Workbench).
1.13 PROFILING TOOL
Conformance SIG has identified the need for a tool to describe profiles. With such a tool the description of a
particular use can be made, and more importantly this description should be in the format of the above-mentioned
profile-DTD. Providers and groups could ask the vendors to supply interface documentation that is conformant with
this profile-DTD. The Conformance SIG is well aware of the fact that a tool with a broad functionality, including
profile comparison, use of an HL7 database, Z-segments, reverse engineered profiles from message samples, is a key
success factor for the profiling approach.
The Messaging Workbench is a Windows-based profiling tool provided free to all HL7 members. This tool creates
the message profile documentation as an XML document Additionally, the tool allows comparing HL7 specifications
to show differences between confomance profiles, reverse engineer specifications, browse messages, etc.
1.14 PROFILE REGISTRATION AND REPOSITORY
Similar to Microsoft’s BizTalk consortium, HL7 provides its members with a Web tool for registering new profiles
and for browsing registered profiles.
HL7 members may submit their profiles as an XML document following the Conformance Profile DTD published by
the Conformance SIG. Each registered profile receives an OID unique identifier.
In order to support browsing of profiles (profile browser), the HL7 tool provides fields for identifying profiles of
interest: the name of the vendor/group, the profile date, and the message type, etc. Providing such fields can facilitate
the construction of smart “yellow pages”.
Health Level Seven, HL7 Conformance User Guide © 2000. All rights reserved.
Draft White Paper
Page 15
2001-02-07
HL7: Conformance User Guide
Organizations other than HL7 could implement their own repositories. However, we encourage publishing as much
as possible profiles in the HL7 repository publishing as much as possible.
Page 16
Health Level Seven, HL7 Conformance User Guide © 2000 All rights reserved.
.
HL7 Conformance User Guide
3. Version 2.X Conformance
1.15 EVENT INITIATED VERSION 2.X MESSAGES
The Specification for Message Profile Content, Version 2.1 was approved as an HL7 informative document2 in July
2000. This document describes the concept of message profiles for enhancing compatibility. A message profile is a
document that describes a particular use of a standard defined message. However, this document does not elaborate
on levels of conformance or the facilities needed for practical use such as a specification template or a repository.
This HL7 Conformance User Guide covers these issues.
The Conformance SIG will specify an XML DTD (and XML schema as soon as schemas are available) that specifies
how a profile should be documented. Please note that this DTD does not specify the messages themselves; rather,
this profile-DTD specifies how a particular use of a message has to be specified. (It is meta-data for the meta-data).
1.15.1 Shareware Tool: Message Workbench
By the end of 2000 a shareware message profiling tool (aimed also useful for conformant queries) created by the
Veterans Affairs has become available through HL7. It is called: Message Workbench. Organizations can develop
message profiles using this tool. The tool offers an output in an XML format describing the profile. We intend to
include the DTD in (an appendix of) this chapter.
The preferred tool for creating message profiles is the Message Workbench (available for download from the HL7
Conformance SIG page on the HL7 web site).
1.16 CONFORMANT QUERIES V2.4
The profile description template for queries is part of the HL7 standard V2.4 chapter 5.
We expect that most unsolicited update HL7 messages be profiled best by the SIG Conformance Specification for
Message Profiling, Version 2. However queries, and especially input/output parameters and formats can be
described best using the 2.4 conformant queries templates.
2
It passed membership ballot but will receive no further accreditation.
Health Level Seven, HL7 Conformance User Guide © 2000. All rights reserved.
Draft White Paper
Page 17
2001-02-07
HL7: Conformance User Guide
Conformant queries allow for variation in the details of response; e.g. you can ask for four or for six fields using the
same query. This type of optionality is identified as non-structural optionality.
Outstanding Issue:
Is it possible to incorporate event driven messages and conformant queries in the same tool / approach.
Outstanding Issue:
Probably there should be two profile identifier types, namely one for 'dynamic' profile and one for 'static' profile.
Outstanding Issue:
Try to incorporate the description of conformant queries in the tool.
1.17 V2 XML
The current V2 XML specification is an informative document, not a normative part of the Standard. The DTDs
produced are dramatically different from the DTDs of the V3 XML ITS.
The XML SIG, in coordination with CQ, is in the process of drafting a normative ballot for the XML encoding of
2.3, 2.3.1 and 2.4 (and by extension any 2.X after 2.4). As part of this, currently changes in the V2 XML are
explored that allow the style to become closer to the V3 style.
As the V2 XML specification is derived from the HL7 standard database (Oemig) to form the 'vertical bar' format, it
can be expected that the current profile approach can be maintained.
1.18 OUTSTANDING ISSUES
Definition of MSH/Profile-Id field MSH 21 in V2.4 is a string type but it should be defined as an OID (ASN.1
Object Identifier). In V2.X, this would be an HD type, using the HD.2 and HD.3 components.
Page 18
Health Level Seven, HL7 Conformance User Guide © 2000 All rights reserved.
.
HL7 Conformance User Guide
4. Version 3 Conformance
This chapter is completely an outstanding issue.
The Version 3 message development methodology includes a conformance methodology that is very similar as the
conformance methodology described in this document.
The Hierarchical Message Definition (HMD) and the Version 2.x event initiated messages (ADT, ORU, QRY, etc.)
are equivalent. Though HMDs tend to significantly less optionality than Version 2.X message definitions. The
implementable specification of an HMD is a message profile the same way it is defined in the Conformance
Framework.
Field Usage Comparison between HL7 Version 3 and HL7 Version 2 Conformance
Health Level Seven, HL7 Conformance User Guide © 2000. All rights reserved.
Draft White Paper
Page 19
2001-02-07
HL7: Conformance User Guide
V2 Domain
R (required)
V3 Domain
M (mandatory)
Optional (Abstract)
Required (Abstract)
RE (required but may
be empty)
Vendor Required
X (not supported)
Vendor Excluded
X (not supported)
Not permitted
The Conformance SIG expects that the effort involved in creating HL7 V2.x conformance profiles will expedite the
migration from HL7 V2.x to HL7 V3. The main objectives of HL7 V3 are compatibility and certification. Plug-andplay compatibility can only be reached by zero-optionality message profiles. Presently, the first set of HL7 V3
messages will be defined focussing more on the message development process than on optionality reduction.
Moreover, a basic requirement for V3 conformance, application roles, has been postponed to a later phase. As a
result, the first set of HL7 V3 messages may have the same level of optionality as the in HL7 V2.x messages.
However, these first messages will provide the healthcare industry with a means to plan for its migration to HL7 V3.
A major piece of that strategy must include how the data is passed in HL7 V2.x messages. Imagine how much easier
the mundane analysis will be using standardized processes, methods, and tools.
The ultimate closest V2 XML style would be obtained by first converting V2 messages into V3 HMDs. Once such
HMDs have been engineered, the accompanying DTDs can be generated and are by definition in the same style as
V3 DTDs. Basically the accompanying MIM (per message) should be constructed, which has been done in the early
days of RIM development. Once the HMD form of the V2 message has been obtained the V3 methodology and
tooling can be applied. Such an approach could greatly encourage the migration towards V3. Profiling should be
done using the same methodology that has to be developed further for V3.
Remark: the current more abstract RIM implies that during the process of creating the HMD a number of choices
need to be made. Besides, a number of the messages can be derived from the same HMD.
Page 20
Health Level Seven, HL7 Conformance User Guide © 2000 All rights reserved.
.
HL7 Conformance User Guide
5. Clinical Templates
Clinical Templates, Registries and Terminologies, Angelo Rossi-Mori, June 2000.
Templates and Conformance are used almost interchangeably. Template registration can take advantage of te
Registration/Browser tool provided by HL7.
Health Level Seven, HL7 Conformance User Guide © 2000. All rights reserved.
Draft White Paper
Page 21
2001-02-07
HL7: Conformance User Guide
6. Document Ontology
Document Ontology Task Force (DOTF), June 2000
Page 22
Health Level Seven, HL7 Conformance User Guide © 2000 All rights reserved.
.
HL7 Conformance User Guide
7. Vocabulary
Vocabulary TC is developing codes and an important part of this work is registration of code systems in a repository.
These activities too may also be subject conformance profiling.
Health Level Seven, HL7 Conformance User Guide © 2000. All rights reserved.
Draft White Paper
Page 23
2001-02-07
HL7: Conformance User Guide
8. Clinical Document
Architecture
Outstanding Issue: How is conformance documented and verified?
Page 24
Health Level Seven, HL7 Conformance User Guide © 2000 All rights reserved.
.
HL7 Conformance User Guide
9. Terminology
(Subject to further development.)
Conformance or Message Profile
A specification that defines the interpretation by the profile owner
of the standard. A profile indicates a more precise, unambiguous
use of message constructs (segments, fields, data types,
cardinality). In addition, the profile describes semantic
interpretations of the standard, mostly in the form of free text
annotations.
A V2.X event message profile represents a message specification
where “optional” is minimized and repeatable constructs will be
bound by minimum and maximum cardinality specifications.
Profiles may contain Z segments.
Profiles may be developed by vendors to describe their
applications’ interoperability and by healthcare providers to
describe their interoperability needs. Interest groups may define
profiles specific for the interest of some group of cooperating
parties.
Conformance Statement
A document issued by the owner of the profile. It describes
interoperability characteristics along with the profiles that reflect
this interoperability. It can describe conformance with the HL7
standard or conformance with a profile of an interest group.
The conformance statement will reference the message profiles
supported by the application.
Profile id
A unique identifier assigned to a profile. Health Level Seven will
issue profile identifiers for profiles submitted by its members
(vendors, providers, and interest groups).
A profile id will consist of an ASN.1 (American Symbolic
Notation) identifier (OID) which permits issuing locally and at
the same time being globally unique.
Compatibility
Relationship between peer interfaces such that, despite
differences, they can interoperate to some extent.
Each Interface has its own profile and conformance statement.
Despite different conformance statements interfaces may still be
Health Level Seven, HL7 Conformance User Guide © 2000. All rights reserved.
Draft White Paper
Page 25
2001-02-07
HL7: Conformance User Guide
compatible.
It is reasonable to assume that an outbound message profile will
be richer in content than an inbound profile. An application such
as a patient registration system intended to broadcast messages,
will send more information in its messages than any one single
receiver may require. A patient registration system’s profile for
broadcast patient management messages may be simultaneously
compatible with a large number of departmental applications’
profiles.
Consistency
Strongly desired characteristic of all profile specifications
registered with HL7. Consistent documentation of message
profiles will ensure more easily integration of applications.
Additionally, consistency will encourage reuse of certain profiles.
Consistency can be achieved through the availability of a
common tool , which created conformance documents as XML
documents and of a template (in the form of a DTD) which
describes the structure of these documents.
Application role
See Version 3.
Registration
A profile document can be registered with HL7 and be granted a
unique message profile identifier.
Certification
The process by which an application’s conformance statement is
verified against the actual application implementation.
Certification is a very important part of conformance and it will
not be conducted by HL7. Other organizations will provide
certification services.
Verification
The process by which a message/document instance (one
message) is verified against the message profile on which it is
based.
In comparison with certification: validation is more technically
focused, e.g. validating parser. Certification includes semantics.
Certification provides confirmation that an application fully
implements its conformance profiles. Certification services will
be provided by a third-party organization, not by HL7.
Conformance Profile Document
Format
Conformance Profiles are submitted using the
Registration/Browser tool. The Conformance Profile is XML
documents, which follow the XMLDTD specified by the
Conformance SIG.
10. References
Page 26
Health Level Seven, HL7 Conformance User Guide © 2000 All rights reserved.
.
HL7 Conformance User Guide
Andover Working Group (AWG)
Plug and Play Conference, Cambridge, 1999
Integrating the Health Environment (IHE), www.rsna.org
DICOM
Message Profiling Specification – informative document- HL7 Conformance SIG
Messaging Workbench – shareware tool
Profile Registration Tool – HL7
Conformance Profile Documentation DTD
Health Level Seven, HL7 Conformance User Guide © 2000. All rights reserved.
Draft White Paper
Page 27
2001-02-07