Developing Product Requirements For Medical Devices
- 1. Product Requirements for Medical Devices White Paper WHITE PAPER Developing Product Requirements for Medical Devices How to write product requirements to provide good V&V evidence for submission By Rob Church, Voler Systems The development of a medical device, like any product, begins by defining the market. A company believes that they have an idea for a product that will solve a particular problem, for example providing a diagnostic or therapeutic treatment. The FDA requires that you show that the new device is safe and effective for its intended use. The purpose of the product requirements document (PRD) or product spec is to clearly and unambiguously articulate the product's purpose, features, functionality, and behavior. Careful writing of the requirements can aid in a more rapid approval process. When writing the PRD and System requirements, each requirement should be testable and measurable. For example, rather than having a requirement The system will inflate a balloon., a measurable requirement would be: The flow rate from the system will inflate the balloon to 4 psi in four seconds. Another source of product and system level requirements is through the Risk Management process. When performing a System Risk Analysis or a FMEA, the mitigation to potential hazards or failure modes will become a requirement for the system. In turn, the mitigation requirements will be verified to prove their effectiveness at reducing the probability of occurrence. Marketing Requirements Document (MRD) This is an overview of Market Need, usually from the marketing perspective. For a full example of a MRD see MRD template. It covers these things: Market Need - At an overview level why is your product needed? Target User - Who will use your product? Target Purchaser - Who will buy your product? . When writing the PRD and System requirements, each requirement should be testable and measurable. Product Requirements Document (PRD) The PRD should clearly specify all product level requirements including: Functionality Usability User Interface System Interface Environmental Manufacturing Serviceability and Support Alarm and Annunciators Cleaning and Sterilization Performance Physical Reliability Security Quality Regulatory Safety Calibration Packaging Disposable Compatibility Internationalization and Globalization Price and Cost
- 2. Product Requirements for Medical Devices White Paper For full example of a PRD see PRD Template Additionally, for products that are complex a system specification (SysRS) further decomposes and allocates requirements into subsystems such as mechanical, hardware, and software. For software only or software-intensive medical devices, a separate Software Requirement Specification (SRS) may be required to fully specify the devices operation. For an example of a SRS document see SRS Template Verifiable The PRD and system requirements are used for two important processes. First you must prove the product meets the needs of your customer, that is the product stands up to your marketing, clinical and regulatory claims. This is referred to as validation. It is typically done with clinical testing, such as animal tests. Second, your regulatory submission must show that the product was designed correctly. To prove this, it is good practice to assign high-level product requirements to sub-systems through requirement decomposition and allocation, and verify each subsystem design meets their respective requirement. This is referred to as verification. It is done by testing every requirement in the lab. This is why specifying requirements must be done carefully. If you cannot test a requirement, you cannot verify its implementation is correct. If you have too many or conflicting requirements, the verification test will be hard (expensive) to do. Verification and Validation are often referred to as V&V. The diagram below illustrates the workflow. 2 Best Practices for Developing and Writing Requirements All requirements must be testable and can fail when testing in a predictable way to prove implementation is correct. o Make sure each requirement is complete. A requirement can reference other requirements if there are dependencies. o Avoid duplicate requirements o Avoid contradictory requirements o It is preferred to write the requirement statement in positive terms. It is easier to prove a system can do something or has a characteristic than to prove it cant or doesnt. o Use your cross-functional team to review requirements for testability. They will help you identify conflicting requirements within your documentation. Requirements should be quantifiable and repeatable. Try to avoid qualitative requirements that add subjective decision making during implementation and verification.
- 3. Product Requirements for Medical Devices White Paper Summary The PRD serves as a contract between the Marketing and Engineering groups to ensure the company is creating and delivering the right product to their customers. Ensuring that all the requirements are identified can take time to analyze and develop; however, this effort is well spent providing clear design specifications to the engineers on what to develop and to the V&V engineers on what to test. About Voler System Voler Systems provides R&D consulting from concept through smoothly moving new products into production. Since 1979, clients have turned to us for reliable new products involving sensors and measurement electronics. Our highly experienced team delivers high quality products on time and on budget. We have developed wearable devices, IoT devices, medical devices, consumer products, and other specialized sensor-based electronics and prototype circuits. Contact Us 408-245-9844 volersystem.com Summary of resources MRD Template https://docs.google.com/document/d/1x4fq9IK9razm11YvoUhgQrDH5LikVFPrjUBJv9hsVTo/ PRD Template https://docs.google.com/document/d/1kQNt4V9mMkA5z_wlkb3GFViv7WAtGuGz9_uVONanWRA/ SRS Template https://docs.google.com/document/d/1q9UzYxumg63KX_zda1xxZGsn3Sxz5gDhkktyNRtQmEo/