What This Template Is For
Software that qualifies as a medical device (SaMD, Software as a Medical Device) is subject to FDA oversight. This means your product requirements document needs sections that standard SaaS PRDs do not have: intended use statements, risk classification, design controls, and verification and validation (V&V) plans. Getting these wrong does not just delay your launch. It can result in FDA warning letters, product recalls, or patient harm.
This template extends the standard PRD format with the regulatory sections required for medical device software. It covers FDA classification, intended use, risk analysis, design controls per 21 CFR 820, and the verification and validation strategy. Use it when your software provides clinical decision support, diagnostic output, therapeutic dosing, or any function that the FDA considers a medical device. If your device also handles PHI, pair this with the HIPAA Compliance Checklist.
How to Use This Template
- Copy the template into your quality management system (QMS) or documentation tool.
- Start with the Intended Use and Device Classification sections. These determine your entire regulatory pathway.
- Work through the Risk Analysis with your clinical and engineering teams.
- Complete the Design Controls section. This maps directly to FDA design control requirements (21 CFR 820.30).
- Define the Verification and Validation strategy before development begins.
- Review the full document with your regulatory affairs specialist or consultant.
- Maintain this document as a living design input record throughout development.
The Template
Device and Regulatory Overview
| Field | Details |
|---|---|
| Product Name | [Device/software name] |
| Product Version | [Version number] |
| Intended Use | [One-sentence statement of what the device does and for whom] |
| Indications for Use | [Clinical conditions or situations where the device is used] |
| FDA Classification | [Class I / Class II / Class III] |
| Product Code | [FDA product code, e.g., QAS for clinical decision support] |
| Regulatory Pathway | [510(k) / De Novo / PMA / Exempt] |
| Predicate Device | [For 510(k): name and 510(k) number of predicate] |
| SaMD Classification | [IMDRF risk category: I / II / III / IV] |
| QMS Standard | [ISO 13485 / 21 CFR 820 / both] |
| Regulatory Lead | [Name] |
| PM Owner | [Name] |
Intended Use Statement
Write a precise intended use statement. This is the single most important sentence in your regulatory submission. It defines what the device does, who uses it, and the clinical context.
Template. [Product Name] is intended to [function] for use by [user type] in [clinical setting] to [clinical purpose]. It is indicated for [patient population] with [condition/situation].
Contraindications. [Product Name] is not intended for [list contraindicated uses, populations, or conditions].
Limitations.
- ☐ Document known limitations of the software's accuracy or applicability
- ☐ Document populations for which the device has not been validated
- ☐ Document environmental or technical conditions required for safe operation
Risk Analysis
Risk Classification
| Factor | Assessment |
|---|---|
| Significance of information | [Treat/Diagnose / Drive clinical management / Inform clinical management] |
| State of healthcare situation | [Critical / Serious / Non-serious] |
| IMDRF risk category | [I (Low) / II (Medium) / III (High) / IV (Very High)] |
| FDA class | [I / II / III] |
Hazard Analysis (per ISO 14971)
| Hazard ID | Hazard | Harm | Severity | Probability | Risk Level | Mitigation |
|---|---|---|---|---|---|---|
| H-001 | [e.g., Incorrect dosing recommendation] | [Patient harm from wrong dose] | [Catastrophic] | [Remote] | [High] | [Clinical review step before action] |
| H-002 | [e.g., False negative screening result] | [Delayed diagnosis] | [Serious] | [Occasional] | [High] | [Sensitivity threshold + follow-up recommendation] |
| H-003 | [e.g., System unavailable during clinical decision] | [Delayed care] | [Moderate] | [Occasional] | [Medium] | [Graceful degradation + manual fallback protocol] |
| H-004 | [e.g., PHI exposure] | [Privacy breach] | [Moderate] | [Remote] | [Low] | [Encryption, access controls, audit logging] |
Risk Acceptability Checklist
- ☐ All high-risk hazards have documented mitigations
- ☐ Residual risk after mitigation is acceptable per risk management plan
- ☐ Risk-benefit analysis documents that benefits outweigh residual risks
- ☐ Risk analysis is reviewed by clinical advisor and regulatory lead
- ☐ Risk management file is maintained throughout product lifecycle
Design Controls (21 CFR 820.30)
Design Input (Requirements)
User Needs. Document the clinical user needs this device addresses.
| Need ID | User Need | Source | Priority |
|---|---|---|---|
| UN-001 | [e.g., Clinician needs to see glucose trends over 14 days] | [User interviews, n=8] | P0 |
| UN-002 | [e.g., Clinician needs alerts for readings outside range] | [User interviews, clinical guidelines] | P0 |
| UN-003 | [e.g., Patient needs to view their own data on mobile] | [Patient advisory board] | P1 |
Design Requirements. Trace each requirement to a user need and a verification method.
| Req ID | Requirement | Traces to | Verification Method |
|---|---|---|---|
| DR-001 | [System shall display glucose readings in a trend chart with 14-day view] | UN-001 | [Functional test] |
| DR-002 | [System shall generate alert when glucose > 250 mg/dL for > 2 hours] | UN-002 | [Unit test + clinical validation] |
| DR-003 | [System shall be accessible via iOS 15+ and Android 12+ mobile app] | UN-003 | [Compatibility test] |
| DR-004 | [Algorithm shall achieve sensitivity >= 95% for hyperglycemia detection] | H-002 | [Clinical validation study] |
Design Output
- ☐ Software architecture document
- ☐ Detailed software design specification
- ☐ Software bill of materials (SBOM)
- ☐ Interface control documents (for hardware integration, if applicable)
- ☐ Labeling and instructions for use (IFU)
Design Review Checklist
- ☐ Schedule design reviews at each phase gate (concept, design input, design output, V&V, transfer)
- ☐ Design reviews attended by independent reviewer not on the project team
- ☐ Review records document attendees, issues raised, and resolutions
- ☐ All open issues from design reviews resolved before phase gate approval
Software Development
Software Lifecycle
| Phase | Activities | Deliverables |
|---|---|---|
| Planning | Requirements, architecture, risk analysis | SRS, SAD, risk management plan |
| Development | Coding, unit testing, code review | Source code, unit test results, code review records |
| Verification | Integration testing, system testing | Test protocols, test results, traceability matrix |
| Validation | Usability testing, clinical validation | Validation protocol, validation report |
| Release | Final review, labeling, regulatory submission | DHF, release notes, submission package |
Software Documentation Requirements
- ☐ Software Requirements Specification (SRS)
- ☐ Software Architecture Document (SAD)
- ☐ Software Design Specification (SDS)
- ☐ Software Development Plan
- ☐ Software Configuration Management Plan
- ☐ Software Problem Resolution procedures
- ☐ Traceability matrix (user needs > requirements > design > verification > validation)
Cybersecurity (per FDA guidance)
- ☐ Threat model for the device and its network environment
- ☐ Software bill of materials (SBOM) listing all components and versions
- ☐ Vulnerability management plan (monitoring, patching, disclosure)
- ☐ Authentication and access control mechanisms
- ☐ Data integrity and encryption measures
- ☐ Incident response plan for cybersecurity events
Verification and Validation
Verification Plan
| Test Type | Scope | Pass Criteria | Owner |
|---|---|---|---|
| Unit tests | All software modules | 100% requirement coverage, all tests pass | Engineering |
| Integration tests | Module interfaces, data flows | All interfaces verified, data integrity confirmed | Engineering |
| System tests | End-to-end functionality | All design requirements verified | QA |
| Performance tests | Load, stress, reliability | [Define thresholds: response time, uptime, error rate] | Engineering |
| Cybersecurity tests | Penetration testing, vulnerability scan | No critical/high vulnerabilities unresolved | Security |
Validation Plan
| Validation Activity | Participants | Pass Criteria | Timeline |
|---|---|---|---|
| Usability testing | [n] representative users | Task completion > 95%, no critical usability issues | [Date] |
| Clinical validation | [n] patients, [n] clinicians | Sensitivity >= [X]%, Specificity >= [Y]% | [Date] |
| Simulated use testing | Representative users in simulated clinical environment | All use scenarios completed safely | [Date] |
Filled Example: Remote Patient Monitoring Dashboard
Device Overview (Example)
| Field | Details |
|---|---|
| Product Name | GlucoWatch Clinical Dashboard |
| Intended Use | GlucoWatch Clinical Dashboard is intended to display continuous glucose monitoring data for use by healthcare providers in outpatient settings to support glucose management decisions for adult patients with Type 1 or Type 2 diabetes. |
| FDA Classification | Class II |
| Regulatory Pathway | 510(k), predicate: Dexcom Clarity (K173369) |
| SaMD Classification | IMDRF Category II (non-serious, drive clinical management) |
Risk Analysis (Example, Abbreviated)
| Hazard ID | Hazard | Severity | Probability | Risk | Mitigation |
|---|---|---|---|---|---|
| H-001 | Dashboard displays stale data without indicator | Serious | Occasional | High | Staleness indicator (amber > 1hr, red > 4hr); alert to provider |
| H-002 | Alert fatigue from excessive notifications | Moderate | Frequent | High | Configurable alert thresholds; smart grouping; daily digest option |
| H-003 | Incorrect trend calculation from data gaps | Moderate | Occasional | Medium | Gap detection algorithm; exclude incomplete windows; document limitation in IFU |
Tips for Medical Device Software PRDs
- Write the intended use statement first and get regulatory sign-off. Every other decision flows from it. A broadly written intended use triggers higher risk classification and more regulatory burden. Be precise about what the device does and does not do.
- Invest in traceability early. FDA expects a traceable chain from user needs through requirements to design to verification to validation. Building this traceability matrix retroactively is painful. Start it when you write the first requirement. The technical PM guide covers documentation discipline.
- Design controls are not optional. For Class II and III devices, FDA requires documented design controls per 21 CFR 820.30. This means formal design reviews, design input/output records, and a complete design history file (DHF). Treat this as a product management responsibility, not a quality team afterthought.
- Separate the clinical algorithm from the UI. If your device includes a clinical algorithm (scoring, classification, dosing), architect it as a separate, independently testable module. This simplifies verification, makes the clinical validation scope clearer, and lets you update the UI without retriggering algorithm validation.
- Plan for post-market surveillance. FDA requires ongoing monitoring after launch. Build your analytics infrastructure to capture device performance metrics, user-reported issues, and adverse event signals from day one. Use the health outcomes tracking template to structure outcome measurement.
Key Takeaways
- The intended use statement determines your entire regulatory pathway. Write it first and get sign-off
- Build traceability from user needs through requirements to verification from day one
- Separate the clinical algorithm from the UI for cleaner verification and validation
- Budget 12-18 months total for FDA clearance, including submission preparation
- Post-market surveillance is a requirement, not an optional feature. Build analytics infrastructure early
About This Template
Created by: Tim Adair
Last Updated: 3/4/2026
Version: 1.0.0
License: Free for personal and commercial use