The complexity of the software employed in many medical devices has rendered inadequate traditional methods (testing) for demonstrating their safety.

The article then provides examples of the types of analyses that can be performed to better ensure safety.

Interesting read.

Here are some references:

BohrBug: Not necessarily easy to find, but once discovered is reproducible.

Heisenbug: The ever-annoying bug that can not be reliably reproduced.

Spin: An open-source software tool for formal verification of distributed software systems.

What healthcare executive wouldn’t want a system that:

• Helps nurses locate necessary equipment in seconds?
• Ensures that only the mother of a newborn or a nurse could remove that baby from the nursery?
• Makes sure patients don’t wander into staff only areas?
• Lists inventory of all the medications in a large medicine storage area in minutes?
• Ensures even equipment distribution across wings and prevents theft?
• Tracks disinfection patterns of employees?

Enter RFID.

RFID (radio frequency identification) is a technology in which radio waves emitted from electronic tags identify them uniquely. The tags are often used to pinpoint the location of the object, or person, to which the tag is attached. This is different than barcode technology, which is usually used to identify an object as belonging to a larger category without individual identification. Barcodes also need to be read one-by-one from very close proximity, whereas RFID readers can read many tags with a single pass of an RFID reader a few meters away.

How does RFID work?

First you need the tags. RFID tags can be split into two main categories: active tags and passive tags. The active tags are battery operated and transmit their data periodically to readers. Their reading distance varies between a few meters to hundreds. Passive tags are much smaller (sometimes like a paper sticker) and do not transmit their data until being interrogated by a reader in their proximity. The passive tags’ reading distance can reach 2-3 meters. Passive tags are usually used for inventory purposes.

The readers consist of an RFID antenna connected to an RFID reader. They receive the data from the tags and then, in order to have a functioning system which will do all the above tasks, transmit the data to a software system which manages the received data.

When the system receives the data, it will both store it for immediate or later review by the healthcare staff, as well as act according to predefined rules set by the administrator. For example, in the case of preventing equipment theft, a rule could be set that if tags attached to pieces of expensive lab equipment go past the reader stationed near the exit to the lab, its signal will set off an alarm, alert important staff members, and lock the exits to that wing of the hospital.

How can RFID help a healthcare institution?

Keeping in mind the stunning figure of 15% of hospital equipment stolen annually as well as the damage that improper maintenance causes, RFID tracking can significantly diminish losses and increase efficient use of equipment. It can ensure that only the right person uses or moves any given piece of equipment, guarantee the correct quantities of a certain apparatus in a designated zone, enable the immediate and accurate location of any item, indicate which item is in use or available, and the list goes on.

RFID can also provide an accurate and comprehensive picture of the total amount of the organization’s inventory, including expiry dates and amount of usage, and provide real-time data on parameters such as temperature and moisture levels, providing alerts in the case of inappropriate conditions that could damage equipment and medications.

Add to this the capacity to track patient and staff movement and interactions with other people and objects – and your RFID healthcare system gives you your entire hospital at a glance, and alerts you to problems.

Implementing RFID systems.

RFID technology is also getting easier to customize. In the past, often RFID hardware would be programmed to work only with specific software. Recently, there have been advances in RFID technology enabling administrators to choose hardware and software independently according to the unique needs of each project. Parameterization tools built into the software can customize applications to specific projects while enabling the implementation of RFID projects in a very short time (days to weeks). You no longer have the time, expense and risk that come with developing software just for your project.

With RFID systems, managing healthcare institutions is getting easier, safer and more efficient.

There was one item I’d like to comment on:

The challenge is, of course, regarding regulatory management of open source frameworks. To a large degree open source software is anathema to the FDA regulatory process–and it relates to control and management of access.

OSS detested or loathed by the FDA? I don’t think so. The open source framework itself would not be subject to regulatory control.  The FDA does not really care where any specific software component comes from.  Also, security and  access management are certainly important, but I’m not sure of their applicability at the device connectivity level.

The FDA cares about intended use, efficacy, and safety of medical devices. All FDA regulated software is subject to the same design controls (§820.30) — design, risk analysis, verification, validation, etc. I.e. any company that included these open source software components would ultimately be responsible for proving these processes are followed.

Shahid N Shah’s OSCon 2011 Talk: The implications of open source technologies in safety critical medical device platforms does a good job of detailing these points (Will the FDA accept open source in safety-critical system? Yes!) as well as presenting an OSS connectivity software architecture.

In addition to the post-conference workshops, there is also a special preconference event: an open house at the Medical Device Plug and Play Interoperability program’s lab. September 7, from 4pm to 6pm attendees can tour the lab, interact with various demonstrations and chat with program staff.

Tim has put together another great conference.

• Just about all medical devices are computerized these days. Most will not harm or kill you if their software fails (Class I & II), but that’s no excuse for writing crappy code.
• As pointed out, the mission critical nature of mass transit systems (airplanes, subways, etc.) affords those industries a much higher level of scrutiny then cars or medical devices ever will. But that’s still no excuse for writing crappy code.

Even through drugs and airplanes need advance approval from authorities before being brought to the market, medical devices and software do not, at least in the United States.

• This statement is not correct. All medical devices, including diagnostic and therapeutic software-only products, require FDA clearance to be sold in the US market (see the Class I & II link above).  There are many exemptions, but a 510k pre-market approval is generally a minimum requirement. After you receive approval the FDA can pull your device off the market (the dreaded “recall”) at any time due to complaints or unsatisfactory audit results.
• The FDA QSR Subpart C (§ 820.30) looks a lot like DO-178B as quality system design controls go, but I’m sure the aviation standard enforcement is far more rigorous (well, at least I hope it is). It’s true, there are no coding standards for medical device software.  Good companies set their own development standards and practices — some even use static analysis! It’s all the other companies that don’t bother to do anything that you have to worry about.

I’m certain that static analysis technology has improved vastly in the four years since some of the articles below were written.  The challenge is that the complexity of medical device software and the systems they run on has also increased tremendously during that time. In particular, the explosion of high bandwidth wireless networks along with advances in handheld computing power and graphics capability (think iPhone/iPad, of course) is fundamentally changing the way medical devices will be developed and delivered to the market in the future.

Static analysis will remain a valuable tool for identifying critical software defects, but new methods will have to be developed for rooting out risks in the new network-connected, multi-touch world.

It’s sad to say, but you should probably be more than “a little uncomfortable.”

Other static analysis articles:

A Few Billion Lines of Code Later: Using Static Analysis to Find Bugs in the Real World
More Software Forensics and Why Analogies Suck
Medical Device Software Forensics
Pascal’s 3 part static analysis series that starts here:
Guest Article: Static Analysis in Medical Device Software (Part 1) — The Traps of C

What this highlights of course is that getting data from a medical device into an EMR is a lot harder than it should be. “It’s not pretty” is an understatement.  In the ideal world nobody should have to be connectologist to get medical data where it needs to be.  Unfortunately, we have a long way to go before that becomes a reality.

Hopefully they’re using an approved non-invasive blood pressure (NIBP) device like the SunTech module.

The built-in ability to e-mail results to family or a physician seems useful, but posting your blood pressure on Facebook or Twitter?  I don’t know…

Hat Tip: medGadget

The success of the vision of Smart Connected Health Grid is dependent on wide scale adoption of cloud computing in all areas of healthcare.

There’s no doubt that adoption of cloud-based technologies are starting to provide concrete market opportunities in the Healthcare space.

There are also two major market barriers that will have to addressed in order for the cloud’s full potential to be realized:

1. Who’s going to pay for it?

• The Apple/Google/Facebook “created a marketplace around the end consumer” model will not work in the medical industry.  Consumers do not manage their own healthcare, and certainly not their medical data.
• Glucose monitoring is also not a good model. Strips and meters are reimbursed by Medicare and most private insurers.
• The “Service Delivery Platform” may be a great idea, but unless you can prove its effectiveness at saving money in the overall healthcare delivery system it has only limited value.
• Proving this effectiveness is difficult to do, and the bar is very high on the expected returns for preventative care.  Maybe this is where the vertically integrated Accountable Care Organizations (ACO) could have an impact?
• The end consumer (re: their willingness to spend money anyway) is not likely to be part of the revenue generation equation.

2. Interoperability.

• You can’t overstate connected in “Connected Health Grid.”  This is where the real value is.
• Data collected from a medical device must be put into context with all of the available health data in order to properly access a patient’s current state.
• This means you have to make the device data that resides in your cloud available to be consumed by others, e.g. payers, PHRs, hospital EMR systems, etc.  Each of these interfaces is unique and costly. HIPAA is also key barrier here.
• There are many technical issues surrounding medical device connectivity. I’ve written frequently about these interoperability topics in the past.

The potential is there, but IMO creating a value proposition that will result in a sustainable market based on a technology alone will probably not work. It’s the old “hammer looking for a nail” problem.

Medical device data combined with cloud-based technology will be part of many effective healthcare solutions. Some of these may actually make money, someday.

Cardiocam is a low-cost, non-contact technology for measurement of physiological signals using a basic digital imaging device such as a Webcam. The ability to perform remote measurements of vital signs is promising for enhancing the delivery of primary health care.

Medgadget covered this in October: MIT Student Uses Webcam to Measure Heart Rate From a Distance includes a video that shows how the Cardiocam is used to create a “medical mirror” for home health monitoring.

A link to a PDF (here) has a full description of the research, including their Cardiac pulse recovery methodology:

The method uses Blind Source (Signal) Separation (BSS) by Independent Component Analysis (ICA) of the changes in the video signal:

Volumetric changes in the facial blood vessels during the cardiac cycle modify the path length of the incident ambient light such that the subsequent changes in amount of reflected light indicate the timing of cardiovascular events.

Very cool.

From the press release Tim Gee says:

The only conference devoted to the topic of medical device connectivity, the program will offer a unique opportunity to get immersed into every aspect of connectivity, workflow automation and enabling technologies. The keynotes and panel discussions on the first day frame the conference’s focus on connectivity and tackle two of the biggest issues facing health care: industry standards and regulatory issues. Program tracks on the second day provide a survey of connectivity applications, clinical capabilities and outcomes, and explore the gap between regulated vendor-managed systems and the customer-managed and controlled environments in which these systems are used.

Here are just a few of the topics I’m particularly interested in:

• EMERGING PROBLEMS AND RISING AWARENESS OF MEDICAL DEVICE SYSTEMS ON ENTERPRISE NETWORKS
• LOOKING BEYOND CONNECTIVITY IN HOSPITALS TO HOME HEALTH AND MOBILITY
• OPEN EHR MANIFESTSO: OPPORTUNITIES FOR MEDICAL DEVICE COMPANIES
• INTEROPERABLE MEDICAL DEVICE SYSTEM ARCHITECTURES

Looks like another great conference!