Medical Device Guide & Checklist
The 10 Essentials for Writing a Clear Product Requirements Document
Sifting through medical device safety and performance requirements to create medical device requirements specifications can be an exercise of patience, but with the right preparation and approach it can be more than just another required piece of paperwork. A well-crafted specification document can become a one-stop reference for personnel involved in the design and development process
2. DEFINE REQUIREMENTS IN MEASURABLE TERMS
When writing a medical device essential requirements checklist, it is important to keep in mind that you must be able to demonstrate how the requirement is met. If you cannot quickly come up with an objective way to show that the requirement has been met, it probably needs to be rewritten. Requirements should be written so that they contain a clearly measurable objective. A person unfamiliar with the product or process should be able to come in and verify requirements are met through a review of documentation.
Remember, if it isn’t documented then it didn’t happen!
1. ENSURE EACH REQUIREMENT IS SPECIFIC
Broad requirements are weak and difficult to verify. One way to make sure that your requirements are specific is to eliminate the use of inherently weak words such as user-friendly, reliable, capable, etc. These words are vague and do not tell the user what is being measured (see Tip #2). Your medical device requirements specifications should be able to standalone without supplementary information to explain what “user-friendly” or other broad terms mean.
“The device must be user-friendly” – This is a weak requirement that leaves many questions unanswered. How is “user-friendly” defined? Who are the users? Is this talking about the user-interface, ergonomics, or other features that the user interacts with?
Instead, this requirement should be broken down into a series of small, objective requirements.
3. USE IMPERATIVES SUCH AS “SHALL” OR “MUST” PROPERLY AND CONSISTENTLY
Anyone that works in the Quality or Regulatory side of medical device is well-versed in reading standards and regulatory requirements like ISO 13485 closely for shall and should statements. Your requirements document should not require a close reading to determine intent.
The device must interface with common accessories. – This reads as non-negotiable, it MUST interface
The device should interface with common accessories. – This reads an optional or nice to have feature
4. ENFORCE CONSISTENCY OF TERMINOLOGY AND PROHIBIT INDUSTRY OR COMPANY JARGON
Sticking with consistent terminology makes it easier to search through requirements quickly and minimizes the risk of incorrect interpretation. It may be helpful to include a definitions or glossary section to the requirements document if conflicting terminology is a consistent concern or the requirements document will be used by personnel that may be downstream in the process and use different terminology.
This also includes consistently referring to acronyms or abbreviations. Acronyms are only useful when they are standardized and understood by all document users. Your medical device requirements specification needs to be easily understood by all personnel that may work with it.
5. PROHIBIT PASSIVE VOICE
Requirements are living documents for a product that needs to actively meet the general safety and performance requirements continuously. The requirement statements should be written in a consistent voice that reflects the active nature of the requirement.
The device must be tested at a consistent flow rate of 5L/min for 30 minutes.
This suggests that this flow rate is an upper-limit test and only needs to happen once.
The device must be able to withstand a consistent flow rate of 5L/min for 30 minutes.
This is better, but still sounds like an upper limit that the device won’t necessarily hit.
The device leak rate must not exceed 0.1 ml/min when a consistent flow rate of 5L/min is applied for 30 minutes.
6. AVOID DUPLICATE OR CONTRADICTORY REQUIREMENTS
Requirements for regulatory agencies often overlap completely or significantly. It is important to decide on a strategy for addressing this issue early on when developing requirements. Will you list the requirement under a section for each regulator or will you lump all regulatory requirements into one section to avoid duplication? Further, regulatory requirements and functional or material requirements may overlap as well.
Depending on the structure of your template it may be easier to list the requirement as both a functional and a regulatory requirement or list all applicable regulations as a source of the requirement.
7. KEEP RISK IN MIND
Assessing risk continues to be a focus for regulatory agencies. The latest revision of ISO 13485 expanded risk assessment to the entire quality system and the new MDR 2017/745 regulations also put more emphasis on risk assessment. Working on risk assessment in conjunction with requirements is one way of mitigating risk before it getting further down the development pipeline. Is there a process that is user-dependent and high-risk? Can a requirement be written to mitigate that risk through design?
8. ASSESS THE REQUIREMENTS WITH A CROSS-FUNCTIONAL TEAM BEFORE IMPLEMENTING
The requirements document should be reviewed within your Design Controls process and the review documented accordingly. The design review requirements outlined in ISO 13485 require that personnel involved in the design stage attend the design review. Since the requirement document will be covering overall requirements there should be representatives present from all potentially affected departments. Getting input from a cross-functional team can minimize hiccups down the line when requirements are being reviewed by areas that may not have seen the requirements document before.
9. MAINTAIN AN AUDIT TRAIL OF REQUIREMENTS IMPROVEMENTS FOR YOUR ISO 13485 COMPLIANT QUALITY MANAGEMENT SYSTEM (QMS)
As the project advances through development it is likely that new requirements will be added and existing requirements will be improved upon. A change control system should be in place to capture these changes. An audit trail should be maintained for all changes to requirements to ensure that the methods and reason for the changes are available for regulatory inspection.
Documenting clear reasons for the requirement change can be helpful later in the development process and can potentially reduce iterations in the development process.
10. REVISIT YOUR REQUIREMENTS
Once the device hits the market the requirements work is not done, especially as regulatory bodies put increasing scrutiny on clinical follow-up and risk assessment. Your device requirements are subject to change. As new information about the device is acquired through clinical trials, post-market clinical follow-up, through user experiences, and other pathways, the requirements will need to change.
This may not mean changing your requirements document for the current version of your device, but it may mean creating a new, draft medical device requirements specification that reflects this new information. This may later be used to develop a new version of the device or an alternative device to meet customer needs.
It is possible to make a requirements document that is a helpful, easy to use tool. Following these tips can help ensure you are incorporating risk assessment, meeting design controls requirements, and creating a document that will easily stand-up to a regulatory inspection. The key takeaway from this tip sheet should be that a little bit of planning and consistency in the beginning of the requirements process will save time and effort in the longer term.
10 TIPS FOR DEVELOPING MEDICAL DEVICE REQUIREMENTS SPECIFICATIONS CHECKLIST
- Ensure each requirement is specific
- Define requirements in measurable terms
- Use imperatives such as “shall” or “must” properly and consistently
- Enforce consistency of terminology and prohibit industry or company jargon
- Prohibit passive voice
- Avoid duplicate or contradictory requirements
- Keep risk in mind
- Assess the requirements with a cross-functional team before implementing
- Maintain an audit trail of requirements improvements for your ISO 13485 Compliant Quality Management System (QMS)
- Revisit your requirements