Key takeaways
- Classify early. The IEC 62304 software safety class (A/B/C) drives how much design and verification rigor you owe — decide it before writing code.
- Documentation is the product. DHF, DMR, V&V records and the ISO 14971 risk file are deliverables, not afterthoughts.
- Cybersecurity is now pre-market. FDA 524B expects an SBOM, signed firmware and a governed patch path for fielded devices.
- Post-market control is where devices fail. You need governed OTA and an audit trail to update a fleet safely.
- FR/EN matters. Health Canada and Quebec contexts often need bilingual, auditable documentation.
Start by classifying the device
The single most expensive mistake in medical IoT is writing code before classifying the software. Under IEC 62304, the software safety class reflects the worst-case harm a failure could cause:
| Class | Worst-case harm | What it demands |
|---|---|---|
| A | No injury possible | Lifecycle process + requirements + verification |
| B | Non-serious injury possible | + Software architecture, integration testing |
| C | Death or serious injury possible | + Detailed design, unit-level verification with coverage evidence |
The class — set together with the ISO 14971 risk analysis — determines your budget, timeline and documentation depth. We scope it before any code so cost is predictable.
The regulatory frameworks you must master
- IEC 62304 — medical device software lifecycle (classes A/B/C).
- ISO 13485 — quality management system for medical devices.
- ISO 14971 — application of risk management to medical devices.
- IEC 60601-1 (and collaterals) — electrical safety of medical equipment.
- FDA 21 CFR Part 820 — design controls.
- FDA 524B (2023 Omnibus) — pre-market cybersecurity.
- EU MDR 2017/745 — for the European market.
- HL7 FHIR R4 — health-data interoperability.
- Health Canada — Medical Device Licence (MDL) pathway.
An engineering method that produces audit evidence
A compliant build aligns the V-model to IEC 62304 so the paperwork is a by-product of the work, not a scramble before submission:
- Scoping & IEC 62304 classification + ISO 14971 risk analysis.
- Software Requirements Specification (SRS) + Software Architecture Document (SAD).
- Development with traceability: requirements ↔ code ↔ tests.
- Verification (unit, integration, system) with documented coverage.
- Validation in a representative environment (clinical where required).
- Production transfer + post-market surveillance and maintenance plan.
Cybersecurity is now part of clearance (FDA 524B)
Since the 2023 Omnibus, the FDA expects cybersecurity evidence before market: a software bill of materials (SBOM), signed firmware, secure boot where the hardware allows, and a plan to monitor and patch fielded devices. A 524B plan is only credible if you can actually push a governed, audited update to a deployed fleet — which is an architecture decision you make at the start, not a document you write at the end.
Proof, not adjectives: the Zillia case
Amotus developed the firmware, board support and connected infrastructure for Zillia‘s connected ocular-diagnostic device — a real, named medical client. Detailed case write-ups (challenge, stack, verification approach, results) anchor our healthcare work in fact rather than generic claims. See the case studies and the healthcare practice.
Where Fundamentum fits
Connected medical devices live or die on post-market control: who can push firmware, to which devices, with what audit evidence. Fundamentum gives medical teams device identity, signed and governed OTA, role-based access and an immutable audit trail inside Groupe Vectanor’s SOC 2 Type II perimeter — the kind of traceability FDA 524B post-market expectations assume. It can connect to a hospital’s existing cloud (AWS, Azure) for data exchange when required, while keeping a residency-aware, governed control plane. See how Fundamentum governs OTA →
Frequently asked questions
What is the difference between IEC 62304 class A, B and C?
The class reflects the worst-case harm a software failure could cause. Class A: no injury possible. Class B: non-serious injury possible. Class C: death or serious injury possible. The class drives how much architecture documentation, detailed design and verification rigor you must produce — C is the most demanding.
How much does class B vs class C firmware development cost?
Cost scales with documentation and verification depth, not lines of code. A class C device typically adds detailed software design, unit-level verification with coverage evidence, and tighter risk traceability versus class B — often a meaningful uplift in engineering hours. We scope it during IEC 62304 classification, before any code, so the budget is predictable.
Are you ISO 13485 certified?
We develop within an ISO 13485-aligned quality process and deliver the design history (DHF) and device master record (DMR) artifacts your QMS needs. The certification of the legal manufacturer remains the manufacturer’s, but our deliverables are built to be auditable inside it. Ask us for our current certification status during qualification.
Can you support an FDA 510(k) or Health Canada licence?
Yes — we produce the engineering evidence those submissions rely on: software requirements, architecture, V&V records, risk management file (ISO 14971), and cybersecurity documentation (FDA 524B). We work alongside your regulatory lead rather than replacing them, and structure deliverables for both FDA and Health Canada Medical Device Licence pathways.
How do you handle post-market cybersecurity (FDA 524B)?
We design for it: a software bill of materials (SBOM), signed firmware, secure boot where the hardware allows, and a governed OTA path so you can patch a fielded fleet with audit evidence. Fundamentum provides the device identity, governed OTA and audit trail that make a 524B post-market plan executable rather than aspirational.
Do you work with pre-revenue med-tech startups?
Yes. Many of our medical clients start pre-submission. We help classify the device early (IEC 62304, risk class), build a demonstrable MVP that won’t need re-architecting for compliance later, and stage the regulatory documentation so it grows with the product rather than being bolted on before a 510(k).
Related reading
Talk to an IoT engineer — free
Book a FREE 30-minute consultation with our team. No slides, no obligation — a working session on your connectivity, platform or compliance questions.
