Tim provides a good starting point for understanding this in EMR Integration for Medical Devices: The Basics.
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.
I'm jealous of companies that get to produce diagnostic medical devices without having to go through the FDA 510(k) process. For example, the iHealth BP3 blood pressure monitor is a high-tech looking device with a free Apple application:
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 article Is Cloud the tomorrow of Medical Devices Industry? includes some of the challenges -- regulatory, privacy, security etc. -- faced by manufacturers trying to manage medical device data in the cloud. You can't disagree with this statement:
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:
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.
Today's New York Times Magazine The Year in Ideas: 10th Anniversary Special features the MIT Cardiocam:
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.
This year's Medical Device Connectivity Conference is being held Sept. 28-29, 2010 in San Diego.
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:
Looks like another great conference!
Here's an interesting analysis of security threats within a Windows-based hospital network for embedded medical devices: A threat analysis of critical patient monitoring medical devices.
The threat models are fairly complex and clearly a product of wider enterprise network IT security needs. I've discussed some of the other issues of putting medical devices on an institutional network in Networked Medical Devices. Security threats were not covered and this is an important topic for every hospital network.
There are a couple of items in this article worth commenting on.
The top five unmitigated threats were found to be:
The corrective action for the top threat (T002) was (my highlight):
After it was decided to remove all ePHI from the medical device data storage, the risk assessment changed and the threat of the medical device infecting the hospital enterprise network (T017) then became our primary concern.
This may be the "most effective countermeasure possible for HIPAA compliance and protecting patient privacy", but it is a not practical solution in the real world. Many medical devices store patient demographics. Because the benefits of patient identification outweigh the security risks, this practice is not likely to change in the future.
On these questions:
I generally agree with the conclusions for the device under analysis. The challenge for a hospital is how do you ensure that every networked medical device follows these best practices (communications integrity, hardened OS, clean distribution media, etc.)?
The FDA approved ISO 62304 as a recognized software development standard in 2009. Developing Medical Device Software to ISO 62304 gives a nice overview.
Besides providing a globally accepted development process one of the other practical components is the assignment of a safety class to individual software items and units:
Each classification changes the required documentation for the assigned software.
These standards will become more widely known as the FDA moves to regulate the proliferation of medical applications for personal and home use, most notably software that runs on mobile devices. I've discussed this before in When Cell Phones Become Medical Devices. As noted more recently in FDA oversight may extend throughout health IT:
... an FDA director stated flatly: "Under the Federal Food, Drug and Cosmetic Act, HIT software is a medical device."
Broad FDA oversight at the QSR/62304 level will probably not happen, but change is certainly coming for many HIT companies.
The Elsmar Cove Forum IEC 62304 - Medical Device Software Life Cycle Processes has a lot of discussion on this topic. This is where I found a document checklist that is useful for understanding the process scope:
IEC62304_Checklist.xls (Excel spreadsheet)
UPDATE (9/9/10): IEC 62304 – The Basics
Andrew Dallas's article Caution: V&V May Be Hazardous to Software Quality touches on a number of good points regarding software quality best practices.
Medical device software development V&V (also see here) and the documentation that goes with it have substantial costs. Any strategy that can reduce this overhead and still meet the necessary quality standards should be seriously considered.
The use of "incremental" software development approaches really refers to Agile methodologies. I've talked about the use of Agile for medical device software development several times:
Most of the discussion revolves around the risks associated with this approach. The benefits of any process change have to be weighed against the possible risks that might be introduced.
Besides the importance of understanding what V&V documentation the FDA actually wants to see, Andrew makes a great point about producing quality software versus the V&V process (my highlight):
V&V is not software testing. Verification testing ensures specified requirements have been fulfilled. Validation testing ensures that particular requirements for a specific intended use can be consistently fulfilled.
Following the required FDA V&V processes alone is not sufficient to ensure software quality. You also have to adhere to software development best practices at all levels. For example, in addition to non-functional requirements there are many software quality factors that require careful design considerations and testing that you may decide are outside the scope of FDA reporting. Deciding what to report and what to leave out is the balancing act.
Developing Software for Medical Devices – Interview with SterlingTech gives a good overview of the challenges that especially face young medical device companies. In particular (my emphasis):
Make sure that your company has a good solid Quality System as it applies to software development. Do not put a Quality System into place that you can not follow. This is the cause of most audit problems.
I couldn't have said it better myself, though I think that focusing on the FDA may distract you from why you're creating software quality processes in the first place. The real purpose of having software design controls is to produce a high quality, user friendly, robust, and reliable system that meets the intended use of the device. If your quality system does that, you won't have to worry about FDA audits.
Since Klocwork is a static analysis tool company I also want to point out a recent related article that's worth reading -- and trying to fully understand:
A Few Billion Lines of Code Later: Using Static Analysis to Find Bugs in the Real World
Note the user comment by Bjarne Stroustrup.
UPDATE (2/9/10): Here's another good code analysis article:
A Formal Methods-based verification approach to medical device software analysis
As announced at a recent MIT workshop: The BCI X PRIZE: This Time It’s Inner Space:
The Brain-Computer Interface (BCI) X PRIZE will reward nothing less than a team that provides vision to the blind, new bodies to disabled people, and perhaps even a geographical “sixth sense” akin to a GPS iPhone app in the brain.
As I've discussed many times (e.g. BCI: Brain Computer Interface), "mind reading" with EEG is a huge challenge. Another hurtle they have to overcome:
The foundation must court donors to make the $10 million+ prize a reality. Once funding is secured,...
That will be the easy part.
The problem with the X Prize incentive approach is one of expectations. If people believe that Avatar-like advances ("new bodies") is a realisitic result, they will be sorely disappointed.
Even though I'm a certified "mind reading" skeptic I think great BCI strides will inevitably be made. The good news is that these innovations will provide numerous benefits for handicapped individuals.
UPDATE (2/5/10): Here's a great example: Technology Behind Second Sight Retinal Prosthesis
