Introduction to HL7 Version 2

InterSystems Support for HL7 Version 2

InterSystems products support HL7 Version 2 messages as virtual documents. A virtual document is a kind of message that InterSystems products parse only partially. This kind of message has the standard production message header and the standard message properties such as ID, Priority, and SessionId. The data in the message, however, is not available as message properties; instead it is stored directly in an internal-use global, for greater processing speed.

InterSystems provides tools so that you can access values in virtual documents, for use in data transformations, business rules, and searching and filtering messages. For background information, see Using Virtual Documents in Productions.

HL7 segment names must be all uppercase.

Overview of HL7 Schemas and Messages

InterSystems products can process and pass through an HL7 message without using a schema to parse it, but associating a schema with a message allows you to do the following:

• Parse the message and access field values in:

  • Data transformations

  • Routing rules

  • Custom ObjectScript code

• Validate that the message conforms to the schema.

Each HL7 message is identified by a message type, which is specified in the MSH segment MessageType field (MSH:9). Some message types share the same message structure. For example, in HL7 Version 2.3.1, the ADT_A05 message to pre-admit a patient has the same structure as the ADT_A01 admit message. The schema specifies that the ADT_A05 message has the structure type ADT_A01.

In order to parse an HL7 message, InterSystems products need two pieces of information:

• Schema category — this is the HL7 version number, such as 2.3.1 or 2.7, or it may be a category for a custom schema defined in your InterSystems product. The production obtains the schema category from the business service Message Schema Category setting or from the Data Transformation settings. Although the HL7 message includes a schema version number in the MSH segment VersionID field (MSH:12), InterSystems does not use this value because many applications do not set this field consistently.

• Structure type — The production obtains the message type from the MSH:9 field and then checks the schema definition to get the structure type for that message.

  InterSystems uses the MSH:9.3 subfield to qualify the message type in some cases. The MSH:9:3 subfield is used in HL7 messages in two ways: 1) as a modifier to the message type, or 2) to specify the structure type. If MSH:9:3 modifies the message type, typically as a numeric digit, InterSystems products include it as part of the message type. If MSH:9:3 specifies a structure type, such as ADT_A01, InterSystems ignores it in both determining the message type and setting the Name property. InterSystems products do not need the MSH:9.3 subfield to determine the structure type because they get the structure type from the schema.

When a business service or Data Transformation creates an EnsLib.HL7.Message object to store an HL7 message, it combines the schema category and structure type and stores it in the DocType property using this syntax:

category:structureType

For example, valid DocType values for category 2.3.1 include 2.3.1:ACK, 2.3.1:ADT_A17, 2.3.1:BAR_P01, and 2.3.1:PEX_P07. The message type, which can be different from the structure type is stored in the Name property.

If you create an EnsLib.HL7.Message object in ObjectScript code, you should set the DocType and Name properties based on the value in the MSH:9 field.

The HL7 standard allows local extensions, such as trailing Z segments. These segments are not defined in the base schema categories. If you want to access a field in a custom Z segment in a data transformation, routing rule, or ObjectScript, you need to define a custom schema category that specifies the extended message. See Using the Custom Schema Editor for details on defining a custom schema.

You can place custom HL7 schemas under source control. Once source control is enabled, the source control options, such as check out and check in, are available from the main HL7 Schemas page, but not on the other pages that you use to work with custom schemas such as the HL7 Schema Message Type page. You must check out the entire schema from the HL7 Schemas page before editing the schema using other pages. A Source Control Output window is available from the main HL7 Schemas page that captures source control activity from all related HL7 schema pages. For information about setting up source control, see Integrating InterSystems IRIS with Source Control Systems.

An HL7 Version 2 Routing Production

The following figure illustrates the flow of an HL7 Version 2 message through a production that works as an HL7 interface routing engine. It shows elements that are referenced by configuration items, but that are not themselves configuration items. These elements include routing rule sets, data transformations, virtual documents, and schema definitions, all of which you create.

An HL7 Version 2 message flows through a production as follows:

1. An HL7 business service receives an incoming message from the specific source application whose messages it is configured to accept.

2. The business service passes the message to a specific HL7 routing process. This is a business process that prepares incoming messages from a HL7 business service for delivery outside the production via a specific HL7 business operation.

3. The routing process may validate the message against an expected HL7 schema definition. This may be a standard HL7 schema or a custom schema.

   (Not shown) If validation fails, the HL7 routing process passes the message to its configured bad message handler. This is an HL7 business operation that disposes of any incoming HL7 messages that fail validation, usually by saving the messages to a file. It may also enter an error in the Event Log or alert an operator.

4. The HL7 routing process applies a routing rule set to the message. The routing rule set chooses one or more target business operations and applies any data transformations that may be needed to prepare the message for the target application.

5. In the typical case, some data transformation is required to prepare the message for the target. The routing rule set may invoke transformations that are custom coded, but commonly transformations are created using the Data Transformation Language (DTL). DTL can call out to utility functions or your own class methods for more complex calculations.

6. When the outgoing message is ready, the routing process passes it to an HL7 business operation. The business operation provides the address and framing information required to send HL7 messages to the target application.

   (Not shown) By default, all HL7 messages that pass through the production are retained in the production message warehouse for as long as wanted. While in the message warehouse, the contents of HL7 messages are available for tracking and viewing using Management Portal features such as the HL7 Message Viewer, Message Browser, and Visual Trace, or by issuing an SQL query. You can configure the production to purge old messages automatically or at an administrator’s discretion.

HL7 Implementation Tools

For information about tools designed to speed up your implementation of HL7 productions and custom schemas, see HL7 Productivity Tools.