Training IEC 62304 SDLC training now available — structured learning, timed assessment & certificate

Software Development

Medical Device Software
Development

SaMD · SiMD · AI-Enabled Devices · IEC 62304 · IEC 81001-5-1 · EU AI Act

We design, build and verify health software and software medical devices, with design controls, risk management, cybersecurity and documentation built in at every stage. Our secure development lifecycle follows IEC 81001-5-1, and every phase ends at a documented stage gate, so your technical documentation grows with the product.

See Our Lifecycle ↓
What We Build
Software as a Medical Device
Standalone SaMD for diagnosis, monitoring, triage and therapy support
Software in a Medical Device
Embedded and connected software working with IEC 60601 hardware
AI-Enabled Medical Devices
Machine learning built to the IEC 62304 Ed.2 AI Annex and the EU AI Act
Health Software
Health and wellness apps built to IEC 82304-1, ready if they cross into SaMD

Development Built for Regulated Products

Whether you are starting from a concept or already have code, we work at the level your product needs, under your QMS or ours.

Concept to Release

Full Product Development

We take your device from intended use to a released, documented product, ready for your Notified Body or FDA submission.

Your Team, Extended

Development Partner

Our engineers work with your team to build reliable, safe software that meets regulatory requirements, within your own lifecycle and tools.

Lifecycle Set-Up

Process & Tooling

Software development plans, SOPs, traceability and CI/CD set up so that compliance is a by-product of how your team already works.

Existing Software

Remediation

Gap assessment and remediation of legacy software or software of unknown provenance where required, including updates for new standards such as IEC 62304 Edition 2.

Phases, Stage Gates & Design Controls

Our software development lifecycle follows IEC 62304 and ISO/IEC 12207 and maps every phase to the design control requirements of ISO 13485 and the FDA QMSR. For AI-enabled devices, an AI lifecycle track runs alongside the same phases. Agile teams work inside this framework: sprints happen within phases, and the gates are where the evidence comes together.

Figure: St John Lynch & Co software development lifecycle. Post-market changes re-enter the lifecycle at the phase their impact assessment requires.

What Must Be True Before a Phase Closes

Each gate is a formal design review with Development, Quality and Regulatory. Nothing moves forward on a promise to document it later.

Gate 1 · Planning

Plan Approved

Software development plan approved, safety class or rigor level assigned with rationale, and AI planning complete where AI is present.

Gate 2 · Requirements

Requirements Baselined

Functional, performance, security, usability, safety and AI requirements reviewed and baselined, with traceability started.

Gate 3 · Architecture

Architecture Approved

Every software item identified and classified, SOUP listed, and security trust boundaries documented for threat modelling.

Gate 4 · Detailed Design

Design Approved

Unit-level design reviewed before coding, with security requirements and input validation mapped to the design.

Gate 5 · Implementation

Code Verified

Independent code review, static security analysis on every build, and unit tests passed with no open critical defects.

Gate 6 · Integration

Integration Verified

All interfaces tested, including error conditions, with defects resolved or risk-accepted and the report approved.

Gate 7 · System Testing

System Verified & Validated

System, security and usability testing complete, AI performance and bias testing passed, and no open critical or high defects.

Gate 8 · Release

Release Approved

Release record signed by Quality, Regulatory and Product Security, SBOM current, known anomalies justified, and post-market monitoring active.

AI-Enabled Devices, Built to Be Trusted

AI brings risks that conventional software does not: data dependency, bias, drift and opacity. Our AI lifecycle adds the controls regulators now expect under the EU AI Act, the IEC 62304 Edition 2 AI Annex and the FDA's AI guidance, inside the same stage gates.

Before Training

Performance Criteria First

Clinically meaningful acceptance criteria, subgroup requirements and human oversight design are fixed before any model is trained.

EU AI Act Art. 10

Data Governance

Documented data sources, annotation, representativeness and bias assessment, with a test set locked away from development.

Validation

Robustness & Bias Testing

Subgroup analysis, out-of-distribution and adversarial testing, and clinical validation matched to your device class.

Transparency

Model Cards & Oversight

Model cards, output explanations and override mechanisms that let clinicians use AI outputs appropriately.

Post-Market

Drift Monitoring & PCCP

Performance and drift monitoring with defined triggers, and predetermined change control plans for planned model updates.

Security

AI Threat Modelling

STRIDE-AI analysis of data pipelines, model weights and inference, including data poisoning and adversarial inputs.

Evaluating Pre-Trained Models Before You Build on Them

Pre-trained and foundation models are software of unknown provenance. Before one goes into a medical device, we evaluate its training data provenance, licence, performance in your intended use, bias, security and vendor support. Our method comes from our own peer-reviewed research, which led directly to IEC 63767, the new international standard for evaluating pre-trained AI models in medical devices.

Read the paper: Evaluating Pre-trained 3rd Party AI Models in Medical Device Software Development for Responsible and Ethical Use (AICS 2025). Our evaluation SOP, work instruction and checklist are available in the .

Faster Development, Without Cutting Corners

We use AI tools to speed up the work around the code, such as drafting requirements and tests, reviewing code and keeping traceability up to date. They are controlled like any other development tool: assessed for their intended use, with every output reviewed by a qualified engineer.

ISO 13485 §4.1.6 · IEC 62304

Assessed Before Use

AI tools are assessed for their intended use with our Oversure framework and documented in the software development plan.

Human Oversight

Reviewed by Engineers

Qualified engineers review and approve every AI output before it enters your code or documentation. AI drafts; people decide.

Configuration Management

Traceable & Controlled

AI-assisted work goes through the same code review, testing and change control as any other change to your software.

Find out how we validate AI tools:

Sustainable by Design

Software has an environmental footprint too: the energy used by servers, cloud services and AI models, the data it stores and moves, and the hardware it runs on and eventually retires. We build ecodesign into the same lifecycle, guided by IEC 62430 and our work on IEC 63686, without compromising safety or performance.

Design Inputs

Environmental Requirements

Objectives such as energy use, data volumes and supported hardware are captured as design inputs, alongside safety and performance.

Architecture

Efficient Compute & AI

Right-sized cloud infrastructure, efficient models and inference, and data retention that keeps only what is needed.

Maintenance

Longer Hardware Life

Supporting existing devices and platforms for longer, with lean updates instead of forced hardware replacement.

Decommissioning

Responsible End of Life

Planned retirement with secure data deletion or migration, so nothing is left running or stored without a purpose.

Software and the Evidence Behind It

You get working software and technical documentation that a Notified Body or the FDA can follow from requirement to test result.

Plans

Software development plan, AI development plan, verification plans and the software maintenance plan.

Specifications & Design

Software requirements, architecture and detailed design, with a traceability matrix linking them to tests and risks.

Verification Evidence

Unit, integration and system test records, security test reports and AI performance reports.

Risk & Security Files

Software inputs to your ISO 14971 risk file, threat models, SOUP list and software bill of materials.

Release Package

Release record, known anomalies list, archived build configuration and labelling inputs.

AI Documentation

Data governance records, training records, model card and the AI sections of your MDR and AI Act technical documentation.

Building Medical Device Software?

Tell us about your device, your intended use and where you are today, and we will propose a development plan that fits your regulatory pathway.