Enterprise-Wide Medical Deivice Integration and CIS Workflow
Last month I spoke at the first CIS Qatar International Conference in Doha Qatar. My topic was the Importance of Enterprise Wide Medical Device Integration in CIS workflow. You can download a copy of my presentation here.
This was the first such conference in Qatar with over 1,500 people attending. The ballroom only had capacity for 1,200 so they had remote screens and audio for the 300 overflow attendees. Several hospitals in Qatar are in the process of implementing Cerner’s EMR, so there is a lot of keen interest in all things EMR.
Lessons from a Recent Recall
A recent Class I recall (not pictured) of a medical monitor with a hospital network connected central station stimulates some generalities about software, “fixes”, and connectivity. (Class I recalls are defined by the FDA as a situation in which there is a reasonable probability that the use of, or exposure to, a violative product will cause serious adverse health consequences or death.)
The use of the product in question was given as:
- a networked solution system used to monitor a patient’s vital signs and therapy, control alarms, review Web-based diagnostic images, and access patient records. The number of monitored vital signs can be increased or decreased based on the patient’s needs
Curiously only one customer was identified as having received the product, or at least this particular version of the product. While the manufacturer and product in question is a matter of public record, and available at the link, I chose not to include it here because my objective is not to repeat the recall information, but to suggest the reasons for the recall, an associated labeling issue, and offer some general lessons.
Workflow Impacts Choice of Connectivity Solution
The Medical Device Connectivity group on LinkedIn has some interesting discussions from time to time (you can join here). This week, Muhammad Siddiqui, a clinical analyst at the Cleveland Clinic, Abu Dhabi, asked:
I’m looking for some feedback. Why would any healthcare organization choose to go with Capsule if they have 90% Philips bedside solutions? Why would they not consider Philips as the nutural choice for device integration? I want to know and your feedback will be greatly appreciated.
As usual, there were numerous insightful responses discussing how the two approaches – connectivity enabled by medical device makers and that provided by vendor agnostic manufacturers – differed. What struck me was that there was no discussion about the workflow that the connectivity was supposed to provide. Since patient monitoring is mentioned, is the desired workflow remote surveillance or alarm notification? Perhaps the need is for clinical documentation from patient monitors to the patient’s chart in an EMR? Another common application is data aggregation in high acuity areas like the OR or ICU. While each of these workflow applications is enabled by an MDDS, they are often provided by different sets of vendors.
Connectivity, With or Without a Server
Many medical device makers contemplating connectivity for the first time, prefer to build everything into the embedded system device rather than using a server to implement most of the connectivity features. This design approach is rarely taken, but why? The following is a quick look at the strengths and weaknesses of building connectivity into the embedded device and using a server.
Before we launch into the pro’s and con’s, let’s identify the basic functional requirements for connectivity:
- You must have the ability to get machine readable data out of your medical device. Most all electronic devices have this ability, provided by a serial port. Alternatively, the device can use an Ethernet and/or Wi-Fi (or perhaps some other wireless technology).
- Next the proprietary data format from the medical device must be parsed and converted into something the target system understands, typically HL7.
- At some point the medical device data must be associated with patient from whence it came. There are many ways to do this, but the key is to make it as automated and reliable as possible.
EMR Integration for Medical Devices: The Basics
Medical device manufacturers in markets that have managed to resist creating connectivity solutions are facing increased pressure from providers adopting EMRs. I mean, what’s the use of automating the EMR if users have to write down numbers read from medical device displays and then manually type them into the EMR? That’s certainly not “automation.” This feature is already a required and necessary feature in some device markets, and rapidly becoming a necessity in many other device markets.
Manufacturers in this situation (needing an interface to EMRs for clinical documentation) often come to me with a plethora of questions. Before we get started, let’s frame the discussion. In this post you will be introduced to a framework for clinical documentation connectivity. I do not get into details on product design or features. Rather we look at a basic framework and external factors that come to bare on any manufacturer contemplating a connectivity feature for their products. What follows is a sketched in foundation or starting point for manufacturers to use to plan for and implement what is probably the most basic connectivity application.
Let’s run through the basics.
What are the basic components of a clinical documentation solution for a medical device?
Medical Device Interoperability Workshop
There is a FDA (CDRH) Workshop on Medical Device Interoperability scheduled for January 25 – 27 at the FDA’s White Oak Campus in Silver Springs, MD. Here’s a link to the meeting’s official web site, which includes a number of downloadable files on the agenda, meeting logistics and background.
There is little question the workflow automation and intelligence offered by interconnecting medical devices can improve patient safety. There’s also little doubt that there is significant market demand for such solutions. For example, if hospitals could purchase PCA pumps and SpO2 monitors that were interoperable, i.e., the monitor could suspend drug delivery at the first indication of respiratory arrest, such a capability would quickly become a standard of care. Interoperability is a huge opportunity.
There is no doubt that there are unintended — and in some respects, unregulated by the FDA — systems of systems made up of medical devices sold and in use by health care providers. At the most basic level, there are medical devices with serial ports that were never intended to provide connectivity (or Medical Device Data Systems as the FDA called them in a draft rule issued almost 2 years ago). At the other extreme, you have systems like closed loop infusion therapy delivery, made up of components that are both regulated and unregulated, and that were originally developed with little or no thought to the demands of interoperability. This is a problem.
The FDA’s been interested in this area for some time. Way back in 2005, the FDA held a workgroup to discuss the system of systems issue regarding networked medical devices (see the blog posts here, here and here). The outgrowth of this meeting was IEC 80001, which is scheduled to be completed this year. In 2007, the FDA published an excellent draft guidance on wireless medical devices (posts here and here) on how to apply the Quality System regulation to wireless medical devices. (I can’t help but wonder why this is still a “draft” guidance.) Also back in 2007, the FDA provided a rather limp statement on interoperability at the 2007 conference on Medical Device Interoperability and High Confidence Software (see the posts in this search). (Offered as the first example of the FDA’s interest in interoperability is their dubious buy-in to the questionable patient safety benefits of new medical device unique device identification requirements was not inspiring — more here.)
