|
Interfacing in the Electronic World of EMRs - by Michael Custode, meridianEMR
CEO
Interfacing disparate systems is an integral component of any successful EMR implementation. With
the EMR being the centralized repository of the patient’s medical record, it is crucial that all data flows easily into
and out of it.
Currently, common EMR interfaces include Practice Management Systems, Reference Labs, and Clinical
Test equipment used in medical care (i.e.: systems that perform Urinalysis or Vital Signs). Other types of interfaces will
continue to expand to include PACS, Radiology, Pharmacies, Hospital systems, and the Patient Lifetime Healthcare Record. We
are quickly moving towards the time when a patient carries a device that contains their entire medical record and this data
is easily updated via an interface every time a patient visits a provider.
Successful EMR vendors must have interface
strategies that address the standards of today (PM, Labs, etc) and will meet the challenges of the future.
Let’s
take a look at Interfacing in the Electronic World of EMRs.
How are Interfaces Done?
One of the most common questions posed when purchasing an EMR is “Can your system exchange data with my Practice
Management System or Lab”? Often you hear that this can be done and that it relies on an agreement between the 2 vendors
(EMR and Practice Management). There are actually 2 main steps to creating any interface, the first is agreeing to the layout
of the data and the second is agreeing to the communication method.
When agreeing to the layout of the data there
is a standard called HL7 that is used. HL7 is a defined group of messages that must be formatted in a specific way. This allows
both vendors to know what to expect when each of the message types are sent or received. For example, there is an HL7 message
for adding a new patient, for updating a patient, for adding a new appointment, etc. Initially the vendors will “swap
specifications” so that each can read the others message formats.
The next consideration for completing an
interface is how the information is to be sent, or what is generally called the communication method. There are many communication
approaches that are used including, sockets, file drops, FTP, and VPN. Without getting too technical the important point here
is that no matter which method is selected the data must be secure when it is passing from one system to the other. HIPAA
defines a secure network as one behind a firewall but that doesn’t mean that information passing within your office
on a non-secure wireless network cannot be hacked.
Once the vendors agree on the HL7 formats and the Communication
Method the next step is to create the interface. This is done in one of 2 ways: 1) creating a new interface by “cutting
and pasting” code from an existing interface or 2) by using an interface engine. The downside of the “cutting
and pasting” method is that the programmer is then faced with the challenge of supporting all these different pieces
of code which at some point in the future will definitely require maintenance. The interface engine approach allows the vendor
to easily configure the interface initially as well as provide ongoing maintenance to all the clients at one time. Clearly
the interface engine is the better choice.
The meridianEMR approach…..
We have developed
a comprehensive Interface Engine that allows us to create and maintain all of our Interfaces. Our engine provides the ability
to customize any interface by creating XML files for each interface. There is a very small amount of actual programming time
as most of the interface time is spent in the format discussions between us and the other vendor. We have been able to provide
an interface for any vendor that has cooperated.
We also go the extra mile when it comes to data encryption and
security. We demand on encryption beyond what HIPAA requires and have had to insist on this with a few vendors. We take security
very seriously.
Practice Management Interfaces
The majority of practices
have an existing Practice Management System (PM) in place and this is generally the first interface that is developed. The
PM interfaces have 3 basic areas of integration including demographics, scheduling and charges.
The demographic
interface includes the ability to send the basic patient information such as name, gender, date of birth, and contact information
(address, phone, fax, email, etc). Some systems can also handle the insurance and the referring provider information. When
a new patient is added to the PM or an existing patient is updated a “trigger” (an event) in the PM system will
send an HL7 message to the EMR System. The EMR System will accept this incoming message and process it. This includes determining
what needs to be added or updated based on the message contents. The PM system generally has a unique identifier for the patient
so that the EMR system can provide a lookup of the patient to determine if the patient is on file. In the absence of a unique
identifier the EMR must have sophisticated logic to match the patient by name, date of birth, and gender to determine if the
patient is on file.
The meridianEMR approach…..
We have developed a full demographic
interface that includes all the basic patient information as well as the patient’s insurance and referring provider
information. Our patient matching logic does not depend on a unique PM and can handle many different matching configurations.
We can handle any configuration of patient demographic information and the patients on meridianEMR will be mirror images of
the patients on your PM.
The scheduling interface includes the ability to send scheduling information
such as, appointment date and time, appointment provider, appt reason, and basic patient information. When a new patient is
added to the schedule or an existing appointment is changed or deleted a “trigger” (an event) in the PM system
will send an HL7 message to the EMR System. The EMR System will accept this incoming message and process it. This includes
determining what needs to be added or updated based on the message contents. The PM system generally has a unique identifier
for the appointment so that the EMR system can provide a lookup of the appointment to determine if it is on file.
The meridianEMR approach…..
We have a full scheduling interface that includes all the basic scheduling
information such as adding new appointments or changing and deleting existing appointments. The appointments will display
in the provider’s workflow so that the provider can see all the patients that are coming in for the day.
We
also go beyond the standard appointment features and have developed some very comprehensive time saving items such as Appointment
Arrival tracking. When a patient arrives for the appointment there is generally a function on the PM System of marking that
patient as arrived. We process that information and locate the appointment and mark it as arrived. This then displays in blue
in the provider’s workflow. Optionally, we can also auto-move the appointment from the provider (who it is originally
booked for) to the nurse that typically greets and examines the patient before the provider. This way a single click in the
PM system triggers a series of events to facilitate the actual patient movement in the practice.
The charge
interface is an interface that flows from the EMR to the Practice Management system. When a charge interface is developed
generally the practice no longer needs the Super Bill as an internal document. The Super Bill is the document that is marked
by the provider and taken to the front desk to process the checkout of the patient. The Super Bill contains the Procedure
Codes, Diagnosis Codes, and appointment information for any return visits.
Using the EMR, the provider documents
the visit and as a byproduct of the encounter automatically generates the appropriate Procedure Code and Diagnosis Code. Saving
the Encounter a “trigger” (an event) that sends an HL7 transaction from the EMR to the PM System. As the patient
exits the practice, the front desk checkout person displays and verifies the patient and the appropriate Procedure and Diagnosis
Codes that were created for this visit.
The meridianEMR approach…..
We have developed
a full charge interface that includes all the charge information that is needed to create the claim, such as the service provider,
the billing provider, encounter facility, Procedure Code, Diagnosis Code, and appropriate units. When a new Encounter is added
a “trigger” (an event) in our system will send an HL7 message to the PM System. The PM System will accept this
incoming message and process it which includes determining what charges need to be added.
We also provide a Billing
Info Window that displays all of the charge transactions that have been sent to the PM for processing. Displaying this Window
will provide a Day Sheet for reconciling your end of day. We also provide the detailed information for the return visit including
the provider, visit timeframe (ex: 2-3 weeks), appointment reason, and notes. This allows the front desk checkout person to
view the information when using the PM system to schedule the appointment.
Lab Interfaces
All practices receive lab results for their patients. The EMR provides a central repository for storage of patient
labs and eliminates the processing of paper results. Many lab companies are excited to work with EMR companies because once
the electronic lab results are in place it eliminates the need for paper results as well as hardware (faxes and printers)
that receive results in the office.
The most common lab results interface will allow the labs that are ordered
by a provider to flow directly into the patient chart and will update the provider’s workflow to indicate that there
is a lab that has been received and needs to be reviewed.
A lab interface will follow the same set of rules in
that the Lab and the EMR vendor will swap their HL7 specifications as well as agree on a communication method.
Lab
Results are sent in electronic batches to the practice a number of days after they are ordered. They will appear in the Provider’s
workflow so that each provider is alerted as to which labs they need to review. The labs are displayed and the provider can
review the results and then sign the lab or send it on to someone else in the practice to review.
The meridianEMR
approach…..
We have developed a comprehensive Lab Results system. Our Blended Model technology allows us
to establish a centralized repository at our Master Server where all lab results are received for all clients. This removes
the technology burdens of establishing secure communication methods at every client’s local server. These are generally
expensive methods that require additional hardware and technicians to set them up. Our centralized repository eliminates this
cost to the practice.
Once labs are received at our Master Server they are then split by provider (using the Provider’s
Upin#) and sent to the appropriate client’s local server. They will appear in the provider’s workflow (or whoever
they designate) for review. The lab result can be displayed to the screen, signed, noted, and sent on to another person for
review. Abnormal labs are noted with a Red Flag in the provider’s workflow so the provider can immediately review the
abnormal labs and take action.
Hardware Interfaces
There are a number
of Hardware Vendors that make equipment that is utilized in a provider’s office. These include systems that measure
vital signs as well as systems that process urinalysis tests.
These systems generally have an output option that
allows the results that are generated to be sent to a computer where they can be captured as part of the EMR. These systems
do not provide HL7 based transactions and very often these are extremely custom interfaces because the EMR vendor usually
has to create the interface from scratch.
The meridianEMR approach…..
An example of this
type of interface is the Clintek Urinanalysis system by Bayer that we interface to. The patient’s urine is analyzed
by the Clintek system and the output will be a series of fields that correspond to specific results. These results are then
automatically captured in a flowsheet for that specific patient. The nurse simply opens the patient’s chart window,
selects flowsheet, and selects capture results. This automatically creates a new flowsheet for that patient.
This
will be an area that will expand rapidly as more and more practices install EMR systems. The goal will be for all systems
to send all orders and results to the centralized EMR.
The Future of Interfaces
Interfaces will continue to be an integral component of any successful EMR installation. As more and more practices adopt
EMR systems the needs and scopes of the interfaces will continue to expand.
EMR companies will need to move beyond
the “Cut and Paste” method used by many today to generate interfaces. These are outdated and eventually the sheer
number of these types of interfaces will be impossible to support.
The meridianEMR approach…..
meridianEMR has already taken the necessary technological steps by creating an Interface Engine that allows us to
customize interfaces without additional coding each time. We simply configure an XML file by practice and setup the parameters
for the interface. Once configured the engine takes over the process. This is by far the most efficient method for interfacing
and provides our clients with the best options.
Our Interface Engine also allows us to quickly respond to changes
in interfaces, which almost guarantees that any updates to the communicating systems will be easily addressed for uninterrupted
data flow. Eventually our engine will be intelligent enough to notice changes on its own, make the adjustments, and continue
to process.
Our centralized approach for receiving and processing lab results is also leading edge technology.
We have removed all of the burdens for the practice associated with establishing a secure connection in their office for receiving
results. This saves them time and money in establishing and maintaining lab interfaces. We can also quickly respond to any
current or future changes to the lab results interface because it is centralized.
|
