meridianEMR Integrations
Through integrations with practice management systems and laboratory systems, meridianEMR provides the most efficient solution for organizing administrative and clinical data in your office.
Our goal is to provide you with the information that you need while making the underlying technology transparent to you.
Click here - for more information on how we can provide an integrated solution for your practice.
Here is a partial list of the companies that we integrate with.
|
Practice Management
PRS - Partner
MedEvolve - Partner
Advantix
Avisena
Benchmark
CCA Medical
Centricity
Companion
GE
Groupcast
IDX
MARS
Medical Manager
Medisoft
Medisys
Medtron
Misys
NetPractice
PCN
Practice Express
Tiger
Vision
Visionary
WebMD
X-Link
|
Laboratories
Ameripath
Barberton
Bostwick Laboratories
Carillion
Care Evolve
CBLPath
CPLPath
Dianon
Ephraim McDowell Health
Fletcher/Floria
Hunter
Hayes
Labcare
LabCorp
Labdaq
Lakewood Pathology
MarthaJefferson
Meditrain
Neointegrate
OurLab
PAML
Quest Diagnostics
Schuylerhouse Labs
Spectrum Labs
Westcliff
|
Hardware Companies
Life-Tech - Partner
Clinitek - Status
|
Interfacing in the Electronic World of EMRs
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.
|
|
|
|
|
