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.)
Market Trends Series #3: Shift from Dept to Enterprise Focus
From what I have observed over many years, Hospitals have historically approached medical device connectivity projects as a tactical issue to be dealt with. Up until relatively recently, technology alone could be used to solve the connectivity issue (i.e. getting data from point A to point B) with little to no negative impact on clinical workflow. Further, the scope of connectivity projects has been mainly departmentally focused and deployments have been relatively basic. By basic, I refer to projects that have focused on connecting one or two bedside medical devices to a single CIS application or EMR.
Evidence of all of this can be found by looking back at the past 10 or more years and examining typical implementations of biomedical device connectivity to information systems.
• Most implementations up to now have been in very specific care areas such as the ICU and OR.
• Most implementations are relatively small in scope, often in the area of about 20 to 50 beds. Incidentally, for most US hospitals this happens to be about the same number of ICU beds per facility.
• In the ICU, the key devices that are interfaced are typically multi-parameter patient monitors and sometimes ventilators – but vents to a much lesser degree than monitors.
• In the OR, the key devices are typically patient monitors and anesthesia/gas machines.
• Outside of high-acuity care areas, in the general ward there are some limited niche interface solutions for mobile vital signs data capture. Many of these are only semi-automated in terms of truly automating both the data capture and the clinical workflow.
• For virtually all of these implementations, the data collected from the devices is identified though a mapping of the medical device’s location – that is a bed or room location identifier is used to associate the data and alarms.
• The device workflow – that is the steps clinicians are required to perform at the bedside to interact with devices to establish connectivity – has been limited. This is because most of the devices are actually fixed to the location – i.e. the monitors in ICU are mounted to the wall and data is interface via a networked gateway with outbound HL7. Therefore few if any steps are required by clinicians because the devices are permanently tethered to a local PC or terminal server that facilitates the data collection.
But as discussed in some of my previous market trends postings – requirements for connectivity have been changing and in some not so subtle ways. Many hospitals are
