Monthly Archive for October, 2007

Ever heard of FRACAS?

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.

Blogging is hard.

When I started this blog I told myself that I was going stay on topic. I’ve strayed a couple of times but blogging about blogging was always very high on the off-topic list.

Then I read How To Achieve Ultimate Blog Success In One Easy Step by Jeff Atwood. He really hits the nail on the head about the motivation and benefits of blogging. So now I’m forced to break my own rules again. [That’s actually one of the nice things about having your own blog, you get to make up your own rules — or break them — anytime you want.] If you have an interest in starting a blog, read his post and the many links.

From his Fear of Writing post:

It’s like exercise. No matter how out of shape you are, if you exercise a few times a week, you’ll inevitably get fitter. And if you write a small blog entry a few times every week, you’re bound to become a better writer.

One of the reasons I started blogging was because I’ve always wanted to be a better writer. Whenever I read a great article or book I’m always envious of the writer’s talent. It’s like watching an athlete: you know how great they are by how easy they make extraordinary feats look. I will never be a superstar (like Coding Horror), but I have so much room for improvement it’s a good bet that I’ll get better.

Writing is hard. At least it is for me. You might think that you could use some of your programming techniques and skills to facilitate writing. I haven’t found that to be the case at all. The whole flow of writing is completely different than programming. When you develop code you’re typically implementing multiple trains of interconnected logic in parallel. In order to do this you’re jumping back and forth between those pieces of logic.

When you blog, the topic you’re discussing may have distinct points or categories, but writing about it requires a single stream of coherent thought. Not only that, you have to be able to write understandable English sentences. All of this is no easy task for an Engineer. Thank goodness for spell-checkers anyway.

Besides the writing part, technology blogging is also a challenge. For some, just finding unique topics can be difficult. This seems to be especially true for programming blogs, mostly because there are so many of them. Fortunately, within my areas of interest I have many topics to discuss that aren’t already being covered by hundreds of others.

Actually, it would be nice to have some more company, so I’ll ask the same question as Jeff:

So when was the last time you wrote a blog post?

Health 2.0

The Health 2.0 movement (also see here) is a comprehensive approach to many of the EMR/PHR topics I’ve discussed in the past. Scott Shreeve, MD (there are many good posts on his blog) proposes what he calls the “Triple-A of Health 2.0” approach (also see the overviews here and here):

Aggregate, Analyze, and Advise

I like Dr. Shreeve’s Health 2.0 Business Model analysis in that it clearly defines corporate motivations in this marketplace. It’s hard not to like the Aggregate concepts of Prostitution, Voyeurism, and Fetishes.

How is value going to be derived and payed for? Put into this Health 2.0 business model context at least you can begin to ask the right questions.

What Health 2.0 makes clear is the complexity of the issues that need to be resolved and that there’s a long road ahead.

UPDATE (15-Nov-2007) :

A new Health 2.0 site: Health 2.0 Blog

Off Topic: Pandora Radio

One of the main reasons I don’t listen to a lot of music is that I tend to get stuck in a rut. I’ll listen to the same thing over and over again until I’m sick of it. Then I’ll just stop all together. I don’t own a music player, but I do have headphones on my office computer. I’ve tried Internet radio stations, but just like regular radio, I end up in switching-channels mode. Then I’ll just stop all together.

If you’re a music connoisseur you probably already know about Pandora Radio. The whole concept of creating stations based on your selection of an artist or song seems strange at first. Once you understand how the station music is selected, it makes a lot of sense. This is especially true when the resulting play-list matches the attributes of the original so well. As you rate the tracks (thumbs up, thumbs down) the selections get even better. It’s pretty amazing actually.

Pandora is a great way to discover new artists that match your tastes. Give it a try.

Medical Device Software Forensics

“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.

Medical Device Software Development – Going Agile

I’ve been involved in some informal discussions regarding the use of Agile methodologies for medical device software. The Medical Device and Diagnostic Industry (MD&DI) October 2007 article by Tim Bosch entitled Medical Device Software Development—Going Agile provides a good overview of the challenges that face medical device design and development organizations that want to embrace Agile. Here’s Figure 2 from the article:

A typical agile development process

I liked the organization ‘rejection, force fitting, or abandonment’ analysis. Changing organizational behavior is a difficult thing to do. Add in the documentation requirements and you can see why adopting Agile is an uphill battle. This is especially true for an organization that already has a history of doing software development the old fashioned way.

On the regulatory side, Tim references General Principles of Software Validation; Final Guidance for Industry and FDA Staff and claims that:

An agile development approach aligns well with this guidance.

I’m not so sure about that. As I’ve pointed out before, because of the validation requirements those guidelines are much better suited for the Waterfall development approach. That’s why most people do it that way. Agile can be applied, but it comes with increased cost and potential regulatory risk.

I think the advantages of Agile methodologies are real and application of them does have the potential to improve the functionality, cost effectiveness, and quality of medical device software. It’s good to see articles that detail the issues and provide a realistic strategy for achieving those goals.

Little Bobby Tables

I’m a Bob and this one is just too funny. Too bad my mother wouldn’t get it — or my wife, or my kids, anyway:

Little Bobby Tables

Original link: (hat tip Peter).

Scoble interview: The Stanford IT doctor is in.

Here’s an interesting interview with Dr. Christopher Longhurst from The Stanford IT doctor is in.

The discussion of standards and interoperability is very good.

Microsoft HealthVault

Everybody is talking (WSJ-Health Blog, MedGadget, Health IT Guy, and many more) about the introduction of Microsoft HealthVault.

This seems to be a step in the right direction for personally controller health records. The direct device interfaces are particularly interesting.


There’s more discussion about this on the HISTalk blog. People certainly have strong feelings about whether PHR has a future, and even stronger ones about Microsoft. From here:

Last on HealthVault: lots of people hate Microsoft. Blue screen of death. Microsoft Bob. Forced upgrades. Browser security holes. Antitrust issues. Internet tollgate. Assume people buy into PHRs on a big scale. Of all the companies offering PHRs, which one would they trust least with their most personal information? Some Ukrainain hater will have it hacked by this time next week, I suspect.

Even if this was a real concern, I’m not so sure the general public has this level of technical knowledge that would lead them to distrust Microsoft.

In any case, I think a bigger concern about companies like Microsoft and Google getting into PHR is their bottom line motive: advertising. You can be sure that everything they do is driven by a business model — i.e to make money. This makes their shareholders happy, but what will it ultimately mean for PHR?

Microsoft and the Health Care IT Market

Here’s a good read about Microsoft and the health care IT market: Vertical Markets: Prescription for Profit. Redmond Channel Partner Online is a magazine for the Microsoft partner community so the article is geared more towards third party opportunities. It talks a little about Microsoft’s marketing efforts (or lack thereof), but nothing about their technology strategy. The discussion about the Azyxxi purchase in 2006 and how it’s perceived by some as a competitive threat is interesting.

The overall take-away is that the health care industry has a lot of potential for Microsoft. What you don’t get from the article is where the competitive threats are in this market.

Here’s a quote I like:

Doctors can be tough customers too. “They’re notoriously cheap,”….



Twitter Updates