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 may qualify the product as Software as a Medical Device (SaMD), 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; we are not a certification body and do not sell “ISO 13485 certified” badges)
• 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)

Standards application is product-specific. We do not claim CE marking, FDA clearance/approval or third-party certification of your product by publishing these names.

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 with client-owned conformity pathways in mind. 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 (client-owned assessment)
• 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; we do not treat deadlines as marketing slogans
• GDPR and applicable national privacy law for processing design — public site forms still exclude PHI
• Harmonised / state-of-the-art standards cited above as technical input to conformity documentation

We are not a notified body and do not issue CE certificates or guarantee conformity outcomes. See EU & US support.

Regulatory alignment — United States

For programmes oriented to the United States, we support engineering and documentation consistent with client-owned FDA 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 — not via the public contact form)

We are not FDA, not a covered entity by virtue of this website, and do not grant clearance, approval or “HIPAA certification.” See Regulatory support.

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

We do not claim certified clinical AI, guaranteed regulatory outcomes or partnership with FDA, EMA or the EU AI Office.

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. Escalate SaMD / device questions — when qualification may apply

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)

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 suitable for client-owned files
• Traceability matrix artefacts usable by RA/QA for EU or US review preparation

Out of scope

• Consumer wellness marketing claims disconnected from intended use
• Presenting software as cleared, approved or CE-marked without client-owned evidence
• Acting as notified body, certification body, FDA or clinic
• Accepting clinical datasets or PHI via the public contact form

Related

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