Software in Medical Devices, by MD101 Consulting

Before beginning

If the medical device is in a high class of risk according to government regulations (e.g. class III for FDA, class IIb for CE Mark) then additional work may be required during the software development project. This additional work aims at ensuring that software matches customer’s needs and is bug free. IEC 62304 defines 3 classes, from lowest to highest: Class A, class B and class C. Before signing the contract, you shall have verified with your customer into which class falls your software.
For embedded software in a device, the class of the device and the class of software may be disconnected. You can have software of class A according to IEC 62304 embedded in a medical device of class III, according to government regulations. For standalone software, the class of software is highly correlated to the class of the device, since they are the same thing. However, it’s possible to divide software into components to insulate the critical functions and minimize the burden. You can divide FooBar software into two parts: Foo with critical functions in class C and Bar with maintenance and secondary functions in class A.
Verify thoroughly the class of software according to IEC 62304 and insulate the critical functions in specific components. Do this before signing the contract, you will save time and money.

Specifications

Many promises were made during the negotiations and it is time to wash out any misunderstanding. As usual, customers want to have a little more than what they said before signing the contract. That’s normal, how can one anticipate everything in the way software will work? Your job is to avoid a divergence of the specifications and their costs, compared to what was sold.
There is a point, however, on which you shouldn’t say no: risks mitigation. Your customer updates his risk management file during the conception of his device. He may invite you to risk assessment meetings and you may help him to find the best ways to mitigate some risks by adding new features to the software. If these additional features are not too big (no radical change of architecture, for example), then you should accept them or negotiate them against something else. Your customer will be grateful (if he his a normal person!) and will accept to remove other secondary features, which bother you.
Any action to mitigate a risk, which can be translated in software specifications, shall not be ignored. Your customer has hardly the choice to dismiss risk mitigation actions. So help him in his risk management.

Conception

Whereas your customer is able to read and understand a document of specifications, he may be totally unable to read a software conception document. An architecture design chart is understandable by someone with a minimum of knowledge in software design. But other conception artifacts, like the break-down in components often requires a strong experience in software specific technologies, like frameworks or libraries.
Okay, so you can do what you want! They don’t give a clue of what it inside the document! Alas, no … there are some requirements in the IEC 62304 standard like architecture design, isolating critical components. Your customer may not understand, but the FDA reviewer or the EEC reviewer will.
A good conception and a good set of documents, which explain the conception, are necessary. These conception documents will be the only thing which reviewers will rely on, to analyze your software. If the conception is not well documented and explained, reviewers may make false assumptions and –worst case – eventually reject your software.

Coding

Tunnel effect

The coding phase presents the highest risk of tunnel effect. You don’t see the customer and he doesn’t see any result for a looong time. Worse, you may take bad assumptions or bad design decisions. What I write here is correct for any software development project. The difference with medical devices is the risk management. You may think that there is nothing to do with risk management during the coding phase and you’re theoretically right. Since you’ve fixed everything in the previous phases, there should not have any news about risks during coding.
But in the real world, the risk management is never finished. Even the tiniest decisions you make while developing software may have a major impact on risk management.
It is possible to verify that a risk is correctly mitigated or not, only when software is coded. It is possible to verify that a new risk wasn’t added or not, only when software is coded. It is possible to verify that the chaining of actions is not risk prone or not, only when software is coded.

Anticipate tests

The good phase to verify everything is the tests phase. However, it is better to anticipate. Showing the software to the customer while it is in coding phase is the best way to do it. As for any software development project, you have to show the software in progress to increase the chances that software fits customer’s needs. Does it implement a good workflow, good ergonomics, and so on? Only your customer can answer these questions. This is also the case for risk analysis. Ask your customer questions about risks analysis to let your customer assess and verify what you coded. This is not a big deal but by doing it this way, you cover all the aspects of software in medical devices during the coding phase.

Code analysis and unit tests

If software is in class C, then additional work may be required during the coding phase: unit tests and code analysis. They aim at verifying that the code is well structured and that it is bug free, at the lowest level.
But they are difficult to set-up. There are lots of frameworks for unit tests but the weak link is the developer, who has to implement these tests. There are lots of tools for code analysis as well, but the weak link is the user of these tools, who has to know how to use them and deal with the code rules.
If your customer asks for such work, verify with him that software has high risks attached to him and falls into class C, the high category of software class according to IEC 62304. It is mandatory to do code analysis and unit tests with full coverage only if the class of the device is high and if software is class C. Otherwise, don’t implement this work, you will save time and money.

Tests

The organization of tests is often divided in three sub phases: factory tests, customer tests and end-users tests.

• Factory tests: your customer comes into your offices. You have the active role and test the software on your test platform. He remains passive, looking at what you do and making comments, if any.
• Customer tests: You come into customer’s offices, you install software and he does the tests. He has the active role and you remain passive, looking at what he does and helping him in the tests.
• End-users tests: your customer tests the software with end-users. He may call them clinical tests or whatever, this is his job, not yours. From your point of view, he is using the software you have delivered (see delivery below). You offer support to him to any problem he may encounter during the use of software.

Test everything

The tests phase is the final phase of software development before delivery. Everything done during the previous phase shall be tested. What do I mean by “everything”? Software, of course, but I also mean its user documentation. User documentation is a very important part of the job in medical devices software development. It always contains proofs of risks mitigations.
For example, the user manual is often full of warnings or cautions about the use of software by end-users. The admin manual and the installation procedure shall not be neglected either. You should certainly deliver user manual, admin manual and installation procedures to your customer. He will certainly adapt them afterwards, as he knows better the end-users than you. But you shall write the basics about the use and administration of software, since this is you who designed and coded it.
Testing everything in software is easy to understand: you pass through every bit of your software by firstly testing each functionality from A to Z and then playing more and more complex scenarios. Testing the documentation is actually verifying its content, especially the presence of the elements required in the specifications. Dummy example: the specifications contain “children shall not use the software and a sign shall make it clear on user documentation”. The test may be something like “Verify that a sign is present on the cover of the user manual, indicating that software is not for children”.

Organize tests

All tests and the way they are organized shall be gathered in one or more document: the software tests plan. The software test plan is the keystone of the tests phase. These documents shall describe how tests are organized, who does the tests, on which platforms, what data should be necessary and so on … for each phase.
If the tests phase is not well organized, it will misfire many times. You will miss data, hardware, tests cases and even the right people to test software.

A good test phase is the best way to mitigate one risk: the risk of having bugs when end-users use it. This is one main goal of the IEC 62304 standard: more structured software development = less bugs.

Delivery

Nothing new here compared to other projects. You deliver everything you developed during the project and you transfer the property of what you deliver to your customer.
For your customer, the tests phase is perhaps the most complicated phase of the project. It can be assimilated to a small project in itself. You are directly involved in some of the sub phases but most of time not in tests with end-users. Your delivery happens in the middle of the tests phase, from the point of view of your customer. Once you’ve done all the tests and you’ve delivered software, your customer continues his tests with end-users.

Problem resolution and maintenance

Software is never finished, even after your delivery. There is certainly something like a long warranty period in the contract you signed, to cover the tests phases of your customer. So you shall offer a support service to your customer and you will have to deliver new versions or patches, to fix any bugs found.
A delicate question is to define the gravity of bugs found by your customer. Usually people use three levels of severity: blocking, major and minor. And a response time is set according to severity, for example:

• blocking= patch in 24h,
• major=patch in 7 days, and
• minor=next service pack.
  

You and your customer may be in an awkward situation, when the end-user finds a bug, says it is blocking, and when you eventually receive the bug, you find it is minor.
To avoid this kind of conflict, define what a bug is and when it shall be fixed. All of this shall be written in a maintenance document or support procedure and accepted by you and your customer.
Of course, such conflict will happen eventually. A customer in an awkward situation may be an awkward customer! But this is more a matter of negotiation and less a matter of procedures.

Conclusion

The development of software for medical devices is not very different from the good practices of development of any software. The main difference resides in the constraints of your customer. He has end-users, which can have very specific needs, like patients. He has to adhere to ISO standards about conception and risk management. He has to adhere to government regulations about medical devices. And he has to provide government’s reviewers with clear documentation about how software was designed.
Having a well-structured software development process, adhering to IEC 62304, and knowing his constraints, are the best way for you to have your customer satisfied with your job.