Archive for the tag 'HIE'

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!

#HIPAA: When our worlds collided


Co-written by Matt Hoover and Matt Leyva 

On Wednesday evening, ESPN reporter Adam Schefter tweeted an image of an NFL athlete’s personal medical records that set the twittersphere ablaze and had #HIPAA trending throughout the nation.  This setup an interesting Thursday morning for us here at Galen, where three of our biggest passions, Healthcare IT, patient advocacy, and professional sports, collided (well, four if you count fireworks safety – seriously, ask your favorite Galeneer about that).  The reactions ranged from disbelief to disdain, but predominantly disappointment.  These types of events erode the inherent trust in a patient-provider relationship that we collectively work to cultivate as an industry.  As trust is lost, patients may start intentionally withholding pertinent information from their providers which could be critical to ensuring that proper care is delivered at the appropriate time.

Initially, Schefter was inundated with backlash for this blatant HIPAA violation.  Was his decision to tweet the image morally justifiable?  We all have our opinions, but let’s not get into that right now.  Was Schefter in the wrong?  From a HIPAA standpoint, both he and ESPN are non-covered entities that fall beyond the bounds of HIPAA regulations, and his actions are legally defensible by the First Amendment freedom of speech clause.  The primary offender, assuming this patient did not provide consent to share his medical records, are the parties belonging to the covered entity who initially leaked the information.  As with similar cases, this flagrant disregard for HIPAA laws will almost certainly warrant punishment – up to $50,000 in civil penalties and up to $250,000 with a maximum of 10 years imprisonment for criminal penalties.

Situations like this will make patients think twice before sharing information due to fear it may not remain private.  It is counterproductive to the efforts so many in the HIT community are pushing to accomplish, especially as we strive towards increasingly connected systems and improved interoperability with applications such as Health Information Exchanges (HIE).  Whether the victim is a Grammy-winning superstar, an Oscar-lauded actor, an all-star athlete, or an average Joe, this isn’t the first instance of unauthorized individuals accessing and/or disclosing ePHI.  It’s probably not the last either, but if there is a silver lining takeaway, maybe it’s that this incident raises awareness and precipitates a change in behavior relating to HIPAA, both in the HIT arena and the media.

For any additional questions about HIPAA or the guidelines that Galen and the HIT industry follow, feel free to contact us at




Point-to-Point vs Interface Engine: Does your interface setup suit your needs?


In today’s healthcare landscape, many organizations are faced with the question of how to connect their EHR to disparate systems.  Hospitals and clinics need data from their lab and imaging vendors.  They also need to be able to send information to referral clinics and to Health Information Exchanges.  Today, providers require a dependable and effective means of exchanging information with partners and affiliates.  At the end of the day, the main objective of interfacing is to “streamline workflow and the revenue objectives of efficiently establishing productive relationships with referring physicians” and other systems.  To accomplish this feat, healthcare orgs typically adopt one of two strategies, each with its own advantages and disadvantages: point-to-point interfaces or an interface engine.


In a point-to-point interface, the receiving organization (the recipient of the healthcare data) provides a set of specifications to the sending organization including:

  • What type of data will the system be receiving?
  • What format does it need to be in?

The sending organization then builds an interface to meet those specifications.  The interface is only used for that one line of communication.  For every new application that requires an interface, this process needs to be repeated over and over again.  There are advantages and disadvantages to a point-to-point interface.


  • This method is cost effective for interfaces that do not change or do not change quickly.


  • This method can become expensive if the healthcare organization requires multiple interfaces to be built
  • This method doesn’t provide a way to monitor interfaces to determine connection status
  • This method doesn’t provide the ability to review message logs, to determine whether or not acknowledgements were received, or to go back and look at the history of traffic over a particular interface
  • Interface complexity increases as the number of interfaces grow – managing the communication environment becomes challenging


Instead of vying for a point-to-point (one-to-one) solution to interfacing disparate systems, a growing number of healthcare organizations are turning to interface engines in order to meet their integration needs.  An interface engine transforms or maps data to the receiving organization’s requirements after it leaves the sending organization’s system.  If a value needs changing or if a lookup table needs to be used to switch from one set of values to another, interface engines can easily do this.  They are built with a one-to-many concept in mind, and allow for message traffic to be easily monitored and maintained.  In addition, there are several other advantages to using an interface engine:


  • Reduces the dependency on multiple vendors to make changes in the format of messages to be sent or received
  • Leverages one import or export module from core applications (e.g., HIS, RIS, LIS, etc…) and distributes interfaces to multiple applications productively
  • Improves physician and client support through proactive interfacing monitoring and message log management
  • Enables flexibility to adapt to different HL7 message standards, XML healthcare standards, etc… as well as different application data format specifications
  • Lowers overall interface cost by repurposing an application’s import/export module to multiple applications


  • One potential disadvantage of using an interface engine is it adds another piece of software that needs to be maintained and/or worked by your staff in order to maintain interfaces.  If your organization only has one or two interfaces, it may be easier to use the point-to-point solution.

When one considers the effort involved in maintaining several point-to-point interfaces and the growing emphasis on interconnectivity in healthcare, the disadvantages of managing a new piece of software start to look minor. If your organization is planning on connecting with multiple sources, this will require the development of multiple interfaces.  Chances are an interface engine solution may make sense.

When selecting an interface engine, there should be several areas of focus.  For a summary of helpful tips and tools for finding potential candidates to handle your integration needs, look out for our second installment of this Healthcare Interoperability series.  The second installment will include a summary of various areas an organization should focus on when considering an interface engine and will provide guidance on how to properly assess whether or not an interface engine will be capable of meeting your organization’s needs effectively.  To find more about our suite of solutions, check out our Technical Integration Services page.



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.


An Interview From The ‪#‎HIMSS15‬ Floor With Galen’s CEO Jason Carmichael

Jason Carmichael, CEO of Galen Healthcare Solutions, explains how Galen helps increase interoperability, leverage Big Data, and supports a platform that predicts the cost of an episode of care while helping design coordinated care plans.

InterSystems Global Summit 2015


If you happened to miss the tweets from @GalenHealthcare, InterSystems Global Summit took place March 8th-11th  in Orlando, FL.  As an implementation partner of InterSystems, members of Galen have attended this conference before, but this was a first for a colleague and myself.  For those of you who don’t know, InterSystems is a global technology company that offers products like Caché®, Ensemble®, and HealthShare®.  They are the main technology provider for companies like Epic, HIXNYSM, HIETexas, as well as many non-healthcare companies.

The Global Summit was a chance for InterSystems, along with its technology partners, to strategize for the new year, share methodologies, educate one another, and celebrate the past year’s successes.  One theme that particularly resonated with me was Interoperability, which has been my main focus for the last five years while working at Galen.  Over time I have gained skills and experiences that help streamline an integration project, but because standards are never strictly followed, or consumers and senders observe different versions of the same standard, an integration does not progress without a few bumps in the road.  While at the conference I picked up a great saying that I hadn’t heard before, “Once you’ve developed one HL7 interface, you’ve developed one HL7 interface”.

Interoperability is my third favorite buzz word phrase behind Big Data and Game-Changing Deep Dive.  Everyone talks about it and everyone claims their solutions are viable.  I believe the true key to interoperability is not to follow the latest and greatest standard but to have the flexibility to support a variety of standards within your product.  InterSystems has been able to accomplish this with C-CDA.  InterSystem’s HealthShare® provides an effective methodology to facilitate version agnostic document exchange.  All documents received into HealthShare® are converted to Structured Document Architecture (SDA) which enables the transformation to any of the 20+ recognized Document Standards. SDA is also considered future proof because you have the ability to create new file formats as the standards change.  This was extremely interesting to me after having dealt first hand with limitations of generating specific document standards to comply with a multitude of receiving systems.

If you would like more information about how Galen can help you with the InterSystems suite of products please contact us at

Next Page »