Medical Device Verification and Validation Traceability Project

This project builds a medical device verification and validation traceability package. The goal is to connect intended use, design inputs, risk controls, test protocols, measurements, deviations, residual risk, and release decision into one reviewable engineering deliverable.

The project is educational and engineering-focused. It is not clinical advice, not regulatory advice, and not a substitute for the applicable quality system, risk management procedure, standards, professional review, or market-specific submission requirements.

Project Objective

Prepare a risk-based V&V traceability package for a connected patient monitoring accessory after a hardware revision, firmware update, and disposable accessory change. The final deliverable should answer:

1. Which intended-use claims and safety functions are in scope?
2. Which requirements, hazards, risk controls, and test methods cover each claim?
3. Which verification tests prove that design outputs meet specified requirements?
4. Which validation activities prove that the device supports realistic users, workflows, and environments?
5. Which deviations remain open, justified, or blocking?
6. Which evidence is strong enough to support release, and which evidence must be repeated?

The output is not only a traceability spreadsheet. It is a release package that lets an engineering review board see what was tested, why it was tested, what passed, what failed, what changed, and what residual risk remains.

Project Boundary

Use this simplified device boundary.

Item	Project value
Device type	connected patient monitoring accessory
Intended engineering function	acquire physiological signals, display status, transmit records, and alert on defined fault states
Users	trained clinical staff and service technicians
Use environment	monitored care area and biomedical engineering service bench
Hardware change	analog front-end input protection changed
Firmware change	alarm state machine and packet timestamping updated
Disposable change	revised lead-wire and sensor accessory supplier
Release decision	engineering release for controlled pilot deployment

The project scope includes design verification, simulated-use validation, service workflow checks, electrical safety evidence, measurement uncertainty, software timing, data integrity, usability-critical tasks, and risk-control verification. Clinical effectiveness, market authorization, purchasing decision, and production-scale validation are outside this simplified project.

Baseline Deliverables

Create these deliverables before the release review:

Deliverable	Required content
V&V traceability matrix	intended-use claim, requirement, hazard, control, test method, result, owner, configuration
risk-control evidence map	hazard, cause, control, verification, validation, residual risk and open action
protocol index	protocol identifier, revision, device configuration, acceptance criteria and raw data location
deviation log	deviation, affected requirement, risk impact, disposition and retest decision
uncertainty and guard-band summary	measurement method, uncertainty contributors and pass/fail decision rule
software and data-integrity evidence	version, build, timestamp, packet loss, latency and fault recovery checks
usability validation summary	representative tasks, critical tasks, observed use errors and mitigations
release decision memo	passed items, conditional items, blockers, residual risk and release recommendation

The deliverables should be controlled documents with configuration identifiers. A passed test with an unknown firmware build, accessory lot, calibration state, or protocol revision is weak evidence.

Step 1: Build the Traceability Matrix

Start with a small but representative set of project claims and controls.

ID	Claim or requirement	Hazard link	Control	Evidence method	Acceptance basis
R1	input signal remains within specified measurement error	wrong physiological trend	calibrated signal test and uncertainty budget	verification	guarded error limit
R2	alarm state changes within required time	delayed response to fault	firmware state-machine test and timestamp log	verification	latency limit
R3	leakage current remains below project limit	electrical exposure	electrical safety bench test	verification	current limit
R4	critical setup task is completed correctly by users	incorrect setup	simulated-use validation and labeling check	validation	critical-task success criterion
R5	disposable accessory change does not reduce signal quality	wrong or noisy measurement	accessory equivalence test	verification	SNR and artifact limits
R6	service technician can confirm configuration before release	wrong version in service	service workflow validation	validation	configuration confirmation without critical error

Each row should identify the exact configuration covered by the evidence. If the firmware, disposable accessory, cable, calibration method, or user workflow differs from the released configuration, the row needs a gap assessment.

Engineering Comment

The matrix is useful only when it connects engineering evidence to risk. A requirement without a hazard link may still be important, but safety-critical claims need visible risk-control evidence. A test without a requirement may be interesting but difficult to use for release.

Step 2: Calculate Traceability Closure

The project starts with the following traceability review.

Traceability state	Count
claim linked to requirement, hazard, risk control and evidence	38
claim linked to requirement and evidence but missing hazard link	7
claim linked to requirement but missing approved evidence	5
claim listed in labeling but not yet in controlled requirements	2

Total claims:

Full closure rate:

Open or incomplete claims:

Open fraction:

Engineering Comment

A closure rate of 73.1\% is not release-ready for a controlled pilot. The five claims missing approved evidence are direct blockers. The two labeling claims outside controlled requirements are also blockers because the released product would make claims that the design file does not control. The seven rows missing hazard links require risk review: some may be low-risk performance claims, but some may hide safety-critical controls.

Step 3: Rank Risk-Control Evidence

Use RPN as a prioritization aid, not as proof of safety. The project has three open risk-control items.

Item	Severity	Occurrence	Detection	Existing RPN	Planned control
delayed alarm state	8	3	4	96	timestamped state-machine test and watchdog fault injection
accessory connector misfit	6	4	3	72	keying inspection, simulated-use setup validation and supplier lot check
noisy input after disposable change	5	5	4	100	accessory equivalence test and SNR guard band

After planned controls, engineering estimates:

Item	Severity	Occurrence	Detection	Revised RPN
delayed alarm state	8	2	2	32
accessory connector misfit	6	2	2	24
noisy input after disposable change	5	2	2	20

For the alarm item:

Relative reduction:

Engineering Comment

The alarm item still has high severity. Lower RPN does not close the risk by itself. The release package must show that the state-machine test used the released firmware, that fault injection covered credible fault states, that timestamps were synchronized, and that any residual delay is acceptable in the risk file.

Step 4: Define Protocols and Acceptance Criteria

Convert traceability rows into protocols with pre-approved acceptance criteria.

Protocol	Covers	Required configuration	Acceptance criterion
VVF-001	signal error and SNR	released analog front end, accessory supplier B, calibrated simulator	guarded error inside limit and SNR above requirement
VVF-002	alarm latency	released firmware build, timestamp logger, fault injection harness	maximum latency below project limit
VVF-003	leakage current	final input protection and cable configuration	measured current inside limit with calibration record
VAL-004	critical setup tasks	representative users, production-intent accessory and instructions	no unmitigated critical task failure
VAL-005	service release workflow	service technician, configuration tool and device label	correct configuration confirmed without critical error

Acceptance criteria must be written before execution. If a criterion is changed after results are known, the release memo should treat the row as a deviation and justify whether retesting is required.

Step 5: Apply an Uncertainty Guard Band

Protocol VVF-001 checks measurement error for an input signal. The project requirement is:

The measured error is:

The uncertainty budget gives:

Contributor	Standard uncertainty
signal simulator calibration	0.20\%
fixture repeatability	0.15\%
environmental drift	0.10\%
analysis script rounding	0.05\%
operator setup repeatability	0.18\%

Combined standard uncertainty:

With coverage factor:

expanded uncertainty is:

Guarded acceptance band:

The absolute measured error is:

Because:

the result fails the guarded decision rule even though it appears to pass the nominal 3.0\% limit.

Engineering Comment

This is exactly why the guard-band rule belongs in the protocol. A nominal pass near the limit can be too close to accept once measurement uncertainty is included. The correct action is not to hide the result. The project should improve the measurement method, improve the design margin, repeat the test with lower uncertainty, or revise the claim if justified.

Step 6: Check Software Timing Evidence

Protocol VVF-002 tests alarm latency from fault injection to displayed alarm state. The project limit is:

Ten recorded trials give maximum latency:

The timestamp logger uncertainty is:

Use a conservative upper-bound check:

Because:

the timing result passes the guarded limit.

Engineering Comment

The pass is valid only for the tested firmware build, fault injection method, logger synchronization, task load, communication path and display configuration. A later firmware optimization, packet retry change, or display update can invalidate the timing evidence even if the requirement text does not change.

Step 7: Interpret Reliability Exposure

The pilot readiness plan runs:

for:

with no safety-critical firmware lockups. Total exposure:

For a simplified exponential model with zero observed failures, a one-sided 90\% lower confidence bound for MTBF can be screened as:

Since:

then:

Engineering Comment

This is a screening calculation, not a universal reliability claim. Zero failures in a short pilot does not prove field reliability across all users, accessories, environments, software states, cleaning cycles, service actions, and network conditions. The release memo should state the exposure covered and define post-release monitoring triggers.

Step 8: Disposition Deviations

The deviation log contains four items.

Deviation	Affected evidence	Risk impact	Proposed disposition
VVF-001 guarded signal error failed by 0.052\%	measurement accuracy	possible trend bias	repeat with improved fixture and review design margin
VAL-004 one user skipped accessory confirmation	setup validation	possible wrong accessory use	revise setup prompt and repeat critical task validation
VVF-002 logger file missing one noncritical metadata field	alarm timing	no timing data loss	document and correct logger template before next run
service workflow used pre-release label artwork	configuration confirmation	possible label mismatch	repeat service confirmation with production-intent label

Only the logger metadata issue may be document-only if the raw timing evidence remains intact and the quality procedure allows the disposition. The signal error, critical task failure and label mismatch affect release evidence and should be repeated or escalated.

Engineering Comment

A deviation is not automatically a failure, but it is also not automatically harmless. The decision should be based on affected requirement, affected configuration, risk control, measurement integrity, and whether the released product will match the tested condition.

Step 9: Make the Release Decision

Prepare the release decision summary.

Area	Status	Release interpretation
traceability closure	not closed	14 incomplete claims remain
signal accuracy	failed guarded rule	blocker until repeated or margin improved
alarm latency	passed guarded rule	acceptable for tested firmware and configuration
leakage current	pending calibrated record	blocker until objective evidence is attached
usability critical task	failed one critical setup task	blocker until mitigation and repeat validation
service workflow	repeated label check required	conditional blocker
reliability exposure	screening evidence only	acceptable for pilot only with monitoring triggers

The release recommendation is:

Do not release the pilot configuration until signal accuracy, leakage current record, critical setup validation, label-based service confirmation and traceability gaps are closed. Alarm timing and preliminary reliability evidence may be retained for the tested configuration if configuration control confirms no relevant change.

Engineering Comment

This is the difference between a test summary and an engineering release package. The package does not ask whether some tests passed. It asks whether every claim and risk control needed for the intended release has objective evidence on the released configuration.

Final Deliverable Checklist

Before closing the project, verify that the package includes:

1. intended-use boundary and release scope;
2. controlled requirement list;
3. risk-control evidence map;
4. approved protocols and acceptance criteria;
5. raw data and calculation records;
6. measurement uncertainty and guard-band decisions;
7. usability validation results for critical tasks;
8. software build, hardware revision, accessory lot and calibration state;
9. deviation log with engineering dispositions;
10. residual-risk statement and release recommendation.

Common Failure Modes

Common V&V traceability failures include:

• testing a prototype configuration but releasing a different configuration;
• linking evidence to requirements but not to risk controls;
• treating a passed verification test as validation of intended use;
• ignoring measurement uncertainty near the acceptance limit;
• closing a deviation without checking affected configuration and residual risk;
• leaving labeling, service, training or accessory changes outside the traceability matrix;
• using reliability exposure beyond the population and conditions actually tested.

Validation and Limitations

This project uses simplified requirements, small example counts and screening calculations. Real medical device engineering requires the applicable risk-management framework, standards, usability process, software lifecycle controls, cybersecurity review, electrical safety evidence, biological evaluation, sterilization evidence, manufacturing process controls, clinical evidence when needed, and independent quality review.

The project remains useful because the traceability logic is transferable: every claim should map to a requirement, every safety-relevant requirement should map to a risk control, every control should map to objective evidence, and every release decision should state the configuration and residual risk it actually covers.