How would you adapt Electrum for a medical device (FDA Class II)?

[yoelf22]

I'm working on a wearable pulse oximeter with BLE connectivity. The core Electrum workflow seems useful, but medical devices have regulatory requirements (FDA 510(k), IEC 62304 for software lifecycle, IEC 60601 for electrical safety) that go well beyond the current gate checklist.

Specific questions:

• Should I run the standard 8 phases first and then layer regulatory on top, or modify the process from Phase 1?
• The gate checklist has 90 items — how many would need to change for a Class II device?
• Does the system description template need a risk management section (ISO 14971) baked in, or is that a separate document?

[yoelf22]

Good question — this comes up often. Here's how I'd approach it:

Run the standard phases first, then layer regulatory

The 8-phase workflow is about product definition, not regulatory compliance. Run it as-is to get clarity on the HW/SW boundary, the architecture, and the hard problems. A pulse oximeter has genuine engineering questions that exist independent of the FDA: What's the SpO2 accuracy target? How do you handle motion artifacts? What's the power budget with continuous BLE streaming?

Get those answers first. Regulatory requirements don't change the physics — they change the documentation and verification burden.

What to modify

Phase 1 (Explore): Add regulatory classification to the exploration. For a Class II pulse oximeter, the predicate device analysis matters early — it tells you which performance standards you're measured against. Add a row to the HW/SW boundary table: Regulatory | — | IEC 62304 software class (likely Class B), risk file | 510(k) submission, clinical data.

Phase 4 (System Description): The current template has 10 sections. For a medical device, I'd add:

• Section 11: Risk Management — hazard analysis per ISO 14971. The system description already names specific components and interfaces, so you can trace hazards to specific subsystems.
• Section 12: Software Classification — IEC 62304 requires you to classify the software lifecycle class (A, B, or C) based on hazard severity. A pulse oximeter that influences clinical decisions is likely Class B or C.
• Section 13: Verification & Validation Strategy — what you'll test and how. This maps directly to the gate checklist FAILs.

Phase 5 (Gate Checklist): The current 90 items cover about 60% of what a medical device needs. The missing categories:

• Biocompatibility (ISO 10993) for skin-contact materials
• EMC testing (IEC 60601-1-2) — the current checklist has basic EMC but not medical-grade
• Alarm management (IEC 60601-1-8) if the device alerts on low SpO2
• Cybersecurity (FDA premarket guidance) — the current checklist has security items but not FDA-specific ones
• Labeling and IFU requirements

I'd estimate you need ~30 additional checklist items for Class II. I've been thinking about publishing a medical device extension template — if there's interest, that could become a contributed template in templates/.

The risk management question

Keep ISO 14971 as a separate document. The system description is an engineering artifact; the risk management file is a regulatory artifact. They reference each other, but they serve different audiences and have different lifecycle requirements. The system description changes when the design changes. The risk file changes when hazards change — which is a subset of design changes.

That said, the gate checklist is the natural bridge. Every FAIL in the gate review should map to a line in the risk file: is this an accepted risk, a mitigated risk, or an open risk? That traceability is exactly what an FDA reviewer looks for.