Interfaces to EMR

When your practice sets out to find a new system, several decisions need to be made before you even start the process.  First, you need to decide if your existing billing application will meet the needs of your practice for at least the next four years.  If the answer to the question is “Yes”, then an interface will definitely be required with the new EMR system.

Next, if you decide the billing system should be replaced, you then have two options.  You can either purchase and EMR system that also has a built in billing system or you can choose the best EMR system and the best billing system and then have the two connect to each other via an HL7 interface.

HDS has implemented both types of systems and each has their pros and cons.  To make a better informed decision, you should first understand the details of how an interface works between an EMR and billing system.  The majority of all integration between two systems uses a standard which is called HL7.  The term HL7 actually stands for Health Language 7.  HL7 is not truly any kind of programming language but instead a specification of what format the data should be represented in.

The following text has come straight from www.hl7.org.  HL7 is defined by HL7.org as:

Health Level Seven is one of several American National Standards Institute (ANSI) -accredited Standards Developing Organizations (SDOs) operating in the healthcare arena. Most SDOs produce standards (sometimes called specifications or protocols) for a particular healthcare domain such as pharmacy, medical devices, imaging or insurance (claims processing) transactions. Health Level Seven’s domain is clinical and administrative data.

Headquartered in Ann Arbor, MI, Health Level Seven is like most of the other SDOs in that it is a not-for-profit volunteer organization. Its members-- providers, vendors, payers, consultants, government groups and others who have an interest in the development and advancement of clinical and administrative standards for healthcare—develop the standards. Like all ANSI-accredited SDOs, Health Level Seven adheres to a strict and well-defined set of operating procedures that ensures consensus, openness and balance of interest. A frequent misconception about Health Level Seven (and presumably about the other SDOs) is that it develops software. In reality, Health Level Seven develops specifications; the most widely used being a messaging standard that enables disparate healthcare applications to exchange keys sets of clinical and administrative data.

Members of Health Level Seven are known collectively as the Working Group, which is organized into technical committees and special interest groups. The technical committees are directly responsible for the content of the Standards. Special interest groups serve as a test bed for exploring new areas that may need coverage in HL7’s published standards. A list of the technical committees and special interest groups as well as their missions, scopes and current leadership is available on this web site (www.hl7.org).

The HL7 version that is most commonly used between EMR and Billing software vendors is 2.3.  While most vendors say they use version 2.3 many times you will discover that they may make minor changes to the specifications just to meet the needs of their application.  We will discuss that later in this article.  The HL7 2.3 specification is divided into what we called segments.  Each segment is used for a specific function by the application.  For this discussion, we will only cover a few of the segments that are typically used in a Billing to EMR interface.

The very first segment type is the MSH segment.  This is commonly known as the Message Header Segment.

The message header segment looks like this:

Typically, the vendor who sends the data will give the specification to the receiving vendor and then tell them what data to expect in what field.  Notice the first column is the sequence.  This is to ensure the every time a message is sent for example, field 4 will always contain the Sending Facilities name.  In this case, the vendor said the field is considered “O” or optional.  If there was data in field 4, then it could be up to 180 characters in length.

Also, notice in field 7 that in the Data Mapping Column the vendor tells the receiving vendor that that a date will be in the format of CCYYMMDDHHMM.  This allows the receiving vendor to know what to expect the date to look like when they read that field of data.

The next segment that is commonly used is the PID segment.  PID stands for Patient Identifier Information.  This segment has the following specification:

Typically, this table is used to communicate the two different Patient ID’s that exist in the billing system and the EMR system.  Usually fields 2 and 3 handle this requirement.  Notice in field 8 that the vendor is specifying how the sex field will contain data.  This is in case the billing system uses “M” to designate a Male and the EMR system may designate the number 1 for a Male. The EMR system may have to write some special program to make the conversion before the data is imported into their system.

The next table that is typically used in the HL7 interface process is the Patient Visit table.  As you can see this table tell you who referred the patient, who the primary care physician is, where the service was performed and the admit and discharge date.