Software in Medical Devices, by MD101 Consulting

To content | To menu | To search

5 recommendations to engineers developing medical device software

A lot of standards and regulations exist about medical devices: how to design, to produce, to sell, to monitor their use … Everything about each step in the life of devices, from the initial idea 10 years before selling anything, to the archiving of records 10 years after the last item has been sold. A lot of specific standards or guidances on how applying medical devices standards exist about software. That’s the consequence of software being very specific (I should say peculiar), compared to other components in medical devices. Conception is the most critical part in the lifecycle of software. Software is never 100% finished, user always want enhancements and modifications.

From my own experience in the field, I gathered 5 basic recommendations you should follow.

1. Manage risks linked to the device

Risk assessment is really important: it is a central activity in medical devices conception. Up to the point that risk management has its own standard: ISO 14971 and risk management specific to software has its own guide: IEC/TR 80002-1, to apply this standard. If you don't do this, you won’t sell it!

2. Choose a development process

And stick to it. The development process is a structure to your software development. Either waterfall or iterative or extreme programming or anything else, you shall adhere to the process. It is an (hidden) expectation of reviewers during certification. As they demand you to write documentation on your project, it has to be organized. The IEC 62304 standard is the central standard for software medical devices. It has requirements, which can be met only with a good development process.

3. Document your project

For each step of your software development project, documents have to be written and/or updated. Documentation can be split in management documents (projects planning, …), technical documents (specification, conception, risk analysis …) and review reports. Each step of our project contains activities for which you shall write documents describing the inputs, outputs and internals of these activities. At the end of each step, a review is scheduled, where the contents of documents is reviewed and accepted (or rejected). I think this is the most difficult thing to do. Why? Because:

  1. Only software engineers can write very technical documents.
  2. Writing documentation is the most bothering task a software engineer can have in its professional life.
  3. One prefers implementing a brand new algorithm than writing a document about something that works (by now, until the next bug).

Eclipse, NetBeans, Emacs are my friends, Word, Excel and Powerpoint aren’t.

4. Design carefully the human machine interface

The users of medical devices may be persons with temporary (or permanent) disabilities if they are patients, or persons under stress at work if they are health care personnel. Human machine interface has to be adapted to these persons, who use your software in very specific conditions. They’re not browsing the web in their sofa. Again, a standard has been defined for Usability Engineering or Human Factors Engineering: IEC 62366. It has impacts on ISO 14791 and IEC 62304.

5. Manage SOUP (aka COTS)

SOUP (Software Of Unknown Provenance) or COTS (Components Off The Shelf) are seen as a source of potential risk by regulatory agencies: risk of obsolescence, of vulnerabilities, of hidden bugs, amongst others. The term SOUP appears in IEC 62304 standard. The term depicts clearly how it is seen by people who wrote the standard. You don’t know what there is in a soup made by someone else! Therefore, you should choose carefully your SOUP. A good rule is to rely on open-source projects widely used. There is a high probability that they are maintained and bug free. Note on Operating Systems. They are considered neither as SOUP (unless you develop it or choose a very exotic linux distribution) nor as medical devices. They are part of the medical device technical environment and shall be addressed in risk analysis.

Five is enough, no? I added a sixth recommendation. It is not equivalent to others. Hence it is more about human relationships than technical considerations.

6. Listen to the quality manager

The quality managers, who know ISO 13485 and ISO 14971, the two main standards about medical devices, have a large view of the device, larger than software itself. Keep him/her informed of the progress of software development project. Invite him/her to reviews (for validation review, this is mandatory) and listen to his/her advices. It is worth doing what they say, even if you don’t see immediately the point! And remember I'm a software engineer, not a quality manager!


1. On Monday, 11 June 2012, 16:22 by stefano

Hi Cyrille, on your blog I read many interesting articles: thanks for your help! I'm currently focusing on SW Risk Management.
1 question about this article: why Operating System (example ucOSII, SafeRTOS, ....) aren't considered SOUP?

Thanks and regards

2. On Monday, 11 June 2012, 23:38 by Mitch

Hi Stephano,

I wrote this a bit too short to keep it simple. The idea is to consider that an OS is not a SOUP because you chose it very carefully. The two OS you quote are high integrity real time OS. For example the manufacturer of SafeRTOS claims that it is certified for use in critical applications.

To give a trivial example, for critical applications, SafeRTOS is a COTS and Windows is a SOUP. You can't rely on windows and have to prove by yourself that it fits your application.

Your question deserves it own article: To make the difference between COTS and SOUP. And to evaluate if an OS is a SOUP. I should write one later on.

Add a comment

Comments can be formatted using a simple wiki syntax.

This post's comments feed