Aug 25

In my past articles I presented, amongst other things, HL7 v2 messaging solutions using the Oracle SOA Suite 11g R1 B2B HL7 infrastructure. At the beginning of the calendar year 2012 Oracle released a new incarnation if its HL7 messaging capability under the name of the “SOA Suite for healthcare integration”. This capability builds on the SOA Suite B2B HL7, adding design, configurator, monitoring and management user interface capabilities which greatly simplify the task of creating HL7 v2 messaging solutions and enhance management and operational reporting.
The new and changed functionality is significant enough for me to consider writing a series of articles on the topic. The series is intended to walk the reader through the tasks of creating specific HL7 v2 messaging solutions using the SOA Suite for healthcare integration.
At this point in time I expect to produce articles on the following topics, in the order given:

  1. Overview of the Development Environment – this article
  2. A Very Brief Overview of HL7 v2 Messaging
  3. A Very Brief Overview of the SOA Suite for healthcare integration
  4. Creating a Canonical Message Model –
  5. HL7 v2 Inbound to File –
  6. Constructing file name from message content and messaging properties –
  7. HL7 v2 Inbound to HL7 v2 Outbound Pass-through –
  8. Transformation and Routing using XSL and Mediator –
  9. Adding Data Map for pass-through code translation –
  10. Automating Exception Message Handling –
  11. Externalise, “Repair” and Resubmit “broken” messages –
  12. Implementing an A19 Query Processor –
  13. Send, Receive and Translate HL7 messages using B2B Web Services
  14. Other Key Features
  15. HL7 v2 solution using JMS “the Java CAPS way” – (this article was propmpted by correspondence with Steve L)

It will take some time to produce these articles and the list may change.
I am interested in hearing from people about other topics they might like to see covered. I will consider suggestions though I am not promising that I will act upon them.
In the following sections I am briefly elaborating on what I expect each topic to cover, and presenting a solution schematic where a solution will be developed.

The article is availabe as “SOA Suite for healthcare integration Series – Series Overview” at

May 28

I notice that people used to the eGate/Java CAPS way of doing things, when looking at migrating to the SOA Suite for HL7 messaging, are trying to reproduce the pattern “HL7v2Adapter?JMS Queue”. This is not necessary when using SOA Suite but can be done if one insists. This article walks through the process of implementing this pattern using Oracle SOA Suite 11g R1 PS3.

The process will follow these steps:
1. Obtain and configure the QBrowser tool for JMS browsing
2. Obtain and configure the HL7 Sender tool
3. Create two WebLogic JMS Queues to be used in the solution
4. Create and deploy a HL7 v2 Inbound Trading Partnership Agreement
5. Submit HL7 v2 messages and inspect them in the corresponding JMS Queue
6. Repeat steps 4 and 5 for another inbound stream

The cmplete article, which can be found at, will demonstrate that Oracle SOA Suite B2B HL7 infrastructure can be configured to receive message streams over multiple inbound MLLP channels and deliver each stream to a distinct JMS destination, much as eGate and Java CAPS solutions used to do.

Apr 08

The Oracle SOA Suite 11g R1 B2B functionality can be used for HL7 v2.x delimited messaging, both inbound and outbound. I have a series of articles which provide step-by-step instructions for developing HL7 v2.x delimited messaging solutions for processing inbound and outbound messages, with varying ACK patterns –

This article discusses how an A19 Query processing solution can be implemented using the SOA Suite 11g R1 PS3.
We have a client sending a HL7 v2.3.1 A19 QRY request, asking for demographic details for a patient specified by an ID. The HL7 v2.3.1 A19 ADR response will carry a PID segment with basic demographics. The client identifies itself with MSH-3 (Application ID) of “A19QRY” and MSH-4 (Facility ID) of “CLI1”. The query processor is identified by the client with MSH-5 (Application ID) of “A19ADR” and MSH-6 (Facility ID) of “GWYQ”.

The complete article is to be found at



Dec 29

New release, v0.7, is available – see link below for downloadable archive. Throughput masurements were added. Manpages were updated.

I spend considerable time working with HL7. In the past I used SeeBeyond ICAN and Sun Java CAPS products, and OpenESB with HL7 Binding Component,  to rapidly create MLLP senders and receivers for the HL7 solutions I was building and testing. I also tried, at various times, 7 Scan, Interface Explorer and more recently HL7 Browser. For the blog articles I am writing on HL7 I need simple tooling that allows me to send HL7 v2 delimited messages from a file to a MLLP listener and receive acknowledgements, receive HL7 messages from a sender and retrun acknowledgements, and recently to combine multiple sender message streams into a single stream, with correct acknowledgement handling. The tooling has to be free for me to distribute with the projects and the articles and to use in my day job as well.

Not finding anything that would fit the bill, and that would work reliably enough, I developed my own tools.

I embellished the basic sender a bit so I could send multiple messages, one after the other, from a file, delay between successive sends, generate MSH-10, replace MSH-3-1, MSH-4-1, MSH-5-1 and MSH-6-1, and increase timeout for acknowledgements.

The tools are all old fashioned command line tools – no graphical user interface.

CMDHL7Listener – man page:

CMDHL7Sender – man page:

CMDHL7Proxy – man page:

Deprecated Distribution:

Current Distribution:

Release 0.5 and 0.7 are free to use by anyone for any purpose and will stay that way. There may not be future releases 🙂
I used HAPI 1.0.1 libraries for HL7 processing –

Oct 23

In any but the simplest of HL7 messaging environments there will be multiple sources and multiple destinations of HL7 messages. It is very unlikely that all, or even a majority of these, will use exactly the same HL7 message structures in terms of versions, optional/mandatory segments, extension Z segments, and so on. A sensible approach to dealing with these kinds of issues, and a key component of the HL7 Enterprise Architecture, is the so called Canonical (or Common) Message Model (CMM). The CMM works hand-in-glove with the enterprise architecture in which transformation to/from the CMM is performed at the edges of the integration domain. This article discusses major considerations and works through the mechanics of deriving a Canonical Message Model for a fictitious Healthcare Enterprise and implementing it using the Oracle SOA Suite 11g HL7 tooling as an example. The article will also discuss and illustrate a mechanism for injecting arbitrary metadata into the canonical message, generated by the B2B Document Editor, in such a way that it is ignored by the Edge-dwelling B2B infrastructure but is significant to the SOA infrastructure.

The text of the article is available at

Aug 31

In this article I discuss and illustrate a “SOA-less” solution in which the Oracle SOA Suite 11g R2 B2B receives a stream of different HL7 v2 delimited messages types (A01 and A03) using a single inbound adapter. The messages are converted into their “equivalent” HL7 v2 XML messages. I say “SOA-less” because all the work is done entirely within the B2B part of the SOA Suite – no OSB or SOA Composites are involved.

This article demonstrates one way in which different message types can be accepted through one inbound adapter.

The complete text of the article is availabloe at

Aug 30

In this article I discuss and illustrate a “SOA-less” solution which uses the Oracle SOA Suite 11g R2 B2B functionality to convert HL7 v2 delimited messages into their equivalent HL7 v2 XML messages. I say “SOA-less” because all the work is done entirely within the B2B part of the SOA Suite – no OSB or SOA Composites are involved.

The article text is available at

Jun 27

This article is a follow on to the “Oracle SOA Suite 11g HL7 Inbound Example – Functional ACK Addendum” article and the “Oracle SOA Suite 11g HL7 Inbound – Customized HL7 Message Structure and Data Validation” article.  In these articles the B2B infrastructure was configured to return the “Functional ACK” when it validated each message. The ACK was a positive or a negative ACK depending on whether the message passed validation. The ACK was generated by the B2B Layer before the message was passed on to the SOA Layer.

In this article I expand on the previous posts by configuring the B2B Layer to pass the message to the SOA Layer and pass the Functional ACK, generated by the SOA Layer on to the requester. To process a message and produce the ACK we will build and deploy a new SOA Composite.

The text of the article is to be found at

Jun 19

As Sun Microsystems, and SeeBeyond before it, Oracle provides support for integration of systems which use HL7 v2.x messaging. Unlike Sun, and SeeBeyond before it, Oracle treats HL7 messaging as Business to Business exchanges (B2B) and uses the B2B part of the Oracle SOA Suite to accomplish the task [1].

There are numerous articles on Oracle SOA Suite and on Oracle B2B. To wade through this material to get to a concise set of steps needed to get started with HL7 messaging is a chore precisely because there is so much material about the SOA Suite and so little on how to deal with HL7 suing it. I set off to work out what it takes to do HL7 messaging and to document it for myself and others.

This article walks through the installation and configuration of all Oracle software necessary to implement HL7 v2.x messaging as development / experimentation environment. It assumes a single machine with limited resources.

I expect that there will be subsequent articles in this series which will use this infrastructure to implement specific HL7 v2.x examples.

The complete article, 01_Installing_Oracle_SOA_Suite_for_HL7_exploration_v1.1.pdf, can be found at

Tagged with:
Sep 16

As a healthcare enterprise looks after patients, information is gathered about various events that take place. Information about notable events, Admissions and Discharges, for example, is recorded in Hospital Information Systems or Patient Administration Systems. These systems typically broadcast event information in a form of HL7 messages for use by other enterprise systems, for example laboratory or diagnostic imaging. A stream of HL7 messages can be intercepted and processed to derive all sorts of interesting information.

The solution developed in this walkthrough deals with Excessive Length of Stay. Length of stay is defined as the period between patient’s admission to and discharge from the hospital. Statistical average expected length of stay is typically available for different kinds of patients presenting with different kinds of conditions. A significant variation from the average length of stay for specific patients may indicate complications, treatment errors, infections and other kinds of issues that the hospital needs to investigate. Notification of such incidents may help the hospital in addressing these issues and prevent future occurrences.

In this solution the Intelligent Event Processor is used to calculate the continuously updated average length of stay over a period of time and use it to compare against each event’s length of stay. It passes, to the downstream component, all events where the length of stay exceeds the average by 1 ½ times and ignores all others.

In the initial iteration, the solution reads a stream of discharge messages, containing admission date, discharge date, length of stay, and a bunch of other fields from a file and passes them to the IEP process. The IEP process keeps the window on the last 10 seconds worth of records and continuously calculates the average length of stay over all records in that window. As records are added to and removed from the window the average is recalculated. As each record is seen its length of stay is compared to the average length of stay of all records in the window at the time. If the length of stay in the current record is less then or equal to 1 ½ times the average at the same time the record is discarded. If the average is greater the record is ejected to the output and ultimately written to a file of exception records.

In a subsequent iteration the solution is modified to accept messages from a JMS Queue. This modification allows the solution to use the stream of discharge messages produced by the HL7 Processor solution, discussed in “HL7 Processor Demonstration – GlassFish ESB v2.1”,

In a further modification the solution is configured to send notification messages to another JMS Queue. Notification messages are processed by a different solution and sent to an email recipient.

The document, “Excessive length of Stay Healthcare IEP Demonstration”, can be found at

The pre-built projects in the “Excessive length of Stay Healthcare IEP Demo Companion Archive” can be found at

preload preload preload