Archive for the 'Medical Devices' Category

Second Annual Medical Device Connectivity Conference

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:

  • 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!

A Threat Analysis of Networked Medical Devices

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:

  1. Can the medical devices be infected from the enterprise network?
  2. Can the medical devices be infected via removable media?
  3. Can infected medical devices propagate malicious software back into the enterprise network?

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.)?

ISO 62304: The Harmonized Standard for Medical Device Software Development

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:

  • Class A: No injury or damage to health is possible
  • Class B: Non-serious injury is possible
  • Class C: Death or serious injury is possible

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)

The Software Quality Balancing Act

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.

The Challenges of Developing Software for Medical Devices

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

The BCI X Prize

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

Depth of Anesthesia Reality Check

I think this is the first time I’ve ever seen MedGadget express such a strong opinion about a technology.

Masimo Invests in Anesthesia Awareness Technology. Good Move? We Don’t Think So doesn’t pull any punches.

What’s interesting to me is that SEDLine was Hospira’s brain function monitoring business (see here).  Hospira bought the technology from a Boston-based company called Physiometrix in 2005.

Back in my EEG days I had a chance to work with Physiometrix. We interfaced with their EEG front-end hardware in an attempt to develop an OEM relationship.  At the time, they were using essentially the same Bispectral index (BIS) technology as Aspect Medical.  The only other thing I remember is that they were also using QNX.

MedGadget’s skepticism seems well founded. On the other hand, the people at Masimo (a couple of which I know) aren’t dummies . They may know something the rest of us don’t.

Ch-ch-ch-changes

About the only thing you can count on in this world, besides taxes and death, is change.

When we moved from Madison to San Diego in 2005, that was a big change. Of course in Jan/Feb the 70 deg temperature difference makes that decision seem pretty smart. When our 12 y/o golden retriever Miles passed away this past Oct. that change really sucked.

Switching jobs is also a big change.  As I’ve previously discussed, my old company was purchased and I chose not to relocate. As soon as wrote the words “in-the-trenches” I had an inkling that I had probably jinxed myself. Maybe jinxed isn’t the right word, but I certainly ended up in a different situation than I had imagined.

Last week I started working as a Health Informatics Architect at ResMed, a global leader in sleep medicine and non-invasive ventilation.  Like all medical device companies, ResMed is faced with the daunting challenge of providing the therapeutic data produced by their flow generators to physicians and healthcare organizations.

This position will allow me to continue to develop solutions for medical device interoperability, but at a whole new level. Working with a global team at a world-class company is a very exciting opportunity. I’m looking forward to the challenges ahead.

This change is good!

A Medical Device Gateway Data Standard?

The Wipro OEM medical device gateway press release makes it all seem so easy (my highlight):

The device, consisting of interfaces that can feed-in data such as blood pressure, pulse rate, ECG reading and weight from the respective devices, is connected to the gateway that would format it into standard patient information and transmit it to either public health data platform such as Google Health or to private platforms like Microsoft Health Vault.

What exactly is “standard patient information”?  Maybe they’ve finally developed the magic interoperability bullet.  Yeah, right!  I’m sure companies like Capsule see these kind of claims all the time.  Statements like these are unfortunate because they give the impression that health data interoperability is a given. Of course we know that is not the case.

Also, since when is Google Health a public health data platform?

Hat tip: Avantrasara

UPDATE (11/19/09):  Wipro ties up with Intel for rural medical solutions

Access to Medical Data: Are PC Standards and PHRs (You) the Answer?

Dana Blankenhorn’s article Give medicine access to PC standards makes some good points about the medical device industry but (IMHO) misses the mark when trying to use PC standards and PHRs as models for working towards a solution.

I’ll get back to his central points in a minute. One thing I find fascinating is the knee-jerk reaction in the comments to even a hint of government control.  How on earth can someone jump from “industry standard” to a “march towards socialism”? We saw the same thing at this summer’s town hall meetings and in Washington a couple of weeks ago.  The whole health care debate is just mind boggling!

Anyway, let’s focus on the major points of the article. First:

Every industry, as its use of computing matures, eventually moves toward industry standards. It happened in law, it happened in manufacturing, it happened in publishing.

It has not happened, yet, in medicine.

Very true.  In the medical device world, connectivity and interoperability are hot topics. A couple of recent posts — Plug-and-Play Medicine and Medical Device Software on Shared Computers — point out the significant challenges in this area.  In particular, the development and adoption of standards is a very intensive and political process. But where’s the incentive for the industry to go through this? Dana’s comment addresses this (my emphasis):

The role I like best for government is in directing market incentives toward solutions, and not just to monopolies or bigger problems.

The reason health care costs jump every year is because market incentives cause them to. Those incentives must be changed, but the market won’t by itself because the market profits from them.

Only government can transform incentives.

Like it or not, this may to the only way to push the medical industry to do the right thing.  But those other industries didn’t need government intervention in order to create their standards.  Using PC (or other industry) standards as a model for facilitating medical data access just doesn’t work.  The health industry will have to dragged to the table kicking and screaming, and the carrot (or stick) will have to be large in order for them to come to a consensus.

Second, I don’t see the relationship between the use of PHRs and the promotion of standards.

By supporting PHRs, you support your right to your own data. You support liberating data from proprietary systems and placing it under industry standards.  You support integrating your health with the world of the Web, and the benefits such industry standards can deliver to you.

Taking responsibility for your own health data is great, but both Microsoft HealthVault and Google Health are proprietary systems.  Just because your data is on the Web doesn’t make it any more accessible.  And even if one of these PHRs did became an industry standard, it would have very little impact on how EMRs communicate with each other or medical devices in general.

There are no easy answers.

Subscribe

Categories