HL7 V3, like V2.x, is a standard for exchanging messages among information systems that implement healthcare applications. However, V3 strives to improve the V2 process and its outcomes. The original process for defining HL7 messages was established in 1987. It has served well since. However, as HL7 membership grew and its standards became more widely used, HL7 has become aware of opportunities to revolutionize healthcare interface computing. HL7 interfaces substantially reduce costs and implementation times when compared to the industry's experience with proprietary interfaces. The development principles behind HL7 V3 lead to a more robust, fully specified standard.
V3 introduces a new approach to HL7 message development.
While the HL7 V2 standard was created mostly by clinical interface specialists, the V3 standard has been influenced strongly by work from volunteers representing the government and medical informatist users. This means that the level of formal modeling, complexity, and internal consistency is radically higher in V3 when compared to V2.
To assist with the comprehension of this new approach, the domain begins with a high-level overview and progressively drill down to lower levels of messaging detail (including storyboards, applications roles, trigger events, D-MIMs, R-MIMs, HMDs, message types, and interactions). Since a big picture understanding of the particular domain is crucial to understanding the messages defined within it, each domain provides a Storyboard.
The Domain Information Model (D-MIM) is presented first in each domain, providing a graphical and narrative detail of the scope of the domain. The D-MIM is the first in the series of information models. The D-MIM is a subset of the RIM but uses specific conventions to represent artifacts. Once the classes, attributes, and associations for a particular domain have been isolated through the D-MIM, the next logical step is to extract the set of classes, attributes, and associations required for an HMD or set of HMDs that originate from the same root class. These extractions are referred to as R-MIMs (Refined Message Information Models), which are a subset of and use the same conventions as the domain D-MIM.
The second element in the domain is one or more domain-level storyboards. Each storyboard includes a diagrammatic representation, called an Interaction Diagram. [Interactions describe the purpose of information flow. Create Patient Billing Account and Delete Patient Billing Account are examples of interactions found in the HL7 V3 messaging standard. Once the overall picture of data exchange is presented, the Storyboard continues with a narrative describing how the interactions might unfold in real life. Following the narrative is a description of each application role. Storyboards may be represented for the entire domain, or may be specific within the domain.]
There are three modes of Acknowledgement Process in HL7 V3.
Immediate Mode
Deferred Mode
Queued Mode
Outlined below is a summary assessment of the two HL7 versions.
Table 1–1 Summary Assessment
Standard |
Benefits |
Challenges |
---|---|---|
HL7 V2 |
Reflects the complex everyone is special world of healthcare |
Provides a one size fits none standard |
Much less expensive to build HL7 interfaces compared to custom interfaces |
Loose and optional ridden HL7 definitions lead to discrepancies in HL7 interfaces |
|
Provides 80 percent of the interface and a framework to negotiate the remaining 20 percent on an interface-by-interface basis |
Not inclusive of international needs No compatibility with HL7 V3 |
|
Historically built in an ad hoc way, allowing the most critical areas to be defined first Generally provides compatibility between 2.x versions |
Defining a detailed list of items to be discussed and negotiated before interfacing can occur is required |
|
HL7 V3 |
More of a true standard and less of a framework for negotiation |
For clinical interface specialists |
Model-based standard provides consistency across entire standard |
No compatibility with HL7 V2 |
|
Application roles well defined |
Adoption will be expensive and takes time |
|
Much less message optionality |
Long adoption cycle, unless storage business case or regulatory requirement changes |
|
Less expensive to build and maintain mid-to-long term interfaces |
Retraining and retooling necessary |
HL7 V3 adopts an Object Oriented (OO) approach using Unified Modeling Language (UML) principles.
Reduced Optionality
Conformance to HL7 V3 will be testable
Within the HL7 V3 standards the components that make up the HL7 V3 are each referred to as Artifacts. This includes,
Interactions
RIM
D-MIMs
R-MIMs
HMDs
Storyboards
Application Roles
Trigger Events
Message Types
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.
Hierarchical Message Descriptions (HMD): 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 corresponding HMD and XSD .
As pet 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. The specification development process identifies various artifacts for a particular domain and submits them. For every domain, the artifacts are organized in the same structure. The following Artifact Codes have been assigned.
Table 1–2 Artifact Codes
Artifact |
Code |
---|---|
Application Role |
AR |
Domain Information Model (D-MIM) |
DM |
Hierarchical Message Descriptor (HMD) |
HD |
Interaction |
IN |
Message Type |
MT |
Refined Message Information Model (R-MIM) |
RM |
Storyboard |
ST |
Storyboard Narrative |
SN |
Trigger Event |
TE |
The Patient Administration domain submits an application role with the following unique artifact identifier:
PRPA_AR00001UV00
Where:
PR Subsection: PracticePA Domain: Patient AdministrationAR Artifact: Application Role00001 6 digit non-meaningful number assigned by the TC to ensure uniquenessUV Realm (the only current value is UV for universal) 00 Current version number
Application roles represent a set of communication responsibilities an application can implement. Thus, they describe system components or sub-components that send and/or receive interactions.
Table 1–3 Patient Billing Account Informer
Structured Name |
Artifact Identifier |
Description |
---|---|---|
Patient Billing Account Event Informer |
FIAB_AR010001UV01 |
Informs a tracker of patient billing account creates (activate), update (revise), closes (complete), deletes (nullify), and merges (obsolete) |
A trigger event is a condition on which an action is initiated. HL7 adapter covers interaction based trigger events.
Table 1–4 Close Patient Billing Account
Structured Name |
Artifact Identifier |
Description |
---|---|---|
Patient Billing Account Event Complete Notification Type: State-transition based |
FIAB_TE010003UV01 |
This trigger event signals that the status of a patient billing account is rendered closed. This means it is no longer eligible for financial transaction posting. |
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.
A Storyboard narrative provides explanation for the storyboard.
Table 1–5 Close Patient Account
Structured Name |
Artifact Identifier |
Description |
---|---|---|
Patient Account Close |
FIAB_SN000106UV01 |
Ms Smith's account for a previous visit is at a zero balance and has not had any activity for some specified period of time. The account is closed, declared inactive and not available for further activity, preparatory to archiving and/or removal from the administrative system. |
Domain specific classes represented in a diagram with relationships.
A subset of D-MIM classes represented in a diagram with relationships. These classes specifically represent information content for one or more HMDs.
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.
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.
Interactions are at the heart of messaging. Interactions define the interaction between two systems. The documentation of interaction defines the following interactions.
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.
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.
Structured Name |
Artifact Identifier |
Description |
---|---|---|
Patient Billing Account Event Complete Notification |
FIAB_IN010003UV01 |
Close patient billing account |
This specification defines HL7 V3 Composite message is composed of:
An HL7 Transmission wrapper (always)
A Trigger Event Control Act (required for all messages except accept level acknowledgements, for which it is not permitted)
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.
The HL7 2.x specifications are
Segments that imply information entities
Events that indicate implied behaviors
The HL7 V3 specifications are
Uses object-oriented analysis methodology to
Improve the internal consistency of HL7
Provide sound semantic definitions
Enable future architectures
Produce an evolution not a revolution
Following are the benefits.
Reduces optionality that results in more specific messages
Uncovers hidden assumptions about application boundaries
Facilities defining clear, fine-grained, conformance claims
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.