Galen Healthcare Solutions: Allscripts Consultants Enterprise EHR

One of the “Menu Set” CMS Final Rule Meaningful Use Stage 1 objective and measures specifies that “at least 40% of all clinical lab tests ordered whose results are in a positive/negative or numerical format are incorporated in certified EHR technology as structured data.” Additionally, the Certification Commission for Health Information Technology (CCHIT  - certifying body for EHRs) indicates via IO-AM 07.02 that “The system shall provide the ability to receive and store microbiology laboratory results with organisms recorded as free-text. (Not MU).” This brings to question the handling of interfacing microbiology results into the EHR.

Microbiology results are often longer, textual results including sensitivities. Additionally, microbiology results can have 3 levels of hierarchy:

1. Orderable item(s) (Urine Culture)
2. Culture(s)/Organism(s) (Light Growth Escherichia Coli)
3. Susceptibility(ies) (Amplicillin)

The problem is that most EHRs are not well-suited to rendering interfaced results with three-levels of hierarchy; rather, the EHR is suited for just two levels of hierarchy:

1. Orderable(s)
2. Resultable(s)

When the interfaced result is sent by the vendor as a “discrete” result, the result likely will not render in the EHR properly:

To accommodate for this, most vendors have the capability of sending the interfaced result as “non-discrete,” or in other words, sending a free-text version of the result.  However in an instance where the vendor is able to send “discrete” microbiology results only, the interface analyst is charge with developing a interface customization to translate the “discrete” result to file into the EHR as a “non-discrete”:

The disadvantages of filing the result as “non-discrete” include the likely lack of ability to aggregate or report on these types of results.

For reference the original printed report from the Laboratory Information System (LIS) for the example above (recall that if an interface is not setup, this is the report that is usually provided by the LIS via fax).

Please contact sales@galenhealthcare.com if you or your organization would like assistance in interfacing discrete/non-discrete results to your EHR.

Tags: Allscripts Enterprise EHR, CCHIT, Certification Commission for Health Information Technology, ConnectR, Database, Enterprise Order, HL7, Integration, Interfaces, Interoperability, Laboratory Information System, LIS, Meaningful Use, Microbiology Results

Currently, exchange of clinical data in and out of the Allscripts Enterprise EHR is facilitated via stored procedures. This  application programming interface (API) approach certainly comes with its downsides. In this article, we propose a re-design of the API to segment out the data and the configuration components of clinical data exchange.

At the outset of an interface project where there has been precedent set (existing Quest or LabCorp <-> AE-EHR order/result data exchange deployments), we almost always get the following questions from the vendor:

• Shouldn’t the interface be the same from client-to-client?
• Why do we need to pay Galen (vendors will often times subsidize the cost of interfaces) to design a known interface deployed across hundreds of clients?
• Why do we need to reinvent the wheel?

Now these are very valid questions. And the response is as follows: Due to the approach utilized with the Allscripts interface API, an interface designer must take care in translating data extracted from outbound stored procedures into a valid, compliant HL7 message the vendor can accept (ORM for orders) and also take care in translating an HL7 message from a vendor (ORU) into a stored procedure call which sets both data elements and configuration options. To help guide the client and vendor through design decisions, Galen provides interface-specific (document, result, immunization) questionnaires.

Back to our proposed re-design: segmentation of the data elements (patient first name, provider ID, order item code) and configuration settings (enable tasking, utilize NPI for provider matching, utilize EntryCode for item matching – setting the traditional form parameters of the inbound stored procedures). With this approach, the vendor is responsible for providing the data elements as they normally do in the HL7 message (ORU for results), and the client sets the configuration settings via a workplace within the TWAdmin context in the AE-EHR – much as they do to set application preferences:

We have covered AE-EHR inbound interfaces quite well, so let’s address proposed re-design for outbound interfaces. Instead of each client requiring a site-to-site VPN and individual interface deployment, what if Allscripts chose some of its top vendor partners (Quest, Labcorp) and offered the capability to exchange out of the box, without the need for one-off interfaces? This approach is somewhat analogous to that of Surescripts acting as the hub and router for electronic prescriptions. In the case of outbound interfaces (orders for our example), there would still be the need to segment data (patient, provider, item) from configuration settings (a setting to enable or disable sending insurance information – IN1 segment of an HL7 ORM order message).

In conclusion the Allscripts clinical data exchange API serves its purpose quite well, but it could do a better job. Much of the functionality is derived from legacy, antiquated methods. Our hunch tells us that in promoting themes of Community Exchange and Connecting, the “new” Allscripts will be addressing this in short order.

Tags: Allscripts Enterprise EHR, ConnectR, Database, Enterprise EHR, Enterprise Order, HIE, HL7, Integration, Interfaces, Interoperability, Meaningful Use, Results Interface, Technical

Galen Healthcare Solutions is proud to announce that we will be continuing our popular series of free webcasts this fall related to Allscripts Enterprise EHR.   These Webcasts will cover topics including Analytics, Allscripts Enterprise EHR Note, Interfaces, Reports, Allscripts Enterprise EHR Orders, Tech System maintenance.

Learn more »

Tags: Allscripts, Enterprise Order, Galen Webcast Series, Integration, Interfaces, Meaningful Use, Technical

Labs require that you provide them with the type of billing, and the insurance info if they are to bill the insurance company.  Sending this information with Allscripts Enterprise (formerly TouchWorks EHR) requires consideration of work flows and design.

Insurance information is easy with Enterprise – you store the insurance with the patient’s record from the Practice Management System (PMS), and then send it along to the lab with each Order placed in Enterprise.

Bill Type is pretty easy too – for the majority Orders that are placed.  Most clinics have certain rules that govern the insurance to be used.  It can be as simple as the clinic always bills the patient or their insurance, or they always have the lab bill.  There are times when the insurance or the order being placed may contribute – sometimes this logic is built in to your interface, other times it’s not deemed worth the build effort.  And, there may be other factors – such as the patient indicates that the reason for their visit is due to an on-the-job injury (Workers Comp).
I have not found a great solution for handling the exceptions, but I did see an interesting solution a few months back that works pretty well.

A group I was working with stumbled upon the Special Billing (aka Injury Type) dictionary and asked if we could use it.  We thought about it for a bit and it seemed to meet a lot of the needs that we had:

1. No impact on other modules – for them, and perhaps not for you, they did not send Special Billing information back to their PMS.  This is the only standard use for Special Billing information.
2. It affected all orders on a particular encounter – in their case they knew that all labs should be billed by the lab, except when they shouldn’t.  They could not determine the rules for exceptions from talking to the clinic – the employees there said they just knew when the clinic should bill and all orders for the encounter should follow that exception.
3. It was sent to the ConnectR interface.
4. They could create their own entries – such as “Client Bill”, “Third-party Bill” and “Patient Bill” (the three values the lab would accept).

Then we were on our way – a small change to the interface to override the logic we had built based on Special Billing / Injury Type, if it was set.  They added the appropriate entries and trained the users to pop in to the Encounter Form and set the Sp Billing value to “Client Bill” if the clinic should charge for the blood work.  It’s a great solution for groups that are otherwise not using Special Billing in Charge.

Tags: EHR, Enterprise Order, TouchWorks