Archive for the tag 'Results Interface'

The Costs of HL7 Interfaces

In the past on this blog, we’ve addressed the top data integration challenges as well as the ROI of a results interface. Recently, Health Management Technology featured a related article on the economics of interfaces. The key points from the article were as follows:

 

    • Opportunity Cost
    • True Investment
    • Integration is not simple
    • Pitfalls of proprietary
    • Features matter
    • Think of the future

 

 

The last point of the article is one that is often overlooked when evaluating pursuing an interface. We have seen this a great deal recently in supporting data conversions for client’s switching EHR vendors and also for conversion of interfaces to support Hospital LIS (Laboratory Information System) and RIS (Radiology Information System) vendor changes. 

When we scope out conversions, one of the first questions we pose is if there are any existing interfaces with the EHR being sunset? If they are, we immediately inquire as to the expectations of end users having these interfaces in the new system – especially with regard to the interfacing with the practice management system. It is likely that users are going to want to be able to interface demographics and appointments from their existing PM system if that is not changing. Additionally, with regard to existing result interfaces with the current EHR, as part of the conversion, contingency plans for switching to paper results may need to be explored as a stop-gap solution until interfaced results are received in the new system.

Likewise, hospitals may decide to change their laboratory radiology system, or their radiology information system. This impacts downstream subscribers to that data – namely the clinics and providers in the ambulatory setting which send their orders to the hospital for fulfillment and currently receive results electronically. This is especially pronounced with radiology integration, where an ADT interface and an Imagelink interface may be involved in addition to the result interface. Again, a question that looms is who is responsible for paying for the costs associated with migrating vendors for a lab or rad information system and associated interfaces?

We recently had one client that put development of interfaces with the ambulatory EHR on hiatus until the hospital lab decided whether they were switching lab vendors. They felt like they didn’t want to sink costs into integrations only to have them rendered obsolete months down the road when the hospital made a vendor switch.

We’d love to hear other groups experiences with vendor migration and the associated costs of migration of interfaces. Share your stories and experiences on the Allscripts Interface Developer Forum.

Announcing Free Allscripts Result Interface Training

Have you ever found yourself asking how the heck does Imagelink work?  How is it possible to click a button in the Allscripts application and view an X-ray?  Have you ever wanted to know how a result closes an order is closed without a Touchworks Order number?  Have you ever heard someone say, did you check the requested performing location dictionary, and not know what they’re saying?  Have you ever wanted to know more about Allscripts result interfaces?

Well you are in luck! The Galen technical services team is proud to host a Free Results Interface Training hosted at it’s brand new office!

Who: Allscripts Interface Analysts

What: Free Result Interface Training

Where70 Federal Street, 7th Floor, Boston, MA 02110.

When:  Wednesday, December 14th, 2011 from 9AM-5PM with lunch provided.  There will also be a cocktails and networking hour from 4PM-5PM with beer, wine and light snacks.

Why: Learn about more of the intimate details, nuances, and best-practices surrounding Allscripts result interfaces

Agenda:

Please contact us if there is a topic you would like to learn more about that isn’t in the list above.

Travel:  If you are driving into the city, there are parking garages nearby. The cheapest and most convenient is the Winthrop Square Parking Garage at $20/day.  If you are coming in from out of town, there are many hotels in the area.  Also note that we will have wireless internet and workstations with a hardwired internet connection available for those who need it.

Space is limited – Register Today! If you can’t make the training, it’s ok!  Galen offers free webcasts about every two weeks.

Top 3 EHR Data Integration Challenges

 

In response to a guest post on EMRandHIPAA, we take a look at the top EHR data integration challenges faced today:

Technology

Proliferation of point-to-point interfaces instead of using a hub-and-spoke type of model (like that which Surescripts utilizes with electronic prescribing). Unfortunately, most organizations which exchange data in and out of the AE-EHR utilize highly-customized point-to-point interfaces for orders, results, documents, etc. The point-to-point model is highly inefficient and does not adhere with a “plug and play” model that so many organizations desire.

We’ve seen Allscripts make an effort to move away from this by introducing capabilities to automatically send immunizations to state registries via the Allscripts Hub by  simply modifying configuration setting (with the caveat that Allscripts has worked with the state to develop the intergration).  We’ve also witnessed companies like Medicity and its Novo Grid technologywhich offers electronic communication between physician practices, hospitals, and other health care providers. Novo embeds agents (small but powerful Java programs) in hospital data centers, physician practices and other locations. The grid component is an object oriented system that can replicate an object to multiple agents and keep it in sync across locations.

 Standards

As outlined in the EMRandHIPAA post, there are no mandated standards for EHR vendors to follow, thus making it difficult to coordinate data sharing between medical devices and other systems. Allscripts does offer the Universal Application Integrator (UAI),  which facilitates extendibility to other applications and devices. However, there is a certification process that needs to be pursued. In terms of the point-to-point interfaces previously mentioned, the Allscripts proprietary (API)  Application Programming Interface(which consists of inbound and outbound stored procedures to their primary clinical DB) does not segment out the data and configuration components of clinical exchange, something touched on in detail in a previous Galen Blog post.  Lastly, most vendors have their own specifications for HL7 message definitions. For instance, Quest may send ordering provider in OBR-16 in an interfaced result ORU message while LabCorp sends this in ORC-12. Another example is communication of “Ask at Order Entry” questions – something Quest expects to receive in repeating OBX segments while LabCorp expects this across Z-segments in an interfaced order ORM message.

Adherence to HL7, proprietary approaches.

Cost

John Halamka bravely predicted that when health IT vendors and providers began adopting new standards, the cost for interoperability would plummet: “We know that we won’t get precisely plug and play—this is a journey,” Halamka told Government Health IT. “But each year, we will get more constrained. We are going from a $20,000 -$30,000 venture hopefully to $5,000-$10,000.” Unfortunately the numbers quoted are accurate – and provide a high barrier to entry for smaller groups looking to electronically exchange data. There is the flip-side to cost and that is the ROI, which could include reduction in direct annual labor costs, elimination of non-billable tests, and elimination of lost charges.

Summary

The benefits of health information exchange are well documented. As outlined in the EMRandHIPAA post, there is a need for a “consistent, secure and reliable way to capture and share patient data among all systems and healthcare providers,” especially given that benefits in improved coordination of care and reduction of medical errors.

Allscripts Enterprise EHR Imagelink Demonstration

A recent article in Health Management TechnologyPoised to touch all things -  highlighted the importance of Picture Archiving and Communication System (PACs) and offered the opinions of where PACs is headed from various leaders within the industry.

Additionally, as presented in a recent article in Health Data ManagementIs a Picture Worth a Thousand Interfaces?: “integrating imaging workflows – and images – in EHRs can be costly. But the benefits keep many trying.”

Many organizations utilizing Allscripts Enterprise EHR are unaware that image integration capability exists, and those that do figure it is too costly to implement.

In this demo, we will present Allscripts Imagelink capability. Imagelink is an Allscripts add-on that can be used to integrate outside systems with Allscripts Enterprise EHR.

More specifically, Imagelink provides organizations access to images and other documents associated with a result from a variety of different systems that have a web-based image viewer - from within the EHR.

With this solution, users of the EHR are presented with the clinical data they need to interpret, comment on, review or validate a particular result – without leaving the EHR application.

Just a few of the vendors we have experience in integrating to the Enterprise EHR via Imagelink include (but not limited to):

  • NovaRad
  • Stryker
  • SCImage
  • GE

Be sure to look out for one of our upcoming free webcasts covering Imagelink configuration within the AE-EHR and implementation of corresponding result interface dependencies.

Contact us today to see if your organization can realize the compelling benefits of Enterprise EHR Imagelink integration.

Order Reconciliation Woes

Organizations exploring Computerized Physician Order Entry (CPOE) might first pursue low-hanging fruit and implement an electronic workflow for results and keep a paper workflow for orders. Often times, electronic order entry can be cumbersome for end users and cause longer workflows.  As alluded to in a previous blog article, the benefits of implementing a solicited result interface are compelling – reducing paper and scanning, and offers the capability for automated result tasking.

In the Allscripts Enterprise EHR (AE-EHR), results can tie back to existing orders, facilitating completion of the order. This functionality is enabled and configured within the results interface deployed at a particular group and can be achieved in one of two ways:

  • Order Number: the Order Number EXT generated from Allscripts is sent back with the results. The Order Number is tied directly to a specific order – a specific CBC order in a patient’s chart.
  • Requisition Number: the Req Number EXT generated from Allscripts is sent back with the results. The Requisition Number is tied one or more orders – all orders on a single requisition. A requisition is defined by the Patient, Encounter, Performing Location and Ordering Provider.

For some organizations, a paper order work flow may be utilized, in which a paper requisition is presented to the lab instead of an electronic order. However, the Laboratory Information System (LIS) may not allow for discrete capture of the Allscripts-generated order number or requisition number. For that matter, the LIS also may not have the capability to send back this number in the result interface (typically a HL7 ORU result message).

Additionally, most organizations encounter a percentage of solicited results that do not complete the order. In the latter scenario, a lab may manually enter the order introducing the possibility for human error and can cause issue with not only reconciliation of the order, but potentially patient or provider matching.

Furthermore, if a lab has to change an order for any reason (for instance, changing the orderable item), the corresponding result will likely not reconcile the order (with the AE-EHR, the correct protocol would be to cancel the order and place a new order with the desired changes).

This situation can cause nightmares for organizations that are trying to gain semblance as to where lab vendors stand in terms of order fulfillment.  Additionally, order reconciliation reporting will likely be inaccurate.

This is especially pronounced in v11 AE-EHR, in which solicited results that are unable to reconcile to the original order create a “reported order.’ The original order is left unreconciled and a “duplicate” order renders in the patient chart:

We have resources available on our wiki to guide an organization through interfaced result-driven order reconciliation and can assist those organizations looking to gain control of order fulfillment and reconciliation. Please contact sales@galenhealthcare.com for more information.

Proposing an Allscripts Clinical Application Programming Interface Re-design

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.

Result Data Exchange with the EHR

The benefits of a results data exchange between a vendor system and the Electronic Healthcare Record (EHR) are profound, as the need for redundant and often erroneous data is greatly reduced. More importantly, by implementing a results data exchange to the EHR, providers are delivered more timely and accurate clinical data, yielding an increased level of patient care.

Benefits

  • Elimination of redundant entry of patient data.
  • Result reconciled to order automatically
  • Immediate availability of the results to the enterprise.
  • Decreased risk of patient matching errors (name misspellings, missing dates of birth, etc).
  • Elimination of scanning of signed paper labs to the EHR.
  • No more lost lab results.
  • Run reporting on the data from labs in EHR (for example, blood sugar change over time).
  • Automated result tasking as well as the ability to send copies to related providers, such as the referring provider or the patient’s primary care provider.
  • Automated Tasking.
    • Verify result task.
    • Carbon Copy (Review result task).

    Results Interface5

  • Automated synchronization of item dictionary.
  • Drop a charge automatically to the PMS (assuming a charge data exchange is in place).
  • Capability to automatically send insurance information to labs for lab direct client bill (assuming the insurance data exists in the EHR. This data is usually fed from a separate PMS data exchange).
  • For PACs data exchanges, facilitates viewing of image result directly from EHR.
    Results Interface1

And perhaps the biggest benefit is that many groups are able to negotiate with their lab and radiology providers to subsidize the cost of the data exchange. Since the data exchange presents many benefits from their point-of-view, the lab and radiology providers are often happy to provide financial incentive for practices to participate in an electronic data exchange.

Return on Investment (ROI)

A three-hospital study conducted by LINK Medical and Philips Medical provides great insight into the return on investment that interfacing can provide. These hospitals analyzed and assessed the effectiveness of automating the process of Electrocardiogram (ECG) orders and test results, with the following realized outcomes:

  • Reduction in direct annual labor costs ($11–25,000).
  • Elimination of non-billable tests.
  • Elimination of lost charges (1% to 2% of ordered tests).
  • Short payback period (less than 12 months).
  • On-going ROI – these savings and associated benefits continued.

Overall cost savings were in the range of $43,000 to $59,000 per annum.

Galen Healthcare Solutions: Interface Services

Result Synching

Synching of results in Allscripts Enterprise EHR v11 has been both very appealing and difficult for many to understand.

The premise is this – if a patient has a test done over time, you would like to compare the results – in HMPs, flow sheets and result history.  If the lab changes the code used for a particular result (as is common), or you send the same tests to multiple labs (also common), you need a way to link those separate resultable entries for comparison.

Recently, we had the chance (a client of mine and I) to speak to some folks at Allscripts – their clinical architect and the product manager for Order.

We had two basic questions:

  1. Should we synch our results?
  2. If we don’t synch, then what?

Ultimately, we chose to use “Considered equivalent” mapping that will be fully functional in a later release – perhaps as soon as v11.1.7.

The details of our discussion should provide insight on the decision that we made.

Should we synch our results?
Ideally yes, the Resultable Item Dictionary (RID) should be setup similarly to the Orderable Item Dictionary (OID) – with one master RID entry representing any equivalent RID entry.  The more lab vendors you interface with, the more important synching becomes.  Synching will make your the HMP, flow sheets/grids, graphs, and historical results display on one consolidated line and look great.

The reality is, that over time, lab vendors will change resultable codes (INR from 1/1/08 – 8/30/08 = code 12345, from 9/1/08-12/31/08 the INR code = 56789).  Since you can only have one RID entry per Requested Performing Location you would have to go update the INR synching to use the 56789 code to represent new INR results.  This means that if you are looking historically at a patient that had a PT INR in March and a PT INR in December their INR results would display on two lines even with Results synching. (See grid below)
results
If we don’t synch, then what?
Allscripts is planning to use the “Considered equivalent only for flowsheet graph:” (which can be set up in the RID entry) to do basically the same thing as the synching, but this would allow you to synch as many resultables as you want together (not just one per result per requested performing location).  The plan is to have the “considered equivalent…” consolidate results in the HMP, flow sheets/grids, graphs, and historical results.  So, even though ideally right now synching will help you consolidate line items it looks like the need for it will be obsolete in the near future.

We’ve made the decision to go ahead and use the “Considered equivalent” setting and hold off on the results synching.  We hope that in the future all of our needs will be met with the equivalent mapping.

This is high level summary of the discussion that we had.  If anyone is contemplating synching and you have any questions or would like to discuss further, please leave a comment.