Archive for the 'Medical Devices' Category

Page 3 of 4

Medical Device Software on Shared Computers

Published on September 7, 2009 by Bob in FDA, Interoperability, Medical Devices and Networking. 8 Comments

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

Published on August 27, 2009 by Bob in Interoperability and Medical Devices. 0 Comments Tags: , .

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

Published on July 14, 2009 by Bob in FDA and Medical Devices. 4 Comments Tags: , , .

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?

UPDATE (4/19/11): Navigating Regulatory Uncertainty for Smartphones

 

Networked Medical Devices

Published on December 20, 2008 by Bob in Medical Devices and Networking. 2 Comments Tags: , .

If you work with networked medical devices, Tim’s post Medical Device Networks Trouble Industry is a must-read.

In order to better illustrate the bigger picture I thought this diagram might help:

netmeddev

This summarizes the relationship between the major players involved with integrating medical devices into an enterprise network and highlights some points I think are important.

  1. Only medical device manufacturers have to be concerned with the FDA regulatory aspects of placing computing and networking components into a medical environment. I’ve previously discussed some of the regulatory and verification/validation issues with Connecting Computers to FDA Regulated Medical Devices.
  2. All of the players — hospital IT, medical devices, and IT/EMR software vendors — deal with the same commercially available hardware and software components. This is simply due to the economy of scale.  The medical industry isn’t large enough create the quantities necessary to drive the cost out of most of these devices. We have to depend on the broader high-volume commercial marketplace  in order to reduce cost.
  3. The medical device industry is involved in standards development, but at the end of the day its the broader market adoption that drives down the cost for everyone (see point #2).  I think this is one of the main reasons why “the days of private medical device networks as we know them are over.”
  4. FDA guidance and regulatory efforts in this area will always be in catch-up mode. As the technology and trends change they will be forced to evaluate the impact on patient safety after the fact. This is already happening — as Tim points out (emphasis mine):

The bottom line here is that we can’t all look to the FDA to solve these issues that are the consequence of putting medical device systems on enterprise networks – when you do this, your enterprise network becomes part of a medical device.

Medical devices have been added to enterprise networks for years, yet IEC 80001 and the Medical Device Data Systems rule are still just drafts.

Some other thoughts:

  • Private Medical Device Networks: Wireless networks are more often private. For wired networks “logically separate private networks through the use of network switches and routers” is more the norm. Since Ethernet took over in the mid 90s (anyone remember token ring?) most hospitals have not allowed private in-wall wiring installations.
  • Enterprise Networks: One of the major challenges is just getting your private “logical” system installed on the hospital infrastructure. In addition to reliability, compatibility, routing, and bandwidth are just a few of the issues.  One of the troubling aspects of this from a regulatory point of view is that there is no way for a medical device manufacturer to test all of the possible configurations that may arise in the field. The sustaining engineering and network variability issues are related problems.
  • Hospital IT Culture: This is an issue that I have seen first-hand.  A previous medical device I worked on used an embedded POSIX compliant UNIX variant. We ran into several hospital IT departments that refused to approve the medical device purchase because their policy would only allow computers running certain versions of the Microsoft OS on their network. This happened quite a few years ago. I can only hope that the integration philosophies of hospital IT departments have become more enlightened since then.

UPDATE  (1/15/09): Here’s another good article on this subject:  Smoothing the Rocky Path of Interconnected Medical Devices.

Keeping Your Own Health Chart, Online

Published on October 12, 2008 by Bob in Medical Devices and PHR. 0 Comments

The New York Times has a piece today that features the Zuri, Healthvault, and Google Health:

Keeping Your Own Health Chart, Online

The article discusses a number of uses for this kind of combined (medical device plus PHR) functionality.  Besides the obvious, it’s interesting that clinical trial matching (TrialX) is also mentioned.

User control of on-line health information has many hurdles to overcome.  Even with adequate security:

First, however, patients will have to become comfortable placing medical data like readings from home tests online.

Medical Devices in Home Health Care

Published on August 10, 2008 by Bob in Medical Devices, PHR and Technology. 4 Comments


If a company like Intel gets involved you know that providing home health screening devices must be a big opportunity.

Intel Health Guide is designed to be a comprehensive home monitoring service.

  1. In-home patient device.
  2. An online interface allowing clinicians to monitor patients and remotely manage care.
  3. Interactive tools for personalized care management.
  4. Integrates vital sign collection.
  5. Patient reminders.
  6. Multimedia educational content and feedback.
  7. Communications tools such as video conferencing and e-mail.
  8. Can connect to specific models of wired and wireless medical devices:
  • blood pressure monitors
  • glucose meters
  • pulse oximeters
  • peak flow meters
  • weight scales

The Health Guide stores and displays the collected information on a touch screen and sends to a secure host server, where health care professionals can review the information. Patients using the Health Guide can monitor their health status, communicate with care teams and learn about their medical conditions.

Another recent announcement is by Freescale Semiconductor: Here comes an ECG-on-a-chip solution!. The Freescale Electrocardiogram (ECG) Hardware Solution along with Monebo ECG Monitoring Algorithms will allow for low-cost integration of ECG monitoring for remote monitoring and even in home-based devices.

There are many health conditions that would benefit from improved remote monitoring capabilities, but heart disease is certainly at the top of the list and has been shown to reduce hospital re-admissions.  Holter monitoring has been around for a long time, but this type of embedded ECG hardware and software technology along with interactive devices like the Intel Health Guide, could significantly raise the bar for ambulatory patient heart monitoring.  Companies like CardioNet are already counting on this trend.

It’s a good bet that PHR providers like Google Health and Microsoft HealthVault will start to incorporate similar interactive technologies into their offerings. Also, Microsoft offers a device certification program that will draw in more devices. Google has similar developer and branding policies in place (see here).

UPDATE (8/19/08): Tools Help Patients Interface With Doctors which also discusses the Zuri device.

UPDATE (11/10/08): Intel Health Guide Undergoing Trials

UPDATE (12/17/08): Intel Health Guide

Digital Devices and EHRs: the ROI

Published on July 28, 2008 by Bob in EMR and Medical Devices. 1 Comment

Here’s a piece that provides a quick analysis of the ROI of having vital signs and ECG devices connected to an EMR:

Digital Devices and EHRs — Perfect Together

The right way to do it:

Electronic transfer of patient information

Electronic transfer of BP and heart rate

Electronic recording of test

MD views results from anywhere

DONE — half the steps, half the time

Ah, if it were only that easy.

More Software Forensics and Why Analogies Suck

Published on July 1, 2008 by Bob in FDA, Medical Devices and Software Quality. 3 Comments

There’s a recent article in the Baltimore Sun called Flaws in medical coding can kill which just rehashes static software  analysis (hat tip: FDA Trying to Crack Down on Software Errors).

I’ve discussed software forensics tools before. Yes, bad software has hurt and killed people, and there’s no excuse for it.  I still don’t think an expensive automated software tool is the silver bullet (which is implied by the article) for solving these problems.

But here’s what really bugs me:

“If architects worked this way, they’d only be able to find flaws by building a building and then watching it fall down”

This is a prime example of why analogies suck.  The quote is supposed to somehow bolster the FDA’s adoption of “new forensic technology”. If you stop and think about it, it does just the opposite.

I guess you first have to consider the source –  a VP of Engineering for a forensic software vendor. This is exactly what a you’d expect to hear in a sales pitch.

What’s truly ironic though is that a static analysis tool can only be used on source code! Think about it. Source code is the finished product of the software design and development process. Also, forensic science, by definition is the presentation of something that has already happened. It can only be done after the fact.

The logical conclusion you would draw from the analogy is that static analysis is probably useless because the building is already up!  If you step back and look at the full software quality process, this may well be true.

I’m not saying that static analysis tools don’t have value. Like all of the other software tools we use, they have their place.

Just beware when you try to use an analogy to make a point.

UPDATE (7/5/08):

Here’s another take on medical device bugs: When bugs really do matter: 22 years after the Therac 25.

UPDATE (7/16/08):
From Be Prepared: Software Forensics Gaining Steam at FDA, David Vogel of ­Intertech Engineering Associates says:

… that static tools are hyped to do more than they can actually deliver. “Static analysis looks for simple coding errors and does not apply heuristics to understand how it will perform dynamically because it is a static analysis tool”

I agree.

UPDATE (7/26/08):

Another reference : Are hospitals really safe?

UPDATE (9/16/08):

A couple more related articles:

Applying Static Analysis To Medical Device Software

Using static analysis to diagnose & prevent failures in safety-critical device designs

UPDATE (9/27/08):

Architecting Buildings and Software: Software architects are an important component in the creation of quality software and need to continue to refine and improve their role in the development process.  No matter how you try to bend and twist it though, the building analogy will always be problematic — so why bother? Maybe that “intuitive understanding” of the construction industry just distracts us from being innovative about what’s required to build software.

UPDATE (12/1/08): If Jeff wasn’t a programmer he’d be a farmer: Tending Your Software Garden

Connecting Computers to FDA Regulated Medical Devices

Published on June 18, 2008 by Bob in FDA, HL7, Medical Devices, Networking and Software Quality. 2 Comments Tags: , .

Pete Gordon asked a couple of questions regarding FDA regulations for Internet-based reporting software that interface with medical devices. The questions are essentially:

  1. How much documentation (SRS, SDS, Test Plan) is required and at what stage can you provide the documentation?
  2. How does the FDA view SaaS architectures?

The type of software you’re talking about has no real FDA regulatory over site. The FDA has recently proposed new rules for connectivity software. I’ve commented on the MDDS rules, but Tim has a complete overview here: FDA Issues New MDDS Rule. As Tim notes, if the FDA puts the MDDS rules into place and becomes more aggressive about regulation, many software vendors that provide medical devices interfaces will be required to submit 510(k) premarket approvals.

Dealing with the safety and effectiveness of medical devices in complex networked environments is on the horizon. IEC 80001 (and here) is a proposed process for applying risk management to enterprise networks incorporating medical devices.  My mantra: High quality software and well tested systems will always be the best way to mitigate risk.

Until something changes, the answer to question #1 is that if your software is not a medical device, you don’t need to even deal with the FDA. The answer to question #2 is the same. The FDA doesn’t know anything about SaaS architectures unless it’s submitted as part of a medical device 510(k).

I thought I’d take a more detailed look at the architecture we’re talking about so we can explore some of the issues that need to be addressed when implementing this type of functionality.

mdds2.jpg

This is a simplified view of the way medical devices typically interface to the outside world. The Communications Server transmits and receives data from one or more medical devices via a proprietary protocol over whatever media the device supports (e.g. TCP/IP, USB, RS-232, etc.).

In addition to having local storage for test data, the server could pass data directly to an EMR system via HL7 or provide reporting services via HTTP to a Web client.

There are many other useful functions that external software systems can provide. By definition though, a MDDS does not do any real-time patient monitoring or alarm generation.

Now let’s look at what needs to be controlled and verified under these circumstances.

  1. Communications interaction with proper medical device operation.
  2. Device communications protocol and security.
  3. Server database storage and retrieval.
  4. Server security and user authentication.
  5. Client/server protocol and security.
  6. Client data transformation and presentation to the user (including printed reports).
  7. Data export to others formats (XML, CSV, etc.).
  8. Client HIPAA requirements.

Not only is the list long, but these systems involve the combination of custom written software (in multiple languages), multiple operating systems, configurable off-the-shelf software applications, and integrated commercial and open source libraries and frameworks. Also, all testing tools (hardware and software) must be fully validated.

One of the more daunting verification tasks is identifying all of the possible paths that data can take as it flows from one system to the next. Once identified, each path must be tested for data accuracy and integrity as it’s reformatted for different purposes, communications reliability, and security. Even a modest one-way store-and-forward system can end up with a hundred or more unique data paths.

A full set of requirements, specifications, and verification and validation test plans and procedures would need to be in place and fully executed for all of this functionality in order to satisfy the FDA Class II GMP requirements. This means that all of the software and systems must be complete and under revision control. There is no “implementation independent” scenario that will meet the GMP requirements.

It’s no wonder that most MDDS vendors (like EMR companies) don’t want to have to deal with this. Even for companies that already have good software quality practices in place, raising the bar up to meet FDA quality compliance standards would still be a significant organizational commitment and investment.

Corrective and Preventive Action (CAPA) and the FDA

Published on March 11, 2008 by Bob in FDA and Medical Devices. 1 Comment

It’s Easy to Get into Trouble Because of CAPA summaries an audio conference on Implementing an Effective CAPA System: What You Need to Know (pdf) sponsored by FOI Services.

Creating a corporate culture that can carry out a quality system plan is a big challenge, especially for new medical device companies. As this figure aptly shows (hacked from page 42), aligning the organization with a formal project Mission Statement, Scope, Goals, and Communication Plan is a key component for implementing an effective CAPA system.

Developing an Effective Nonconformance Control and CAPA system

The survey statistics on the use of risk management tools and CAPA effectiveness are interesting. Of particular interest of course are the number of firms sited by the FDA for CAPA deficiencies. The slides detailing CAPA implementation and advice are also quite informative.

I stared at the “Big C” (page 23) for a while. I know it’s trying to show the relationship between CAPA (820.100, “little c”?) and the rest of the quality system. I thought I figured it out a couple of times, but in the end I was not able to decipher its true meaning. I could buy the audio CD to find out or maybe Jan can just clarify it for us.

Subscribe

Categories

Twitter Updates