Archive for the 'Medical Devices' Category

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 Staff Software Engineer in the Health Informatics division 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.

Plug-and-Play Medicine

The MIT Technology Review article Plug-and-Play Medicine claims that:

… a Boston research group has come up with a software platform for sharing information among gadgets …

Uh, what software platform? I discussed the MD PnP program a couple of years ago. Other than the Integrated Clinical Environment (ICE, ASTM F2761:2009) standards work I don’t see a lot of progress, let alone software to look at.  The draft ASTM standard (Dec-2008) is still just a shell. The overall model structure makes sense, but the models themselves are not described in any detail (that I could find anyway).

I have a lot of respect for academic endeavors, but creating a comprehensive standard for something as multidisciplinary and complicated as medical device connectivity will not be an easy task.   I once participated in an ASTM standard that was limited to a single communications protocol, and it took years to finalize.  Developing models for how systems behave and interact is at a level of complexity that I’m not sure can ever really be standardized (how do you nail down a moving target?).

A good example is HL7 V3 RIM (Reference Information Model).  RIM has been under development for more than 10 years and as HL7 RIM: An Incoherent Standard (warning: PDF) points out, many mistakes have been made.  These issues may partially explain the woeful rate of HL7 V3 adoption.

The other thing HL7 V3 shows is the magnitude of work required in these standards efforts. The MD PnP group understands this and that standards are just part of the solution. The slide from here (warning: PDF) summarizes this well:

PnP

Unfortunately, the devil is in all these messy details and is the reason why plug-and-play medicine is still a long way off.

Hat tip: Mike Attili

Medical Device Software on Shared Computers

ECG PCThe issues raised in Tim’s post Running Medical Device Software on Shared Computers literally opens Pandora’s box. Installation of medical device software on general purpose computers is an intractable problem.

It’s very similar to the complications associated with Networked Medical Devices, except worse.  An FDA approved device in a changing network environment is one thing.  Software that controls a medical device on a PC that is open for the user to install operating system upgrades, applications, and other device drivers is a recipe for disaster.

I don’t care how obsessed a vendor is, there is no way for a medical device manufacturer to verify proper operation for all possible hardware and software environments.

With today’s PC architectures, the highest risk area is at the device driver level. Running multiple devices that require even modest I/O bandwidth can cause interference that could result in lost or significantly delayed data. This is especially true with Windows XP or Vista that do not inherently provide any real-time data processing capabilities.

I think the best strategy is to provide stand-alone medical devices that have no dependencies on the PC hardware and software that may be available for down-stream data processing and display. This not only reduces compatibility risk, but it can also address mobility issues. With miniaturization and wireless capabilities, the medical device can now travel with the patient.

Also, with Pandora’s box safely closed, solving the networked medical device issues suddenly feels manageable.

UPDATE (9/15/09): Here’s an interesting take on this subject from the consumer perspective: Should Medical Devices Multitask?

Inaugural Medical Device Connectivity Conference and Exhibition

meddeviceconn-conf

Tim Gee has put together an impressive conference. It’s happening Sept. 10-11, 2009 in Boston. Unfortunately, I will not be able to attend. Hopefully Tim and others will be able to provide highlights from the many interesting topics.

Here’s a condensed list of the agenda:

Day 1:

MEDICAL DEVICE  CONNECTIVITY IN HEALTH CARE: WHERE ARE  WE, WHERE ARE WE GOING, AND HOW DO WE  GET THERE?  Tim Gee, Connectologist & Principal, Medical  Connectivity Consulting

CONNECTING  OPERATIONAL AND STRATEGIC PERSPECTIVES  Julian M. Goldman, MD, Medical Director of Biomedical Engineering, Partners HealthCare System, Director,  CIMIT Program on Interoperability and Medical Device Plug-and-Play Interoperability Program, Massachusetts General Hospital

INDUSTRY STANDARDS  (FORMAL AND DE FACTO) IN CONNECTIVITY Charles (Chuck) Parker, Executive Director, Continua Health Alliance

PANEL DISCUSSION: INDUSTRY STANDARDS – WHICH STANDARDS WILL BE ADOPTED AND WHY?

IMPACT OF PROPOSED FDA RULE ON MEDICAL DEVICE DATA SYSTEMS William A. Hyman, ScD, PE, Professor, Department of Biomedical Engineering, Texas A&M University & President, ACCE Healthcare Technology Foundation

IEC 80001 AND PATIENT SAFETY Stephen L. Grimes, FACCE, FHIMSS, FAIMBE, Vice
President, Technology in Medicine, Inc. & Immediate Past President, American College of Clinical Engineering (ACCE)

PANEL DISCUSSION: HOW WILL MDDS AND IEC 80001 IMPACT THE MARKET?

HOW CLINICIANS AND DEVICE MANUFACTURERS CAN COLLABORATE TO REDUCE RISK Steven R. Rakitin, President, Software Quality Consulting & AAMI member

THE BASIC COSTS OF CONNECTIVITY Bridget Moorman, CCE, President, BMoorman Consulting, LLC

Day 2:

TRACK A – INFRASTRUCTURE

CONVERGED MEDICAL DEVICE AND ENTERPRISE NETWORKS: CHALLENGES AND BEST PRACTICES

OPTIMIZING SUPPORT FOR POINT OF CARE AUTOMATION

DISTRIBUTED ANTENNA SYSTEMS: REALITY VERSUS HYPE

WIRELESS SENSORS: PERFORMANCE, COEXISTENCE & INTEROPERABILITY

TRACK B – CONNECTIVITY SOLUTIONS

INFUSION PUMP CONNECTIVITY FOR EMR DOCUMENTATION

ENABLING POINT OF CARE APPLICATIONS WITH DEVICE CONNECTIVITY

POSITIVE PATIENT ASSOCIATIONS IN CONNECTIVITY

OPERATING ROOM INTEGRATION: THE INFORMATION CROSSROADS IN SURGERY

TRACK C – CLINICAL & WORKFLOW IMPACTS

POST SURGICAL PATIENT-CENTRIC CENTRAL SURVEILLANCE: PREDICTORS OF CARDIORESPIRATORY MORBIDITY

THE LINK BETWEEN MEDICAL DEVICE CONNECTIVITY AND CLINICAL DECISION SUPPORT FOR INTERVENTIONAL GUIDANCE

CREATING A CONNECTIVITY STRATEGY FOR HEALTHCARE

OPTIONAL POST-CONFERENCE WORKSHOPS

ONE — DISTRIBUTED ANTENNA SYSTEMS IN HOSPITALS: BEST PRACTICES

TWO — IEC 80001-1: APPLICATION OF RISK MANAGEMENT FOR IT NETWORKS INCORPORATING MEDICAL DEVICES

UPDATE (9/10/09): Tim is posting conference updates here: The Connectologist

UPDATE (9/16/09):

Review #1: Wireless connectivity and medical devices

Integrating wireless technology into medical devices presents the industry with both a carrot and a stick: Stimulus cash (carrot) versus increasing demand for connective devices from hospitals (stick).

Review #2:  Analyst: Healthcare’s wireless sensor opportunity

Gee broke down some of the drivers for the recent interest in medical sensors, outlined use cases and dissected the market for the more than 200 attendees at last week’s event.

When Cell Phones Become Medical Devices

airstripMobile devices are quickly becoming the conduit of choice for collecting and disseminating clinical data.  The FDA will soon be forced to step in and take regulatory control.  It’s going to happen eventually.

Bradley Merrill Thompson does a good job of outlining the factors that lead to FDA oversight in the article FDA may regulate certain mobile phones, accessories. The Components vs. Accessories distinction is an important one for manufacturers — regulatory oversight is dependent on who buys it. The “intended use”, labeling, and marketing are also factors.

Because of its unique user interface, display, and broadband capabilities the Apple iPhone is a particularly attractive platform for medical applications. For example, the AirStrip OB application is available for download at the Apple App Store and is FDA cleared. Other modalities, like the Critical Care monitor application (shown) is still in testing.

The “intended use” issues are complex.  A cell phone that is used to communicate clinical information, e.g. to a PHR, essentially becomes part of a Networked Medical Device.

This mean that 510(k) premarket notification may also be necessary under the proposed Medical Device Data System (MDDS) rules.  If you read though what constitutes a MDDS, you can see how well the definitions fit mobile device functionality:

  • The electronic transfer or exchange of medical device data from a medical device.
  • The electronic storage and retrieval of medical device data.
  • The electronic display of medical device data.
  • The electronic conversion of medical device data from one format to another format.

Its not the end of the world to be classified as a medical device, but verification and validation of these functions are not a trivial endeavor (see here).

The FDA is almost certainly looking and will be taking action soon.

UPDATE (7/25/09): Here’s a mobile device that does not appear to have FDA approval: EKG On Your Mobile Wherever You Are

UPDATE (11/24/09): When will the FDA drop the gavel?