Mirth Connect – Not Just HL7

Mirth Connect is an open source application used for healthcare data integrations, specifically designed for HL7 interfaces. It is widely used for transfer of health data between two parties in an order to results cycle. But what happens when you need to transfer data to another party who isn’t using an HL7 interface? Limiting your inbound/outbound capabilities to only the HL7 format may prevent adding new customers. But, adding a second interface/solution may not be worth the cost of adding the new customer. The need to invest in a second solution is resolved by the different Connector Types available within Mirth Connect.

In this post, I am going to show you an example of how to interface HL7 data to a Web Service. We implemented this back in 2012 for a client. Our client had an existing HL7 interface and was receiving HL7 orders, processing the claim, and sending back HL7 results. They had a potential customer also looking for an electronic data transfer. However, they were not using HL7 formatted data. The potential customer used an application that received data via a secured SOAP request. Because this was a single client, it was unlikely that building a separate interface specifically for the integration would be the best business decision. So, we explored the possibility of using existing functionality (Mirth Connect) to send data to this web service.

Mirth has the ability to transform data between multiple formats. In this case, we were able to use the JavaScript writer to take the necessary data points (via Source Transformers) and complete the proper SOAP request. While Mirth Connect offers a Web Service Connector Type, we found the best flexibility in the JavaScript writer, where you can customize all the functionality and you are not limited by the default behaviors of the template.

Check out our example below, and find more information on Mirth Connect here: http://www.mirthcorp.com/products/mirth-connect

// open a connection to the Web Service
var url = new java.net.URL("https://testinterface.com/Document.asmx");
var conn = url.openConnection();

// set the connection Timeout
var connectTimeout = 30000;

Here we are returning the XML from our Source tab under the Transformers. This isn’t the only way to do it, but this worked best for us and our current solution.

var messageString = messageObject.getEncodedData();

You could also do something like this, where you build out the Request XML and use Transformer variables that you include as XML Node Text

var messageString = "<SOAP:Body><Patient>" + messagePatient + "</Patient><MRN>" +  messageMRN + "</MRN></SOAP:Body>"

conn.setConnectTimeout(connectTimeout);

Here we needed to use Request Headers, which we found easier to setup in the JavaScript writer than the Web Service Connector.

conn.setRequestProperty("ID", "123");
conn.setRequestProperty("USERNAME", "ALGONQUIN");
conn.setRequestProperty("PASSWORD", "PASSWORD");
conn.setRequestProperty("Content-Type", "text/xml; charset=utf-8");
conn.setDoOutput(true);

// Write our XML data to the Web Service URL
var outStream = conn.getOutputStream();
var objectStream = new java.io.OutputStreamWriter(outStream);
objectStream.write(messageString);
objectStream.flush();
objectStream.close();

var inStream = new java.io.BufferedReader(new java.io.InputStreamReader(conn.getInputStream()));

Advertisements

How The Direct Project Will End Faxing In Healthcare

What is the Direct Project?

It’s an open source initiative being convened by the Office of the National Coordinator (ONC) to establish a means for secure communication of medical records between providers, laboratories, hospitals, pharmacies, and patients. Rather than devise some elaborate scheme and then cram it down the public sectors throat, the ONC decided to ask for help in developing a standard that used existing technologies to establish a nationwide exchange. The private sector stepped up to the plate with big name participants including Microsoft, Google, IBM, GE, Intel, and many of the major EHR/HIT providers.

How does it work?

To oversimplify, it’s basically secure email and it can be configured so that you use your existing email client (i.e. Outlook) to send and receive secured transmissions.

Sure, the underlying technologies can sound complicated. The Direct Project Overview describes the technical implementation as follows:

  • Content is packaged using MIME and, optionally, XDM
  • Confidentiality and integrity of the content is handled through S/MIME encryption and signatures
  • Authenticity of the Sender and Receiver is established with X.509 digital certificates
  • Routing of messages is handled through SMTP

To the untrained eye that’s a lot of acronyms and probably sounds like a monumental task to implement. The truth is, as far as technology goes, we’ve all been doing this stuff for a long time. That’s the beauty of the solution that the Direct Project and its community have established.

Are people actually using it?

Absolutely. The original pilot programs can be seen here and new ones are popping up everyday. For example, Clinician-to-clinician Direct Messaging just went live in New York State). Many Electronic Health Record (EHR) providers are adding these capabilities to their platforms. Personal Health Record (PHR) platforms like Microsoft Health Vault already utilize Direct messaging to allow patients to send and receive secure emails with their providers.

There is a problem though…

In order to send secure messages, you must establish a trust that ensures the sender and recipients are who they say they are. Users establish this trust with their Health Information Service Provider (HISP) – a role often fulfilled by their Regional Health Information Organization (RHIO). With this, the individual can easily exchange secure communications with other users who subscribe to the same HISP. The problem is that you typically cannot send a Direct Message to users who subscribe to another HISP. The ONC calls this “Pockets of Automation”. The technology is there to do it, but the HISPs effectively don’t yet trust each other (at least not enough to hand off patient data).

The ONC and the Direct Project community are on it. They held the Direct Scalable Trust Forum in November of 2012 and Deloitte Consulting released a report on their findings on February 6, 2013. As usual, the project community has set some aggressive goals and agreed on the following targets:

  • Feb 2013 – ONC to provide a “Ready to Go” set of policies, pilots, and education for vendors
  • Apr 2013 – Accreditation bodies formed, operating, and ready for business
  • Sep 2013 – Half of HISPs participating in accreditation

Ok… so what does all that have to do with faxing?

The federal government does not want you sending personal health information (PHI) via fax and as soon as they are able, they will make it illegal to do so (and unless you’re taking some pretty specific steps today, one could argue that it’s already not HIPAA compliant…. but that’s a whole other post). The problem is that faxing is ubiquitous in healthcare today and the industry simply cannot survive without it. As soon as the Direct community resolves the “HISP trust issues”, all of the pilot programs will quickly become connected and natural pressures of competition (not to mention Meaningful Use) will cause Direct Messaging capabilities to spread like wild-fire. Once there is a reliable, national network for securely exchanging PHI, non-secure methods like faxing will fade away for good.

For more information on the Direct project, check out the wiki.

For information on how to get started, check out the Reference Implementation Workgroup