Monday, November 6, 2023

#995 - OIC Healthcare - MLLP adapter

The latest release of OIC includes an MLLP adapter. MLLP, aka Minimal Lower Layer Protocol, goes hand in hand with HL7 message processing. So this new adapter is very interesting from an OIC Healthcare perspective. This post shows you how this works and details a simple demo you can use. 

Firstly a BIG thanks to my colleague Steve Tindall for his support here.

The MLLP adapter leverages the connectivity agent, as you can see.

I will be invoking an OIC MLLP triggered integration via a 3rd party tool, HL7 Inspector.

First use case will be as follows - HL7 invokes the following integration - 

The only action is a Logger, which will log the incoming HL7 message.

It is configured as follows - 

Let's look at the inbound connection definition - 

The listener port can be set to a value of your choice. The actual "listening" is done by the connectivity agent, which then triggers the integration.

I have the following setup, in this simple scenario -

So HL7 Inspector sends the request to localhost:6200. 

Time to look at how this is setup in HL7 Inspector

I click on the Send icon and then, the setup icon -


HL7 Inspector ships with a sample HL7 message, which I can use for this sanity test.

I click the Send button - 
Check out response - note the acknowledgement.

Now to OIC Observability - 

That's the basics working. But how would you implement such? I have a client or clients sending me HL7 messages over MLLP. The message types can, of course, vary. For example, messages of type ADT (Admit/Discharge/Transfer) can include messages such as -
  • ADT01 - Patient Admit
  • ADT02- Patient Transfer
  • ADT03 - Patient Discharge
  • ADT04 - Patient Registration
I can adopt the following pattern - Dispatcher/Router integration receives the message. It checks an OIC lookup to retrieve the correct target( Processor) integration -

Let's implement this - first back to our Dispatcher/Router integration - 

I've added a couple of actions, as you can see. First step is the Assign - here I get a handle to the incoming HL7 message.

The next step is the HealthCare action - configured as follows - 

Note, I've selected all the HL7 documents I have created in the OIC instance.
These are available here - 

The Map to the Translate step is configured as follows - the target is set to the variable created in the Assign step.

The final activity, the Logger, outputs docType and version.

Let's this this with a valid 2.8 version of patient admission.

The activity stream output is as follows - 

Now a test with Patient Registration ADT^A04

I create 2 "processor" integrations, one for patient registration and one for patient admission.

These will have REST triggers and the input for both will be based on the output from the Translate step

The "processor" integration will then invoke Healthcare to convert the message reference to document - 

Here is the REST trigger definition of the "processor" integration for patient admission - 

The Healthcare action invoked is - Convert Message Reference to Document

The mapping is simple - the request stream is the source and the target is - 

I add a Logger as the final action, logging the patient. The final result - 

Now to the OIC Lookup, mentioned earlier - this will contain the routing rules  

The lookup will be used in the mapper, when the "dispatcher/router" invokes the "processor" integration - 

The "router" integration has been augmented as follows - 

The Mapper for the InvokeProcessor step is configured as follows -

Integration Code and Integration version are set via the Lookup.


All that's left is to add a new "processor" integration for ADT_04 - Patient Registration - same modus operandi.

Let's test with a new ADT_01 ( Admit Patient ) document from HL7 Inspector

Now to OIC Observability

and here's our patient - Adam Everyman -

That's how simple it is! Summa Summarum, this is a compelling new feature of OIC. Currently it is available via a feature flag, so ping me if you want to try this out now.

No comments: