Medical devices

Medical-device safety arguments sit at the intersection of three things: a strong existing risk-management standard (ISO 14971), a software lifecycle standard tied to it (IEC 62304), and a regulator-submission process that ultimately wants the same artefact — a defendable argument that the device is safe for its intended use.

GSN gives you a way to draft that argument once and present it consistently across submissions to different regulators.

The standards stack

• ISO 14971 — Medical devices — Application of risk management to medical devices. The harm/hazard/risk model and the lifecycle benefit-risk analysis.
• IEC 62304 — Medical device software — Software lifecycle processes. Defines the software safety classes (Class A / B / C) and the development activities required for each.
• IEC 62366-1 — Application of usability engineering. Increasingly tied into the safety argument for devices with non-trivial UIs.
• IEC 60601-1 + collateral standards — General requirements for basic safety and essential performance of medical electrical equipment.

Regulator submissions reference these through their own frameworks: FDA premarket submissions (510(k), De Novo, PMA), EU MDR technical documentation, TGA inclusion under the ARTG, MHRA UKCA submissions. The underlying argument is the same; the paperwork varies.

This page is high-level context for the assurance argument, not regulatory advice. Submission strategy belongs with your regulatory affairs lead.

What GSN gives you

A medical-device safety case typically threads together risk-management outputs, software development records, verification and validation evidence, usability engineering files, and clinical evaluation reports. GSN holds these together as a single argument:

• Top-level claim: the device is safe and effective for its intended use within its operating environment.
• Decomposition strategies: by hazard (from the ISO 14971 hazard analysis), by software safety class, by essential performance, by intended-use scenario.
• Sub-claims: each identified hazard mitigated to acceptable risk, each software-safety-class B/C component developed to the required rigour, each essential performance characteristic verified.
• Evidence (Solutions): risk-management file entries, software unit/integration/system test reports, usability test results, clinical evaluation reports, post-market surveillance plans.

An example fragment

A high-level argument for an infusion-pump dose-rate calculator at IEC 62304 software safety class C:

Each sub-Goal terminates in Solutions — the hazard analysis entry, the risk-control verification record, the IEC 62304 Class C development evidence (architecture, detailed design, unit tests, integration tests, system tests, traceability matrix).

Where Lemmatica fits

• Risk management and software development tend to be written in separate documents by separate teams. The structured argument forces — and exposes — the link between them.
• Multi-regulator submissions are easier when the underlying argument is one artefact rather than per-jurisdiction prose.
• Modular sub-cases via away goals let you separate hardware, software, usability, and clinical sub-arguments while keeping the top-level claim coherent.
• Continuous validation catches structural gaps before they become regulator queries — an undeveloped hazard branch is visible as you build, not after submission.