Regulated Software · Yoctobe
SaMD and AIaMD development
Most SaMD programmes fail their first notified-body review because the regulatory strategy was written after the code. Yoctobe builds Software as a Medical Device and AI-enabled diagnostics under ISO 13485 and IEC 62304 from the first sprint — classification, risk management and clinical evaluation designed in, not assembled under deadline pressure.
Medical Software That Passes Audit
Classification errors, thin clinical evaluation evidence and retrospectively-assembled SDLC documentation are the three most common reasons SaMD programmes stall at notified-body review. Each one is preventable when regulatory strategy shapes the architecture from the outset — not when a compliance sprint replaces proper engineering. Yoctobe embeds ISO 13485 design controls and IEC 62304 lifecycle management from sprint one, so when your technical file reaches a notified-body reviewer, the evidence was gathered during development, not constructed after it.
Whether you are a medtech startup preparing a first CE or UKCA submission, or an established manufacturer extending a diagnostic platform with machine learning, we align engineering output with ISO 13485 design controls, IEC 62304 software lifecycle requirements and MDR expectations for technical documentation. AIaMD adds dataset governance, model validation and post-market performance monitoring — handled as part of the same controlled lifecycle, not bolted on after launch.
Audience
Who SaMD Development Is For
Organisations that need regulated software built correctly the first time — with traceable requirements, validated releases and documentation your quality team and notified body can actually follow. Not proof-of-concepts that become compliance emergencies six months before launch.
Medtech startups
First SaMD or AIaMD product — from intended purpose and classification through MVP build, clinical evaluation planning and technical file structure for CE or UKCA.
Established manufacturers
Extending hardware portfolios with companion apps, cloud analytics or AI-assisted triage — integrated into existing QMS and change control without slowing innovation.
Diagnostics & digital health
IVD software, decision support and imaging algorithms where performance claims must be substantiated with clinical evidence and rigorous verification.
Clinical innovators
Hospital spin-outs and research groups translating validated workflows into market-ready SaMD with appropriate risk class and post-market surveillance plans.
Regulatory pathway
Classification To CE/UKCA
We map intended purpose to MDR classification rules, define the regulatory strategy and build the technical documentation your notified body expects. Borderline analysis — wellness app versus medical device, clinical decision support versus information-only — is resolved early so your SaMD development roadmap matches the actual conformity route, not the one that seemed easier at kickoff.
- Intended purpose & classification — rule application, IMDRF SaMD categorisation and borderline analysis
- Risk management — ISO 14971 hazard analysis, benefit–risk assessment and mitigation traceability
- Clinical evaluation — literature review, equivalence arguments and clinical investigation planning
- Technical documentation — design dossier aligned to MDR Annex II/III and UKCA essential requirements
flowchart TB IP["Intended purpose & borderline analysis"] --> CL["MDR / UKCA classification"] CL --> RA["Risk analysis ISO 14971"] RA --> CEP["Clinical evaluation plan"] CEP --> TD["Technical documentation Annex II/III"] TD --> NB["Notified body review"] NB --> MK["CE / UKCA marking"] MK --> PMS["Post-market surveillance & PMCF"]
Software lifecycle
IEC 62304 And AI/ML Governance
Software development under design controls — requirements traceability, SOUP management, verification and validation evidence. For AIaMD, we add dataset governance, model validation and monitoring for drift and performance degradation. Every release carries documented test results, known anomalies and approved change records. No release goes out without the evidence to defend it.
- QMS-ready SDLC — design inputs/outputs, design reviews and change control with full traceability
- SOUP & cybersecurity — third-party software assessment, SBOM and IEC 81001-5-1 alignment
- AI lifecycle — training data provenance, bias assessment, locked models and retraining policy
- Post-market — vigilance, periodic safety update reports and PMCF planning
flowchart LR
subgraph core["IEC 62304 core"]
DI[Design inputs] --> DV[Verification]
DV --> VAL[Validation]
VAL --> CC[Change control]
CC --> REL[Controlled release]
end
subgraph ai["AIaMD overlay"]
DG[Dataset governance]
MT[Model training & lock]
MV[Performance validation]
MO[Drift monitoring]
end
DI -.-> DG
DG --> MT --> MV
REL -.-> MO
How we work
SaMD Development Delivery
Structured phases with clear gates — so regulatory milestones keep pace with engineering sprints and your internal stakeholders stay informed.
flowchart LR P1["Phase 1\nDiscovery & classification"] --> P2["Phase 2\nArchitecture & planning"] P2 --> P3["Phase 3\nControlled build"] P3 --> P4["Phase 4\nSubmission & post-market"] P1 -.-> P1a["Classification memo · preliminary risk analysis"] P2 -.-> P2a["Safety class · SOUP inventory · traceability matrix"] P3 -.-> P3a["2-week sprints · design reviews · V&V evidence"] P4 -.-> P4a["Technical file · notified body liaison · PMCF setup"]
Phase 1 — Discovery
Intended purpose, user profiles and clinical claims captured. Outputs: classification memo, preliminary risk analysis and regulatory strategy for CE, UKCA or FDA pathways.
Phase 2 — Architecture
IEC 62304 safety class, SOUP inventory, cybersecurity threat model and traceability matrix. For AIaMD: dataset acceptance criteria and validation protocols before training begins.
Phase 3 — Controlled build
Two-week sprints with design reviews at phase boundaries. Verification runs continuously; validation protocols drafted alongside feature work so UAT is not a release bottleneck.
Phase 4 — Submission
Technical file assembly, notified body liaison, release packaging and post-market surveillance — PMCF plans, vigilance and software update change control included.
Outcomes
Benefits Of Partnering With Yoctobe
Audit-ready from sprint one
Design controls and documentation are produced alongside code — not reconstructed months later under deadline pressure.
Clear regulatory pathway
Classification, clinical evaluation and technical file structure defined early — reducing costly pivots before notified body engagement.
AI governance built in
Dataset lineage, model validation and drift monitoring integrated into the same IEC 62304 lifecycle as conventional SaMD.
Notified body experience
We prepare submission-ready artefacts and support audit responses — drawing on programmes delivered under ISO 13485 and MDR frameworks.
Maintainable codebase
Clean architecture, automated test suites and knowledge transfer so your team can sustain the product after initial certification.
UK & EU market access
Dual CE and UKCA strategies where needed — with GDPR-aligned data handling and ISO 27001 security practices throughout.
Case study
Sonas Care — AIaMD in practice
Sonas Care applies edge-based video understanding for in-home fall detection, routine monitoring and caregiver alerts — delivered with privacy-by-design architecture and the documentation rigour AI-as-a-medical-device programmes require.
Certifications
Built On Recognised Standards
Our SaMD development processes align with the frameworks regulators and notified bodies expect.
UKCA · IEC 62304 · ISO 27001 · GDPR
Common questions
SaMD Development FAQ
What is the difference between SaMD and AIaMD?
SaMD is software that meets the definition of a medical device on its own — for example, an app that analyses ECG signals to detect arrhythmia. AIaMD is SaMD where the clinical function relies on machine learning or other AI techniques. AIaMD carries additional expectations around training data quality, model validation, explainability where clinically relevant and ongoing performance monitoring after deployment.
How long does SaMD development take to reach CE marking?
Timelines depend on device class, clinical evidence requirements and team readiness. A Class I self-declared product with literature-based clinical evaluation may reach market in months; Class IIa and above with notified body review typically require twelve to twenty-four months from stable requirements. We provide a milestone plan after discovery so you can align funding, clinical studies and go-to-market dates.
Do you act as the legal manufacturer?
Yoctobe typically delivers SaMD development as an engineering and regulatory documentation partner. The legal manufacturer remains your organisation unless a specific commercial arrangement is agreed. We support your QMS integration, technical file ownership and notified body interactions while you retain product liability and market authorisation.
Can you work with our existing QMS?
Yes. We adapt deliverable formats to your document control system, participate in design reviews and supply evidence packs mapped to your procedures. If you are pre-QMS, we help establish the minimum viable quality system for your target device class.
How do you handle software updates after launch?
All post-market changes follow your change control process. We assess regulatory impact — whether an update is a minor correction or requires new clinical evaluation — and deliver regression test evidence. For AIaMD, retraining triggers are defined upfront so performance drift is detected and managed before it affects patient safety.
Bring Your SaMD To Market
Share your product concept — we will outline intended purpose, classification, regulatory pathway and realistic milestones for your SaMD or AIaMD development programme.
Contact Us
