Bob on Medical Device Software

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.

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.

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.

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.

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.

I read with interest “Art Vandelay’s” (an anonymous Seinfeld fan and HIStalk contributor) comments regarding Patient Command Centers on HIStalk Update 1/21/08. Here’s what the PCC is supposed to do:

It will manage service desks for IT, facilities, clinical engineering, and equipment, as well as clinical alerts and data from medical devices and the computerized patient record for singular issues and trended problems.

Wow! That’s a tall order. Even with advanced tracking systems and AI software trying to make sense of all the activity (events), it seems to me that all these management tasks would require intensive human interaction.

“Art” also raised a question regarding device communications:

SNMP isn’t that complex. What are the chances of getting the medical device vendors to add this to their devices?

IMHO, probably not real good. SNMP was primarily used for the management of network devices (routers, hubs, etc.) and protocols. On the surface, its ability to manage large numbers of enterprise networked devices seems like it would be a good fit for hospitals. Unfortunately, the development and adoption of a unique object identifier (OID) for each medical device seems unlikely. Also, a new OID would require the SNMP manager software to be updated in order to recognize it and properly handle the new data.

As medical devices have become networked, the trend has been to embed an HTTP (Web) server in them. This allows secure remote access and control via any Web browser. Many other commercial networked devices have also taken this route.

Even with my pessimistic view on a couple of the details, I don’t think the vision for a PCC is any worse off than it was before. The concept of a PCC is broad and ambitious. As such, its value to an institution and implementation details need to be continually explored and refined.

I ran across Commercial brain computer systems are coming today (original article is here). This is a cool graphic:

I’ve talked previously about Human-Computer interface (HCI) work.

Invasive BCI technologies have incredible potential. In addition to the unique device-human interface challenges (primarily sensors), it will also require significant advancements in the basic understanding of the underlying electrophysiology (cortical and motor). As reported, EEG-based processing will continue to be a corner-stone for this work, just as it is for non-invasive systems.

This slide from the report (pp. 170) summarizes the uses and importance of this type of work:

Here’s a shorter overview of BMI: Mind Controlled Bionic Limbs

Earlier today I was in my auto shop’s waiting area while my car had its annual smog check. I started looking through the pile of magazines and came across the November 2007 issue of Popular Mechanics. To my amazement the cover article was on fMRI (functional magnetic resonance imaging) — Thought Police: How Brain Scans Could Invade Your Private Life.

My previous discussion on Mind Reading Software was mostly concerned with techniques that used EEG signal processing. fMRI technology is summarized by the article:

The underlying technology involved in functional magnetic resonance imaging has been around for decades. What’s new is the growing sophistication in how it is being used. Inside a massive doughnut-shaped magnet, an fMRI scanner generates powerful fields that interact with the protons inside a test subject’s body. The hemoglobin molecules in red blood cells, for instance, exhibit different magnetic properties depending on whether they are carrying a molecule of oxygen. Since regions of the brain use more oxygen when they’re active, an fMRI scanner can pinpoint which areas are busiest at a given moment. These can be correlated with our existing anatomical understanding of the brain’s functions—and, as our knowledge of these functions improves, so does the accuracy of neuroimaging data. With fMRI, then, researchers can see what is going on across the entire brain, almost in real time, without danger or discomfort to the test subject.

As the title indicates, most of the article discusses the on-going debate over the use of fMRI for things like lie-detection. There’s also an overview of some fMRI research activities.

NPR’s Morning Edition also ran a story on this last week: Neuroscientist Uses Brain Scan to See Lies Form.

Just like with EEG-based techniques, fMRI “mind reading” provokes many legal and ethical questions. I think there is legitimate cause for concern when companies (like No Lie MRI) are making claims that could affect people’s lives.

I used quotation marks around mind reading because the current state of these technologies is not anywhere close to being able to know a person’s memories, thoughts, or intentions. I wouldn’t be too worried about having your private life invaded. Not for a long while anyway.

Update (05-Nov-2007):

I’m not sure if what they’re doing in the UK is any different, but this technology is certainly pushing the legal system. See Groundbreaking Experiments Could Lead To New Lie Detector.

FMEA (Failure Mode and Effects Analysis) is a regular part of our development process (we call it “Hazard Analysis”), but I was unfamiliar with FRACAS (Failure Reporting, Analysis, and Corrective Action Systems) until I ran across this: 10/21/2007 FRACAS? – Never heard of it.

I’d also never heard of “software reliability growth”. The model is described here, and there are also some other good links available from the Google search.

I’m a software developer, not a quality systems person. According to Jan, even medical device quality people are not that familiar with these methods. In addition to Jan’s explanation for this, one reason I (or others) might not have heard of these is that my experience has been exclusively in Class II non-invasive diagnostic devices. The development of Class III life support and implantable devices is a whole different animal when in comes to quality control rigor.

CAPA’s (Corrective and Preventive Action) are of course part of the standard FDA Quality System Regulations (§ 820.100). These procedures are primarily implemented to deal with quality problems after the product has been released to the field.

The concept of preventing recurrence of observed errors (FRACAS) during the development process is certainly an interesting one. The difference between CAPA and FRACAS is similar to the argument I made regarding Software Forensics — these techniques should be used to ensure quality before the product is released.

“The Gray Sheet” has an article called CDRH Software Forensics Lab: Applying Rocket Science To Device Analysis. Can it really be true that CDRH is doing static code analysis for detecting software defects in recall investigations?

Static code analysis has been around for a long time. I remember using Lint back in the old days. Nowadays all commonly used computer languages (like C and C++) have fairly advanced analysis tools. For Microsoft .NET languages there are tools like FxCop and ReShaper. These tools are great for spotting trouble areas and maintaining code conventions during the development process.

I just have a hard time imagining a process using these tools that would successfully detect real defects in complex medical device software. Especially software that’s controlling hardware devices, doing communications tasks, and recording sensor data. Also, what about all of the assembly language code for embedded processors and DSPs?

Anyway, from the article:

A recent review in the forensics lab found 180 “questionable constructs” in 100,000 lines of code, but only two turned out to be real design issues, Taylor said.

He also pointed to two other cases where static analysis of the software did not find any bugs, thus clearing software as a root cause candidate in the recall investigations.

These statements beg the following questions:

1. Were the two “real design issues” related at all to the device failures?
2. Just because no static analysis “bugs” were found, why does that exonerate the software from being the cause of the failure?

I’m not impressed that static analysis has “been embraced by the aeronautical and automotive sectors”. IMHO this approach just seems like it would create a lot of work for very little return. The manufacturer that produced the device should be responsible for tracking down and fixing the software (and/or hardware) defects.

I’ll stop now.

UPDATE (25-Oct-07):

Check out Tim’s post on this subject: FDA Raises Bar on Medical Device Software Testing.

Tim Gee’s EMR Connectivity for Medical Devices Is a Mess post is right on target. I’ve also expressed my opinion (”total chaos”) on this, but as you’ll see I’m coming from a different perspective.

The HealthLeaders Technology article primarily focuses on the challenges of interfacing medical devices in the hospital environment. I think the situation in a physician’s private practice or small group office is even worse.

The needs for medical device connectivity in both environments are essentially the same:

• Reduction in medical errors.
• Decrease in paperwork.
• Increased staff productivity.
• Timely delivery of clinical results.

Hospitals have the advantage of working with big EMR vendors who in turn can provide connectivity solutions for a larger variety of medical devices. Also, large hospital chains have enough clout to be able to mandate performance criteria from their vendors that include interoperability.

The typical physician’s office uses a smaller EMR provider (or even worse, a ‘home brew’ system) where in many cases connectivity with external devices is an afterthought, if it exists at all. Even when you work with mid-sized EMR companies, each has their own proprietary external data interface. Very few of these smaller stand-alone EMR management systems provide standard interfaces (e.g. HL7) for external device data capture.

The interoperability problem is not a technical one. The issue is the time and resources it takes to implement and validate a given medical device interface. The real hope of a MD PnP-like solution is that the cost of that interface can be significantly reduced.

So, here’s my perspective. As a medical device manufacturer, when we take our device into a private practice physician that has an existing (or planned) EMR system the first requirement is pretty much always the same. It’s simply that the diagnostic results from our device automatically appear in a patient’s record in their EMR system. To make this happen, they have to choose between three possibilities:

1. Pay the medical device manufacturer (us) to interface with their EMR system.
2. Pay their EMR vendor to do the interface.
3. Find a third party vendor or contractor that will provide or build the custom interface.

The problem with #1 is that we don’t have the resources to build each unique interface required to satisfy all of our customers. Plus that, our business is building medical devices, not EMR solutions.

#2 might not work out because unless the EMR company has a lot of customers with our devices they will either charge a large custom engineering fee or may just say they won’t do it at all. The third option is doable, but is also potentially costly.

Notice that all of the choices require additional investment by the physician. I wonder if these types of issues may be one of the contributing factors for the low adoption rate of EMR for office-based physicians.

Not being able to provide cost-effective EMR integration is bad for everyone involved. It’s bad for a medical device manufacturer (like us) because it makes it that much harder to sell systems. It’s bad for the physician’s office because without EMR integration they’ll end up with a less effective paper-based solution. It’s also bad for the EMR companies because they won’t be able to take advantage of the future opportunities that a fully integrated medical office would provide.

The reasons may be different, but my conclusion about EMR connectivity with medical devices is the same as Tim’s: “It’s a mess.”

UPDATE (7/21/08): Ran across this MIT Technology Review post about the MD PnP program:
“Plug and Play” Hospitals (Medical devices that exchange data could make hospitals safer).

I spent quite a few years developing diagnostic Electroencephalography (EEG) systems and software. I always get a kick out of articles with titles like this one: Microsoft Working On Mind-Reading Software. It’s the mind-reading part that gets me because your first impression is that Microsoft is developing technology that will allow it to somehow detect what you’re thinking. This, of course, will not be happening in the near or foreseeable future.

The work that Microsoft Research is doing in this area (see here) is fundamental research on the Human-Computer Interface (HCI). The Using a Low-Cost EEG for Task Classification in HCI Research article uses standard frequency domain EEG features (delta, theta, alpha, etc.) as classifiers in a Bayesian Network for differentiating three mental tasks. What was interesting to me was that they recognized the limitations of using EEG technology alone as a human-computer interface. The understanding and use of other physiological data (e.g. motor activity) along with EEG will have to be explored as a way to improve task detection.

Not only is this type of work important for meeting the needs of the physically disabled, as the Wii and Surface have shown, innovative HCI systems can have a dramatic affect on how we all interact with computers.

‘Thought-reading’ system controls wheelchair and synthesizes speech is another one. The system processes larynx nerve signals for speech synthesis and wheelchair control. The technology looks very cool and has the potential to improve the lives of handicapped individuals. I suppose you could consider motor neuron activity as the output of thought, but ‘thought-reading’ just feels like a misnomer. Maybe it’s just me.

Another ‘mind-reading’ technique is the use of Evoked Potentials (EP). One that got a lot of press is a few years back was Brain Fingerprinting (also see here). I’m sure there’s still on-going research in the P300 area, but nothing has grabbed much attention since.

Also, checkout Computers can read your mind. Amazing!

UPDATE:

I found some companies that appear to be trying to use EEG processing algorithms for HCI. Both are focused on the gaming industry. They provide no details on how their products work, so it’s hard not to be skeptical about their functionality claims.

NeuroSky

Emotiv

Also, Smart BrainGames provides more classical biofeedback development systems. All are mentioned here.

UPDATE-2:

Here’s another interesting technology: Functional near-infrared spectroscopy (fNIRS) is an emerging non-invasive, lightweight imaging tool which can measure blood oxygenation levels in the brain. Check out the article here.

UPDATE-3 (15-Oct-2007):

Here’s the Microsoft patent application: Using electroencephalograph signals for task classification and activity recognition (via here).

UPDATE-4 (13-Nov-2007):

Check out Brain2Robot Project which uses EEG signal processing (my highlighting):

Highly efficient algorithms analyze these signals using a self-learning technique. The software is capable of detecting changes in brain activity that take place even before a movement is carried out. It can recognize and distinguish between the patterns of signals that correspond to an intention to raise the left or right hand, and extract them from the pulses being fired by millions of other neurons in the brain. These neural signal patterns are then converted into control instructions for the computer.

If they can do this reliably, that’s quite an accomplishment.