post

Medical Data Flight Recorder Requirements?

Share on FacebookShare on Twitter
Share on TumblrDigg ThisShare via email

medical data flight recorder metaphorThe FDA created a ripple of discussion earlier this month when it released its Fiscal Year 2011 Annual Report from the Office of Science and Engineering Laboratories. There is a figure in the report (figure 5)— which is neither cited— explained, or sourced, as far as I can tell, that claims that about 24% of  of “Recalls” are attributable to software failures. I assume by context that it means “medical device recalls.” I would really like to know where the data behind this chart came from because it’s been widely distributed and cited in the security blogosphere already.  Setting that aside, pending, you know, an actual explanation, the part of the report that caught my attention was the section titled “Medical Device ‘Flight Data Recording’ and Animation,” which calls for devices to include “medical data flight recorders.”

Medical Data Flight Recorder: The Metaphor

Kudos to the Medical Electronics Laboratory (part of the Division of Electronics and Software Engineering, which is part of the Office of Science and Engineering Laboratories, which is part of the Center for Devices and Radiological Health, which is part of the Food and Drug Administration, which is part of the Department of Health and Human Services, whew!). Kudos to the Medical Electronics Laboratory for inventing a metaphor that can be easily understood by oversight committees and funding bodies. Everyone knows about the “black boxes” that record flight data in airplanes. So it’s easy to imagine a “medical data flight recorder” embedded in devices.

The Medical Electronics Laboratory explains their work as:

As medical devices become more complex and interoperable, so too is the need for recording medical device data. To address this issue we are developing a set of “flight data recording” requirements that can be used in medical devices (or networks of medical devices) to help eliminate or mitigate future adverse events.

It is not enough to be able to record adverse event data. There is a need to “play back” or animate the data in a manner that is helpful to investigators. This issue becomes particularly complex for interoperable devices. Here, it may be necessary to integrate and animate data from multiple medical device flight data recorders to gain a comprehensive understanding of an adverse event. Researchers are developing techniques to perform this animation integration.

Analogs in the IT Industry

Let me be the first to use the term medical information event management (MIEM). No doubt a magic quadrant for this  market segment will emerge real soon now. And I’m sure someone will soon develop a medical device nmap-like tool— heck let’s go ahead and call it “mmap”—  for exploring and mapping networks of medical devices. And let’s go ahead and invent a market segment for managing medical device “endpoints.” The medical data flight recorders can be a component of the endpoints and be discoverable by mmap. Their data can be collected, archived, and analyzed by product offerings in the MIEM market segment. I’m willing to bet that IBM’s QRadar SIEM appliance could easily be adapted to managing and analyzing event data.

In case my snarky point isn’t obvious, there’s a huge, mature market for securely managing event data, medically related or otherwise. Why do we need people in the FDA setting up developing a set of requirements for medical data flight recorders when there are existing standards that can be used off the shelf? An annual report is not going to give the folks at the Medical Electronics Laboratory space to build their case. But I think the burden is on them to explain why this topic must be built up from scratch.

photo credits

 

Speak Your Mind

*

2,429 Spam Comments Blocked so far by Spam Free Wordpress

HTML tags are not allowed.