Software in Medical Devices

Today, two publications of the AAMI about interoperability and wireless devices.

The first one is the report of the medical device interoperability summit. The summit was organized in october 2012 by the AAMI and the FDA.
The second one is the report of a workshop about wireless devices in healthcare. It was organized by the AAMI just after the interoperability summit.

Until the early 2000's, the mouse used to rule as absolute king over other man machine interfaces.
Since then, touchpads, touchscreens, touchless peripherals like the kinect and other devices have appeared and conquered large territories of mouse kingdom.

The Internet of Things is probably the next step of the networking of our everyday life.
The web 1.0 was the era where websites were only read-only, with very little interaction.
The web 2.0 is the web of today, with social networks and heavy interaction between web users.
We don't know yet what the web 3.0 will be. But the interaction between networked objects and between networked people and networked objects is perhaps one facet of the web of the future.

We all use Wifi in out everyday life. When we don't have it, we growl and yowl. When we have to use a good old RJ45 network cable, we feel like a dog on a leash.

In two previous articles, I talked about the differences of bugs, software failures, and risks.
I left the discussion unfinished about the probability of occurence of a software failure or a defect.
I think that assessing the probability of occurence of a software failure is a hot subject. I've already seen many contradictory comments on this subject. It's also a hot subject for software manufacturers that are not well used to risk assessment.

In my previous post about Bugs, Software Risks and Software Failures, I explained the concepts of bugs, defects or anomalies, and the concept of software failure.
Let's continue now with Risks.

Hello,

I run this blog on a free platform, it is going to be full and I'll be soon unable to use it any more. I spent most of my time to port the blog on a new PAAS this week. I continue with the same blog engine (dotclear), to maintain the architecture and the URLs. It's very important to keep my google rank!
I should be able to release it in september, when all bugs are fixed.

One important thing happened this week: the ASEAN countries released a draft of ASEAN Medical Device Directive (AMDD), see here . This is a bit like the CE medical devices directive, with one set of regulations for many countries.
It gives me the opportunity to introduce the concept: Develop once, Certify anywhere
It means that, with the convergence of regulations, one set of documents is enough to create a technical file submitted in many countries. For example, data submitted to the EU authorities would be also submitted to the ASEAN member countries.
I'll post more details on this concept later on.
Bye.

Post edited August 29th 2012:
Here is the new blog platform!
No big changes for you, only a new layout.
I let it run for one week in beta test to see if everything's ok.
The previous blog is still active, for backup: previous blog platform.

This blog is registered on technorati with code: W4S4GJXCQPTP

Happtique, an appstore for mobile medical devices has drafted an App Certification Program.
This not a program or a process but a list of functional and non functional requirements that mobile health apps should respect to be certified - according to Happtique. It' a bit like the requirements of Apple to be authorized to place an app in the Apple Store. Happtique publishes your app on its store if you are compliant with its certification program.
There is a lot of work behind this document, and a lot of knowledge. However I don't think this is enough to make a certification program. This document focuses on the results, whereas all software development standards focus on the processes. FDA focuses also on the processes when its auditors verify compliance to 21.CFR.
In the scale of precedence of documents, I would put it here:

1. Legal (choose your country): 21.CFR, 92/42 EEC (essential requirements), CMDCAS, ANVISA, KFDA...
2. Medical devices general standards ISO 13485 and ISO 14971
3. Software development standards: IEC 62304, IEC 60601-1, and the like
4. Guidances: GPSV, IEC/TR 80002-1, ISO/TS 14969
5. Generic functional and non functional requirements: Happtique App Certification Program.

It's obvious that Happtique wants to make some noise with its certification program (and it has reached his goal, you're reading this post). But I have to recognize that this document contains a big source of information for software requirements. The content of this certification program is a perfect source of ideas to write a software requirements specification (SRS).

The world of mHealth is moving fast. In the same kind of article, I have found Tech Barbarians at the Medtech Gates, this article is a good summary of antagonist forces at stake. On the one hand, the regulators and their, so called, ante-Flood rules. On the other hand, the software industry with its new world of mHealth. Guess who's going to have the last word? If, like me, you don't have the answer, continue to apply the standards and regulations...
Bye.

I didn't have time to post anything worth it this week.
To give a side view of my last post about software classes, here is a link to DO-178B on wikipedia. It is the reference about software embarked in aircrafts.
If you take time to read this document, you will see that it goes very further than what we have today in IEC 62304. The constraints about design on high classes are very very hard to respect. That's normal, when you think that software is used in flight commands and other stuff in the cockpit.
It has some side effects, mainly to stretch software development projects, and to ban software from some parts of the plane, for cost-driven reasons.
For example, a microcontroler plus software plus electric motors would be perfect to memorize and retreive the position settings of the pilot's seat. But the cost to develop such software is very high, as the pilot's seat is seen as a critical component. Aircraft manufacturers prefer replacing software and microcontroler by good old analogic electronics to do the same task on some models.
In my humble opinion, the constraints of the two highest classes for software in aircrafts would be to high for medical devices. There is always a pratician, or an emergency medical service, able to "catch" the patient if something goes wrong. Whereas there is nobody to "catch" a falling plane if its flight commands fail. The consequences of risks are far higher in aircrafts, with potentially hundreds of victims in an accident.
That is why classes A, B and C, and their design constraints are enough for medical devices.

Next week, I'll talk about exemptions of ISO13485 for standalone software medical devices.
Bye.

Dozens of companies recall their medical devices every month. A recall happens when something wrong happened with the device, like a bad labeling or a bad sterilization. It's the responsibility of the manufacturer to warn ALL their customers and the government agencies that a given lot or batch of products has a defect. The batches shall be destroyed or sent back to the manufacturer for further analysis.
That's what happened to Pfizer with its Rheumatology Calculator, a smartphone app used to compute a score to assess the desease of patients according to complex algorithms. There is a bug in the app and it gives wrong results.