Sun HL7 Message Library User's Guide

Overview of HL7 and the Message Library for HL7

The Message Library for HL7 provides HL7 files formatted in Java^TM syntax for use with Java CAPS applications. A Message Library, also know as an Object Type Definition (OTD) Library, is a compilation of pre-built message structures for industry-standard formats. The HL7 Message Library is designed to work in conjunction with the Sun Adapter for TCP/IP HL7 to help you establish and maintain an efficient and reliable HL7 messaging system.

The HL7 Message Library supports the following versions of HL7:

The HL7 Message Library files can be copied and modified using the Message Library Editor. The editor also allows you to test libraries and verify that all data elements are available and data formats are correct before runtime. The editor executes a trace of parsing during the unmarshal process to assist with troubleshooting.

About HL7

HL7 is a standard for electronic data exchange in healthcare environments. It standardizes the format and protocol for the exchange of certain key data sets among healthcare computer application systems. HL7 is designed to be flexible, allowing the various systems that send or receive patient information to share and apply data as needed. Because of this diversity in systems (data models, operating systems, communication environments, and so on), HL7 cannot be a plug and play interface standard.

HL7, or Health Level Seven, is also the name of an organization consisting of technical committees and special interest groups whose goal is to provide standards for the exchange, management, and integration of data that support clinical patient care and the management, transfer, and assessment of healthcare services. More specifically, the goal is to create flexible, cost effective approaches, standards, guidelines, methodologies, and related services for interoperability between healthcare information systems.

The HL7 Standard

The HL7 standard addresses the interfaces among various systems that send or receive healthcare focused information, such as patient admissions, registration, discharge or transfer (ADT) data, queries, resource and patient scheduling, orders, results, clinical observations, billing, master file update information, medical records, patient referral, and patient care. It does not try to assume a particular architecture with respect to the placement of data within applications but is designed to support a central patient care system as well as a more distributed environment where data resides in departmental systems. Instead, HL7 serves as a way for dissimilar applications and data architectures operating in a heterogeneous system environment to communicate with each other.

Components of the HL7 Message

An HL7 transaction or message is comprised of a number of components in a defined sequence. This section defines the components of the HL7 transaction. The HL7 message is a unit of data transferred between systems. It consist of a group of segments in a defined sequence. Each message has a message type that defines its purpose. For example an ADT Message type is used to transmit portions of a patient's Patient Administration (ADT) data from one system to another. A three-character code contained within each message identifies its type. A trigger event, a real-world event such as a patient being admitted, initiates the exchange of messages.

Segments

A segment is a logical grouping of data fields. Segments may occur only once or repeat in a message and may be required or optional. Each segment is given a name. For example, the ADT message may include the following segments: Message Header (MSH), Event Type (EVN), Patient ID (PID), and Patient Visit (PV1). Segments are identified by unique three-character codes known as the Segment IDs.

Fields

A field is a string of characters. HL7 is not concerned with how a system actually stores data within an application. When fields are transmitted, they are sent as character strings. Except where noted, HL7 data fields may take on the null value. Sending the null value, which is transmitted as two double quote marks (""), is different from omitting an optional data field. The difference appears when the contents of a message is used to update a record in a database rather than create a new one. If no value is sent, (that is, it is omitted) the old value should remain unchanged. If the null value is sent, the old value should be changed to null.

Data field characteristics are as follows:

Position: The ordinal position or sequence of the data field within the segment.
Maximum Length: Maximum number of characters that one occurrence of the data field may occupy.
Type of Data: Restrictions on the contents of the data field. There are a number of data types defined by HL7, for example TX (text data), SN (structured numeric), PT (processing time), DT (date), and so on.
Optionality: Whether the field is required, optional, or conditional in a segment.
Repetition: Whether the field may or may not repeat, or the number of times the field may repeat.
Table: The manner in which HL7 defines the valid values for tables varies depending on institution, data type, reference, and so forth.
ID Number: Small integer that uniquely identifies the data field throughout the Standard.
Name : Descriptive name for the field.

Message Delimiters

Message delimiters are the specific predefined characters that are used to define the beginning and end of a message component. They are the segment terminator, the field separator, the component separator, subcomponent separator, repetition separator, and escape character.

Escape Sequences in Text

Fields Escape sequences vary depending on the type of field.

HL7 Message Sets

HL7 messages are grouped by type or purpose into transaction sets. For example, a Patient Administration (ADT) message is used to transmit patient admittance, transfer, demographic and discharge information. The Patient Administration transaction set includes messages that transmit portions, instances, or updates of this data necessary to the participating healthcare system.

Control

Control defines the general rules that apply to all messages, including the form used to describe messages, encoding rules for converting abstract messages to string characters, programming procedures for exchanging messages, relationship with lower level protocols, common message segments, and the acknowledgment message that can be used as-is in multiple applications.

Patient Administration

The Patient Administration transaction set (HL7 Standard, chapter 3), one of the most commonly used, provides demographic and visit information about patients. The event is transmitted as an unsolicited update or as a response to a record-oriented query.

Order Entry

The Order Entry transaction set provides for the transmission of orders for materials or services, and information regarding orders, for specific patients or departments. Order Entry messages include components that specify quantity, timing, billing, start and end date, priority, and so on.

Query

The Query transaction set provides requests for specific information with either an immediate or deferred response, depending on the type of query. Newer versions of HL7 include many of the most common queries that are likely to occur in a hospital.

Financial Management

The Financial Management transaction set provides for the entry and manipulation of information pertaining to billing accounts, adjustments, payments, charges, insurance, and other related patient billing and A/R information.

Observation Reporting

The Observation Reporting message set provides for the transmission of structured patient-oriented clinical information. This includes clinical observations such as clinical laboratory results, the results of imaging studies (excluding images), EKG pulmonary function studies, vital signs, intake and output, measures of patient status and condition, severity and/or frequency of symptoms, drug allergies, diagnostic lists, physician and nursing history, physicals, progress notes, operative notes and so on. Message information is reported in text, numeric or categorical values.

Master File

A master file is a common reference file containing more or less permanent descriptive information about a principal subject. In the healthcare environment, some common master files are doctor, location, system user, patient status, patient type, lab test definition, exam code definition, and charge master files. The Master Files Notification messages support the distribution of changes to various master files between systems, by either providing changes to the files or making data available for review and possible inclusion.

Medical Records/Information Management

The Medical Document Management (MDM) transaction set provides for the transmission of new or updated documents. MDM messages may contain a description of the status of a document (for example, the document has been dictated and is awaiting transcription) or both the status description and the document itself. A medical document or record is a legal document that serves as an accurate and comprehensive account of healthcare services provided to a patient.

Scheduling

The Scheduling transaction set supports the communication of various events in relation to schedules, appointments, services and resources. A schedule controls the dates and times available for the performance of a service or the use of a resource. The scheduling set contains three basic types of messages:

The Request transaction, used to request an appointment for services or the use of resources.
The Query transaction, which actively solicits scheduling information between systems.
The Unsolicited transaction, which passively gathers and provides scheduling information between systems.

Scheduling messages may also contain other supporting information, including the reason for the appointment, patient information, person initiating the appointment, and location.

Patient Referral

The Patient Referral transaction set provides for patient referral communications between separate healthcare related entities. This includes primary healthcare providers, hospitals, labs, specialists, government agencies, and other healthcare entities. The receiving entity may require billing information, test results, provider information, patient demographics and so forth, calling for multiple inquires and responses. For this reason, the referral set includes the referral, requests for information, and returned patient information.

Patient Care

The Patient Care transaction set supports the communication of problem-oriented records which include clinical problems, goals, and clinical pathway information. The problem in this case may be a diagnosis or other professional description of healthcare issues affecting a specific patient. Goals are objectives to be attained as the result of healthcare intervention applied to an individual. A pathway refers to a standardized plan of care by which progress toward an expected outcome is measured.

Laboratory Automation

The Laboratory Automation transaction set supports the communication of equipment information, including status, inventory, logs and service, test code settings, response, notification, and comment, as well as specimen status.

Application Management

The Application Management transaction set supports the transmission of application management information and application control-level requests.

Personnel Management

The Personnel Management transaction set supports the transmission of details regarding education, language, practitioner, and professional affiliations, as well as information on practitioner organization unit, and staff identification.