![23 must-haves product requirements document_greenlight-guru-qra]()
With the rapidly accelerating pace of innovation in the medical device arena, the procedures and practices of the past are struggling to keep up. As a result, medical device recalls are on the rise, regulatory agencies are implementing increasingly strict controls, and medical device manufacturers are trying to adapt.
There are proven methods to reduce risk and improve quality, but the amount of time and effort required to maintain these systems has become burdensome as the functionality and interoperability of devices continue to grow.
The standard Global Design and Development Model is a proven way to reduce risk and maintain quality. This model is based upon the FDA Quality System Regulation (QSR) and ISO 13485. Due to the complexity of new innovations, traditional approaches to these systems are being pushed to their limits.
For example, maintaining compliance and quality for a simple product with 500 requirements is a much different endeavor than trying to follow the same procedures for a modern smart device with 20,000 requirements.
Fortunately, as medical device technology has advanced, so have the tools that can offset these risks and facilitate product development. eQMS systems keep you on top of your regulatory requirements and quality systems. Requirement management tools allow you to trace, organize, and reuse your requirements in different projects. And now, requirement quality tools like QVscribe are here to supercharge development models by automating tedious checks that can be difficult to maintain, but are too important to ignore.
In this guide, we’ll provide a step-by-step process for defining product requirements at each of the 5 major stages in the Global Design and Development model. There will be a particular focus on how to leverage the design input stage to accelerate development and reduce risk with the use of modern tools.
FREE GUIDE + CHECKLIST: Click here to download the free eBook PDF of this guide and printable checklist.
Stage 1: User Needs
Once an opportunity for a new product has been identified, the first step is to consult with potential users, patients, subject matter experts, and other key stakeholders to get a clear understanding of what user needs the product must meet. These will be used to communicate the user needs to all stakeholders and to establish the high-level acceptance criteria.
1) Determine the Use Case in the form of a narrative. This is typically handled by a subset of your project team. Best practice is to use a team of three that includes marketing and engineering so you have various perspectives and get a comprehensive narration. The goal is to identify all the different ways and environments in which your product could be used in order to get as clear of a view as possible on the problems your product will solve.
2) Translate the use case Narrative into distinct user needs. This is where your requirements start to take shape. user needs are more formalized than the use cases, and each should be unique, structured, and singular in purpose. Every requirement in the next stage will trace back to at least one specific user need. You will uncover additional user needs as you iterate on the requirements, but it’s important to cover as much ground as possible before moving on to the next step. If you can imagine a product that satisfies all your documented user needs, but doesn’t align with the vision for your product, keep going until it does.
In the broader sense, this step is a part of “Requirement Elicitation” or “Requirement Gathering”.
Stage 2: Design Input
In this stage, you will develop a complete consistent set of requirements that ensures the device will be fit for the purpose that was defined in Stage 1. Think of your design input as a series of walls that define the general shape of your device - the final design can take on any form, so long as it fits within the confines of the design input.
1) Translate user needs into design requirements. The centerpiece of this stage is the Product Requirements Document, which is the complete list of all product requirements. The FDA breaks these down into 3 distinct categories, pictured to the right, and we’ve identified 23 different types of must-have requirements to consider across these three categories. Let’s take a look at each one:
Functional Requirements
Physical characteristics and exterior design: Document the minimum and maximum size dimensions, and weight of the instrument. Will an operator need to move a module? Is there a shelf space or floor footprint maximum that needs to be met? Make sure your weight and dimensional requirements reflect that.
Features and functions supporting user needs and intended use: What’s required for the user to interface with the machine? Determine and document any aspect of the system configuration and sub-system configurations, including disposables and cartridges that the user will interact with, to ensure that the device’s intended use is met.
Software Requirements: For complex devices, this can quickly become the largest set of requirements for the product. You need to clearly define how you want the product to behave under each specific circumstance it may encounter. Computers don’t make decisions, they only do exactly as they’re told, so it’s important to clearly document each of these behaviours so you don’t end up with any avoidable surprises in testing or when the product is in market. The requirements rules defined by the International Council of Systems Engineering (INCOSE) are particularly helpful when defining system behaviors, but they have their limits. More on that later.
Product and data security: How will your system retain log files and generate reports? Determine how long that information will be retained and how it can be accessed.
Packaging: What kind of packaging is needed for sending, protecting, maintaining sterility, and presenting the product to the customer? Are there other accessory components that are specifically for maintaining product integrity, form, etc. (a mandrel or stylet to maintain a lumen or keep a component straight, for example), that need to be included with the packaging?
Labeling and product documentation: Where does product information need to be visible and how will it be read when stored on the shelf? Note which languages the labels need to be, and indicate what user documentation will be included with the instrument and how the language will be determined. Will any of your labeling be in electronic format?
Single versus multi-use: Don’t take this for granted. It is important to make sure everyone is on the same page with the number of times each unit, or each specific component, will be used, as this will shape virtually every other design decision. For example, if it is single patient use, is it multi-use within the patient’s procedure? Establishing and clearly communicating this as a numeric value or range as early as possible will reduce the risk of misunderstanding and avoidable rework.
Sterile, non-sterile, cleaning: Will the product be offered sterile? If so, what method of sterilization is required? Or instead, does this product need to be sterilized before use? If it’s multi-use, how and with what cleaning agents must it be cleaned and stored?
Performance Requirements
Reliability: Under what conditions, and for how long, must the device operate consecutively? What is the service life? Consider reliability of sub-components as you flesh out the lower level requirements. Remember that absolutes are, by definition, impossible to test and verify. If 99.9% uptime is required, what are the procedures related to maintaining functionality while undergoing maintenance, upgrades, or replacements?
Temperature and humidity: What are the operating conditions for safe use? Document the acceptable tolerances, keeping in mind the possible environments and use-cases for the product to be of practical use.
Power: How much power will the device draw in different modes? What is the peak power? For portable devices, what are the minimum battery life requirements under different modes and conditions?
Fluid ingress: What will be required to clean the device? Where will the fluids be stored and at what rate will they pass through different parts of the device? Be sure to apply appropriate IP ratings, as described in detail here: https://starfishmedical.com/blog/water-ingress-medical-devices.
Sound: What are the acceptable noise levels that the device can emit? Some of these will be user requirements to ensure a comfortable environment, others may relate to what is acceptable to prevent person-to-person miscommunication in an operating room, or to ensure that it does not interfere with other devices. These values should also reflect what is required in order to operate the device without Personal Protective Equipment. Are there any requirements for the device to be usable in loud environments? If the user has physical limitations or is in a loud environment, are there other ways for them to communicate with the device?
Calibration: How often and under what circumstances does the device need to be calibrated? Who is capable of performing the calibration? Who is responsible for making sure it is calibrated correctly and on schedule? How will this be communicated? Considering these requirements early in the process expands the options the R&D team will have in order to design solutions into the product itself.
Safety, regulatory requirements and standards: What are the potential safety hazards and associated regulations of your device, and how will the design prevent them? What are the FDA regulations you’re required to meet? Decide how your device will comply with ISO, RoHS, IEC and other regulations, and document that in your PRD.
Shipping, handling and storage: Document any shipping, handling and storage conditions that need to be met to protect the integrity of the instrument. If it’s single use, what are the storage and handling requirements to ensure sterility?
Vibration: Remember that all requirements must be testable. Now is the time to decide on specific values for both sinusoidal and random vibrations. Include tolerances for the vibrations the device can create, and the environmental vibrations it must withstand, if applicable. A packaging test house or test lab such as NAMSA, Steris, UL, or TUV can provide guidance.
Environmental: How will you prove that the finished product complies with environmental requirements in the countries where the device will be manufactured and sold? How will you prove that the device adheres to organizational business rules and principles related to environmental impact? How will the device be disposed of responsibly?
Other performance requirements and characteristics: Are there any other product features or processes not covered by the other categories that are unique to your device? What other characteristics must your device possess in order to be successful?
Interface Requirements
Usability and application support: Document all of the user interface requirements with exception handling included, modes of operation, usability requirements, and levels of access.
Product configurations and external interfaces: What else does the instrument need to interface with and what’s required to make that possible? Will there be different versions with different ports and connectors for different accessories? How many versions will be available?
Compatibility with other devices: List the specific devices or standards with which your device will connect. Be sure to include model names and specific version numbers, to ensure the final product does not miss any important functions that previous versions may have included, and that it is compatible with new and soon-to-be released products or peripherals.
Maintenance, service and installation: What is required to service the instrument? Include spacing requirements that allow hands or instruments necessary access to the internal components and note how servicing will be logged. Are special tools required for installation? How many service users will installation require? Also, document how often the instrument should receive maintenance and how long that should take.
Characteristics of a Comprehensive PRD
The 23 must-haves above will help ensure that you haven’t missed important pieces that need to be a part of your design input. They can promote “completeness”, but this is just one characteristic of an effective PRD.
Per FDA 21 CFR 820.30(c): “Each manufacturer shall establish and maintain procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including the needs of the user and patient. The procedures shall include a mechanism for addressing incomplete, ambiguous, or conflicting requirements.”
There are two more steps in Stage 2 that take place after the PRD is complete and approved:
2) Perform Initial Risk Assessment: Review and understand the product risk based on the description in the requirements. This is when hazards and potential harms are documented according to ISO 14971 and any risks that can be mitigated by design are addressed.
3) Identify Regulatory Requirements and Standards: Now, it’s time to identify regulatory requirements and standards that apply to your device in the regions wherein it will be sold. This is fairly straightforward, but it is also time consuming if this device is a first for your company, as opposed to a similar device where you can leverage off of a previous list of standards.
Stage 3: Design Process
If the work was done properly in Stage 2, you’ll already start to see the benefits here. With what the FDA calls a “solid foundation”, your development team will have the luxury of knowing what they’re expected to design from the beginning. This prevents two kinds of re-work: the work that needs to be done again based on an incorrect understanding of what the product is supposed to do, and the additional work that needs to be done because one aspect or feature of the product was designed in isolation of the other requirements.
Every engineer doesn’t need to know every detail of the project, but if the requirements are properly defined, key members of the team will be able to communicate the overall vision and quickly catch when it’s going off course. It’s expected that changes will be required to Stages 1 and 2 as you work through the design process.
Be sure to update your user needs and design input as you go, these should be living documents that always reflect the latest understanding of what the product will be.
Stage 4: Design Output
When the design process is substantially complete, the next stage will create the documentation to build, configure, test, package, and use the product. The design input describes what your product will be like, your design output describes what it is. At this stage, you go back and verify that the design output is properly aligned with the design input (verification). The focus of this article is on the design input, but here’s a shortlist of what to include with the design output:
1) Production Specifications
a. Assembly drawings
b. Component and material specifications
c. Production and process specifications
d. Software machine code
e. Work instructions
f. Quality assurance specifications
g. Online packaging and labeling specifications
h. Sourcing and manufacturing
2) Acceptance Criteria: The output documents must also include the final list of acceptance criteria, which are based on the PRD from Stage 2. The acceptance criteria is used for the verification of the design.
3) Implement Risk Controls for Manufacturing: At this time, the Risk Controls that are needed in manufacturing to mitigate any remaining product risk must be determined and documented according to ISO 14971. These can vary greatly depending on the class of your medical device and the risk levels that are identified.
FREE GUIDE + CHECKLIST: Click here to download the free eBook PDF of this guide and printable checklist.
Stage 5: Medical Device
With the design output in hand, the product is then manufactured and tested according to the quality standards laid out in the Production Specifications. At this stage, the product can be validated to ensure that it meets all of the user needs that were defined in Stage 1. If it does, it’s ready for clinical trials, regulatory approvals, and production.
Conclusion
Medical devices are becoming more complex by the minute, but the Product Requirements Document is still the foundation of your medical device project. Ignore it, or give it just enough attention to prove compliance, and you’re setting your team up for avoidable frustration and rework.
Invest in mastering it, and you will experience greater efficiency at later stages of development, and higher quality products. That’s why the FDA Design Control Guidance recommends that 30% of the total project timeline should be devoted to this critical activity. Your team will have a common understanding of what they’re working on and will be able to build with confidence.
This article was originally published on the QRA Team Blog and can be viewed by clicking here.
Looking for a design control solution to help you bring safer medical devices to market faster with less risk? Click here to take a quick tour of Greenlight Guru's Medical Device QMS software →
