This is a ready-to-use determination record. It documents whether a device software function is Basic or Enhanced under FDA’s premarket software documentation guidance, and the document set that follows. Replace every <<FILL: ...>> placeholder, have Regulatory Affairs sign it, and keep it with the design history file. A filled specimen follows. This content is educational reference, not legal or regulatory advice; confirm the current guidance and your device classification before you rely on it.
Record control
| Field | Entry |
|---|---|
| Record title | Software Documentation Level Evaluation |
| Record number | <<FILL: REC-ID, e.g. REC-RA-SW-014>> |
| Device / software function | <<FILL: name of the device software function>> |
| Product / project | <<FILL: product or program>> |
| Version / revision | <<FILL: version>> |
| Prepared by (Regulatory Affairs) | <<FILL: name, date>> |
| Reviewed by (Risk / V&V) | <<FILL: name, date>> |
1. Purpose and basis
This record determines the premarket software Documentation Level (Basic or Enhanced) for the named device software function, following FDA’s guidance “Content of Premarket Submissions for Device Software Functions” (final, June 2023), which replaced the former minor/moderate/major level-of-concern framework. The determination sets the depth of software documentation, especially testing evidence, that the submission must contain.
2. Software function description
| Field | Entry |
|---|---|
| Intended use | <<FILL: the medical purpose>> |
| Software type | <<FILL: SiMD (in a device) / SaMD (standalone) / combination-product constituent>> |
| Device classification | <<FILL: Class I / II / III and product code, if determined>> |
| Operating environment | <<FILL: platform, OS, connectivity>> |
| Role in patient care | <<FILL: how the output is used and by whom>> |
3. The Documentation Level test
Answer each in order. The determination stops at the first Enhanced trigger that applies. The risk questions are assessed before risk mitigation, that is, on the hazard of the software failing, not the residual risk after safeguards.
| # | Trigger question | Answer | If yes |
|---|---|---|---|
| T1 | Does the software test blood donations for transmissible agents, determine donor/recipient compatibility, or is it Blood Establishment Computer Software? | <<FILL: Y/N>> | Enhanced |
| T2 | Could a failure or latent flaw of the software function present a probable risk of death or serious injury (to patient, user, or others) before risk mitigation? | <<FILL: Y/N>> | Enhanced |
| T3 | Is the software a constituent part of a combination product? | <<FILL: Y/N>> | Enhanced by default (a rationale for Basic may be submitted for FDA to weigh) |
| T4 | Is the device a Class III device? | <<FILL: Y/N>> | Enhanced by default (a rationale for Basic may be submitted for FDA to weigh) |
Determination: <<FILL: Basic / Enhanced>>
Rationale: <<FILL: which trigger drove the outcome, or why none apply; if a combination-product or Class III function is called Basic, state the rationale FDA will weigh and confirm the risk file contains no death/serious-injury hazards>>
Consistency check with the risk analysis: <<FILL: confirm the risk file's worst-case hazards are consistent with the level chosen; a device called Basic must not carry pre-mitigation death/serious-injury hazards>>
4. Resulting document set
Items marked for both levels are expected at Basic and Enhanced; Enhanced adds the rest.
| Deliverable | Basic | Enhanced | Included? |
|---|---|---|---|
| Documentation Level Evaluation (this record) | yes | yes | <<FILL: Y/N>> |
| Software Description | yes | yes | <<FILL>> |
| Risk Management File (per ISO 14971) | yes | yes | <<FILL>> |
| Software Requirements Specification | yes | yes | <<FILL>> |
| System/software architecture diagram | high level | detailed | <<FILL>> |
| Software Design Specification | no | yes | <<FILL>> |
| Software testing / V&V evidence | summary | unit + integration + system detail | <<FILL>> |
| Revision history | yes | yes | <<FILL>> |
| Unresolved anomalies list | yes | yes | <<FILL>> |
5. Acceptance criteria
- The determination follows the trigger order and is assessed pre-mitigation.
- The rationale is documented and consistent with the risk analysis (no Basic device with death/serious-injury hazards in its risk file).
- If a combination-product or Class III function is called Basic, the rationale FDA will weigh is recorded.
- The resulting document set is enumerated and each item’s inclusion is tracked.
6. Approval
| Role | Name | Signature | Date |
|---|---|---|---|
| Regulatory Affairs (owner) | <<FILL>> | ||
| Risk Management | <<FILL>> | ||
| Software / V&V lead | <<FILL>> |
Filled specimen
Illustrative determination for the embedded control software of a connected autoinjector that is the device constituent of a drug-device combination product.
| Field | Entry |
|---|---|
| Device / software function | Autoinjector dose-delivery and occlusion-detection firmware |
| Software type | SiMD, combination-product constituent |
| Device classification | Class II (illustrative), delivery-system product code |
| T1 blood/BECS | N |
| T2 pre-mitigation death/serious injury | Y (an undetected occlusion or overdose delivery could cause serious injury before mitigations) |
| T3 combination-product constituent | Y |
| T4 Class III | N |
| Determination | Enhanced |
| Rationale | T2 alone drives Enhanced; T3 confirms it. The risk file lists serious-injury hazards pre-mitigation (overdose, missed dose in a critical therapy), consistent with Enhanced. Basic was not considered viable. |
| Document set | Full Enhanced set including Software Design Specification and unit + integration test evidence. |
Because the determination is made before mitigation, the excellent occlusion-detection and dose-check mitigations do not pull this device back to Basic; the pre-mitigation hazard governs. That is the point reviewers check first.
Common inspection / review findings this record prevents
- A device called Basic whose own risk file describes serious-injury hazards pre-mitigation (reviewers cross-check the level against the risk analysis).
- A Documentation Level assigned late, after test planning, so the testing depth is short of Enhanced expectations.
- A combination-product or Class III function called Basic with no documented rationale for FDA to weigh.
- No enumerated document set, so the submission is missing the Design Specification or unit-level test evidence.
How to adapt this record
- Set your record number and link it to the design history file.
- Confirm the current title and date of the premarket software documentation guidance before issue.
- Keep the pre-mitigation phrasing in T2; assessing residual risk instead is the most common error.
- Where you call a combination-product or Class III function Basic, attach the supporting rationale as a numbered section.
- Trace the resulting document set into your submission’s table of contents so nothing Enhanced is omitted.