Why Regulations for Medical Device Software? I have yet to meet a software engineer who is excited about regulations and the constraints they put on software development. How do we help these engineers understand the reasons and needs for regulations? Explaining why the regulations exist and how they can help us create better products alleviates some of the software developers’ rage. Granted, they’re still a little annoyed by it all (at least I was) but they understand why the regulations exist.
The main goal of the FDA’s regulations and the EU’s MDR is the same as our goal as medical device manufacturers. We want to create safe and effective devices that benefit people. And that’s what these regulatory bodies want too.
Medical device manufacturers have a wide range of skill sets, experiences, and goals. Unfortunately, some medical device manufactures let their goals of making money overshadow their goals of creating safe and effective devices; they tried to sell “snake oil.” Which led to governments creating regulatory bodies to ensure safety and efficacy.
When determining whether medical device software is safe and effective, the main metric is working software. That’s the goal: software that works. Which is the same goal in the Agile Manifesto. We can’t give regulators our software and expect them to be able to determine its safety and efficacy on their own. If they were doing all the analysis and testing it would bog down the approval process, increase costs, and not provide much benefit.
Therefore, regulators require us as medical device manufacturers to provide evidence that the medical device software is safe and effective. That evidence is risk-based documentation. If the software is low-risk, meaning that if it fails it is unlikely to hurt anyone, then the evidence we provide to regulatory bodies is basically us saying, “Yep, it works.” As the risk surrounding the software increases, so do the documentation requirements.
The process and documentation requirements were not created in a vacuum. The authors of the regulations used their own software development experience along with quality and process research from software development over the last seventy years to define the risk-based, documentation artifacts. The regulations are not stagnant. They continue to evolve as we develop better processes and tools. (See TIR45 Guidance on the Use of AGILE Practices in the Development of Medical Device Software and FDA’s draft guidance, Content of Premarket Submissions for Device Software Functions). Additionally, there are several white papers describing how to implement Agile software development processes when creating medical devices.
So what are the requirements? Each regulatory body asks for slightly different things. Here are some documentation artifacts that they have in common and can be mapped to specific regulatory requirements.
V-Model Diagram
| Note that some medical device manufactures look at the v-model as a process model. I am not using it as a process model here. I’m using the v-model as a way to show the relationships between documentation artifacts. |
Planning
Some of the documentation artifacts generated from planning are the software development plan, configuration management plan, test plan, user needs, maintenance plan, and risk management plan. These documents feed into all subsequent artifact blocks.
Requirements
The documentation artifacts generated here are the software requirements specification and the initial risk assessment. The risk assessment will be updated and modified throughout the life-cycle of the software product.
Architecture
The software requirements are decomposed down to create software architecture documentation.
Detailed Design
The software architecture is further decomposed to create detailed design specifications for each unit of software.
Code
The requirements, architecture, and detailed design feed into all the code artifacts.
Unit Testing
The documentation artifacts generated for unit testing are the unit test cases (whether automated or by hand) and test reports. Each unit test can be traced to one or more detailed design specifications and the test plan.
Integration Testing
The documentation artifacts generated for integration testing are the integration test cases and test reports. Each integration test can be traced to one or more architecture design specifications and the test plan.
Verification
The documentation artifacts generated for verification are the verification test cases and test reports. Each test can be traced to one or more software requirements specifications and the test plan.
Validation
The documentation artifacts generated for validation are the validation test cases and test reports. Each test can be traced to one or more user needs and the test plan.
| Keep in mind that this documentation relational model does not include documentation requirements for integrating the software with other medical devices. Nor does it represent the documentation requirements for continued post-market surveillance. Also note that some of these artifacts are only required depending on the Level of Concern or Safety Classification of the software. |
A lot of times software developers are already doing these activities and creating these artifacts. The artifacts look different and are called different names. The artifacts could be emails or chats back and forth between developers, or the artifacts could be pictures of white board drawings. The artifacts could be any number of sketches, drawings, or discussions. When creating medical device software those ad-hoc artifacts need to be formalized, reviewed, and documented with traceability and version history.
Do you need help getting your software documentation and related activities into place? Send me an email at curt@luova-solutions.com and I can help or visit Contact Us Now – Luova Solutions (luova-solutions.com)
