Following up on our first blog post on how to become a trusted software supplier to established medical device manufacturers with the help of IEC 62304, we will now shed some light on specific clauses and requirements of that standard.
IEC 62304:2006/Amd 1:2015, 4.3 – Software Safety Classification
The 2015 amendment provides more clarity on the classification of medical device software, so make sure you are using the latest version of the standard.
The software can be class A, B or C, in order of risk. The risk is based on the potential effects of a software failure, without considering any mitigation internal to the software itself. It is still possible to take credit for mitigation external to the software under development, i.e. hardware controls that prevent hazards / harms from happening in case of failure of the software. Of course this is not possible in case of SaMD (Software as a Medical Device).
As mentioned in the first post, you will likely not know the final application of your product as it depends on the customer. You can decide to develop it per whatever class you prefer. The higher the class the slower the process but the higher the reward. If you develop it to Class C it can potentially be used in any type of medical application.
Risk aspects can drive the architecture of your software. As it is permitted to classify each item in your software separately, you want to concentrate and isolate (we will discuss segregation in another post) critical features so only a limited number of software items will have a high risk class, while you can downgrade the others. This way you can focus your attention (and effort) on those more likely to result in a serious effect on the patient or user. Remember that the software system derives its safety class from the highest safety class of its software items, i.e. software items cannot have their safety class higher than that of the software system (otherwise it means you have misclassified something) and there must be at least one item with the same class as the software system (the one(s) that are driving the overall class). For example: if you have established that, based on the possible application of the software, the overall software system safety class is B, then all your items must be class A or B, but they cannot all be class A.
IEC 62304:2006/Amd 1:2015, 5.1 – Software Development Planning – 5.1.1
As per all regulations and best practices of the Medical Device industry, a plan must predate any action.
The Software Development Plan is one of them. It can be part of a system-wide plan, but you have to ensure it contains the minimum requirements of this clause of IEC 62304. Or it can be broken into several smaller plans.
If you have procedures that cover the aspects described below, then just point to them in the plan, but they have to be IEC 62304 compliant. If they are not, either fill the gaps in the Software Development Plan or clearly document the discrepancies. Do not leave unexplained gaps!
Processes
This refers to the life-cycle of the software and how you are going to implement it. Waterfall, V, agile, hybrid, or whatever you use to develop software; but there must be a process you have to follow. This include
Deliverables
Documentation, source code, executables, literature (e.g. manual) and any other object that will be generated during the different phases. At a minimum you have to specify what documentation will be produced and at what stages of the process. The same is required for product deliverable such as Alphas, Betas, release candidates and final product.
Traceability
Explain how you are going to achieve full traceability for the system requirements, software requirements, tests and risk control measures. Remember that you need to be able to trace any of these object to all the related items in any situation or regardless of the entry point. E.g. if you pick a random software requirement, you must be able to find the system requirement(s) it came from, which protocols were used to verify (test) it, their results and (if applicable) the risk(s) it is mitigating. Nevertheless, it does not mean you need explicit bidirectional traceability nor that it has to be “easy” to follow the traces.
Configuration and Change management
Software developers are familiar with the concept of creating a release manifest with the details of the version of the components and tools used. But in this case you will have to state upfront what you are going to control and how. It is not enough to show the configuration of the released product, but you also need to keep track of it during development and more important during verification. Otherwise any regression is founded on no solid bases. At a minimum you will have to control the source code items, the final binary file, the SOUP items and the version and configuration of the tools you use to develop and test the product. Especially the configuration of tools (e.g. flags in a compiler) can be a source of unplanned changes in the product; different settings can results in different binary files, different static code analysis results, test results etc. If you are not on top of them you will never be able to reproduce the process.
This requirement includes how you will control changes and upgrades in configuration. Using a properly configured source code repository may be enough to comply.
Software problem resolution process
We will discuss this process in greater detail in our next blog post, but this requirement is primarily about bug tracing and resolution. This is not much different from what software developers always do, but there are some particular requirements of IEC 62304 that you will have to implement to ensure full compliance.
IEC 62304:2006/Amd 1:2015, 5.1 – Software Development Planning – 5.1.2
A development plan is never a one off. Things change. Milestones, dates, team members, scope, etc.
Remember to keep it up to date and revise it when appropriate.
IEC 62304:2006/Amd 1:2015, 5.1 – Software Development Planning – 5.1.3
If the software is part of a larger system (whether it is a software only system or it contains hardware), the Software Requirements Specification (SRS) will be derived from the system requirements.
Even when the software is the only component, there should be system level requirements to be referenced, as you cannot simply start from low level SRS.
It is also required to indicate how (if applicable) the software will be integrated and verified / validated at a system level. Typically unit tests and some software system tests can be done at a software level, but more comprehensive, system tests can be covered only when testing the whole system.
IEC 62304:2006/Amd 1:2015, 5.1 – Software Development Planning – 5.1.4 – Class C only
Standards: local and international standards such as IEC 62304.
Methods: development methods and strategies, such as Agile, Scrum, Waterfall, Hybrid, continuous integration, a combination of those or any other practice you use in the company.
Tools: (Primarily) Software tools used during the development and testing. E.g. Jira, Bamboo, Stash, Git, Jenkins, etc. Include their purpose and the versions.
