Why requirements - for Medical Devices
•Download as PPTX, PDF•
2 likes•315 views
Medical device companies must develop their products according to quality standards from regulatory bodies like the FDA and MDD in order to obtain necessary certifications. These standards require extensive documentation covering areas like requirements management, risk management, usability, validation, and verification. Maintaining requirements traceability is also required to show how risks, user needs, and test results are linked. Using the right tools can help automate documentation and support an agile development process while still meeting regulatory expectations.
More Related Content
What's hot
What's hot (11)
Viewers also liked
Viewers also liked (9)
Similar to Why requirements - for Medical Devices
Similar to Why requirements - for Medical Devices (20)
Recently uploaded
Recently uploaded (20)
Why requirements - for Medical Devices
- 1. https://matrixreq.com Why do you need to manage requirements for a medical device?
- 2. https://matrixreq.com MDD (Europe) & FDA (US) both require medical device companies to develop according to some quality standards
- 3. https://matrixreq.com Standards: • ISO13485 – Medical Devices Quality Management • IEC60601-1 – Medical Devices Electrical Safety • ISO14971 – Medical Devices Risk Management • IEC62304 – Medical Devices Software • IEC62366 – Medical Devices Usability • …
- 4. https://matrixreq.com What needs to be done? Planning of processes Execution of processesRelevant standards
- 5. https://matrixreq.com How is it verified? 1. Review of the static documentation at certification (CE Mark or 510(k)) 2. Review of the dynamic documentation during audits (scheduled or unannounced)
- 6. https://matrixreq.com Certification These documents build a file: Design History File (FDA) or Technical File (CE) • It contains some plans and • lots of documents which describe the product Planning of processes Execution of processesRelevant standards plans design documentation
- 7. https://matrixreq.com Audits During the audit there is also a strong focus on reviewing the process documentation which should prove that you followed your own processes. Planning of processes Execution of processesRelevant standards plans design documentation process documentation
- 8. https://matrixreq.com Standards do not necessarily tell you • How to do things but • What needs to be done • What evidence needs to be shown
- 9. https://matrixreq.com User Requirements • User Requirements (or Marketing Requirements) make sure you make something which addresses the users needs
- 10. https://matrixreq.com System Requirements • System Requirements make sure your engineering team knows what to build
- 11. https://matrixreq.com Requirements Specifications • Requirements specifications (aka Design Output) make sure you know what has been built
- 12. https://matrixreq.com Risks and Risk Controls Risks and Risk Controls make sure you build a safe device
- 13. https://matrixreq.com Usability Frequently used functions, worst case use scenarios, critical user interface functions make sure the product is easy to use and is not prone to user errors
- 14. https://matrixreq.com Validation Validation is the assurance that the product meets the needs of the customer
- 15. https://matrixreq.com Verification Verification is the assurance that the product does what it was designed to do
- 16. https://matrixreq.com How many? Example of a simple class B device (medium risk) Usability • 30 frequently used functions • 5 critical user interface functions Risks • 127 risks • An average of 2.7 risk control/risk User Requirements • 47 User/Marketing Requirements System Requirements • 384 System Requirements Requirement Specifications • 841 Software & Hardware Requirements Verification • 512 Test cases • Average of 35 test steps / test case Validation • 40 Validation Tests • Average of 15 test steps / test case
- 17. https://matrixreq.com Traceability You are required to maintain a traceability file to show that: • Each risk control is tested • Each user requirement is implemented • etc …
- 18. https://matrixreq.com Traceability Usability User Requirements System Requirements Requirement Specification Verification Validation Risks and Risk Controls
- 19. https://matrixreq.com Looks like a lot of work? If you start early with documentation: • you will be faster in the end • you will have a better product • you will have a safer product
- 20. https://matrixreq.com Using the right tools will: • Not add much overhead • Make sure everybody in the company is involved and understand why he is doing something • Allow you to see what are the impacts of a proposed change • Allow your team to work agile and still produce the required documentation