Use the following information to help you to test the Healthcare: HL7 to HL7 pattern.
This topic contains the following sections:
You can use this pattern to interconnect HL7 applications, and route filtered messages from one sender application to many destination applications. Find out how to get started with the pattern instance by using message flows to simulate source and destination clinical applications.
The TestApplication project that is included with this pattern, see Resources for the Healthcare: HL7 to HL7 pattern, includes one Source flow called SourceApplication and six Destination flows called DestinationApplication. The six destination application flows are all the same except for their connection details. The destination application flows are each set up to use localhost with the port number that is specified in the flow name. Therefore, for example, DestinationApplicationListensOnPort2222 has its connection details set to localhost:2222 .
The connection details of the TestApplication project flows match the default connection details for the pattern instance. If you change the connection details in the pattern instance configuration, you must also change the connection details in the flows of the test application.
To test the pattern by using the flow debugger, read "Testing and debugging message flow applications" in the IBM Integration Bus documentation. To use the flow debugger with the GenericHL7Input and Generic HL7Output nodes you must import the subflows used by these nodes; see Resources for the Healthcare: HL7 to HL7 pattern.
The Pattern Test Application allows you to send and receive HL7 messages to the integration node using MLLP. The application can simulate a single source and destination clinical application. The test application provides options to simulate different MLLP configurations and message sequencing. HL7 messages are provided in the pattern resources to use as test data; see Resources for the Healthcare: HL7 to HL7 pattern.
The Pattern Test Application is launched from the Healthcare new file category - the application is straightforward and intended to be self-explanatory.
An HL7 message is split into segments and fields. The boundary between segments can vary depending on the sending application. The sample messages that are used in the test application use the hex characters 0D and 0A . Fields within a segment are separated by using the character declared in the MSH segment at the start of every HL7 message, the default is the vertical bar character (|). The segments are identified by the first field; the following example has four segments: MSH, EVN, PID, and PV1. The MSH segment is the header of the message, and has several fields that are explained in this topic.
The following example shows a typical HL7 message (ADT A01) (line breaks have been added to make it easier to read):
MSH|^~\&|HL7ABLAB|HNA500|HNAM|HNAM|20090911132151||ADT^A01|
Q30235031T29347435X328970|A|2.3|123
EVN|A01|20090911132100|||^DRONE_PM1^DRONE_PM^^^^^^^Personnel
PID|1||1357920591||IntFace1101A^WinTask^^^^^Current||19801117|M||||||||||
10000476524^^^FIN^FIN NBR|100000451||||||0
PV1|1|Inpatient|CD:16067689^CD:16067691^CD:16067741^Uniontown Hospit^^Bed(s)
^Uniontown Hospit||||||||||||||501455^Orr^Maggi^^^^^^External ID^Personnel^^^
External
Identifier~25584^Orr^Maggi^^^^^^PERSONNEL PRIMARY
IDENTIFIER^Personnel^^^Personnel Primary Identifier|Inpatient|||||||||||||||||||
||
Uniontown Hospit||Active|||20090911132100
The main message flows of the pattern instance are:
If you choose to create a pattern instance with more destinations, more DestnSender flows are created, where n is the number of the destination.
You must ensure that you have all the queues set up for the pattern instance, see the "Queues" section in Managing a Healthcare: HL7 to HL7 pattern instance.
When you send a message with the test application, the information flows through a pattern instance in the following sequence:
If you set up message or segment filtering, the filtering is carried out in this flow. Depending on the pattern instance setup, this flow might also contain nodes that publish remainders in the message and the canonical form of the message.
All flows also have an exception handling subflow that handles any problems that are caught by the flow.
You can set up sequencing for the pattern instance in the
Options
group of parameters. If the
Arrival based
option for sequencing is selected, the correct order for the messages is based
on the order in which they arrive in the pattern instance. If the
Content based
option for sequencing is selected, the value of the thirteenth field (123
in the example) in the MSH segment of the message is used as the sequence number.
The Receiver message flow sets up the sequencing for the pattern instance and
takes the sequence number of the messages.
Messages are resequenced in each of the destination flows. For each destination you can choose either strict or lax sequencing. If you choose strict sequencing and a message is missing, the remaining messages are held until the missing message arrives, which might block the flow indefinitely. If you choose lax sequencing and a message is missing, you decide how long the flow waits before it stops waiting for the missing message and continues processing messages.
To exercise the sequencing options, you can manipulate the order in which messages are sent to the pattern instance, change the sequencing number in the message, or take messages off queues during processing.
If the
Check duplicates
parameter is selected, the Receiver message flow contains extra nodes to check
for duplicates. The tenth field (Q30235031T29347435X328970 in the
example) in the MSH segment of the message contains the message control ID, used
to check for duplicate messages. After a message is processed by the flow, the
message is saved on a queue that can be checked. The
Check duplicates
subflow checks for duplicate messages; if the message is not a duplicate,
processing continues as normal. However, if the message is found to be a
duplicate and ACK messages are turned on, the original ACK message is returned
to the sending application. If ACK messages are turned off, the duplicate
message is processed in the same way as a new message arriving in the flow.
To exercise duplicate processing, you can manipulate the tenth field of the MSH segment in your messages.
If the Send acknowledgment parameter is selected, after the message has been processed by the Receiver message flow the pattern instance sends an ACK message to the sending application. This action informs the sending application that the message has been successfully processed. The SourceApplication message flow has nodes that are configured to handle ACK and negative acknowledgment reply (NACK) messages. If a problem occurs with the message processing, a NACK message is sent to the sending application instead.
Nodes are also contained in the destination flows to handle ACK messages that get sent back to the pattern instance from the destination application after the destination application has successfully received the message.
Several of the parameters in the Options group of the pattern instance configuration allow you to choose what information is logged about the messages as they are processed:
Message filtering
allows you to filter messages based on their event type, the ninth field (ADT^A01
in the example) of the MSH segment of the message. Not all messages from a
source application are required by all destinations. You can use message
filtering to exclude specific messages from specific destinations. Message
filtering is configured on a per destination basis.
When specifying message filters, the ninth field provides values for Code and Event . The two values are separated by the circumflex character (^). For the example message at the start of this document, Code is ADT , and Event is A01 . If sequencing is on and a message is filtered out, a dummy message is sent in its place so that the sequence is maintained.
Segment filtering allows you to specify the segments that are removed from a message when it is sent to a destination. You can use segment filtering to remove these segments from a message before it is passed on to a destination. If the destination does not support all the message segments that are sent by the source application, you might want to use this option to filter out the segments, for example, extensions to HL7 messages called Z-segments. Segment filtering is on a per destination basis.
Segments are specified by a three letter code (MSH, EVN, PID, and PV1 in the example message). The MSH segment is the message header, which cannot be filtered out even if it is specified by the user.