Pipes, Hats … and OpenClinica: Digesting HL7 in OpenClinica

If you’re an OpenClinica administrator somewhere, the chances are good somebody has asked you: “Can OpenClinica handle HL7 messaging?”

“No, it doesn’t,” you’ve said.

You probably said that with a sigh of relief because HL7 is a byzantine data exchange standard whose complexity keeps an army of consultants employed and drives neophytes like myself to madness.  The HL7 2.X specification uses eye-fatiguing pipes (“|”) and hats (“^”) as delimiters and has been referred to by experts as the “non-standard standard” (see this). Unfortunately, it is also the lingua franca of health-care messaging currently, and will likely continue to be for a long time to come.

So, it is with a heavy sense of resignation that we here at Geneuity are taking up the challenge to make OpenClinica fluent in HL7. As a contract clinical laboratory, we are particularly interested in having OpenClinica able to digest HL7 ORU messages that convey lab results.  This article details our first pass at the problem.

Our approach is shown in Figure 1.  It makes use of Mirth and a new web service in OpenClinica developed by Geneuity called EventDataInsert.  As shown, an HL7 message containing a lab result is sent by TCP to a Mirth channel which is configured to transform it into a SOAP message palatable to EventDataInsert.  EventDataInsert reads the message and then sees if the specimen has already been accessioned into OpenClinica.  If so, it inserts the data into the underlying database and signals a successful entry.  If not, it does nothing and signals a rejection.  These signals are transmitted back to Mirth which issues a standard HL7 acknowledgment (ACK) message coded with either ‘AA’ for ‘Application Accept’ or ‘AR’ for ‘Application Reject’.  It is the responsibility of whoever (or whatever) sent the HL7 message in the first place to follow up when a lab result is rejected.

To develop this strategy, we used several tools.  To generate HL7 test messages, we utilized the HL7 generator (freely available here) made by the people responsible for the ELINCS initiative.  To send and receive HL7 messages to and from Mirth via TCP, we used Netcat, another freely available utility.

And there you have it!  Of course, the HL7 standard covers much more than the delivery of lab results, but this exercise is most relevant to our concerns and represents an important first step in making OpenClinica talk the talk when it comes to HL7.

HL7 Strategy for OpenClinica

Figure 1:  HL7 Strategy for OpenClinica

First, a HL7 message conveying lab results is sent to a Mirth channel listening for TCP requests.  Mirth parses the message and transforms it into a SOAP message which it then hands off to the EventDataInsert webservice listening within OpenClinica.  EventDataInsert looks to see if the specimen to which the lab result pertains has been accessioned into OpenClinica’s underlying database.  If so, it inserts the results and signals back to Mirth that fact.  If not, it enters nothing and signals back to Mirth that it did nothing.  Mirth digests these signals and sends back to the sender an appropriately configured ACK message via TCP.

CDASH: A new way to standardize data elements

Many people who work with EDC systems have heard of or been impacted by CDISC, Clinical Data Interchange Standards Consortium.  CDISC’s mission is to develop and support global, platform-independent data standards that enable information system interoperability to improve medical research and related areas of healthcare.  They have many different initiatives, but one of their newest ones promises to aid the development and use of electronic Case Report Forms (eCRFs), the foundation of an EDC system.

Clinical Data Acquisition Standards Harmonization, (CDASH) aims to standardize ways of collecting data in a clinical trial.  The current EDC landscape has hundreds, even thousands, of different eCRFs that capture essentially the same information, but with CDASH’s initiative one common data element can be used for each piece of information collected.

The initiative is not being pushed to enforce the way an eCRF looks and feels; rather, it seeks to standardize the way the fields and data on a form map to a database.  Allowing users to create eCRFs with one standard in mind will allow the users to re-use their work again and again rather than having to create new eCRFs the next time they begin a study.

By mapping OpenClinica CRFs to CDASH content standards (element name, definition, and the related metadata) users of OpenClinica can access a basic set of global data collection fields with semantics agreed upon by representatives from Contract Research Organizations (CROs), Academia, Government and Industry.  These CRFs can be found in the OpenClinica Enterprise CRF Library.