Several Health Level Seven Version 3 (V3) Specifications have been approved by the American National Standards Institute (ANSI), giving them normative status as American national standards.

The HL7 Version 3 project "represents a new approach to clinical information exchange. It is built from the ground up around a single object model (Reference Information Model - RIM) and a rigorous UML-based methodology that ties model to messages and finally to the message's expression in XML syntax."

Among the ANSI-approved HL7 documents is the XML Implementation Technology Specification — Data Types, Release 1. It "defines the V3 data types that will be used by all of HL7 V3 and onwards; it also defines the representation of HL7 V3 data types in XML, including the schema necessary to derive XML schemas for HL7 V3 Hierarchical Message Descriptions (HMD)."

Other HL7 specifications approved by ANSI cover UML Implementation Technology (UML Data Types specification that binds the V3 data types to the UML/OCL kernel types to allow for formally correct OCL constraints), Scheduling, Claims and Reimbursements, Reference Information Model (RIM), Shared Messages, and Refinement, Constraint and Localization to Version 3 Messages.

The HL7 Board believes that the use of XML represents a primary value in Version 3. XML's "transparent representation of complex data and its extensibility is creating widespread acceptance throughout the IT industry. Version 3 fully supports the expressive capability of XML. It supports generation of XML schemas with the logical information relationships and element names that directly relate to the HL7 models — and hence to the concepts that analysts and programmers will have to grasp to relate Version 3 messages to their own information systems or to use them in new ways for Web browsing, XML repositories, etc."

The V3 specification is built around subject domains, for each of which it provides storyboard descriptions, trigger events, interaction designs, domain object models derived from the RIM, hierarchical message descriptors (HMDs) and a prose description of each element. Implementation of these domains further depends upon a nonnormative V3 Guide and normative specifications for: data types; the XML implementable technical specifications (ITS) or message wire format; message and control wrappers; and transport protocols."

Health Level Seven (HL7) is an "ANSI-accredited standards developing organization dedicated to providing a comprehensive framework and related standards for the exchange, integration, sharing, and retrieval of electronic health information that supports clinical practice and the management, delivery and evaluation of health services. HL7's more than 2,000 members represent over 500 corporate members, including 90 percent of the largest information systems vendors serving healthcare."

Bibliographic Information for Implementation Technology Specifications: XML and UML

• XML Implementation Technology Specification — Data Types. Edited by Gunther Schadow (Regenstrief Institute for Health Care), Paul Vincent Biron (Kaiser Permanente), Grahame Grieve (Kestral Computing P/L), and Doug Pratt (Siemens Medical Solutions, Health Services Co). HL7 Version 3 Standard.

  "Data types are the basic building blocks used to construct messages, computerized patient record documents, business objects and their transactions. Data types define the meaning of any given field's value. Without knowing a field's data type, it is impossible to interpret the field's value.

  Representation of Data Values. On an abstract layer, independent from representation, data types define properties of values. When values are represented, some of their properties are directly represented as atomic literal forms or as data structures. At that point we call those properties 'components'. On the representation layer we can also distinguish simple data types, represented as atomic literal forms, from complex ones, represented as structures with components. For the implementor, it is important to realize that data types have more properties than shown as components, and that it only depends on the implementation technology and ITS specification what data types are simple or complex and which of their properties are represented as 'components' and which are inferred from those components.

  This specification defines standard representations for data values in XML only. Other ITS, and programming environments may choose different representations and data structures, all of which must be consistent with the Data Types Abstract Specification.

  This standard specifies the XML representation for the HL7 data types. The XML representation is described in several different ways: Narrative; Template; Schema; XPath Predicate. The schema representations are provided for convenience, as the XML schema is a compact and specific way to describe the XML representation. However the schema is not in itself a normative part of this specification. While HL7 publishes schema for the HL7 data types, other schema could be proposed that describes the same XML representation, and these schemas are no less valid, though they may differ in their usefulness for a given task. It is the XML representation of the data type that is normative..."

• XML Implementable Technology Specification for V3 Structures. Edited by Charles McCay (Ramsey Systems Ltd, Co-Chair), Dale Nelson (Zed-Logic Informatics, LLC), Kai Heitmann, Paul Biron (Kaiser Permanente), and Paul Knapp (Co-Chair).

  "The objective of this document is to present an Implementable Technology Specification (ITS) for the encoding rules for HL7 Version 3 messages based on the Extensible Markup Language XML (XML).

  Several XML encoding methods could serve as a messaging syntax for HL7 V3 messages. This document represents the method that is recommended by HL7, describing the underlying rules and principles. The corresponding data type descriptions necessary for this specification are described in the Datatypes XML ITS.

  This document describes how HL7 V3 compliant messages can be expressed using XML. It describes how the definition of the set of valid XML instance documents is derived from a specific HL7 Message Type. It covers ISO levels 5 and 6. Those familiar with V2 might call these the 'XML encoding rules' for HL7 Version 3 messages..."

• UML Implementation Technology Specification — Data Types. Edited by Grahame Grieve (Kestral Computing Pty. Ltd) and Gunther Schadow (Regenstrief Institute for Health Care). HL7 Version 3 Standard.

  "The Abstract Data Types specification defines the semantics of the HL7 Data Types, which are the foundation of all HL7 Version 3 artifacts, including the Reference Information Model (RIM), Version 3 messaging artifacts, and the Clinical Document Architecture (CDA). The Abstract Data Types specification includes a Unified Modeling Language (UML) diagram that presents the semantic declarations of these data types in a standard UML fashion.

  This UML ITS implements the semantics of the Abstract Data Types specification using UML in such a way that HL7 data types are mapped into the core UML and OCL kernel data types where such mappings are appropriate. In addition, this representation uses only established object-orientated formalisms. Since this specification shows how to implement the HL7 data types using the UML core data types and methodology, this specification is an ITS for the data types in UML. This specification is based on the UML 2 standard."

XML in the New HL7 V3 Standard

"Healthcare costs evermore dominate national economies, and Draconian measures to control cost have hampered provider effectiveness and impacted citizen satisfaction and safety. Information Technology (IT) has helped, and is on the verge of being able to help much more. HL7 Version 3 will be a key part of the contribution of IT to healthcare's reaching new levels of (1) effective and cost-efficient patient care decisions, (2) safety and cost savings that come from 'doing it right,' in the sense of preventing avoidable errors, and (3) the aggregation of health information for evidence-based medicine and data-based policy. Many general IT advances create the foundation for this new capability [including] the maturing of XML and related standards to provide a means for easy-to-program, highly extensible, robust exchange of information among information systems...

The most intractable barrier to their use in healthcare has been the lack of standards for exchanging fine-grained, highly heterogeneous, structured clinical data among information systems created by different entities using different technologies. Since its inception in 1987, HL7 Version 2 has enabled information exchange among systems created by different entities. Indeed, Version 2 is so widely used that it will not soon go away and the Board is committed to continuing to evolve it as long as there is a clear need. However, where users have used Version 2 for fine-grained, structured clinical data, they have accomplished it through substantial investments in bilateral negotiations adapting it to establish specifications for representing fine-grained, clinical knowledge. Efforts to aggregate on a larger scale, for research or public health have had the same issue.

The strength of Version 3 messaging is precisely enabling the exchange of fine-grained data without the original research and bilateral negotiations that leading-edge organizations have attempted....

Three conceptual models form the basis of Version 3 messages: (1) The Reference Information Model (RIM), which is now an ANSI standard has evolved into a simple abstract framework which addresses the wildly heterogeneous and interlinked nature of clinical data with only six important classes. We have similarly simplified the representation of administrative data. (2) In the Domain Information Model (D-MIM) you will see how the abstract RIM is made specific to define the information elements for a domain or specialty area. (3) In the Refined Message Information Model (R-MIM) you will see how the D-MIM is refined to define the information elements of a family of messages. (4) The vocabulary model provides the tools to deal with previously intractable problems of multiple vocabularies across organizational or national boundaries.

The Hierarchical Message Description is a convenient way to organize a mass of details about the contents of specific messages, providing the most authoritative list of all the constraints and detailed semantic definitions not appropriate in the more abstract representations. Finally, in the Implementable Technology Specification you will see how this information is represented as XML Schemas.

These deliverables are the basis of our belief that the Version 3 Messaging standards will be easily extended over time to incorporate new standards, deal with unanticipated requirements and even address areas of standardization other than application-to-application messages.

We have demonstrated the flexibility of this approach by incorporating an important new technology, XML, in mid project without revising our modeling methodology or content. We believe you will find XML a primary value in Version 3. Its transparent representation of complex data and its extensibility is creating widespread acceptance throughout the IT industry. It is the basis of an expansion in the market of middle-ware vendors providing support for application-to-application integration. While version 2.x has been adapted to XML, Version 3 fully supports the expressive capability of XML. It generates XML schemas with the logical information relationships and element names that directly relate to the HL7 models — and hence to the concepts that analysts and programmers will have to grasp to relate Version 3 messages to their own information systems or to use them in new ways for Web browsing, XML repositories, etc.

As industries have taken up XML they have come to recognize that it is not a substitute for application level semantic standards. HL7 Version 3 provides that missing ingredient, so that healthcare stakeholders can optimally reach the technological benefits of XML..." [adapted from the HL7 Board of Directors' ballot note]

HL7 Standards Man

"Wes Rishel helps guide the influential but sometimes meandering technical-standards group, HL7, as it reaches a crucial juncture...

The Ann Arbor, Mich-based organization, which is blessed by the American National Standards Institute (ANSI), is at a crucial crossroads in its history. It has expanded its mission well beyond its intra-hospital messaging roots to inter-enterprise interoperability. And it has started rolling out elements of its XML-based HL7 Version 3, a collection of protocols developed with an object-oriented, model-driven methodology.

Version 3's solid foundation will yield messaging standards that are clearly defined and easily tested, supporters say. That means that once developers become well-versed in HL7 v.3, system interfaces should be less costly to build and maintain.

Ultimately, champions say, the new standards will greatly improve interoperability between disparate clinical systems. So, for example, once a patient is admitted to a hospital, computer systems can readily pass along information to help that patient get X-rays, lab tests, and other services within that hospital and even beyond its walls...

Although adoption of the new version will take time and money as 2.x interfaces are replaced and programmers retrained, top hospital technologists, like John Halamka, believe it's time for HL7 leaders to press the Version 3 pedal to the metal. Halamka, the CIO at CareGroup Healthcare System, an operator of six Boston-area hospitals, and also CIO at Harvard Medical School, is adopting Version 3 because it supports his hospitals' efforts to build Web services and XML-enabled systems. 'The reality is [an effective HL7 leader must determine] how to foster the adoption of standards. The answer is: talking to a whole lot of people, achieving consensus, and motivating them to adopt the standard, and by being a good communicator, present everywhere at every conference, and be a respected authority,' Halamka says. 'I think [Rishel] has accomplished those tasks.'

Going forward, HL7's standards will utilize both RIM and HDF, Rishel says. That includes the HL7 Version 3 messaging standard; the Clinical Document Architecture for exchanging documents that typically begin as verbal reports, such as discharge summaries; and, eventually, the Clinical Context Management specification, which lets independent applications running on a clinician's desktop share patient data.

Still, migration to Version 3 will take considerable time, Rishel acknowledges. Versions 2 and 3 will coexist for years, with v.3 adopted for new applications and embraced more quickly in countries where Version 2 is not so prevalent. Britain's National Health Service has selected Version 3 as a future standard..." [excerpted from Health-IT World Volume 1, Number 2 (May 2004). ]