Skip to main content

Introduction to HL7 Version 2

This page introduces how to route HL7 Version 2 messages from one application to another using an InterSystems product as the routing engine.

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.

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.

FeedbackOpens in a new tab