Hospital EMR Interface

Holston Medical Group’s acquisition of Lucentglow gave me an opportunity to layer HL7 interface development into my experience.  Interfaces form the connecting communication of data between disparate systems both within and exterior to the organization.  Healthcare operations are typically an amalgam of different systems to support finance, insurance processing, labs, radiology, etc.  These systems typically communicate through XML, or more commonly HL7 message formats.

​

An HL7 message created by one system isn’t (typically) immediately compatible with another.  Patient identifiers, results and other data values must be mapped from sending system schema to receiver’s requirements.  Even between identical systems, the business process requirements may require data transformation.

​

Mirth is a great tool for managing these interfaces.  With source and destination modules for database connections, data transport and transformation.  Transformations are typically coded in JavaScript.

​

One of my first assignments was a challenging one.  A client hospital was migrating away from a custom-developed EMR/radiology application to a commercial EMR.  The custom-developed EMR relied largely on open source applications such as MySQL and PHP.  As a custom-developed application, the EMR fit the organization’s business requirements very well, making adoption of a commercial application more challenging.  Interface development for this project required much more effort than simply mapping data due to the need to adjust the commercial EMR processes more closely to those already in place.

​

Although the developer of the original open source EMR was resourceful, he left minimal documentation or inline code comments.  Additionally, the hospital IT staff had recently turned over, leaving no one with understanding of the custom-application or interfaces.  This required a great deal of detective-work with me analyzing SQL data to determine the difference between a value of “Y” and a value of “YZ” in a field, for example, with only deductive reasoning and process of elimination.  This deductive process also involved interviewing staff members to uncover undocumented program logic.

​

The custom-developed EMR also provided some capability not available in the commercial EMR product, specifically, it lacked several essential elements to support radiology.  When a patient is registered, the custom EMR system leveraged a commercial radiology package to lookup the patient’s radiology film ID.  If the film ID existed, it was attached to any subsequent radiology orders, if the patient had no previous radiology visits – they were assigned a new radiology film ID number within an open source PACS system.

​

I developed interface code to receive the registration ADT message and look up the film ID number using a series of increasingly “fuzzy” matches as the PACS system relies on patient name and date of birth to uniquely identify patients which creates challenges if registration enters names differently from visit to visit.

​

Making the project more challenging, there was minimal preparation time – less than a month from start to “go-live”.

​

My projects always benefit from the breadth of my expertise. Not many developers have as well-developed “people” skills. I was at ease engaging directly with critical hospital staff. Interviewing the client’s teams helped me recreate the familiar functionality from the custom system in new interfaces without existing documentation. A more experienced developer lacking strong people skills would not have been as effective.

​

I documented all of the new interfaces and when the hospital went live, I was there throughout – both night and day.

​

I wrote a huge amount of interface logic, transforming new message formats into those required by the hospital’s processes. I also developed transformations that minimized impact to their business partners.

​