Amotus partners with medical device manufacturers and med-tech startups to design the electronics, firmware, and cloud infrastructure of their connected products. Our deliverables are auditable and aligned with IEC 62304, ISO 13485, IEC 60601, and the requirements of the FDA and Health Canada. Bilingual engineering team headquartered in Quebec City.
- 13+ years of IoT & electronics engineering, including medical device projects
- IEC 62304 classes A, B and C
- DHF / DMR documentation delivered
- EN / FR Quebec-based team
Book a FREE 30-min qualification call — response within 48 h →
Who we build connected medical devices for
Established medical device manufacturers (Class II–III)
You’re launching the connected version of a commercialized device, or adding an IoT module to your existing lineup. You need a partner that maintains a Design History File, delivers IEC 62304-compliant Software Requirements Specifications, and supports your 510(k) submission or Health Canada Medical Device Licence. We integrate into your ISO 13485 quality system and work in lockstep with your regulatory team.
Med-tech startups in pre-submission phase
You’re preparing your first FDA or Health Canada filing. We co-build the risk-compliance architecture from the concept phase, with verification and validation activities planned into the development cycle. No regulatory surprises six months before submission — traceability is documented from sprint 1.
Health-tech SaaS vendors and innovative hospitals
You’re integrating patient telemetry (remote patient monitoring), connecting medical equipment (HL7 v2, FHIR R4), or building a multi-site monitoring platform. We build the bridge between the device and your cloud infrastructure, while respecting HIPAA, PHIPA / PIPEDA, and Quebec’s Law 25.
Standards and regulatory frameworks we work to
| Standard | Scope |
|---|---|
| IEC 62304 | Medical device software life cycle (classes A, B, C) |
| ISO 13485 | Quality management system for medical devices |
| ISO 14971 | Application of risk management |
| IEC 60601-1 + collaterals | Electrical safety of medical electrical equipment |
| FDA 21 CFR Part 820 | Quality System Regulation and Design Controls |
| FDA 524B (Omnibus 2023) | Pre-market cybersecurity for connected devices |
| EU MDR 2017/745 | European medical device regulation |
| HL7 FHIR R4 / HL7 v2 | Health data interoperability |
| Health Canada | Medical Device Licence (MDL) — Class I to IV |
Transparency note: Amotus is not the holder of a corporate ISO 13485 certificate. We engineer to the requirements of these standards and integrate directly into your organization’s quality management system. Our deliverables (DHF, V&V records, risk files, SBOM) are structured to be auditable by your internal auditors and your notified bodies. Several of our clients are themselves ISO 13485-certified and have successfully audited our deliverables within their own QMS.
Our services for the medical sector
Medical device electronics design
PCBs engineered to IEC 60601-1 requirements (patient isolation, leakage current, EMC), redundant architecture for safety-critical functions, component selection with long-term availability (10+ years).
Deliverables: schematics, BOM with second-source analysis, gerbers, EMC compliance file, environmental test reports.
Class B and C embedded firmware
Firmware development to IEC 62304 and MISRA C:2012, with bidirectional traceability from requirements → code → tests. Typical MCUs: STM32H7, NXP i.MX RT, Nordic nRF52/nRF53.
Deliverables: SRS, Software Architecture Document, documented source code, V&V plan, test coverage report, unresolved anomalies list.
Medical device cybersecurity (FDA 524B)
Software Bill of Materials (SPDX or CycloneDX), versioned STRIDE threat modeling, secure boot, encryption in transit (TLS 1.3) and at rest, post-market vulnerability management plan, coordinated disclosure process.
Deliverables: machine-readable SBOM, threat model, CVE monitoring plan, patch management strategy.
Health connectivity and cloud
Bluetooth Low Energy 5.3, Wi-Fi 6, LTE-M, Cellular on the device side. Fundamentum IoT platform on the cloud side, with connectors to AWS HealthLake / Azure Health Data Services for specialized health-data services when required. HL7 v2, FHIR R4, DICOM integration. HIPAA, PHIPA, Law 25 compliance.
Deliverables: documented cloud architecture, FHIR models, audit logs, end-to-end encryption plan.
OTA updates for medical devices
Cryptographically signed update mechanism, automatic rollback on failure, auditable logging aligned with FDA post-market expectations. Compatible with Class B and C constraints.
Deliverables: documented OTA protocol, signing infrastructure, staged rollout plan.
Regulatory documentation (DHF, DMR, Technical File)
We deliver a complete, traceable, and auditable Design History File aligned with your ISO 13485 QMS and your target market’s requirements (FDA, Health Canada, EU MDR).
Deliverables: structured DHF, Device Master Record, MDR technical file, traceability matrix.
Our medical methodology, aligned with IEC 62304
- Scoping and IEC 62304 classification (A, B or C) + ISO 14971 risk analysis
- Software Requirements Specification (SRS) + Software Architecture Document (SAD)
- Development with traceability requirements ↔ code ↔ tests
- Verification (unit, integration, system tests) — documented coverage
- Validation (clinical if required, representative environment)
- Production transfer + maintenance plan and post-market surveillance
Each phase produces deliverables compatible with your QMS. Traceability is maintained in our tooling (Polarion, Jama, or your ALM) and exportable to your preferred format.
Project example — connected ocular diagnostic device (Zillia)
Project: transforming a laboratory prototype into a portable, connected medical device, with documentation structured to be FDA-ready from the first sprint.
What we engineered:
- Embedded electronics design (optical sensors, isolated medical-grade power supply)
- Linux Yocto BSP on NXP i.MX 8
- Firmware with secure OTA
- End-to-end encrypted cloud infrastructure with FHIR export to hospital information systems
Tech stack: NXP i.MX 8 · Yocto Linux · Fundamentum IoT platform · FHIR R4 · TLS 1.3
Most of our medical clients operate under confidentiality agreements, so project details on this site are shared at the technical level only. We can discuss relevant, reference-checkable experience under NDA during a qualification call.
Typical tech stack for a medical project at Amotus
| Layer | Technologies commonly deployed |
|---|---|
| Hardware | STM32H7 · NXP i.MX RT and i.MX 8 · sensors from Maxim, Texas Instruments, Analog Devices |
| Embedded OS | FreeRTOS · Zephyr · Linux Yocto · QNX (for safety-critical SIL) |
| Languages | C (with MISRA rules) · C++ · Rust (greenfield projects) |
| Connectivity | BLE 5.3 · Wi-Fi 6 · LTE-M · Cellular (Nordic, Quectel, u-blox) |
| Cloud | Fundamentum IoT PaaS (multi-region) — connects to AWS HealthLake / Azure Health Data Services for specialized health-data services if required |
| Health protocols | HL7 v2 · FHIR R4 · DICOM · MQTT over TLS |
| QA tooling | Polyspace · Coverity · Cantata · pytest · GitLab CI/CD with documented coverage |
Frequently asked questions — medical device development
How do you handle data security?
Security is a first-class design requirement, not an afterthought. We work to SOC 2 Type II–audited practices (Groupe Vectanor), with zero-trust architecture, mTLS between devices and cloud, encryption in transit and at rest, and data residency in the region you require on our multi-region Fundamentum platform (Canada, US, Europe, and more). Your data stays yours, with clear ownership and open export.
What is the difference between IEC 62304 Class A, B and C?
The class is determined by the risk the software can cause to the patient. Class A: no injury or damage to health is possible. Class B: non-serious injury is possible. Class C: death or serious injury is possible. The higher the class, the greater the level of documentation, testing, and traceability required. Classification happens at the scoping phase and drives the entire software life cycle.
How much does Class B medical device firmware development cost?
For a moderately complex device (one MCU, one connectivity path), Class B firmware development typically represents 600 to 1,200 engineer-hours, roughly CAD $90,000 to $200,000 depending on algorithmic complexity and the scope of the V&V plan. V&V usually accounts for 35–50% of total effort — that’s the part that distinguishes a medical project from a standard IoT project. These are industry-typical ranges; your actual quote depends on scope.
Are you ISO 13485 certified?
Amotus is not the holder of a corporate ISO 13485 certificate. We engineer to ISO 13485:2016 requirements and integrate into your organization’s quality system. We deliver auditable documentation that your internal auditors or notified bodies can review. Several of our clients are themselves ISO 13485-certified and have audited our deliverables within their own QMS successfully.
Can you handle the FDA 510(k) submission or Health Canada licence?
We are not a regulatory affairs firm — drafting the submission dossier and interacting directly with the authorities is handled by your team or a regulatory consultant. However, we deliver the full technical documentation the dossier requires: DHF, V&V plan, test reports, ISO 14971 risk analysis, 524B SBOM. We regularly collaborate with Canadian and US regulatory partners and can recommend one.
How do you handle post-market cybersecurity (FDA 524B)?
We put four structural elements in place: (1) a Software Bill of Materials in SPDX or CycloneDX format, (2) a versioned STRIDE threat model reviewed each sprint, (3) a CVE monitoring plan for third-party firmware and cloud components, (4) a signed OTA mechanism with secure rollback. All of it is delivered as part of the DHF and remains usable by your team for the post-market phase.
Do you work with pre-revenue startups?
Yes. We work with med-tech startups from Seed to Series A. We offer capped-effort engagements for scoping and prototype phases, and we can structure milestone-based payment. For strategic projects, equity or deferred-payment arrangements may be considered case by case.
What is the typical duration of a full medical development project?
From 9 to 24 months depending on IEC 62304 class and complexity. A Class B device with simple firmware, BLE, and a mobile app typically represents 11 to 14 months. A Class C multi-sensor device with FHIR integration and a full cloud back-end often exceeds 20 months. Final V&V alone can represent 3 to 5 months.
Are you bilingual for regulatory documentation?
Yes. Our team delivers technical documentation in English (FDA and IEC standard) and can produce the French versions required by Health Canada and Quebec’s Law 25. This in-house bilingual capability avoids the delays and loss of precision that come with outsourcing technical translation.
Why Amotus for your medical device
- Full-stack hardware-to-cloud — electronics, firmware, embedded OS, connectivity and cloud under one roof, so regulatory traceability is maintained across every layer
- Bilingual EN / FR — Quebec-based team, FDA-ready and Health Canada-ready documentation
- We work to your QMS — we slot into your ISO 13485 system rather than imposing ours; deliverables are auditable by your notified bodies
- Technology partnerships — including Variscite (System-on-Module integration), and established relationships with major MCU and cloud vendors
- Fundamentum IoT platform — our sovereign Canadian IoT PaaS can accelerate the cloud/back-end layer of connected medical projects when appropriate
Book a FREE 30-min qualification call — response within 48 h →
