Software in Medical Devices, by MD101 Consulting

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!