Software in Medical Devices, by MD101 Consulting

General standards: ISO 13485 and ISO 14971

Implementing these standards implies the whole organisation of a medical device manufacturer, for example: from purchases to human resources. Many articles were already published on ISO 13485 and ISO 14971. Just have a look on your favourite web search engine and you’ll find treasuries.

But ISO 13485 and ISO 14971 are not talkative about software. The first requires implementing a conception procedure, the second a risk management procedure. This is not surprising as the standards are applicable to any medical device. They can only have generic requirements.

Remark: In ISO 13485, the word “conception” means the entire process of designing a medical device. Its meaning is different from the meaning in the software industry, where it matches one step of the software development process.

Specific standard: IEC 62304

Since software design is so specific, a third standard was written to focus on it: IEC 62304. Note that it is not an ISO standard but an IEC standard. (If you don’t know what it is, don’t bother with it. Assume that ISO is more general than IEC). And what do we find in IEC 62304? The good old software development process, which every software engineer was taught at school. We find also risk management requirements adapted to software.

Risk management makes really the difference between usual software development and software development for medical devices. It’s impossible to skip it or you won’t have any homologation. Why? You have little risk for you health when you use software found in every computer like office tools, games and internet browsers. But a patient or a healthcare professional might have a high risk using a medical device, with dreadful consequences like severe injuries or death of the patient.

And software can be the direct cause of risk, as more and more devices are designed to be “intelligent” or “smart”. Imagine an artificial respiration device, which is controlled by software. What can happen if there is a bug in the software? Another example: Imagine a software computing doses of medicine administered to patients? What can happen if there is a bug in the software? But bugs are not the only cause of risks. Risks may be present in bug free software, especially during human – machine interaction. Imagine a software device, which computes medicine doses based on statistical data. It displays 2 successive message boxes with information to the user. The first displays input parameters summary before launching statistical calculation. The second displays information about the statistical relevance of the result. In 99,9% of cases, the relevance is good. After a month of use, the user takes the habit to click on “ok”, without reading the messages. One day, after 6 months of use, the second message is a warning saying that the results are not relevant. What could be the consequences if the user gives the medicine dose computed by the software to a patient?

The goal of risk management is to prevent such bad situations. Again, risk management really matters and makes all the difference with common software development.

Software development + risks management = software in medical devices

Another point underlying in the IEC 62304 standard (and in fact in every standard): you have to write documentation about your software. It shall contain the results of all the engineering steps of your development process, with traceability between what you do in one step and what you did in the previous step. Looking at the way the standard is written, the best solution is to follow the waterfall development process.

4 Steps to develop software for a medical device

So, if you want to develop software for a medical device, in the most straightforward way to the homologation, you have to:

• Follow the most known software design process: waterfall,
• Write the documentation about you software,
• Adapt the software design to risk management activities,
• Write risk management documentation.

Remark: by most straightforward, I mean that the outputs of software development and risk management processes (mainly the documentation) will be directly used as inputs to the documentation for the homologations.

Step 1: Follow the most known process

There are many methods to develop software. Many of them were used and quickly forgotten, for they were not very usable or useful. Some continue to survive, in spite of the tremendous pace of evolution of computer science. For example, new and agile methods like Extreme Programming and the good old one: waterfall. Even if IEC 62304 doesn’t quote any method, it is written in a way that pushes the reader to think about the waterfall method. By the way, the waterfall method is chaining the phases of a software development project, likes wagons in a train: statement of work, specification, conception, coding, integration, testing and delivery of software. It is also called the V method and is presented in a manner like the graph below.

Remark: coding is at the bottom. I don’t agree. Software developers are not at the bottom. :-)

These phases are simply presented in the sections of the IEC 62304 standard, and for each phase, the standard gives requirements like “unit tests shall be written and documented”. If you start from zero, setting up a waterfall process is not a very complex task; it is firstly defining a project plan with such phases and writing documentation on what you did in each phase. The IEC 62304 stems from the IEEE 12207 standard. It tells how to develop software for any industry. This standard is itself inspired from the American DOD (Department of Defence) standards. And they look pretty alike. For each phase of the project, you have inputs and outputs. In the waterfall model, the outputs of one phase are the inputs of the next phase. Outputs are verified and approved in reviews, before they can be used in the next phase. The first phase has an input of the customer: the statement of work. The last phase has the last output: the software and its documentation. Let’s explain the phases (if you are familiar with software development, you can skip this phase):

Remark1: there are many other things to do during software lifecycle. The tasks described here are those of conception, the core of software lifecycle. They represent roughly 80% of the work necessary to release new software.

Remark 2: This table is only about software and IEC 62304. If the software is integrated in hardware, which is programmable electric medical device (PEMS), additional steps are required before and after software. This is not the purpose of this article and will be discussed in an article about IEC 60601-1.

Let’s see with an example what is the content of these phases: a tiny program to zip files. The statement of work is: “I want very simple software to zip files when they are too big”.

Specification

Input: SOW – “I want very simple software to zip files when they are too big” Output: SRS – The xxx compress method is used The soft has one window only to remain simple The soft allows choosing the file to zip with a list to browse files The soft shows the progression of the zipping operation

General Conception

Input: SRS Activity: Describe the architecture of the software (like general plans of a building), from the technical requirements Output: SAD – The soft is organized in 3 modules: one for the zip algorithm, one for the window and one for file management

Detailed Conception

Input: SRS and SAD Activity: Describe the software in details (like detailed plans of each room of a building) Output: SDD – Example: (this is a dummy example, the conception is commonly explained in UML, a language for engineers) Module 1 contains xxx algorithm, it uses xxx open source library Module 2 contains a main window with, a list, a button to go up one folder, a progress bar Module 3 contains a method to read file to zip and a method to write zipped file.

Coding and Integration

Input: SDD Output: Software code and STP – Software test plan The software test plan contains scenarios to use the software, from simple unitary cases to very complex scenarios. Example: Action: open software, Result: software shows main window Action: choose a file to zip and click on OK, Result: software zips the file, a bar shows the progress of the zipping

Testing (or verification)

Input: Software and STP Activity: Test scenarios and fix bugs Output: Tested software and STR – Software Test Report Example: Action: choose file to zip and click on OK, Result: software zips the file, a bar shows the progress of the zipping → PASSED Action: choose file to zip and click on OK, Result: software zips the file, a bar shows the progress of the zipping → FAILED, bug #1: “No progress bar shown when software is zipped”

Delivery

Input: Software and its documentation Output: Software packaged (if necessary) and versioned and its documentation Example: Here is MyZip V1.0! The user manual, all technical documentation (SRS, SAD …) and software are on CDROM named “MyZip V1.0 Delivery 2011-09-14”! One bug, named bug #1 was found and fixed. No other remaining bug.

This example is fairly simple. I just want to show that it is important to have everything about one software version in a well identified location (here a CDROM with a unique name).

Step 2: Write documentation

All these phases are not useful if their content is not described in documents. The documentation is the memory of the software development project. Without a good documentation up-to-date, your efforts to develop software which meets the statement of work are ineffective.

Many documents templates exist. You can find some on the internet named MIL-STD-98. They were defined by the US army, which wanted to develop software properly. As far as I know, they were the first organization to publish free online templates. They were so widely used that a good bunch of templates found in many organizations still have a lot in common with the US army templates. The content of these templates is a good guide to the redaction of documentation. Most of times, it’s difficult to organize one’s mind to describe software, its contents, its goals. Templates shall help in these tasks. A very important task is the traceability of customer requirements with the rest of the documentation. Traceability ensures that what the user wants is really found in the software.

For example, we can link requirements this way in our simple zip tool. Traceability from SOW to SRS:

SRS to SAD

Remark: Traceability from software requirements to software design is usually a hard task. Here the window module appears in three requirements. It should be necessary to split the window module in sub modules to determine what is done by which sub module. Usually, software architecture is good when traceability is easy.

SAD to SDD

In parallel, tests shall be linked to requirements as well. One again, this can be a one-to-many relationship. One requirement is tested by many tests scenarios.

SRS to STP

The traceability can be seen as a tree with customer requirements in the trunk, technical requirements in the branches and coding in the leaves. Tests are done to ensure that all branches are connected to the trunk and that all leaves are connected to the branches. There shall not have a dead branch or a dead leaf on a branch.

Step 3: Adapt process with risk management

The risk management process is done in parallel to the software development process. The activities of development and risk management are tightly linked. Outputs of risks processes are inputs of development process and vice-versa. Note that risk management is really a different view of things, compared to development concepts. Someone familiar with software development cannot immediately switch to risk management. It’s a different way of thinking.

During specification, the risk analysis is performed to identify potential risks. Their identification come from history of similar products, literature and, of course, the experience of people doing risk analysis. The risks shall be mitigated if they are considered as not acceptable (I won’t explain the “acceptability” of a risk). Or they can be left as they are if they are acceptable. Mitigation can be done in several ways: changes in organization, definition of processes, impacts on conception and warnings in documentation (mainly the user manual). Hence the conception and the documentation can be modified to mitigate a risk.

The graph below shows the insertion of risk management activities in the software development process. The interaction between both types of activities (soft dev and risk) is mandatory for their success.

For our zip tool, as risk was identified: Risk of zipping a file twice. Note: this risk is purely theoretical! This risk is considered as not acceptable in the context of use of the zip tool. So, it shall be mitigated. The easiest way is to check that the file is not already zipped before zipping it.

To do so, a new requirement is added to the SRS: “The tool tests if a file is zipped before zipping it”. This is the mitigation action of the risk. A module is added to the SAD: the zip check module. And a test of the requirement is added to the tests scenarios. This is the verification of the good implementation of the mitigation action.

The traceability is: From risk management to SRS

• Risk Mgt: Risk of zipping a file twice
• SRS: The tool tests if a file is zipped before zipping it

From SRS to SAD and SDD

• SRS: The tool tests if a file is zipped before zipping it
• SAD: zip check module
• SDD: The zip check module does …

Tests of risk mitigation:

• SRS The tool tests if a file is zipped before zipping it
• STP Verify that the tool doesn’t zip a file twice

STP content: Action: choose a file already zipped, Result: software aborts zip process and shows a warning “file already zipped”

At the end of the tests phases, if the test passes then the risk is mitigated. This short example shows that risk management and conception are very tighten. Risk management has impacts on conception. Conception has impacts on risk management as well. For example, if there is a change in software architecture during general conception, then risk analysis shall be double checked to ensure that no risk arose from this change.

Last information if you want to handle properly your risks. The general risk management requirements are in ISO 14971 and specific risk management requirements for software are in IEC 62304. A guideline exists for the application of ISO 14971 to software: IEC/TR 80002-1. This one has a wealth of explanations to manage software related risks.

Step 4: Write the risk management documentation

Risk management is an activity which is thoroughly screened by reviewers and auditors. As I mentioned before, a risk can lead to a dangerous situation and harm to people. So, write your risk management documentation as perfectly as you can.

This documentation contains: a risk management plan, a risk analysis report and a risk traceability matrix. There aren’t many ways to manage risks. Those documents come from the requirements found in ISO 14971. IEC 62304 adds a few things for software specific aspects.

The risk management plan is written at the beginning of your software development project. When you have written the first one for your first project, you have almost written all the plans for all your projects. Hence, there are not many ways to manage risks, if you work on the same type of medical devices, only a few things will change from one project to another.

The risk analysis report is fed with information gleaned during the whole life of the software project. At the beginning it only contains identified risks, at the end it contains mitigation actions, verification of mitigation actions and residual risk assessment.

The risk traceability matrix contains the links between risks, requirements added to mitigate risks and tests proving that requirements are well implemented.

What’s up after?

At the end of the software development process, you have your software and its documentation. These documents are going to be used to fill the technical files submitted to each regulation agency. The easiest way is to copy-paste the contents of your documents into the technical files demanded by the agencies. Another way is to constitute the technical files with references to the software development files. This technique avoids the copy-paste of documents, leading to highly probable inconsistency between file versions. But it requires that your documentation fits with the structure of technical files demanded by agencies.

Here is an example with US FDA 510k and CE mark:

The project documentation is an input (the main input) to produce the technical files demanded by regulation agencies. Remark: Outputs listed are not exhaustive and are given only as examples.

Submitting the technical file

This is not as simple as that. The compilation of technical files required by government agencies is a complex task. Many consulting companies offer services to help beginners to create technical files. This is especially the case if you submit a file to a foreign country. Most of times (I don’t known cases when you can do it by yourself), you need a representative in the foreign country. The representative is able to create the technical file and submit it to the regulation organisation of the country. Of course, this is an expensive task, as not so many companies have the capabilities to do that job. But this is the price to pay, to sell a medical device in a country.