Working with TCP/IP HL7 Collaborations

TCP/IP HL7 V3 Adapter Collaborations

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.

Introducing the Methodology

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

What's New with HL7 V3

HL7 V3 adopts an Object Oriented (OO) approach using Unified Modeling Language (UML) principles.
Reduced Optionality
Conformance to HL7 V3 will be testable

Artifact Identification System

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

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.
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 .

Artifact Codes

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 Role (Code: AR)

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)

Trigger Event (Code: TE)

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.

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 Narration (Code: SN)

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 Information Model (D-MIM) (Code: DM)

Domain specific classes represented in a diagram with relationships.

Refined Message Information Model (R-MIM) (Code: RM)

A subset of D-MIM classes represented in a diagram with relationships. These classes specifically represent information content for one or more HMDs.

Hierarchical Message Descriptor (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.

Figure 1–16 Hierarchical Message Descriptor

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 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.

Table 1–6 Close Patient Billing Account Notification


Structured Name	Artifact Identifier	Description
Patient Billing Account Event Complete Notification	FIAB_IN010003UV01	Close patient billing account

Figure 1–17 Close Patient Billing Account

Figure 1–18 Sending and Receiving Roles

Transmission Wrapper and Control Act Wrapper

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.

Comparison between HL7 V2.x and HL7 V3

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

Benefits of V3 to HL7

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.