Best Practices for Designing a Healthcare Integration

Note the following best practices for designing an optimal healthcare integration.

• Build a Parent Routing Integration to Invoke Child Integrations that Process a Single HL7 Inbound Message
• Use a Lookup Function in the Mapper to Select the Child Integration to Invoke
• Add Fault Handling to Address Inbound Messages that are Not Selected in the Healthcare Action
• Plan for Future Oracle Integration for Healthcare Updates

Build a Parent Routing Integration to Invoke Child Integrations that Process a Single HL7 Inbound Message

You may design an integration that receives many different HL7 inbound message types. For example:

• ADT_A05 (Pre-admit a patient)
• ADT_A08 (Update patient information)
• ADT_A09 (Patient departing - tracking)

As a best practice, build a parent routing integration that invokes child integrations that each process a single HL7 inbound message type. For this example, create three child integrations. Do not attempt to build a single integration with a routing action (for example, a for-each action or switch action) to process each message.

Create your child integration with a REST Adapter trigger connection that can accept a binary format as its request payload. Select the default application/octet-stream as the mime-type. You pass the message-reference object that you get back from calling the healthcare action into your child integration. See Overview of the Integration Receiving the Inbound HL7 Message During Runtime.

Use a Lookup Function in the Mapper to Select the Child Integration to Invoke

Use a lookup function in the mapper to select the child integration to invoke. Based on the message and message type, the lookup function returns the name of the integration (Integration Code) and the version of the integration (Integration Version) to invoke.

In the lookup table, based on the specific inbound message received, a specific integration is invoked.

Add Fault Handling to Address Inbound Messages that are Not Selected in the Healthcare Action

A healthcare action is not designed to throw faults. You should design fault handling logic into your integration to catch message faults. For example, assume you design the following integration to receive inbound messages from an HL7 application:

In the healthcare action, you select the following two inbound message types for translation:

• ADT_A08 (Update patient information) version 2.5
• ADT_A08 (Update patient information) version 2.3.1

Assume the healthcare action also receives an inbound ADT_A04 (Register a patient) message from the HL7 application. Because this message type has not been selected in the healthcare action, it cannot be translated into an Oracle Integration payload. The ADT_A04 message type is passed through the healthcare action, but fails in the subsequent map action with errors.

As a best practice, add and design a switch action immediately after the healthcare action and before the map action with the following branch logic:

• Route 1: If the message is not selected in the healthcare action, then address the fault in that branch with your own fault handling logic. For example, add a notification action that sends an email to the inbound HL7 application informing them that an unplanned message was received.
• Otherwise: If the message is selected in the healthcare action, translate it into an Oracle Integration payload, perform mapping, and call the child integration for further processing and delivery to the outbound application endpoint.

Plan for Future Oracle Integration for Healthcare Updates

A common interface payload to use for the invocation from the handler integration to the child (processor) integration is provided. This JSON document forms the contract between the handler and the processor integrations.

<strong>{
    "document-standard": "HL7V2",
    "document-version": "2.3.1",
    "document-type": "ADT_A01",
    "document-definition": "HL7V2_ADT_A01",
    "message": [
        {
            "healthcare-message-reference": "clm:base64_meta.base64_payload1",
            "message-tracking-id": "123"
        },
        {
            "healthcare-message-reference": "clm:base64_meta.base64_payload2",
            "message-tracking-id": "abc"
        }
    ]
}</strong>

Use of this JSON message in your child integrations is not required. However, use of this message enables you to take advantage of potential future features. The idea is that if you use this JSON message as the contract in your child integrations now, change are not required in the future. You do not need to create a new handler integration. The incoming HL7 message is routed to the appropriate processor integration based on your routing rules. For this to work, you need to build your integration using this JSON payload.

This payload provides metadata about the message and capability to also support batch messages. You map this data using the data returned from the healthcare action when you call the operation Match and translate inbound message. An example of this mapping is shown below.