Code review
AuraScore 81/100

Medical Device Firmware Peer Review Protocol

Establish a rigorous peer review plan for embedded medical device firmware targeting IEC 62304 verification standards.

Deploy this template when coordinating formal code reviews for safety-critical embedded systems and device drivers. It ensures traceability between source code changes, risk controls, and regulatory test evidence.

Template

Role: Lead Embedded Systems Verification Engineer specializing in IEC 62304 medical device software compliance.

Context

  • Device subsystem: {{device_subsystem_name}}
  • Risk classification: {{safety_classification}}
  • Hardware target: {{target_architecture}}
  • Automated tooling: {{static_analysis_toolset}}
  • Test harness: {{regression_test_suite}}
  • Regulatory milestone: {{regulatory_submission_deadline}}

Task

Construct a comprehensive peer review protocol to inspect low-level device software changes, confirming deterministic memory safety, hardware register management, and traceability against safety requirements.

Method

  1. Correlate code modification tickets with risk management records designated for {{safety_classification}}.
  2. Review static analysis findings from {{static_analysis_toolset}} to filter false positives and surface MISRA/AUTOSAR violations.
  3. Assess hardware abstraction and interrupt service routines for {{target_architecture}} timing constraints and race conditions.
  4. Verify that dynamic memory allocation is avoided or strictly bounded to prevent heap exhaustion during device runtime.
  5. Audit watchdog timer refreshes, hardware fault handlers, and fail-safe recovery state transitions.
  6. Align code paths with corresponding automated test cases in {{regression_test_suite}}.
  7. Document objective evidence of review completion suitable for inclusion before {{regulatory_submission_deadline}}.

Constraints

  • MUST mandate independent two-person review for all safety-critical interrupt routines.
  • MUST NOT permit unresolved static analysis defects of high or medium severity to merge.
  • Firmware inspection must explicitly address {{target_architecture}} memory models.
  • Limit scope to verification and review protocol actions without including full source code dumps.

Output format

Provide a structured review plan containing:

  • Scope & Hazard Boundary (bulleted summary of subsystem components)
  • Stepwise Review Action Items (6 clear review tasks with checklist items)
  • Defect Classification Criteria (table with Severity, Definition, Required Remediation, and SLA)
  • Sign-off Verification Artifacts (numbered list of required compliance records)

Self-review

  • Confirm alignment with the safety rigor implied by {{safety_classification}}.
  • Check that specific checks for {{static_analysis_toolset}} and {{target_architecture}} are included.
  • Ensure all four required output sections are present and fully fleshed out.
AuraScore breakdown
81/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering10/12 · Adequate

Hard boundaries — what the model must and must not do.

Output specification6/14 · Thin

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency7/10 · Adequate

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness3/5 · Adequate

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

developers
developers-code-review
healthcare-life-sciences
iec-62304
embedded
firmware