A good starting place for help when you want to develop a medical device for the US market is Voler Systems' guide, Developing Product Requirements for Medical Devices.

Write your Requirements Documents

You must first define the market need, which is done in the MRD or Market Requirements Document. This is a description of the product from the point of view of the customer. It describes the function of the device in general terms and the medical result that it should provide.

Next is the PRD, or Product Requirements Document. Your PRD describes in detail your product’s purpose, features, functionality, and behavior. The PRD becomes the guideline for building your product, so every requirement must be measurable and testable.

The guide includes a template for your MRD and PRD, as well as templates for your SRS (Software Requirements Specification). Make sure to write clear system requirements for complex products, again including criteria that are both measurable and testable. Each requirement will be turned into a test to be performed in the verification phase.

The test criteria are critical to the FDA’s verification and validation requirements for the approval of medical devices. You must also show that the product was designed correctly. All of your products’ subsystems will have product requirements and you must demonstrate that each subsystem design meets its respective requirements, which is referred to as verification. You must prove the product meets the needs of your customer and that the product stands up to your marketing, clinical and regulatory claims contained in the MRD. This is referred to as validation.

The guide includes a very useful workflow for the verification and validation process, showing the kinds of testing and measures to be expected to satisfy the regulatory requirements.

For the novice to requirements writing, the guide includes some best practices for writing good requirements. Your requirements document directs your engineers what to build and your QA organization what to test, verify and validate.

Developing Your Medical Device Software

One component of medical device development that requires special callout is the software. As Aaron Joseph points out in his article Beginners Guide to Medical Device Software, the FDA controls the software that is part of medical devices even more tightly than the hardware because software problems are not as easily detectable in the development process.

Guidance to software developers from the FDA has been confusing because there are two sources of regulation, existing regulation of medical devices under 21 CFR 820 (Code of Federal Regulations) and the more recent IEC 62304 Medical Device Software standard, an International Electrotechnical Commission standard followed in both the United States and the European Union (EU). Joseph recommends that the medical device developer follow the IEC standard, and then make any adjustments necessary to meet FDA requirements.

For medical devices, verification and validation are very different for software than for hardware. Joseph provides definitions to use that conform to the IEC 62304 standard. The IEC standard calls for three levels of software testing as part of your software development for medical devices: software unit verification, software integration testing, and software system testing.

Overall, Joseph's article and Voler Systems' guide are important to review as you start to build out your new medical device.