The HL7V3.0 Primer

What is HL7V3.0 ?

HL7V3.0 is a model based messaging specification which was proposed to resolve the weaknesses of HL7V2.x. The aim of a model based messaging standard is to create a standard set of structures for the sharing of healthcare information and support binding of standard clinical terminologies to the model. The creation of a standard clinical model with standard terminology establishes a healthcare domain specific common language which would allow any healthcare application model to map onto the reference model. This mapping would allow interoperability with other applications apart from allowing re-use of healthcare data in the application which has mapped its model onto the model.

Methodology Overview

Figure below shows the methodology used in HL7V3.0

The different processes in the HL7V3.0 methodology to obtain the message specifications are described below

Use Case Modeling:

The Use case Model consists of the following definitions

Ø Scope statement: A high level use case for the entire project

Ø Use case: Describes specific situations in which communication between healthcare entities is needed

Ø Actor: An entity which initiates or participates in the use case. Discovered in the process of developing use cases

Ø Use Case Diagram: Provides a graphical form to develop the use case model from the business process analysis and makes it easy to show the relationship between use cases

Interaction Modeling:

The Interaction Model

Ø Describes roles to which systems may claim conformance

Ø Fine-grained abstraction; every system will claim several roles

Ø Not standardizing system or application functions, only messaging roles

Ø Basis for contractual agreement

Ø Potential basis for conformance testing

Ø Captured in a MODEL, a TABLE, and a DIAGRAM

Each Interaction consists of:

Ø Trigger event :Event dependency usually expressed as the state of one or more classes

Ø Message ID : Each interaction sends one particular message

Ø Sender role

Ø Receiver role

Ø Receiver responsibility :A specific functional responsibility for the receiver to initiate another (consequential) interaction

Information Modeling:

The information model consists of the following

Ø A detailed and precise definition for the information from which the data content of HL7 messages are drawn.

Ø Follows object-oriented modeling and diagramming techniques, and is centered on a depiction of the classes that form the basis for the objects in HL7 messages.

Ø Provides a means for expressing and reconciling differences in data definition independent of message structure.

Ø Forms a shared view of the information domain used across all HL7 messages.

The Information Model defines

Ø classes, attributes, data types, and relationships

Ø vocabulary domains, code systems, and value sets

Ø states, trigger events, and transitions

Reference Information Model:

The model which forms the basis for the development of HL7V3.0 message specifications labeled RIM (Reference Information Model) is an object oriented model where the information is organized into classes that have attributes and that maintain associations with other classes. The information-related content of HL7 3.0 protocol specification standards is drawn from this model. RIM uses notation based on the Uniform Modeling Language (UML) and information modeling conventions outlined in the HL7 message development framework. RIM provides an explicit representation of the semantic and lexical connections that exist between the information carried in the fields of HL7 messages.

RIM is conveniently fashioned into three areas – semantic control, structured documents and message control.

The backbone of RIM consists of four primary classes and two linking classes. The four primary classes in the semantic content partition of the RIM are

Act: An Act is defined as intentional healthcare related action in the business domain of HL7. An instance is a record of an act. Acts definitions (master files), orders, plans, and performance records (events) are all represented by an instance of Act. An act is represented by a brick colored block in the RIM as following example

Act has the following sub-classes

Ø Account

Ø ControlAct

Ø DeviceTask

Ø DiagnosticImage
Ø Diet

Ø FinancialContract

Ø FinancialTransaction

Ø InvoiceElement

Ø Observation

Ø Participation

Ø PatientEncounter

Ø Procedure

Ø PublicHealthCase

Ø SubstanceAdministration

Ø Supply

Ø WorkingList

Entity: Entity is a physical thing or organization and grouping of physical things. A physical thing is anything that has extent in space, mass. Excludes information structures, electronic medical records, messages, data structures, etc. An Entity is represented by a green colored block in the RIM as following example

Entity has the following sub-classes

Ø Container
Ø Device

Ø LanguageCommunication

Ø LivingSubject

Ø ManufacturedMaterial

Ø Material

Ø NonPersonLivingSubject

Ø Organization

Ø Person

Ø Place

Role : For people, role is usually positions, jobs, or ‘hats’ and for places and things are what these places or things are normally used for. Each role is “played by” one Entity and is usually “scoped” by another. Thus the role of Patient is played by (usually) a person and scoped by the provider from whom the patient will receive services. Similarly, an Employee role is scoped by the employer. A role is represented by a yellow colored block in the RIM as follows



Role has the following sub-classes:

Ø Access
Ø Employee

Ø LicensedEntity

Ø Patient

Participation: Role exists only within the scope of one act. Acts have multiple participants, each of which is an entity in a role. Role signifies competence while participation signifies performance. Participation is represented in the RIM by the following block

Participation has ManagedParticipation sub-class.

Act Relationship: ActRelationship is association between a source Act and a target Act. A point from a later instance to a earlier instance OR point from collector instance to component instance.Act Relationship is represented in RIM by the following block

ActRelationship has no sub-classes

Role Link: Role Link is a relationship between two entity roles. For example Clinicians relationship with a Hospital and a Patients relationship with a Hospital to express the doctor and patient relationship. Role Link is represented in RIM by the following block

RIM Classes Example

Figure below shows the relationships between the different classes in the RIM with an example

In the above example the Act Examination is performed by Entity Person A in his role as GP and the Subject of the Examination is the Entity Person B in his role as Patient.

Attributes:

Class attributes are the core components of the information model. The attributes are the source for all the information content of HL7. There are three special kinds of attributes in the information model: identifier attributes, classifier attributes and state attributes.

Ø Identifier attributes: Identifier attributes can be used to identify an instance of a class. Values of identifier attributes never change. Examples of identifier attributes from the RIM include Entity.id and Act.id, which uniquely identify a particular Entity or Act respectively

Ø Classifier Attributes: The classifier attributes are a critical aspect of the classes forming the backbone of the RIM. The classifier attributes are named "classCode".

Ø Structural Attributes: Structural attributes are those attributes whose coded values are needed to fully interpret the classes that they classify. ClassCode together with moodCode, typeCode and determinerCode are the structural attributes.

Ø State Attributes: A state attribute is used in subject classes (classes that a Technical Committee designates as the central focus of a collection of messages). It contains a value that concisely indicates the current state (named condition) of the class.

Message Design:

The Message Design in HL7V3 from RIM is obtained as follows Message Design Overview

Domain Message Information Model:

DMIM is

Ø Full description (model) of the information classes within a domain and the way in which they are being used

Ø Classes are ‘cloned’ (copied and adapted) and renamed (alias) according to the way they are used in the domain context

Ø Data Types and vocabulary for attributes are specified

Ø Every RIM class category has its own colour; this makes the model description more visual

To obtain D-MIM from RIM

Ø Select RIM classes to be included in D-MIM Select the subset of RIM classes relevant to the problem domain.

Ø Clone subset classes of the RIM If the same RIM class is selected to meet different information needs then create as many clones of the RIM base class as needed. Ø Select a subset of class relationships Add relationships between the D-MIM clones consistent with existing class relationships in the RIM.

Ø Select a subset of class attributes For each D-MIM clone select the applicable attributes from its RIM base class.

Ø Select a subset of attribute data types and vocabulary domains Assign data types and domains to D-MIM attributes that are consistent with assigned data types and domains in the RIM

Refined Message Information Model:

R-MIM is

Ø Same type of representation as D-MIM

Ø Aimed for a specific category of interaction (e.g. all inpatient admission related messages) Ø Special form of an R-MIM are the Common Message Element Types (CMETs).These express common and reusable ‘information units’, that are derived from a D-MIM (like all R-MIMs) but can be used in other D-MIMs (and therefore R-MIMs) as building blocks (e.g. ‘patient’)

To obtain R-MIM from D-MIM

Ø Create clones of D-MIM classes and attributes Further specialize D-MIM classes by creating additional clones for each unique collection of attributes

Ø Assign alias class and relationship role names Assign domain specific names to class clones Ø Eliminate unnecessary class hierarchies Remove classes with no attributes and relationships from the class hierarchy

Ø Finalize class relationships and cardinality Alter relationship cardinality to reflect the appropriate minimum and maximum class occurrences

Ø Finalize attribute data types and domains Replace data type and domain specifications with the most appropriate constrained version of each

Hierarchical Message Definition

HMD is a further restriction of an R-MIM:sequentialized/serialized; represented in a different format. To create a HMD

Ø Select a root class for the message Chose a class to serve as the starting point for message content

Ø Arrange classes and attributes hierarchically Follow the relationships from class to class and add the attributes to the HMD.

Ø Declare inclusion and repetition constraints For each attribute specify if its presence in message content is optional, mandatory, or conditional and specify the number of times the attribute may repeat

Ø Declare data type and domain value constraints Declare additional constraints on the data types and domain values

Ø Assign message element names Assign a final meaningful business name to each attribute in the HMD

HL7 V3.0 Data Types:

HL7 data types define the structure and constrain the allowable values of attributes in the RIM. The HL7 data type specification declares the set of data types, identifies components of complex types, and defines relationships between data types. The HL7 data type implementation technology specification defines constraints and operations for data types and describes how data types are to be represented in XML. Data types are reusable atomic building blocks used to create all HL7 V3 information structures. Each RIM attribute is assigned one data type; each data type is assigned to zero, one, or more RIM attribute. Few of HL7V3.0 data types are given below

• AD: Postal Address
• ANY: DataValue

• BAG: Bag

• BL: Boolean

• CD: Concept Descriptor

• CE: Coded With Equivalents

• CS: Coded Simple Value

• ED: Encapsulated Data

• EN: Entity Name

• GTS: General Timing Specification

• HIST: History

• II: Instance Identifier

• INT: Integer Number
• IVL: Interval
• LIST: Sequence
• MO: Monetary Amount
• ON: Organization Name
• PN: Person Name
• PPD: Parametric Probability Distribution
• PQ: Physical Quantity
• REAL: Real Number
• RTO: Ratio
• SC: Character String with Code
• SET: Set
• ST: Character String
• TEL: Telecommunication Address
• TN: Trivial Name
• TS: Point in Time
• UVP: Uncertain Value - Probabilistic

HL7V3.0 Vocabulary Specification:

The HL7 V3 Vocabulary Specification defines vocabulary domains used in RIM coded Attributes and coded data type properties. A vocabulary domain is an abstract collection of interrelated concepts. It describes the purpose or intent of a coded attribute. A value set is a collection of coded concepts drawn from a single code system. A vocabulary domain may be associated with many value sets. A context expression provides a means of designating which value sets within a given domain are applicable for a given usage context. A coded concept has a concept code assigned by the coding system and a concept designation which names the referenced concept. A coded concept may be a parent concept for a collection of additional concepts within the same code system.

HL7 XML Schema Generator:

The HMD’s constrained with HL7 Vocabulary Specification and HL7 Data Type specification to a HL7XML schema Generator gives the XSD the schema definition of an HL7V3.0 message. Figure below shows the set up for the generation of XSD.

Links, References, Acknowledgements and Copyright

http://www.hl7.org

20 Minute HL7V2.x Primer

HL7 V2 Philosophy

The philosophy of HL7V2.x is based on the assumption that a real event that occurs in a healthcare setting creates data that needs to be exchanged between different systems of that setting. This is essentially to eliminate duplication of data collection from the patients and to automate administrative process saving time and money.

The real world events e.g. patient admitted or Lab orders raised are represented by trigger events and messages are specified for each trigger event. The structure of an HL7v2.x message is shown in Figure 1 below

Figure 1: Version 2 Message Structure

Segments - Version 2.X messages are designed around message segments indicated by a three letter segment id e.g. PID – Patient Identification; ORC- Common Order etc. Each message is composed of a group of segments in a defined sequence. Segments of message many be mandatory or optional and may repeat .A segment is a delimited line of data that contains data relevant to one specific use in the message. For example, patient identification information is in PID segment while patient allergies are defined in AL1 segment. Groups can be thought of as simply a collection of segments or other groups.

The HL7V2.x standard specification defines the standards segments. However the messages can also contain segments that are not part of the standard. These segments are locally-defined segments, called “Z-Segments” as their Segment ID code begins with a “Z”. These are allowed to add flexibility to the standard and usually appear at the end of the relevant segment group.

Each segment is a logical grouping of data fields. then composed of data fields. Each data field can have one or more components and each component may have sub-components.

HL7 V2.x History

HL7 1.0 originated in 1987 as an open standard for vendors for interfacing different clinical systems within an organization. It was defined in a period of six months with initial set of Orders and ADT messages. They were not widely implemented but laid a foundation for defining standard healthcare interfaces. HL7 v2.0 which was demonstrated at 1989 HIMSS convention introduced the concept of triggers, added additional detail to the Message header, and expanded the set of messages to include billing. HL7V2.0 was also not widely implemented. Figure 2 below shows a timeline of HL7 Version 2 releases.

Figure 2: Version 2 Timeline

HL7 Version 2.1 - HL7 Version 2.1 is the first widely used standard after its publication in March1990.HL7 2.1 is still in use today by some clinical systems.

HL7 Version 2.2 - HL7 Version 2.2 is primarily centered around cleaning up and clarifying version 2.1 specifications The notable changes to version 2.2 among others is that Segments were added to existing events for e.g. Merge Segment was added to the Transfer events (A06 & A07); Next of Kin Segment was added to the Patient Query (A19) event. Some additional fields were added to segments for e.g. additional fields to PID segment to handle newborn baby information and Next of Kin was made more generic to handle any person associated with the patient. New messages to handle Pharmacy, Diet and supply orders were added. Apart from adding new data types the HL7 acknowledgment paradigm has been extended to distinguish both accept and application acknowledgments, as well the conditions under which each is required.

HL7 Version 2.3 - Version 2.3 offers new data types, especially the 'x'-tended versions of PN, CN, etc. Enhanced query functionality and clear definitions of tables for e.g. differentiating ID/IS data types. In Financial Management Additional messages were added and message constructs were extended to allow greater specificity in the intent of the message, and to report additional information.

HL7 Version 2.3.1 - HL7 V.2.3.1 includes an updated TQ (timing/quantity) datatype to manage order occurrences, updates to the OBR segments and ORU message to facilitate public health surveillance reporting, updates to tables, segments and data types to accommodate international paradigms for reporting names and pharmacy orders, and the addition of a new field to the ORC segment to satisfy the HCFA Medical Necessity requirements for outpatient services, and an update to the FT segment to satisfy federal requirements for Level 2 Modifiers.

HL7 Version 2.4 – Version 2.4 is approved as an ANSI standard in October 2000. HL7 v.24 introduces Conformance Query profiles, and adds messages for laboratory automation, application management and personnel management. Additionally, a new event, specific to OPPS and APC requirements was added. This event, Transmit Ambulatory Payment, includes two new segments, the Grouping/Reimbursement Visit Segment and the Grouping Reimbursement Procedure Segment.

HL7 V2.x Message Construction

Message Encoding Rules: Version 2.x messages have some defined special characters that delineate data fields which make up the message. These special characters are the segment terminator, the field separator, the component separator, the sub-component separator, and the repetition separator. Table 1 below shows the definition of these separators


Table 1: Version 2 Separators

The interface that implements version 2.x messages will use escape sequences for e.g. \F\- Field Separator to signify that reserved characters (delimiter or separator characters) is present in the value

Message Construction Rules: A Version 2.x message consists of segments. Message segments are constructed in the order defined below

1. The first three characters in the message segment that will be inserted into the message is the segment ID code, e.g. - PID – Patient Identification Details.

2. Each segments consists of different fields and each of those data fields that make up a segments are inserted into the segment in sequence:

2.1 A field separator ¦XYZ¦ is placed at the beginning and the end of the field. If there is no value present in the field then no other characters are required and a ¦¦ is used.

2.2 If the value is present but equivalent to null, two consecutive quotation marks are placed in the field ¦""¦.

2.3 If a field is defined to have components (combination of meaningful data fields), the following rules apply:

• Components are separated by the component separator.


• Components that are present but null are represented by two consecutive quotation marks


• Components with no value require a component delimiter but do not require characters in the component. For example: ¦ABC^^DEF¦


• Components at the end of a data field with no value do not have to be represented by a component delimiter. For example: ¦ABC^DEF^^¦ = ¦ABC^DEF¦


• When a component is itself a data type that contains components, its delimiters are demoted by one. For example, the component delimiters for the composite field ¦ABC^DEF¦ are demoted by one to ¦JKL^ABC&DEF¦

2.4 If component has sub-components, the following rules apply:

• Sub-components are separated by the sub-component separator.


• Sub-components that are present but null are represented by two consecutive quotation marks.


• Sub-components that are not present require place holder separator but no characters in the sub-component.


• Sub-components at the end of a data field with no value do not have to be represented by a sub-component delimiter.

2.5 If the field definition permits repetition, the repetition separator is used only if more than one occurrence is transmitted. The repetition separator is placed between occurrences.

2.6 End each segment with an ASCII Carriage Return character - ASCII(13), HEX(0D).

3. Steps 1 and 2 are repeated until all segments have been generated.

4. The receiving system will ignore segments, fields, components, and extra repetitions that are present but not expected. The receiving system will treat segments that are expected but not present as consisting entirely of fields that are “not present”, and it will treat fields and components that are expected but not included in a segment as “not present”.

Data Types: Data types define the structure of the fields. Data type specification is an important tool for simplifying the complexity of the HL7 standard, and is critical for understanding the data contents of an HL7 field.

Version 2 supports the following data types

• Primitive – consisting of one component e.g. ST(String)


• Simple – multiple components, no ‘type’ code e.g. CE (Coded Element)


• Complex – multiple components with a ‘type’ code e.g. XAD(Extended Address)

The application of data types to the fields can be gauged by the following examples.

The format of CE as per version 2 specification is

CE :< identifier (ST)> ^ <text (ST)> ^ <name of coding system (IS)> ^ <alternate identifier (ST)> ^ <alternate text (ST)> ^ <name of alternate coding system (IS)>

e.g. 11289-6 ^ Body Temperature ^ LN

11289-6 is the identifier; Body Temperature is the text and LN (LONIC) is the name of the coding system.

The format of XAD as per version 2 specification is

XAD : <street address (ST)> ^ <other designation (ST)> ^ <city (ST)> ^ <state or province (ST)> ^ <zip or postal code(ST)> ^ <country (ID)> ^ < address type (ID)> ^ <other geographic designation (ST)>^ <county/parish code
(IS)> ^ <census tract (IS)>

e.g.: ¦23 Sussex Place ^Flat 3 ^ Slough ^ Berkshire^SL11NH^UK^P^^BERK^¦

23 Sussex Place corresponds to street address ; Flat 3 for other designation; Slough for city; Berkshire for state;SL11NH for postcode; UK for country and P which stands for permanent.

HL7V2.x Message Anatomy

Imagine the following scenario

• Patient Andy Smith Carol was admitted on July 22, 2006 at 11:23 a.m. by Doctor John Carol (#C145678) for an orthopedic procedure (ORT).



• He has been assigned to room 202, bed 10 on nursing unit 1000.



• The Patient Lives at 23, Sussex Place, Slough, Berkshire, SL11NH and was born on December 23rd 1961.



• The hospital the Mary Green Maternity – MGM has PAS System - ADT1 and a laboratory system PATHLAB.

The admission of the patient corresponds to a trigger for Admit patients and an event A01 is intended for admitted patients. This will be sent from PAS system to Lab system in real time as soon as the admission takes place. According to HL7 V2.3.1 message specifications a portion of message structure of A01 shown in Table 2

Table 2: A01 Message Structure

Download the complete A01 HL7 V2.3 message specifications from HL7 website (http://www.hl7.org/)

The most important fields in the message segment (MSH) header are shown below in Table 3.

Table 3: Relevant MSH Fields

The message segment MSH shown below sent in the message based on the scenario above shows what has been sent in the following scenario with the data items from the PAS database populating these fields.

The other important message segment PID in A01 whose important fields are shown in Table 4. The complete list of fields is available from v2.3.1 Message pack on HL7 Website.

Table4: Relevant PID fields

The message segment PID shown below sent in the message based on the scenario above shows what has been sent in the following scenario with the data items from the PAS database populating these fields.

Messaging Communication: The most commonly used mechanism for sending HL7 Version 2.x messages is Lower Layer Transport protocol (LLP). The messages are sent over TCP/IP over the network.

The protocol is very simple to implement using the implementation setting sockets. The protocol requires that that each message should be preceded with the character 0x0B (11) and followed with the characters 0x1C (28) and 0x0D (13). This is required for communications code to be able to recognize the start and the end of each message

Finally each segment is terminated by a 0x0D (13) character. This is mandated by the standard, but often HL7 log data can be received via ftp or email where the segment separators have been transformed into 0x0A characters, etc

Current Status of HL7V2

Some countries such as Germany have legislation that stipulates the use of V2.X, and V2.4 which is a ANSI standard from 2004 is now being proposed as an ISO standard, making it a truly international standard though it have been developed for American market.

The Version 2.x standards are widely used in different countries in the world, in particular in acute healthcare settings and in some countries even in primary care. The HL7 versions 2.1 to 2.5 which have been published are in wide use and the work is underway on V2.6, which is expected to be published late 2005/early 2006.

Version 2.5 – HL7 Version 2.5 is the last published standard in the HL7 Version 2.x series. Version 2.5 contains new messages and updates to HL7 Version 2.4. Version 2.5 is supposed to be broader in scope that Canadian Health Information Technology Trade Association (CHITTA) have issued a position paper to Canada Health Infoway urging the agency to reconsider its support of Health Level 7 (HL7) Version 3 in view of the supposed unavailability of Version 3 normalised specifications (Ref: Section xxx) and asked it to endorse HL7V2.5 which provides greater interoperability. HL7 Version 2.5 introduced a number of new events, segments and messages and expanded the Control section. Version 2.5 is more consistent and supports more functionality than any of the previous versions. The significant modifications to version 2.5 are

• Better and clearer documentation of the data types



• A definition of a message profile methodology



• Better support for Radiology/Imaging by means of a new segment and a new order message



• Support for orders related to blood products



• New update message for diagnosis/procedures



• New specification of claims and reimbursement messages

Version 2.6 - HL7 Version 2.6 completed the first ballot cycle in September 2004 and is nearing completion and will be released in 2006. V2.6 will include enhancements made to allow the communication of Electronic Health Record (EHR) information which is sighted as one of the biggest deficiency of version2.x. Version 2.6 is an upgrade to HL7 Version 2.5 and it includes new segments, fields, components and subcomponents necessary to apply either a documented regulatory requirement or a harmonization requirement with HL7 Version 2 material created by other committees. The main changes to version 2.6 from version 2.5 are

• Addition of general new segment -UAC "User Authentication Credential"



• Better management of access to sensitive patient information by adding Access Restrictions (ARV) segment.

• New message type to support the US National Animal Health Laboratory Network (NAHLN)



• Deprecation of data types such as CNN,LA1, LA2 and NDL data types



• Addition of components to the XAD and XTM data types.



• "TS" Timestamp data type is being replaced by the DTM "Date/Time" data type.



• CE "Coded Element" data type is being replaced by either the CNE "Coded with No Exceptions" or the CWE "Coded with Exceptions" data types

• Code tables defined by external standards organizations will not be considered as HL7 tables but an HL7 number will be assigned.



• Many new fields have been added to the segments in the Financial Management



• “Observation Reporting” chapter has added support for referral and shared care



• Personnel Management chapter contains new attributes to the STF and ROL segments.



• New chapter Materials Management with messages for communicating various events related to the appointment scheduling for services and resources

XML encoding :The German HL7 group defined a comprehensive database of the HL7 standard to allow consistency checks of items and to support the application of the standard by the user when they realized that the different chapters in the published standard have been developed by different groups and there are no distinct rules or guidelines for the development of various parts of the standard.

The database is a Microsoft Access database and contains the official definitions for events, messages, segments, fields, data types, components, tables and values. An XML representation of version 2.x standard is algorithmically derived directly from this database. The algorithm consists of SQL queries to extract tables which are then exported to ASCII delimited files. Perl scripts are applied to these ASCII files to generate XML DTD’s.

Two sets of DTD’s have been provided;
A single DTD (hl7_v231.dtd) that contains all HL7V2.3.1 definitions. This file is broken up into four separate DTD definitions – Message.dtd; segments.dtd; fields.dtd datatypes.dtd.

One DTD for each message structure. Each imports the same datatype DTD referenced by hl7_v231.dtd, but is otherwise self contained with all message, segment and field declarations needed for the message structure.

The XML representation represents HL7 message structures as XML elements. Message structures contain segments, also represented as XML elements. Segments contain fields, again representedas XML elements. A field's data type is stored as a fixed attribute in the field's attribute list, while a field'scontent model contains the data type components. Other fixed attributes are used to expand abbreviations and indicate HL7 Table value restrictions


A simple version 2.x representation is shown below



The representation of the above message using XML encoding rules is shown below.