Integration of medical device data into EMRs

EMR Daily News: “Recording and charting changes in vital signs has been identified as one of the core areas that will be measured for meaningful use incentives. The new Intelligent Medical Devices HIMSS Analytics white paper, sponsored by Lantronix (NASDAQ: LTRX), and posted on the HIMSS Analytics website, details progress on these efforts. The research suggests that just one-third of hospitals in the HIMSS Analytics sample on medical device utilization indicated they had an active interface between medical devices at their organization and their electronic medical record (EMR).”

Integration of medical device data into EMRs is highly desireable, and many vendors have broached the subject. The reality, however, is that few vendors have been able to create a reliable way of pulling that data into an usable EMR format in real-time. During this years Siemens Innovations conference, I received a private showing of Siemens EMR, i.e. Soarian, and its ability to pull data from several medical devices. As impressive as the display was it still required quite a bit of manual manipulation by the end user to be useful.

The sticking point in all this data collection appears to be the inability of all the different vendors to get on the same page. I spent some time last year speaking with one particular vendor about the issue and they agreed that the difficulty wasn’t necessarily the data, but gaining access to it.

From a pharmacists perspective data from vital sign monitors, ventilators, infusion pumps and blood glucose monitors would be of particular interest as this information is often collected manually and used to make decisions regarding patient care and medication use.

Instead of creating another third party solution to collect and manage all this information, maybe it’s time for vendors to sit down and find a common ground on which to build. I’m just sayin’.

The new Intelligent Medical Devices HIMSS Analytics white  paper referred to in the EMR Daily News article can be found here.

3 thoughts on “Integration of medical device data into EMRs”

  1. Jerry,

    Interesting perspective on device data integration with EMR’s. You mentioned that vendors need to come to some type of “common ground” – which I assume is agreeing on standards for data integration. I do agree that there should be more standards put in place for the exchange of medical device data in order to improve patient safety, but the one concern I have, is that you suggest bypassing third party vendors altogether. The reason I bring this point up is because I believe there are certain issues that third party vendors with expertise can address, that IHE Standards and Profiles cannot solve alone.

    First, we have to think about the unique concerns of hospitals- and how every environment differs in terms of architecture and workflow- and this can be very complex when dealing with medical device connectivity solutions. There would have to be multiple standards and multiple profiles put in place to address these complexities, such as the need for hospitals to connect their newer devices, as well as their older, legacy devices. Not to mention all of the clinical workflow issues at the point of care.

    Additionally, in locales such as the US, there are very stringent FDA regulations, that forces adherence to a stringent validation process. As a result, the long road for hospitals achieving meaningful use goals, would be even longer without a commercial integration solution. Hospitals would be faced with addressing key issues regarding regulatory, clinical workflow, receiving data in real-time, filtering out the data they need from certain devices, data caching, and also looking at the big picture of medical device connectivity from now, into the future. And I think that’s too much for hospitals to swallow right now. But, together, IHE adoption standards can work with vendors to help educate the market on device connectivity and how it can be achieved, managed, and adopted. Over time, creating standards will ultimately drive costs down for customers and reduce complexity. Less money will be spent on testing, validation, etc – because there will just be standard interfaces. If the two can work hand in hand, I think that the benefits will be realized on all sides. Thoughts?

  2. Hi Brian –

    Thanks for taking the time to leave your thoughts. I think healthcare in general is a data black hole; everything goes in, but nothing comes out. We utilize a “best of” system with each component doing its own thing, which in turn requires a hord of IT people to find ways to push data from one system to another. Some systems use KG, while another choses to use gram, for example. Or another choses to display SCr in mg/dL while another choses to utilize umol/L. One system might use HL7, while still another might chose to use something else. Or my favorite, “our data is proprietary so I can let you at it”. And then to top it off there are vendors that make a living “aggregating” the data and spitting it right back at you. That’s an interesting concept that exists becasue we, i.e. healthcare, can’t get our act together. It’s a little bit like the accounting profession; wouldn’t exits without lots of bloated bureaucracy.

    As far as pharmacy workflows go they’re not as different as many people would like to think. I’ve worked in six hospitals, and while they all have their nuances, the basic premise is the same: get the drug to the patient. And to be quite honest the way data is presented and collected has nothing to do with workflow. I want to know the results of the met-10 or the patients vancomycin level. I couldn’t care less where it came from as long as I have access to it. The same could be said for the FDA regulatory requirments. You mention that they are very stringent in the US. I have no doubt that what you say is 100% accurate. However, what does that have to do with how you chose to present your data. If one device manufacturer meets the requirement with a certain data structure why wouldn’t another? I want them all to agree on how that’s done. If the FDA requirements are so stringent then I would think it would make standardization even easier. I mean they’re telling you how to do it, right?

    I want standardization. I want ease of data acquisition. I want a centralized data repository. I’m tired of pushing data all over the place with different structure and one-offs. Healthcare is an interesting industry. They do nothing to defend themselves from vendors and take it in the shorts as a result. In my 13 years as a pharmacist I’ve never seen a CEO, CIO, or upper level executive tell a vendor to take a hike because they didn’t like the system. Instead they buy it, complain about it and simply live with the garbage provided. If the consumer market was anything like the healthcare industry we’d still be using the Commodore-64 for our computing needs. Why, because noone would have ever cried foul and demanded more. Consumers are a smart lot, they don’t buy something if they don’t like it. Healthcare on the other hand gets distracted by shiny objects with little value. Of course this is only my opinion and could be absolutely worthless, but healthcare IT is a mess.

  3. You’ll get a lot of agreement among providers that the lack of standardization is crazy and infuriating. The vendors are slowing coming around to the idea that they need to get serious about improving this situation, and you’ll find a lot of major vendors of monitors and other devices and software (Philips, GE, Draeger, Mindray, Carefusion, BBraun, Capsule, Cerner, and many more) working together in the “Integrating the Healthcare Enterprise” (IHE) Patient Care Devices effort at standardizing codes, units, data formats and so on. For various reasons the products conforming with the standards are coming only slowly (including that a lot of customers aren’t asking for it very loud, and product development cycles in regulated medical devices are long), but the effort is definitely progressing.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.