Medical Software & Digital Health

When this is needed

• Clinical, diagnostic or research software must meet regulated-industry expectations
• Product, engineering and RA teams lack a shared technical narrative
• Platforms need structured delivery without generic IT ambiguity
• Intended use and risk controls must influence architecture choices

Types of software we build

Engagements are scoped to intended use. Typical categories include both functional (operational / clinical workflow) and scientific (analysis, modelling, visualisation) software:

Functional / clinical-operational

• Software for clinics and care organisations (workflows, scheduling-adjacent tooling, operational decision support — as defined per product)
• Tools for diagnosticians and laboratory / imaging-adjacent workflows
• Digital health applications near or within medical-device expectations
• Integration layers and platforms that must remain auditable and change-controlled

Scientific / analytical

• Scientific visualisation and interactive exploration of study or experimental data
• Scientific and statistical models used in research or evidence programmes
• Analysis pipelines and tooling that must stay reproducible and documented
• Prototype-to-product paths when research software moves toward regulated use

When intended use points to Software as a Medical Device (SaMD), we give a reasoned qualification view and design to those rules from the start — see SaMD Development Support.

Engineering standards we work to

Medical and health software is not “another web app.” Where intended use, clinical risk or quality expectations apply, we engineer and document to the core international standards used for medical device software — not improvisation. On engagements in this practice we apply these norms in lifecycle, risk and documentation work (product-specific scope; client remains manufacturer / operator of record where that role applies):

• IEC 62304 — medical device software lifecycle: what must be planned, designed, implemented, verified and maintained at each stage
• ISO 14971 — risk management for medical devices: hazard analysis and residual-risk control when software can fail (data loss, wrong output, unsafe control of equipment)
• ISO 13485 — quality-management expectations for medical devices: version history, accountable review/approval and traceability of controlled documents (we align deliverables to the client’s QMS)
• IEC 62366-1 — usability engineering for medical devices (where relevant)
• IEC 82304-1 — health software product safety (where relevant)
• Cybersecurity and secure development practices appropriate to the product risk profile
• Interoperability inputs where in scope (e.g. HL7 FHIR, DICOM; national exchange architectures such as Poland’s P1 when the programme requires it)

Traceability

Auditable medical software needs a linear chain — a traceability matrix — so every critical behaviour can be shown end-to-end:

Clinical / medical need → system requirement → architecture / code → test case (and evidence)

If an auditor asks where a safety-critical control lives and how it was tested (for example preventing a duplicate dose), the answer should be retrievable as linked requirement, design, implementation and signed verification evidence — not a tribal memory of the sprint.

Documentation package (IEC 62304-oriented)

For programmes that need a technical file / design history file inputs for a notified body, FDA review or the client’s QMS, we produce or contribute to the usual IEC 62304-oriented artefacts (scoped per engagement), including:

• Software Development Plan (SDP) — how the team works, tools, configuration and version control
• Software safety classification — A / B / C (no injury → serious injury / death), which drives documentation depth
• Software Requirements Specification (SRS) — functional, performance and safety requirements
• Architecture and detailed design — structure, interfaces and data stores at a level suitable for review
• SOUP list — Software of Unknown Provenance (third-party / open-source components): versions, licences and risk rationale
• Verification plan and report — unit, integration and system testing evidence

Where the client’s QMS requires Part 11-capable electronic signatures and controlled records, documentation sits in their ALM/QMS toolchain — not as unsigned Markdown alone.

Regulatory alignment — European Union

For programmes oriented to Europe, we engineer and document against the applicable conformity frameworks. Depending on intended use, relevant instruments may include:

• MDR (EU) 2017/745 — Medical Device Regulation
• IVDR (EU) 2017/746 — In Vitro Diagnostic Medical Devices Regulation (where IVD software applies)
• MDCG and related guidance on software / SaMD qualification and classification
• EU AI Act (Regulation (EU) 2024/1689) — where the product includes an AI system; for medical AI this often applies alongside MDR/IVDR (complementary, not a substitute). Typical engineering/documentation themes: data governance, transparency, human oversight, AI-specific risk and performance evidence, and technical file content that can sit inside the client’s existing MDR/IVDR documentation set
• Staged AI Act applicability (including later dates for many AI systems that are safety components of devices subject to notified-body assessment) — programme planning should track current Commission / MDCG timelines
• GDPR and applicable national privacy law for processing design
• Harmonised / state-of-the-art standards cited above as technical input to conformity documentation

Regional pathway framing: EU & US support.

Regulatory alignment — United States

For programmes oriented to the United States, we support engineering and documentation consistent with applicable FDA device-software pathways and quality expectations. Depending on intended use, relevant instruments may include:

• FDA expectations for medical device software and SaMD (guidance and applicable product-specific requirements)
• FDA expectations for AI/ML-enabled device software — including lifecycle, change control and, where relevant, predetermined change control plans (PCCP) and related guidance
• 21 CFR Part 820 (Quality System Regulation) / evolving QMSR alignment as applicable to the client’s QMS
• 21 CFR Part 11 — electronic records / electronic signatures, where applicable to the system
• FDA cybersecurity and premarket / postmarket software considerations where relevant
• HIPAA (Privacy, Security and Breach Notification Rules) — engineering and documentation support for systems that process protected health information where the client acts as a covered entity or business associate; contractual BAAs and operational compliance remain with the client
• Other state privacy / security expectations applicable to the product context, arranged under contract

AI-enabled medical and health software

When models or automated decision support are in scope, we treat AI as part of the same engineering story as intended use, risk and quality — not as a separate demo track.

• Intended use, claims language and human oversight designed explicitly
• Training / validation data governance, bias and subgroup performance where relevant
• Traceability from requirements through model versions to verification evidence
• Change control for model updates (including locked vs adaptive approaches)
• Documentation inputs usable under MDR/IVDR + AI Act (EU) and/or FDA AI/ML expectations (US), as scoped

Ongoing operations and maintenance

Some programmes need support after first release — patches, monitoring, environment hygiene and controlled change management on infrastructure suited to the client’s region. Where scoped in the SOW, we can provide ongoing application maintenance and operations alongside the same engineering and documentation discipline as initial delivery.

• Maintenance and operational support on infrastructure aligned to US HIPAA themes, EU GDPR / health-sector context, or Canadian privacy expectations — as agreed per client
• Security-certified specialists involved where product and infrastructure risk require it (see Trust)
• Client remains accountable for BAAs, conformity, privacy programmes and production go-live decisions unless a contract states otherwise

Methodology

We engineer with intended use and documentation in view from the start:

1. Context — users, claims language, data flows, privacy (e.g. GDPR/HIPAA where relevant), EU/US and AI pathway pressure points
2. Architecture & practices — design suited to IEC 62304-oriented lifecycle, risk controls, change control and AI oversight where models apply
3. Build in increments — delivery paired with documentation inputs for client QMS / RA
4. Review readiness — gaps flagged; standards and regional requirements made explicit
5. SaMD / device qualification — reasoned view and design-phase discipline when intended use points to medical device software

Overall stages: How we work.

In scope

• Software design and implementation for medical, clinical-operational and scientific life-sciences contexts
• Architecture and quality-relevant engineering practices aligned with the standards above (as applicable)
• Documentation inputs for later regulatory or quality review (EU and/or US oriented)
• Ongoing maintenance and operations on regulated-aligned infrastructure where agreed (see Trust)

Example deliverables

• Design and implementation increments agreed in the engagement
• IEC 62304-oriented lifecycle artefacts (SDP, SRS, architecture, SOUP, V&V) as scoped
• Risk (ISO 14971) / usability / cybersecurity inputs for the technical file / DHF
• Traceability matrix artefacts usable by RA/QA for EU or US review preparation

Out of scope

• Consumer wellness marketing claims disconnected from intended use

Related

SaMD support · Regulatory support · Device readiness · Digital health · MedTech · EU & US support · Trust

For role boundaries (regulator, notified body, certification, outcomes), see Trust.