Archive for the tag 'HL7'

5 Challenges to Overcome En Route to a Successful HIE Migration


Recently, Galen’s technical consultants took part in a large state Health Information Exchange’s (HIE) migration from Axolotl HIE to the Orion HIE platform.

Often times, connecting a participant to an HIE means compromising between two sets of standards to find a maintainable medium.  Having a flexible, driven team of passionate consultants committed to the long-term success of a project can be the difference between a successful and an unsuccessful endeavor.  These are some of the challenges faced throughout the HIE migration that were overcome with our technical experience and dynamic solutions.

Normalizing Converted Data With Minimal Background Information

When migrating from one HIE vendor to another, it is imperative to backload historical data to perpetuate the data repository built up over years on the legacy system.

Decisions are often made in healthcare IT to overcome limitations of a system.  These choices can cause unforeseen downstream issues, especially when migrating to an HIE with a different set of specifications and standards.  In many situations, decisions made in the past aren’t well tracked and the reasoning for handling the data isn’t easily discernable.  Over long periods of time, these issues become magnified, especially when they involve multiple data sources.  As issues are discovered, adjustments are made to mappings and resolutions are developed on the fly, though the documentation around these decisions is sometimes inadequate and difficult to follow.

Galen’s team of interface analysts is uniquely equipped to identify patterns in data sets and develop solutions to overcome the transition to a new HIE.  With our extensive interface knowledge and experienced team of healthcare IT professionals, Galen can provide a deep understanding into how data is changing over time, discern the specific reasoning behind why decisions were made, and determine how best to move forward with the information and tools that are available.

Managing Reused Patient Identifiers

HIE systems require that patient identifiers (e.g. MRNs) be unique.  That is to say, each patient identifier that comes into an HIE from a particular facility should be distinct to a patient, and should never be reused on another patient.

There are instances where this isn’t the case in HIT, for example, reference labs will sometimes recycle patient identifiers used in previous years.  In order to retain the uniqueness, identifiers need to be intelligently manipulated.  Galen’s interface analysts have experience dealing with this situation and can help partners develop customized solutions to overcome this challenge.

Managing Reused Message Control Identifiers

Some interface engines also require that each HL7 message have a unique message identifier in the MSH-10 field.  If an HL7 comes in with the same message ID as one that was previously processed by the system, the interface engine knows to reject that message (typically, this would be a repeat message).  Some participants do not or cannot send a unique MSH-10.  In these cases, Galen’s analysts have collaborated with partners to develop creative solutions to circumvent these limitations when converting data from legacy systems.

Managing Order Codes with Multiple Descriptions

Order codes should be unique to the order description they align with, although there are instances in the real world where this isn’t the case.  Sometimes, facilities send the same order code (OBR-4.1) with distinct order descriptions for results that are actually different.  Take a microbiology result for example: a facility might provide an order code of MICRO with an order description (OBR-4.2) of URINE CULTURE, but they might also send an order code of MICRO with an order description of BLOOD CULTURE.

In some HIE systems, the first description loaded with the order code of MICRO is the description that will always display in the patient portal whenever a subsequent result with the same code of MICRO is processed, regardless of the actual description code.  Let’s say a patient first has a URINE CULTURE resulted, then a few months later, that same patient has a BLOOD CULTURE resulted.  That BLOOD CULTURE result is going to display in the patient portal as a URINE CULTURE because the system has already been populated with:

Order Code Order Description

Galen has developed a methodology for working through this issue.  Our analysts can help organizations create a customized strategy for appropriately handling order code and order description data to enable an HIE to correctly display order codes with multiple descriptions.

Properly Linking Microbiology Results to Susceptibilities

Microbiology results are especially tricky when dealing with any consuming system.  Depending on whether the result indicates a need for further testing, microbiology HL7 results contain either:

  • Just the initial microbiology result
  • Both the initial result and susceptibility follow up results

When a microbiology result does require a susceptibility follow up, it will typically have two OBR segments.  The first OBR segment will pertain to the original culture like a Blood Culture or a Urine Culture.  The second OBR segment will contain information regarding results for the associated susceptibility.

Many systems require that the child (susceptibility) report contain elements from the parent result, though participants don’t always send this information in the parent report appropriately.  Galen is adept at identifying the patterns with which a participant sends their microbiology results, and our consultants have extensive experience developing logic to appropriately process microbiology results into consuming systems.

Overall, there are many challenges that can arise when converting from one HIE to another.  Galen Healthcare Solutions’ experienced interface analysts and HIE specialists can work with you to ensure a successful and timely migration that best serves your patients and physicians.  For additional information, feel free to contact us!

Nine Considerations To Take When Adopting A New Interface Engine

Cloud 2

As previously discussed in our comparison of point-to-point vs interface engine connectivity, as healthcare networks grow, so does the need for more robust interoperability.  When selecting an interface engine, there are several areas of focus to consider.  Intersystems, an Integration Engine company, offers some great tips and tools for finding potential candidates to handle your integration needs.  They suggest looking at the following categories in order to properly assess whether or not an interface engine will be capable of effectively meeting your organization’s needs:

  • Reliability
  • Scalability
  • Ease/effectiveness of interface development
  • Easy/effectiveness of system management
  • Quality of support
  • Foresight
  • Interoperability
  • Robustness and ease of use of analytics
  • Business growth


Does your interface engine have a plan for minimizing system downtime should an emergency occur?  Should data be lost in an emergency, what sort of plan is in place to recover/retain susceptible data?  Does the company have a history of exemplary performance in the industry?  What do others in the same field say about this interface engine?  Do you have any contacts you could reach out to for a word of mouth recommendation about the quality of the software?  Does the interface engine guarantee the delivery of their messages?


Is the interface engine capable of handling your organization’s level of traffic today, and are they capable of handling the message load of the future?

Ease of interface development

Is there a simple, consistent graphic development environment that is used?  Is it possible to create the HL7 Interfaces without intimate knowledge of certain programming languages?  Is there the ability for sophisticated users to extend functionality of the system should there be unorthodox interface needs?  Is the ability to route messages to different destinations based on “rules” (content in the messages or the type of message)?  Does the interface engine have compatibility with several types of standards (HL7, XML, X12, SOAP, etc.)?

Ease of management

Are there dashboards available for viewing system statuses at a glance?  Are there systems for automated alerts via email, phone, or other communication avenues for various reasons?  Does the interface engine have the ability to aggregate, analyze, and report on messages flowing through the system without using external software?  Can users stop, start, and upgrade individual interfaces while the system is running?  Can users track and trace messages as they move through the system in order to assess how the messages change over time and how long processes take?

Quality of support

Are the staff of your integration company knowledgeable, dedicated, responsive, and experienced?  Do they offer support in your time zone during your operating hours?

Designed for the future

Is there support for a wide range of communication standards and development technologies?  Is the engine specifically designed for creating connected systems in healthcare?  Are business activity monitoring and business intelligence capabilities available?  Is there a database management system for the stores of messages and data?  Is there end-to-end management?


Does the engine handle a wide variety of formatting standards and delivery methods? Does the system handle a wide variety of protocols and profiles that are becoming more common in healthcare?  Does the system support a wide variety of B2B standards?

Business Insights

Can the interface engine analyze real time information from all your sources in an easy-to-access and understandable way?  Are messages being stored and can you usefully search those messages to find insights and valuable information for your business?

Business Growth

Is the business growing and getting better?  Will your interface engine keep growing and building alongside you?  Do they have a positive track record, a history of innovation, and a focus on backwards compatibility?  The solution you choose should be able to meet the changing demands of the industry for at least the next 10-15 years.

With all this being said, it’s important that a healthcare organization have a team of experienced, flexible, thoughtful, and prepared healthcare professionals to complement your choice of integration engine.  Galen’s integration services team is a group of talented professionals that are fluent in HL7, Orion RhapsodyTM, Allscripts ConnectRTM, MirthTM, and SQL.  They have worked in small clinics and large hospital networks alike, and always work with the organization to find a solution that works best for them.  If you’re working with one of these interface engines and you have a solution that needs developing, please visit our Integration Services to learn more.



Corporation, Intersystems. Nine Questions to Ask Before Replacing an Interface Engine (n.d.): n. pag.

Health, Corepoint. What Is Your Healthcare Interface Approach? (n.d.): n. pag.

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.

Next Page »