Vishnu's Blog

Understanding HL7 Version 3 from Developer perspective

Introduction

Understanding HL7 V3 specification is a difficult task for the developers who worked on HL7 v2 messages. The HL7 V3 specification is different in many ways from V2. I have gathered all the information required for transmitting HL7 V3 messages from the V3 specification documents and here I will give a general overview of different elements of V3 and constructing the V3 message that can be exchanged with other compatible systems.

HL7 V2 versus V3

HL7 V2 is primarily intended for developers or clinical interface specialists, whose job is to move clinical data or create tools to exchange such data from one application to another. Thus, V2 is designed to ease the exchange of clinical data between different systems. Whereas V3 is influenced by Medical informatists who work in the field of healthcare and study how healthcare information is created. Thus the V3 specification primarily focuses on Healthcare data rather than how to transmit the data.

HL7 V3 message development process

The V3 message development process is based on information models produced by the development groups. An information model represents data in object oriented way. It has classes with relationships, properties, states and constraints. The information models are refined and localized to come up with messages that can be exchanged with different systems.

Reference Information Model (RIM): The RIM is an information model collectively developed by the HL7 working group. It is the information model that encompasses the HL7 domain of interest as a whole. The RIM is a coherent, shared information model that is the source for the data content of all HL7 messages. The RIM is intentionally abstract to represent the HL7 data in a standard way across all the domains of Healthcare. It is the root of all information models and structures developed as part of the V3 development process.

Domain-Message Information Model (D-MIM): The classes, attributes, state-machines, and relationships in the RIM are used to derive domain-specific information models called D-MIMs. A D-MIM is a refined subset of the RIM that includes a set of class clones, attributes and relationships that can be used to create messages for a particular domain (a particular area of interest in healthcare). Domains under Administrative Management : - Accounting and Billing - Claims & Reimbursements - Patient Administration - Personnel Management - Scheduling Domains under Health and Clinical Management: - Clinical Document Architecture - Medical Records - Public Health Reporting - Clinical Genomics - Specimen Domain - Regulated Studies

Refined-Message Information Model (R-MIM): The R-MIM is a subset of a D-MIM that is used to express the information content for a message or set of messages with annotations and refinements that are message specific. The D-MIM is used as a common base upon which all R-MIMs within a domain are built.

Heirarchical Message Descriptions (HMDs): The HMDs are abstract message structures which represent the information from R-MIMs. The HMD represents R-MIM in an organized way which can be exchanged between systems. The HMDs are called abstract because they define the message structure without reference to the implementation technology.

XML Schemas: HL7 V3 defines Implementation technology specifications (ITS). These ITS define how the abstract message types should be transmitted using an underlying technology. V3 currently defines XML ITS and UML ITS. The XML ITS defines data types and structures. The XML datatypes represents HL7 datatypes in XML specific way. And the XML structures represent the structures defined by HMDs. Thus for every message type there is a HMD and XSD correspondingly.

Understanding V3 Artifacts: We saw the process of V3 message development, where V3 information models are refined to come up with XML schemas which can be used to construct V3 XML messages. But I didn’t mention which are the XSDs contain all required information to come up with complete V3 message. In the below section, I will address this. To understand the V3 specification, understanding the artifacts of the specification is very important. The HL7 technical committee during the specification development process identifies various artifacts for a particular domain and submits the same. For every domain, the artifacts are organized in the same structure. Thus for every domain specification, the committee submits the artifacts documented as explained below. To identify every artifact, the HL7 has come up with an unique attribute called Artifact Identifier. For example, an application role submitted by the Patient Administration domain will have the following unique artifact identifier: PRPA_AR00001UV00 Where: PR = Practice(Subsection) PA = Patient Administration (Domain) AR = Application Role (Artifact type) 00001 = 6 digit non-meaningful number assigned by the Technical Comittee to ensure uniqueness UV = Realm (the only current value is UV for universal) 00 = Current version number

Application Role (Code:AR): Application roles represent a set of communication responsibilities that might be implemented by an application. Thus they describe system components or sub-components that send and/or receive interactions.

Trigger Event (Code:TE): A trigger event is a condition on which an action is initiated. 

Storyboard (Code:ST): A storyboard explains the series of actions in a particular scenario. Its primary purpose is to identify the various scenarios. Each storyboard is represented as sequence diagrams. It also lists the interactions between two or more systems playing different Application Roles.

Storyboard Narrative (Code:SN): A Storyboard narrative provides explanation for the storyboard.

D-MIM (Code:DM): Domain specific classes represented in a diagram with relationships.

R-MIM (Code: RM): A subset of D-MIM classes represented in a diagram with relationships. These classes are specifically to represent information content for one or more HMDs.

HMD (Code:HD): The Message Structures or Message types which form the payload of the data transmitted. The base HMD is depicted in a tabular format or in excel view. It also lists the various message types built based on this HMD.

Message Type (Code:MT): A message type represents a unique set of constraints applied against the common message. It is represented in Table view or in XML schema view.

Interaction (Code:IN): Interactions define the interaction between two systems. The documentation of interaction defines: - Trigger Event which initiated the interaction - Message Type which should be used for interaction (The payload) - Transmission Wrapper: A Message Type to wrap the payload with - Control Act Wrapper: A Message Type to hold the administration information about the payload being transmitted. - Sender: The Sender Role for this interaction - Receiver: The Receiver Role for this interaction.

Transmission Wrapper and Control Act Wrapper: This specification defines HL7 V3 Composite message is composed of:

1. An "HL7 Transmission wrapper" (always)
   

    



2. A "Trigger Event Control Act" (required for all messages except accept level acknowledgements, for which it is not permitted)
   

    



3. The "HL7 Domain Content" specified by an HL7 domain specific technical committee (required for each Trigger Event Control Act)
   

    

The HL7 Transmission wrapper is specified in domain: Transmission Infrastructure. This domain specification describes the details on composing a V3 composite message and exchanging the composite message between systems. It covers features like acknowledgements, sequence no. protocol support, error handling and security. “Trigger Event Control Act” is detailed in domain: Message Control Act Infrastructure. This details the administrative information about the data being transmitted. Thus the interactions define the complete set of information that is required to exchange HL7 data between the systems.

Conclusion: The HL7 V3 specification contains the XSDs for Interactions which can be used to construct the composite HL7 V3 message. This composite message then can be transmitted between the systems. The V3 Specification says that a system can claim for V3 conformance based on the Application Role it will play in a particular domain. The system playing the Application Role will recognize the Trigger Events, the message types and the data content of these messages. Thus a system whose sole responsibility is to exchange the V3 data between systems reliably should claim conformance for the Application Roles defined under Transmission Infrastructure Domain.

Posted at 05:42PM Aug 07, 2007 by vishblog in Sun  |  Comments[16]