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.)
Last year the FDA was one of several organizers in a series of workshops on wireless medical devices. Oh, and I almost forgot the FDA's proposed rule on Medical Device Data Systems (MDDS) it was published so long ago (2 years ago next month). You can read more about the draft MDDS rule here, here, here, and here. Finally, the FDA has participated in a number of standards and test and certification efforts, such as the IHE's Patient Care Device workgroup.
In many ways, the FDA's regulatory framework is based on the concept of medical devices as stand alone black boxes controlled by manufacturers and used by health care providers. With stand alone medical devices, a regulatory framework that only applies to manufacturers is fine. But when medical devices become components in wider systems that are designed and implemented by sometimes unregulated third parties and maintained by customers, things can break down. As a result, the efficacy of this long standing regulatory framework is called into question. The blog post Medical Device Networks Trouble Industry, offers another example of the potential gaps resulting from limiting regulatory requirements to manufacturers. Medical device networking was also the subject of my presentation proposal for the workshop.
So what's the purpose or desired outcome of this workshop? From the workshop web page:
The purpose of the workshop is to facilitate discussion among FDA, industry, academia, professional societies, clinical investigators and other interested parties on issues related to safe and effective interoperable medical devices.
This is an uninspiring, or more accurately, overly broad objective. In fact, anyone who attends is likely to have more substantive objectives they'd like to see realized. For example:
- A desire to be educated, either industry's interests in the regulatory requirements for medical device interoperability, or regulators interests in the kinds of interoperable solutions offered or under consideration by manufacturers
- A goal of convincing the FDA to adopt a new and less onerous regulatory framework within which to realize interoperability
- The objective to gain specific regulatory guidance from the FDA on how to apply current regulations to specific products incorporating interoperability
- As always, there will be some health care providers in attendance who simply want to know how they can go about buying or creating the interoperable solutions they've been waiting for so long
After chairing last September's inaugural Medical Device Connectivity Conference in Boston, I'm just glad to be an attendee.
UPDATE: A revised agenda (dated January 20, 2010), including descriptions of all the presentations, has been released. You can download it here.
Tim,
I am glad to see that you will be there to ask the right questions. What is your perspective on initiatives like what NIST (and others) are working on, do you really see any of the major vendors actually committing to non-proprietary protocols in the next 10-15 years? It would be nice that if one day reaching interoperability did not mean supporting 6 gateways to make 3 products work together or the requirement of another Rosetta Stone.
From an alarm management standpoint, what worries me is that I think the major vendors are going to create partnerships or in the case of Philips, buy another vendors technology. I could easily see each major device vendor aligning themselves with a specific middleware vendor and then submitting their solution as an overall system to the FDA. This of course will just push the dream of enterprise solutions out farther.
The SIP protocol is a great example of what is going on out there, now I need two different vendors SIP servers to support two versions of a Nurse Call system that is made by the same manufacturer.
Thanks,
Craig
Craig, I’m not sure which initiatives you’re referring to that NIST and others are working on. If you mean IHE PCD activities, you probably know that most of what’s shown at the Interoperability Showcase each year at HIMSS does not make it into commercial products you can actually buy. There are exceptions to this, and I welcome those vendors to post comments here describing them.
Currently all messaging middleware applications like alarm notification are built on one-off custom integrations. The business model is indeed to create partnerships to create solutions limited to a particular set of products and manufacturers.
When you start tying things in to phones, you run into all sorts of standards: TAP, SIP, ESPA in Europe, and various IP protocols. And you’re right, there are multiple variations of many of these standards that makes integration challenging.
We would likely have never gotten a rational implementation of DICOM if the US military hadn’t started requiring it for their purchase of imaging modalities. There are some activities that will hopefully steer the industry in a more productive direction — HITSP, ICE, and possibly the IHE PCD.
It is interesting to note how the remote monitoring/ambulatory market is out pacing the hospital market in this regard through the efforts of the Continua Health Alliance. It seems they were founded yesterday, yet they already have cross-vendor interoperable products released and for sale!
Tim,
Thank you for the response. I misspoke when I referenced NIST, I was looking at the test tools they have out around x73 when I was writing that. With respect to the military driving a rational implementation of DICOM, I absolutely agree. Perhaps, with the recent research grant given to Live Data from the US Army Telemedicine and Advanced Technology Research Center, they will once again drive adoption (beyond the OR).
Don’t get me wrong, I think interoperability will be great, however I will just be happy when we get to a point where you don’t need six proprietary gateways, four different SIP servers and a multitude of other points of failure just to get a couple of data points or a message from point A to B.
The old military saying applies here to the vendors, “Lead, Follow, or Get Out of the Way.â€
Craig
The missing piece in the wouldn’t it be great if device A could talk to device B scenario (e.g SpO2 to PCA pump as used here) is, who wrote the rules of that conversation? Was it the SpO2 vendor, the pump vendor, a third party, etc? Are those rules always right, or always wanted? Can you turn the rule on and off? Can you modify it?
Connecting things together does not automatically create an intelligent conversation. Besides the stop PCA for low SpO2 rule, are there other appropriate conversations that are applicable to different patients? If so, then how is the correct conversation selected among the many available conversations?
Are there more than two devices talking? This escaluates the problem non-lineraly (5th power?). Suppose device A is telling device B more, but device C is telling device B less, who wins?
On a more technical note, if I have 100 SpO2s and a 1000 PCA pumps, all accessible via the network, how is it determined which SpO2 is talking to which PCA pump (and when the conversation is over) assuming that the rules of the appropriate conversation have been established.
The ability of two devices to communicate with eachother is a prerequisite to addressing a much more complicated problem. It is not the solution to a problem.