Free EMR Newsletter Want to receive the latest news on EMR, Meaningful Use, ARRA and Healthcare IT sent straight to your email? Join thousands of healthcare pros who subscribe to EMR and EHR for FREE!

Are EHR Lab Interfaces Finally A Standard?

Posted on May 1, 2014 I Written By

John Lynn is the Founder of the blog network which currently consists of 10 blogs containing over 8000 articles with John having written over 4000 of the articles himself. These EMR and Healthcare IT related articles have been viewed over 16 million times. John also manages Healthcare IT Central and Healthcare IT Today, the leading career Health IT job board and blog. John is co-founder of and John is highly involved in social media, and in addition to his blogs can also be found on Twitter: @techguy and @ehrandhit and LinkedIn.

I was getting a demo of an EHR software a couple days ago and they were showing me the results area of the EHR. As I looked at the interface for the lab results it basically assumed there was a lab interface with the EHR. I imagine they have some way to manage scanned lab results for someone who doesn’t have a lab interface with their EHR, but I realized at that moment that lab interfaces are now just a standard with every EHR.

Are any EHR users not doing a lab interface?

I imagine there are some exceptions and some stragglers. I bet there are also quite a few places where the lab won’t interface with the EHR software or vice versa. It’s too bad when this is the case, but it’s understandable when an organization chooses not to do it if the EHR vendor and/or lab is charging them to create the interface.

With those exceptions in mind, I expect that most EHR implementations will have a lab interface. I remember on my first EHR implementation implementing the lab interface was one of the best decisions we made. It was hard work making sure that the lab interface worked properly since we had a custom lab interface done, but once we verified that the interface worked properly it was like manna from heaven.

Sure, lab interfaces can have their own quirks and downtime issues, but those times just remind you how nice it is when the interface does work (which should be most of the time).

I love to think that our EHR’s have gotten to the point where they can basically assume granular lab data. This is a very powerful thing and will become even more powerful over time. I’m sure people can point out plenty of issues with the quality of the lab data. I’d still rather we had data to talk about quality versus wishing we had data at all.

Subsidiary Modules in Certified EHR Products

Posted on June 2, 2011 I Written By

When Carl Bergman isn't rooting for the Washington Nationals or searching for a Steeler bar, he’s Managing Partner of the last dozen years, he’s concentrated on EHR consulting and writing. He spent the 80s and 90s as an itinerant project manager doing his small part for the dot com bubble. Prior to that, Bergman served a ten year stretch in the District of Columbia government as a policy and fiscal analyst, a role he recently repeated for a Council member.

Carl Bergman, from, sent me the following email which poses some interesting questions about various certified EHR vendors and the software that they depend on to be certified.

Many of the [certified EHR] products relied on several other software companies to function. Usually this was Dr. First’s Rocopia, Surescripts, etc. However, many others had required several subsidiary modules to work. For example, Pearl EMR lists: MS .NET Framework 3.5 Cryptographic Service Provider; SureScripts; BCA Lab Interface; Oracle TDE.

There is nothing inherently wrong with this, but it raises three questions. Does the vendor include the price, if any, for subsidiary software? More importantly, how well integrated are these programs integrated into the main program? Does the vendor take responsibility if the subsidiary software changes making them incompatible?

He definitely asks some interesting questions. I’d say that in most cases, there will be little issues with the dependent software. Any changes by the dependent software are going to have to be dealt with or in some cases replaced by the EMR vendor. That will just be part of the EMR upgrade process that the EMR vendor does for you.

The only exception might be things like the third party ePrescribing software. Depending on how this is integrated it could be an issue. In most cases, integration with the ePrescribing software can be very much like an interface with a PMS system or even a lab interface. If you’ve had the (begin sarcasm) fun (end sarcasm) of dealing with these types of interfaces you know how it can be problematic and often a pain to manage. I believe the interface with an ePrescribing module is less problematic, but it will exhibit similar issues depending on how the EMR software works with the ePrescribing.

Personally, I don’t have much problem with these types of integrations. As long as the EMR vendor is providing all of the software for you. The reason this is important is because if you get the EMR software from one vendor and the ePrescribing software from another vendor and then tell them to work together, you’re just asking for a lot of finger pointing. However, if your EMR software chooses to integrate a third party software to flesh out the certified EMR requirements and provides you all of the software, then you’re in a much better position. As they say, then you only have one neck to ring if something goes wrong. You don’t want to have to call both vendors and have each vendor point the finger at the other. That’s a position that no one enjoys.