Software in Medical Devices

In my previous post, I explained how I tweaked the waterfall model to obtain something close to agile methods. But still not agile, actually...

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.

Don't worry, I'm not going to talk about money and quantitative easing! I let people with better knowledge in economics (that makes a lot of people!) do that.
When I talk about inflation, I mean the inflation of software medical devices in their number and variety, which creates a collateral inflation in the number of regulations, guidances, standards, and the like.
This post is the first of a series of three. In this first post, I focus on the inflation of standards. The next one will be on the inflation of regulations and the last one on the inflation of medical devices.

Congratulations! You have signed a contract with a medical devices manufacturer. They don't have a very good knowledge of software. They rely on you to develop something brand new on a smartphone. The application they want to develop will bring new functionalities to doctors and let them do their jobs faster. Your customer chose you because you are the specialist of software on every OS’es on smartphones. You ensured him that your company can be in conformity with IEC 62304 standard. To that purpose, you modified and added the necessary procedures and forms to your quality system. You have one year to develop the application, which fits their desires … and the medical devices standards!

The homologation of a medical device is a complex task and can become a nightmare with devices with a high level of risk. It involves many standards and regulations, different from one country to another: FDA in the USA, CE Mark in Europe, CMDCAS in Canada, KFDA in South Korea, and so on …

Fortunately, most of these regulations have common requirements and rely on ISO standards, the most important standards being ISO 13485 and ISO 14971. If you meet the requirements of these standards, you increase your chances of passing the homologations for the devices with low risk. For devices with high risk, these standards are (almost) mandatory.