Archive for the tag 'HL7'

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.

Top 3 EHR Data Integration Challenges


In response to a guest post on EMRandHIPAA, we take a look at the top EHR data integration challenges faced today:


Proliferation of point-to-point interfaces instead of using a hub-and-spoke type of model (like that which Surescripts utilizes with electronic prescribing). Unfortunately, most organizations which exchange data in and out of the AE-EHR utilize highly-customized point-to-point interfaces for orders, results, documents, etc. The point-to-point model is highly inefficient and does not adhere with a “plug and play” model that so many organizations desire.

We’ve seen Allscripts make an effort to move away from this by introducing capabilities to automatically send immunizations to state registries via the Allscripts Hub by  simply modifying configuration setting (with the caveat that Allscripts has worked with the state to develop the intergration).  We’ve also witnessed companies like Medicity and its Novo Grid technologywhich offers electronic communication between physician practices, hospitals, and other health care providers. Novo embeds agents (small but powerful Java programs) in hospital data centers, physician practices and other locations. The grid component is an object oriented system that can replicate an object to multiple agents and keep it in sync across locations.


As outlined in the EMRandHIPAA post, there are no mandated standards for EHR vendors to follow, thus making it difficult to coordinate data sharing between medical devices and other systems. Allscripts does offer the Universal Application Integrator (UAI),  which facilitates extendibility to other applications and devices. However, there is a certification process that needs to be pursued. In terms of the point-to-point interfaces previously mentioned, the Allscripts proprietary (API)  Application Programming Interface(which consists of inbound and outbound stored procedures to their primary clinical DB) does not segment out the data and configuration components of clinical exchange, something touched on in detail in a previous Galen Blog post.  Lastly, most vendors have their own specifications for HL7 message definitions. For instance, Quest may send ordering provider in OBR-16 in an interfaced result ORU message while LabCorp sends this in ORC-12. Another example is communication of “Ask at Order Entry” questions – something Quest expects to receive in repeating OBX segments while LabCorp expects this across Z-segments in an interfaced order ORM message.

Adherence to HL7, proprietary approaches.


John Halamka bravely predicted that when health IT vendors and providers began adopting new standards, the cost for interoperability would plummet: “We know that we won’t get precisely plug and play—this is a journey,” Halamka told Government Health IT. “But each year, we will get more constrained. We are going from a $20,000 -$30,000 venture hopefully to $5,000-$10,000.” Unfortunately the numbers quoted are accurate – and provide a high barrier to entry for smaller groups looking to electronically exchange data. There is the flip-side to cost and that is the ROI, which could include reduction in direct annual labor costs, elimination of non-billable tests, and elimination of lost charges.


The benefits of health information exchange are well documented. As outlined in the EMRandHIPAA post, there is a need for a “consistent, secure and reliable way to capture and share patient data among all systems and healthcare providers,” especially given that benefits in improved coordination of care and reduction of medical errors.

Next Page »