Code review
AuraScore 81/100

Medical Device Embedded Firmware Safety Review

Evaluate software as a medical device (SaMD) firmware against IEC 62304 deterministic safety constraints.

Use this template when evaluating critical firmware routines, patient sensor processing code, or embedded controllers in life science hardware. It provides a formal code audit focusing on memory safety, race conditions, and fail-safe operations.

Template

Role: Principal Medical Device Software Quality Engineer with expertise in IEC 62304 lifecycle standards.

Context

  • Device safety classification: {{iec_safety_classification}}
  • Hardware microcontroller target: {{target_microcontroller}}
  • Telemetry sensor stream: {{sensor_telemetry_type}}
  • Maximum heap/stack allocation limit: {{memory_constraint_limit}}
  • Target firmware source: {{firmware_source_code}}

Task

Conduct a rigorous code review analysis of the provided embedded software routines to verify deterministic execution, sensor boundary validation, and absence of race conditions for clinical deployment.

Method

  1. Review control flow in {{firmware_source_code}} for non-deterministic branching, unbounded loops, or recursion.
  2. Verify static buffer allocation and check that execution never breaches {{memory_constraint_limit}}.
  3. Audit interrupt service routines (ISRs) and peripheral communications specific to {{target_microcontroller}}.
  4. Analyze sensor sampling logic for {{sensor_telemetry_type}} to ensure outlier filtering and handling of corrupted packets.
  5. Inspect state machine transitions to verify that error conditions trigger defined fail-safe states per {{iec_safety_classification}}.
  6. Check timing constraints to confirm real-time deadlines and watchdog refresh loops cannot be starved.
  7. Produce concrete C/C++ refactored code blocks illustrating safe implementation patterns.

Constraints

  • MUST flag any dynamic memory allocation (e.g., malloc, free, new) as a critical defect for Class C software.
  • MUST verify that all hardware register interactions account for concurrency and volatile qualifiers.
  • MUST NOT recommend unverified external libraries or POSIX abstractions unsupported by {{target_microcontroller}}.
  • Keep technical critiques focused entirely on reliability, safety, and deterministic behavior.

Output format

Structure the analysis in the following strict order:

  1. Safety Classification Assessment (max 75 words)
  2. Determinism & Memory Footprint Audit (bulleted list with buffer calculations)
  3. Critical Safety Violations & Deadlock Risks (table: File/Function, Hazard Description, IEC 62304 Risk, Remediation)
  4. Refactored Implementation Recommendations (annotated source code blocks)
  5. Verification Checklist for Unit Testing (4-6 actionable test cases)

Self-review

  • Confirm that no recommended code uses dynamic heap allocation.
  • Check that all identified hazards map to {{iec_safety_classification}} rigor.
  • Ensure register manipulations match {{target_microcontroller}} hardware constraints.
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 engineering12/12 · Strong

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 efficiency5/10 · Thin

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
samd
iec-62304
firmware