Requirements Management for Medical Devices
Requirements management is arguably more important in the medical devices industry than in any other space – it could mean the difference between life and death for vulnerable patients who depend on medical equipment to live. The factors of safety, reliability, security, and quality control are what drive the success of these companies.
Why is Requirements Management Important?
Due to the increasing regulations and industry compliance required for complex medical devices, customers are more regularly looking for solutions based on existing technology which has already been proven to work and comply with all the desired protocol. Nonetheless, new innovations are sometimes required as our medical knowledge grows.
Developers in the medical space must look to optimize the quality of their products by closely synchronizing their hardware and software teams. If these teams can work synergistically, their workflow is more conducive to success and turnaround times can be greatly reduced. Requirements management initiatives and goals can also be met more effectively, which is why development teams are encouraged to work in this manner.
The Problem With Traditional Working Methods
In traditional working methods, there is a single set of requirements for a medical device which need to be met by both the hardware team and the software team separately. However, in these outdated systems, the hardware and software teams work separately, using their own disparate systems, tools, and metrics to create their work and measure their individual success.
When these two teams eventually come back and review their progress at the predesignated date, there is often a cornucopia of compatibility and optimization issues which need to be resolved before progressing further. Although the hardware and software may appear to conform to the requirements separately, they cannot come together and meet the requirements as one.
This then leads to a long process of troubleshooting and fixing issues between the hardware and software team, aiming to solve problems and iron out compatibility. Needless to say, this wastes time which could be better spent bringing the overall device closer to a completion in line with its requirements.
What About The Grey Areas?
Even if medical device developers manage to run disparate hardware and software teams which can independently meet the product requirements with limited compatibility issues, there are some grey areas which need to be taken into consideration.
For example, if the requirements state that the device must be able to activate a certain mode, how should the mode be activated?
Should the hardware team develop a physical button/toggle or should the software team implement the mode switch into the UI? These kinds of requirements need to be specified from the beginning, leaving no room for confusion or uncertainty regarding whose responsibility is whose.
Another grey area arises when developers are to create a line of products which are designed for different users and scenarios. For instance, the team may be developing a line of medical devices which can be used by both a trained nurse and a patient or caregiver with no medical training. Both devices’ core requirements remain the same (i.e. person medical function X) but the design of the product needs to reflect the circumstances of the user.
This way, you can end up with various versions of the same base requirements. For example, a thermometer might have the same base requirements of accurately recording someone’s temperature, but a version designed for at-home use requires much simpler and more intuitive hardware/software designs than a version designed to be used by trained doctors and nurses in hospital settings.
Medical Device Regulations
Standards such as IEC 62304 have been introduced in recent years, specifying the life cycle requirements of medical software and any software which is contained within medical devices. Standards such as IEC 62304 have been harmonized by both the EU and the US, effectively acting as a global benchmark for medical device developers who wish to comply with medical device regulations in these huge markets and beyond.
If developers wish to comply with these regulations, they must ensure that their software process is completely traceable. This places a greater emphasis on the synchronization of the software and hardware development teams, encouraging them to work together toward compliant requirements from the onset. Strong requirements engineering processes reduce turnaround times and allow regulators to follow traceable audit trails through the development process.
The Solution
As a result of all this heavy regulation, companies require a system which can manage both the hardware and software requirements of a medical device, ensuring that both the hardware and software teams work toward the same overarching requirements. Regulators want to ensure that all of a medical product’s requirements are met – whether they are met through hardware or through software features.
After creating the high-level requirements which must be met, sub-requirements should be created and divvied up appropriately between the hardware and software teams. This ensures that there is no room for confusion and everyone is working to serve the top-level requirements. This process could quickly become muddled and confusing if not laid out at the beginning of the project, so it is critical to instill seamlessness between development team branches.
Final Thoughts
When creating medical devices, there are many top-level requirements which need to be met, asides from the obvious ones of the device functioning and performing its basic duties. For example, some questions you may need to ask yourself include:
-Is the medical device compliant with regulations in its area of distribution?
-Is the hardware/software lifecycle extensive enough?
-Is it possible to attain end-to-end traceability?
-Can the product be easily upgraded in the future?
-Are there any bugs in the software?
Of course, these questions and top-level requirements will vary from device to device, although the health and safety of vulnerable patients using such medical devices should always be a top priority. When striving to fulfill all the requirements that are set out for your new medical device, be sure to encourage transparency and synchronization in your hardware and software teams. This way, you can more easily comply with regulations and meet your top-level requirements upon initial completion.
About Modern Requirements
Modern Requirements4DevOps includes all of the necessary capabilities to ensure that your teams build cohesive and traceable requirements. With our Part 11 Compliant Review tool, simple to create Baselines, and always up to date Traceability Matrices, Modern Requirements is fully equipped with all of the tools your team needs.
Built directly into Microsoft’s Azure DevOps and Azure DevOps Server, our solutions are backed by industry leading security and reliability standards.
Time to Read: 10 minutes
Related Articles
Request a Demo!
- Schedule a demo with one of our trained product experts.
- Receive a personalized demo that mimics your team's process
- Engage our experts on topics such as workflow or best practices.
Reduce UAT Efforts
50% Reduction in UAT efforts
Proven Time Saving
80% time saving on creating Trace Analysis
Streamline Approvals
Significant reduction in approval delays
Increase Performance
50% requirements productivity improvement
Reduce Rework
10-fold reduction in development rework
Simplify Compliance
40% reduction in compliance reporting efforts
