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

An Introduction to SAML

Security Assertion Markup Language (SAML) is an XML-based open standard for exchanging authentication and authorization data between parties – typically an identity provider (IdP) and a service provider. A standard SAML integration does not involve the exchange of a password and simply operates on a system of trust wherein only the user’s identity is passed between these providers.

SAML is commonly used in instances where an end user has access to many different applications or products, such as the health care or higher education fields. Instead of having to login with a username and password for each of these applications, a user simply has to authenticate once in order to access any of them. This is commonly referred to as single sign-on (SSO).

After authenticating with the IdP, a user has access to multiple applications and/or products due to a previously defined trust relationship. This trust relationship is facilitated through the use of certificates, which have been previously distributed between the IdP and the service providers. These certificates are used to “sign” all communication between the IDP and service providers.

A sample SAML integration:

  1. A trust relationship is defined between the IdP and each service provider through the use of installed certificates.
  2. An end user authenticates into the IdP using a single set of user credentials (username and password).
  3. A user selects a service or external system to log in to.
  4. The IdP sends a “signed” SAML Response to the service or external system with the user’s identity.
  5. The service or external system validates the SAML Response.
  6. The browser redirects the user to their requested resource – typically a welcome or landing page.

This is part one of what will be an ongoing series on the topic of SAML. If you have any questions or comments, please post below – or contact us.

Is Encryption Required by HIPAA? Yes.

Ok… technically that’s not 100% true.  The HIPAA Security Rule doesn’t explicitly require encryption of data at rest, or even during transmission. However, this doesn’t mean what people think it means and that misunderstanding is getting a lot of folks into trouble (literally).

The HIPAA Security Rule is a 3-tier framework broken down into Safeguards, Standards and Implementation Specifications. Within the Technical Safeguards, both the Access Control Standard (i.e. data at rest) and Transmission Security Standard (i.e. data in motion) have an Implementation Specification for Encryption. Neither of them are “Required,” but are both listed as “Addressable.” So we’re done, right? Not so fast…. From the HHS FAQ:

“In meeting standards that contain addressable implementation specifications, a covered entity will do one of the following for each addressable specification:

  1. Implement the addressable implementation specifications;
  2. Implement one or more alternative security measures to accomplish the same purpose;
  3. Not implement either an addressable implementation specification or an alternative

So… it’s not required.  But HHS goes on:

“The covered entity must decide whether a given addressable implementation specification is a reasonable and appropriate security measure to apply within its particular security framework. For example, a covered entity must implement an addressable implementation specification if it is reasonable and appropriate to do so, and must implement an equivalent alternative if the addressable implementation specification is unreasonable and inappropriate, and there is a reasonable and appropriate alternative.”

The key phrase here is “reasonable and appropriate.” As in, encryption IS required if it’s reasonable and appropriate to encrypt. This is really important and we’ll come back to it later. HHS continues:

“This decision will depend on a variety of factors, such as, among others, the entity’s risk analysis, risk mitigation strategy, what security measures are already in place, and the cost of implementation. The decisions that a covered entity makes regarding addressable specifications must be documented in writing.  The written documentation should include the factors considered as well as the results of the risk assessment on which the decision was based.”

Basically what they’re saying is that you don’t “have to” encrypt, but if you choose not to you’d better be prepared to demonstrate, in writing, why you believe that. Then, in the event of an audit, The Office for Civil Rights (OCR) will review your documentation and determine whether or not they agree with you.

Mobile Devices

If you check out the HHS Wall of Shame where breaches involving 500 or more patients are posted, you’ll notice a very large number of lost or stolen laptops that were not encrypted.  In a comment about the settlement with Hospice of North Idaho that involved a stolen laptop, OCR Director Leon Rodriguez said: “Encryption is an easy method for making lost information unusable, unreadable and undecipherable.”  And it really can be easy. You can purchase inexpensive encrypted hard drives for all new laptops and install 3rd party tools on old ones (see Five Best File Encryption Tools from Gizmodo).  If you have mobile devices that may contain PHI and are not encrypted, stop reading and go encrypt them right now. Seriously.

The Data Center

Many people have bought into the idea of encrypting mobile devices, but not their servers. To an extent this makes sense given that most breaches have resulted from lost or stolen devices and not so much from hacking.  However, Leon Rodriguez noted in a presentation at HIMSS13 that he anticipates hacking to be a threat that will likely grow as time goes on, and the best protection in that scenario is data encryption. This is a more complicated issue for sure, but there are lots of tools and techniques that make this very doable. I plan to elaborate on those options in an upcoming post.

Data in Motion

I’m not going to get into much detail on this one. Use SSL, VPN, or some other method of encryption when transmitting your data over public lines. Period. If you have a scenario where it is “reasonable and appropriate” to send someone’s health information in plain text over the public internet, I’d love to hear about it.

Conclusion

You’re required to encrypt PHI in motion and at rest whenever it is “reasonable and appropriate” to do so. I’ll bet that if you do a proper risk analysis, you’ll find very few scenarios where it’s not. Even if you think you’ve found one, and then you’re beached, you have to convince Leon Rodriguez and the OCR, who think encryption is both necessary and easy, that you’re correct. Is that an argument you want to be making in the face of hefty fines?  Not me… and that’s why I have convinced myself that encryption is required by HIPAA.

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