Working with TCP/IP HL7 Collaborations

Inbound HL7 V3 Deferred Collaboration Overview

The Inbound HL7 V3 Collaboration, jcdHL7V3DeferredInbound, contains OTDs for the HL7 V3 Resource Adapter, JMS Data, JMS Journal, JMS Error, and JMS APP ACK as well as the HL7 V3 Patient Administration Domain Interaction Event (PRPA_IN403001UV01) and the corresponding HL7 V3 Commit Acknowledgement (MCCI_IN000006UV01) and Application Acknowledgement (MCCI_IN000007UV01). The Collaboration works with its own internal code and the Properties Configuration files.


Note –

Deferred Mode: Contains two types of Acknowledgement OTDs,

  1. Commit Acknowledgement (MCCI_IN000006UV01)

  2. Application Acknowledgement (MCCI_IN000007UV01)

The above JCD (jcdHL7V3DeferredInbound) will also work for both Immediate Mode and Deferred Mode.


HL7 V3 Standard Inbound Message Mode Data Flow (For Deferred Mode of ACK Process) — Part 1

A HL7 V3 message triggers an inbound Collaboration received from an external system or an outbound HL7 V3 Client. Execute the following Collaboration calls of the HL7 V3 User Collaboration Rule receive().

The receive method is the entry point to the HL7 V3 User Collaboration, with the following signature:

public void

receive(com.stc.connector.appconn.tcpip.hl7.HL7ServerApplication input,

com.stc.connectors.jms.JMS otdJMS_DATA,

xsd.hl7v3.PRPA_IN403001UV01.PRPA_IN403001UV01_ otd_PRPA_IN403001UV01_1

xsd.hl7v3.MCCI_IN000004UV01.MCCI_IN000004UV01_ otd_MCCI_IN000004UV01

xsd.hl7v3.MCCI_IN000006UV01.MCCI_IN000006UV01_ otd_MCCI_IN000006UV01

xsd.hl7v3.MCCI_IN000007UV01.MCCI_IN000007UV01_ otd_MCCI_IN000007UV01

com.stc.connectors.jms.JMS otdJMS_APPACK

otdHL7_ACK_1,com.stc.connectors.jms.JMS otdJMS_JOURNAL,

com.stc.connectors.jms.JMS otdJMS_ERROR) throws Throwable.

Once the message is received, the Collaboration determines whether the message needs to be validated. The HL7 V3 message is then validated, making sure that the message structure is correct. Various fields in the Transmission Wrapper of the message are also validated, such as Version Code, Processing Code, Processing Mode Code, and Interaction ID. If these fields do not match the configuration, a NAK is returned.

If sequence numbering is enabled the Collaboration checks to see if the messages sequence number is valid. If the sequence number is not valid, the adapter sends a NAK. The validated HL7 V3 message moves on to processInitialHandshake().

Figure 1–21 Deferred Mode of ACK Process — Part 1

Deferred Mode of ACK Process — Part 1

HL7 V3 Standard Inbound Message Mode Data Flow (For Deferred Mode of ACK Process) — Part 2

The Collaboration receives the HL7 V3 message from the external using receiveHL7message(). If an exception occurs due to incomplete data, and the adapter fails to read the data within the configured number of retries, the associated recourse action is taken. If the exception is due to no response, the associated recourse action is taken.

If no exception occurs, validateHL7Message() is called, which validates the message to determine whether to ACK or NAK the message. Other helper methods are also called to validate the HL7 V3 message.

If the HL7 V3 message passes validation, the Collaboration calls makeCommitAck() and sendHL7CommitAck() to create and send the Commit ACK (MCCI_IN000006UV01) to the external. It then calls journalHL7AppAck() to create Application ACK (MCCI_IN000007UV01) and store it into the JMS.

Figure 1–22 Deferred Mode of ACK Process — Part 2

Deferred Mode of ACK Process — Part 2

HL7 V3 Standard Inbound Message Mode Data Flow (For Deferred Mode of ACK Process) — Part 3

After the Commit ACK is sent and the Application ACK is stored in JMS, the HL7 V3 message and the ACKs are journaled to the JMS Queue Journal destination. If the message fails to journal the associated recourse action is taken.

Figure 1–23 Deferred Mode of ACK Process — Part 3

Deferred Mode of ACK Process — Part 3