Archive for the tag 'HL7'

Can HL7 solve your Meaningful Use needs?

By now most healthcare organizations are knee-deep in Meaningful Use (MU) – but a new year means a new stage of MU, which means new requirements, new opportunities for solutions, and new pressures to find the right solution for your organization. That’s where we come in.

Next week Wednesday, February 18, Galen will be presenting a webcast on HL7 interfaces and how they fit into the Meaningful Use puzzle. The focus will be on Meaning Use Stage 2, as only 1% of hospitals and Eligible Professionals completed attestation for that stage in 2014; the bulk of qualified organizations will attest for Stage 2 in 2015 and 2016. The webcast will cover this year’s requirements, thresholds for attestation, new menu objectives, and Clinical Quality Measures.

HL7 timeline

We will also give a brief overview of HL7 messaging and its role in interoperability. The HL7 standard is used by 95% of U.S. healthcare organizations and boasts backwards capability – meaning HL7 is able to be integrated into nearly any existing information system. We will select seven MU2 objectives (shown below) and take an in-depth look at which HL7 interfaces would be appropriate as solutions.


Next week’s webcast is intended for an audience that have already been exposed to the basics of both Meaningful Use and HL7. However, we have previously presented separate webcasts for beginners on both topics, which can be found on Galen’s Wiki (notably, here are the links for the HL7 Fundamentals webcast and the MU2 Requirements webcast).

You can register for the “Your HL7 Interface and What It Means for Meaningful Use” here.  We hope you can join us!

Let My Data Go!

I recently had a nice chat with a colleague analyzing HIT industry trends for Kalorama Information. Kalorama does industry research for the medical and life sciences for many of the major news and consulting organizations. I got in touch with her specifically because of Kalorama’s analysis on EHRs in 2012 which was used by Bloomberg Government for their (very expensive) EHR industry analysis for provider and vendors. She found that in 2012 one of the most immediate challenges for providers was implementing EHR systems that meet meaningful use standards. She also found that vendors were having trouble with interoperability and usability.

Fast forward to 2013; a lot has changed. Epic has grown to dominate many markets. Allscripts has a new CEO and a few new toys to play with. eClinicalWorks has become a force to be reckoned with in the small practice space. However, the challenges the providers are facing have changed. My colleague and I talked for a while about various organizations we each have worked with and came to the same conclusion: providers are now having trouble with interoperability and conversions of data.

2013 Priorities

The majority of physician offices have implemented EHRs, but they must now communicate with other entities such as HIEs and ACOs. With the increase in mergers and acquisitions, we are also seeing an increased demand for conversions from one system to another. These problems involve a thorough understanding of the underlying data structure as well as a solid foundation in interoperability standards such as LOINC, HL7, SNOMED, and CDA. The vendors have the expertise to work on the problems for their products, but they are not enthusiastic about helping clients switch off their platform. Selling the EHR has been the primary goal for vendors in the past, not technical support that moves a client away from their product. Vendors are under the assumption that if they make switching off their product difficult, then clients will be less likely to undertake the conversion or integration with a product that is not part of the vendor’s family of products. While this is definitely true for disgruntled clients, it only makes it frustrating for clients who do not have a choice in the products they work with. This reality has led to some very important questions.

Where is an organization to go when their own vendor is not supporting their efforts? How do organizations extract meaningful data from such complicated or cloud based databases? How can we become self-sufficient in managing our data? How does an organization meet new institutional and government requirements? Galen can help clients with these challenges, but vendors need to help by making products that play nice with others.

At the end of our conversation my colleague and I simultaneously came to the same conclusion: “Organizations feel like their data is being held hostage!

De-Identify Patient Data

Have you ever provisioned a new environment and need to populate it with quality, robust patient data?  Or have an old environment with great patient data but need to de-identify the patient data? Well so have we…

I was recently tasked with pulling a bundle of HL7 messages. The messages consisted of ORUs (lab and rad results), MDMs (doctor’s notes), ADTs (registration), and SIUs (scheduling) of twenty-five patient’s transactions over a five-day period.  This resulted in 1400 HL7 messages with live patient data. So just to recap, we have real life scenarios starting with registration of a patient to radiology, lab, and transcription information. Awesome!

We’re done… right?

Well this makes someone training providers or someone testing the new functionality of an application happy, but what about someone at HIPAA? We need to make sure if you we were to try and track down a patient we get a response like below.


We need to figure out a way to not compromise the patient data we compiled without leaving a trace. So what does that mean? We want to keep the patient orders date ranges consistent and adhere to HL7 message protocol without being able to figure out if your neighbor recently had a complete blood count (CBC). We could manually track down the patient sensitive data and update it but that is unreasonable. Luckily Inner Harbour Software has a great tool that accomplishes everything above called HL7Spy. The custom code functionality uses C# and will transform the patient data for you, while keeping the date ranges intact. I.E. if a CBC was ordered and two days later the specimen was collected; HL7Spy ensures the two-day period is maintained in the de-identified messages.

HL7Spy is a very robust and versatile tool. HL7Spy has the ability to analyze hundreds of thousands of messages and is a must have tool for HL7 integrators! I highly recommend you try their 20 day free trial (

If you also have a lot of PHI in a train, test, or development Allscripts Enterprise EHR environment that needs to be de-identified; we can help! Galen can go into these environments and run a script to scramble the patient data. We can only use a list of 200 first names and last names and replace it with all patients’ information. Only using a few specified SSNs, MRNs, addresses, etc ensures we protect the patient’s data.

City of Hope Achieves Bidirectional Lab Integration with Quest and LabCorp

We thoroughly enjoyed working with Galen on our lab interfaces project. They were experienced and guided us with expertise from start to finish. With the help of Galen we were able to implement bi-directional lab interfaces that not only meet but exceed the expectations of our clinicians. As a multi-site cancer specialty we rely heavily on lab work for our patients. With the help of Galen we have been able to significantly reduce the turn-around time to receive the clinical data required to deliver the best possible care to our patients.
-Glen Zhou, Senior Clinical Systems Analyst, City of Hope Medical Foundation

We recently assisted one of our clients—a National Cancer Institute-designated comprehensive cancer center – in standing up bidirectional lab integration with Quest and LabCorp. The project offered an additional layer of complexity in that the compendiums for the labs had to be synchronized. The project lasted 6 months in duration, culminating in a big-bang go-live in October 2012. The client now has versatility in the number of labs their end users can leverage, seamlessly integrate with, and reap the compelling benefits of bidirectional lab integration.

View this document on Scribd

The Costs of HL7 Interfaces

In the past on this blog, we’ve addressed the top data integration challenges as well as the ROI of a results interface. Recently, Health Management Technology featured a related article on the economics of interfaces. The key points from the article were as follows:


    • Opportunity Cost
    • True Investment
    • Integration is not simple
    • Pitfalls of proprietary
    • Features matter
    • Think of the future



The last point of the article is one that is often overlooked when evaluating pursuing an interface. We have seen this a great deal recently in supporting data conversions for client’s switching EHR vendors and also for conversion of interfaces to support Hospital LIS (Laboratory Information System) and RIS (Radiology Information System) vendor changes. 

When we scope out conversions, one of the first questions we pose is if there are any existing interfaces with the EHR being sunset? If they are, we immediately inquire as to the expectations of end users having these interfaces in the new system – especially with regard to the interfacing with the practice management system. It is likely that users are going to want to be able to interface demographics and appointments from their existing PM system if that is not changing. Additionally, with regard to existing result interfaces with the current EHR, as part of the conversion, contingency plans for switching to paper results may need to be explored as a stop-gap solution until interfaced results are received in the new system.

Likewise, hospitals may decide to change their laboratory radiology system, or their radiology information system. This impacts downstream subscribers to that data – namely the clinics and providers in the ambulatory setting which send their orders to the hospital for fulfillment and currently receive results electronically. This is especially pronounced with radiology integration, where an ADT interface and an Imagelink interface may be involved in addition to the result interface. Again, a question that looms is who is responsible for paying for the costs associated with migrating vendors for a lab or rad information system and associated interfaces?

We recently had one client that put development of interfaces with the ambulatory EHR on hiatus until the hospital lab decided whether they were switching lab vendors. They felt like they didn’t want to sink costs into integrations only to have them rendered obsolete months down the road when the hospital made a vendor switch.

We’d love to hear other groups experiences with vendor migration and the associated costs of migration of interfaces. Share your stories and experiences on the Allscripts Interface Developer Forum.

Next Page »