Healthcare Messaging Standards

HL7 and HIPAA Healthcare Messaging Standards

HL7 (Health Level Seven) is a messaging standard for exchanging clinical and administrative data between healthcare applications from various vendors, typically within an enterprise. HIPAA (Health Insurance Portability and Accountability Act) was enacted in 1996 and is designed to streamline healthcare transactions across enterprises and to uphold patients' privacy rights.

TIBCO ActiveMatrix™ BusinessWorks Plug-in for HL7 with FHIR can address the HL7 integration needs of an enterprise. In addition to addressing HL7 needs, it also addresses the HL7 requirement for integration with HIPAA, as HIPAA has HL7 requirements for some of its transactions. See TIBCO HL7 and HIPAA Solutions for more information.

How HL7 and HIPAA Messaging Can Overlap

Within enterprises like hospitals, events like patient admission and billing trigger HL7 messages between enterprise applications. Between enterprises like hospitals and insurance companies, which exchange HIPAA (Health Insurance Portability and Accountability Act) EDI-X12 transactions, HL7 is used in certain HIPAA EDI-X12 transactions.

For example, when a patient is admitted to hospital, the Patient Administration System (PAS) records details about the patient and the admission. Other systems, such as Pathology Laboratory Information Systems or Pharmacy Systems, are likely to need information about the new patient. The PAS sends an HL7 message about the patient to each of the appropriate hospital systems.

Later, when the hospital sends a claim for payment to another enterprise, like an insurance company, the hospital and the insurance company exchange HIPAA EDI-X12 messages. One or more of those HIPAA EDI-X12 messages may contain an embedded HL7 message with additional patient information.

HL7

HL7 is a structured, message-oriented framework for communications between healthcare application systems. When designers began to develop HL7, they borrowed from what is now ASC X.12 (EDI). However, the current similarity between the two standards is accidental for practical purposes since HL7 has evolved down its own path since its creation.

The HL7 protocol architecture is hierarchical, moving from high-level groupings and structures to a set of several hundred data fields. Each level of the hierarchy serves a different organizing purpose.

Functional Group

Areas of the protocol are grouped according to common application function. For example, ADT, Order Entry, Finance, Control, and Ancillary Reporting all represent groups described in the standard. Different functional groups are typically given individual chapters in the HL7 specification document.

Message Type

Within a functional group, one or more message types are defined that can be implemented in various combinations to support high-level business rules for the applications involved. For example, ADT only specifies one message type, while Order Entry describes more than a dozen.

Message Definition

Within each message type, one or more message definitions describe the specific set or combination of segments that make up a properly formed message. For example, ADT distinguishes among more than 30 separate message definitions based on trigger events or more detailed business rules. Each message definition includes one or more segments.

Segment Definition

Segments provide a logical grouping for data elements. For example, the Patient Identification (PID) segment includes fields for such identifying information as patient name, social security number, medical record number, account number, and miscellaneous demographic details. How fields are grouped in segments forms part of the HL7 implied data model. Segments can be required or optional, can be nested, and can repeat. A parsed message, then, can take on a relatively arbitrary yet unambiguous form. This is an important characteristic in the context of decoding and encoding messages.

Field

The HL7 standard identifies several hundred data elements for communicating patient demographic, clinical, and financial information. HL7 uses more than a dozen abstract data types to define the nature of the fields. One consequence is that some fields may hold more than one data element.

For example, a field that holds a time stamp (TS) follows a prescribed format. In addition, many fields are or can be coded, and the standard includes a variety of code tables to define acceptable contents. While each field is defined with a maximum length, the standard does not intend to prescribe format to that level of detail. In merely includes lengths because it helps readers understand the purpose of the field, and it may have a practical importance in specific implementations.