The EMR-Medical Devices Mess

Tim Gee's EMR Connectivity for Medical Devices Is a Mess post is right on target. I've also expressed my opinion ("total chaos") on this, but as you'll see I'm coming from a different perspective.

The HealthLeaders Technology article primarily focuses on the challenges of interfacing medical devices in the hospital environment. I think the situation in a physician's private practice or small group office is even worse.

The needs for medical device connectivity in both environments are essentially the same:

  • Reduction in medical errors.
  • Decrease in paperwork.
  • Increased staff productivity.
  • Timely delivery of clinical results.

Hospitals have the advantage of working with big EMR vendors who in turn can provide connectivity solutions for a larger variety of medical devices. Also, large hospital chains have enough clout to be able to mandate performance criteria from their vendors that include interoperability.

The typical physician's office uses a smaller EMR provider (or even worse, a 'home brew' system) where in many cases connectivity with external devices is an afterthought, if it exists at all. Even when you work with mid-sized EMR companies, each has their own proprietary external data interface. Very few of these smaller stand-alone EMR management systems provide standard interfaces (e.g. HL7) for external device data capture.

The interoperability problem is not a technical one. The issue is the time and resources it takes to implement and validate a given medical device interface. The real hope of a MD PnP-like solution is that the cost of that interface can be significantly reduced.

So, here's my perspective. As a medical device manufacturer, when we take our device into a private practice physician that has an existing (or planned) EMR system the first requirement is pretty much always the same. It's simply that the diagnostic results from our device automatically appear in a patient's record in their EMR system. To make this happen, they have to choose between three possibilities:

  1. Pay the medical device manufacturer (us) to interface with their EMR system.
  2. Pay their EMR vendor to do the interface.
  3. Find a third party vendor or contractor that will provide or build the custom interface.

The problem with #1 is that we don't have the resources to build each unique interface required to satisfy all of our customers. Plus that, our business is building medical devices, not EMR solutions.

#2 might not work out because unless the EMR company has a lot of customers with our devices they will either charge a large custom engineering fee or may just say they won't do it at all. The third option is doable, but is also potentially costly.

Notice that all of the choices require additional investment by the physician. I wonder if these types of issues may be one of the contributing factors for the low adoption rate of EMR for office-based physicians.

Not being able to provide cost-effective EMR integration is bad for everyone involved. It's bad for a medical device manufacturer (like us) because it makes it that much harder to sell systems. It's bad for the physician's office because without EMR integration they'll end up with a less effective paper-based solution. It's also bad for the EMR companies because they won't be able to take advantage of the future opportunities that a fully integrated medical office would provide.

The reasons may be different, but my conclusion about EMR connectivity with medical devices is the same as Tim's: “It’s a mess.”

UPDATE (7/21/08): Ran across this MIT Technology Review post about the MD PnP program:
"Plug and Play" Hospitals (Medical devices that exchange data could make hospitals safer).

This entry was posted in EMR, Interoperability, Medical Devices. Bookmark the permalink.

7 Responses to The EMR-Medical Devices Mess

  1. Pingback: Bridging the “Device Divide”

  2. Tim Gee says:

    Bob, thanks for the link! You’re right, connectivity in ambulatory care is even worse off than in hospitals. It is expensive in hospitals, but in the physician office market many vendors (especially EMR vendors) refuse to do the work.

    Certainly configuring HL7 at each installation is not practical in a highly fragmented market like physicians (where there are hundreds of thousands of practice locations). Proprietary APIs, like that offered by Midmark on the device side, and AllScript on the EMR side, are even worse. Integrating an API is a much bigger task than configuring the table of an HL7 interface. And there are dozens of medical device vendors in that market, and hundreds of EMR vendors.

    There are ways to overcome this situation, but it won’t happen through market “evolution” – it will take a real effort. Eventually the market will drive both device and EMR vendors to make this effort. Bob, I hope we’re both still around to see it!

  3. The purpose of HIPAA was to improve the efficiency and effectiveness of the healthcare system through the development of established health data standards and requirements for the transmission and storage of electronic health information. Currently, however, most EMR and medical transcription companies dont comply with these standards. We need to create a licencing mechanism to ensure that companies are indeed HIPAA compliant, similar to how manufacturers get ISO-9001 certified. Otherwise, the act just turns into a marketing tag line for companies.

  4. Pingback: Dreaming of Flexible, Simple, Sloppy, Tolerant in Healthcare IT | Bob on Medical Device Software

  5. EMR says:

    That does sound like a pretty big mess. Hopefully it’s fixed by now.

  6. Pingback: Plug-and-Play Medicine | Bob on Medical Device Software

  7. Pingback: Why Healthcare IT is Not a Game Changer | Bob on Medical Device Software

Leave a Reply

Your email address will not be published. Required fields are marked *