Pular para conteúdo

IEC 62304:2006+A1:2015 Software Lifecycle — EPPA

Lifecycle artefacts are missing

As of 2026-05-21, EPPA has working software but no formalised IEC 62304 lifecycle artefacts (no Software Development Plan, no SOUP register, no V&V plan signed off, no formal Software Architecture Description). This document defines the artefacts that must exist before EPPA can be the subject of an EU MDR technical-documentation submission to a notified body (see 10-eu-mdr-saMD-classification.md).

1. Document identity

Field Value
Document title IEC 62304 Software Lifecycle Plan — EPPA
Document ID EPPA-SLP-001
Version 0.1 (draft)
Status Draft — not approved
Effective date n/a
Owner LABIS UCA — Software lead (pending)
Linked documents 10-eu-mdr-saMD-classification.md, 12-iso-14971-risk.md, 50-secdev-checklist.md

2. Regulatory anchors

  • IEC 62304:2006+A1:2015 — Medical device software — Software life cycle processes.
  • IEC 82304-1:2016 — Health software — Part 1: General requirements for product safety.
  • ISO 14971:2019 — Application of risk management to medical devices.
  • ISO 13485:2016 — QMS for medical devices (process anchor).
  • EU MDR Annex I §17 — General requirements for software.
  • MDCG 2019-16 Rev.1 — Cybersecurity for medical devices.

3. Software safety classification (IEC 62304 §4.3)

IEC 62304 §4.3 requires the manufacturer to assign a software safety class to the software system (and to each software item, with allowance for the "divide and segregate" principle of §4.3(b)).

3.1 Definitions

Class Definition (§4.3)
Class A The software system cannot contribute to a hazardous situation; OR a hazardous situation that could result from a software failure does not result in unacceptable risk after consideration of risk control measures external to the software system.
Class B A hazardous situation that could result from a software failure could result in non-serious injury.
Class C A hazardous situation that could result from a software failure could result in death or serious injury.

3.2 EPPA classification reasoning

Question Answer
Can EPPA software failure lead to a hazardous situation? Yes. Wrong marker placement, wrong scaling, wrong angle computation or wrong qualitative classification can mislead a clinician's interpretation of postural alignment.
Can that hazardous situation result in death? No. Even worst-case mis-classification leads to mis-prescribed corrective exercises, not life-threatening outcomes. EPPA does not administer energy, drugs or surgery.
Can it result in serious injury (per IEC 62304 definition: "injury or illness that directly or indirectly is life threatening, results in permanent impairment of a body function or permanent damage to a body structure, or necessitates medical or surgical intervention to prevent permanent impairment")? Unlikely. Mis-prescribed corrective exercise is reversible. However, if EPPA outputs were used outside the intended use (e.g. as the sole basis for surgical planning, contraindicated in 01-intended-use-statement.md §5), the worst case could rise toward serious injury. This is mitigated by the non-device disclaimer and the explicit non-claims.
Can it result in non-serious injury? Yes — mild musculoskeletal strain from inappropriate corrective exercise; misallocation of clinical resources; psychological harm from misinformation about postural condition.

Conclusion: Class B.

Why not Class C

Class C requires that a software failure could result in death or serious injury after consideration of risk controls external to the software. With the clinician-in-the-loop control measure (Art. 22 GDPR non-applicability; explicit clinician judgement required), the residual severity is non-serious. The MDR Rule 11 classification (Class IIa, 10-eu-mdr-saMD-classification.md) is consistent with IEC 62304 Class B; the two scales are independent but typically co-vary.

3.3 Segregation (IEC 62304 §4.3(b))

EPPA is currently monolithic — Next.js client + FastAPI server + Python analysis modules in a single repository. The §4.3(b) segregation principle allows the manufacturer to identify software items of higher safety class and segregate them from items of lower safety class. EPPA today does not exploit segregation; the entire system inherits Class B.

A future refactor that isolates the analysis kernel from the presentation layer could enable Class A for the UI shell and Class B only for the kernel, reducing the V&V burden on UI changes. This is a roadmap item, not a current commitment.

4. Required lifecycle artefacts (Class B mapping)

The following table maps each IEC 62304 process to the deliverable required for Class B. Process numbers reference IEC 62304 clauses.

Process / clause Deliverable Required for Class B? EPPA status
§5.1 Software development planning Software Development Plan (SDP) Yes Missing
§5.1.6 Configuration management plan CM Plan (or section of SDP) Yes Implicit (Git) — needs formal document
§5.1.7 Software problem resolution plan Problem resolution procedure Yes Informal (GitHub Issues) — needs formal document
§5.2 Software requirements analysis Software Requirements Specification (SRS) Yes Missing
§5.3 Software architectural design Software Architecture Description (SAD) Yes (Class B+) Missing (informal claude.md notes)
§5.4 Software detailed design Detailed Design (Class C only) No for Class B n/a
§5.5 Software unit implementation Source code + unit tests Yes Partial — vitest/pytest present, no traceability
§5.6 Software integration and integration testing Integration test plan and report Yes Partial — playwright e2e present
§5.7 Software system testing System test plan and report Yes Missing as a formal artefact
§5.8 Software release Release records (build hash, version, configuration baseline) Yes Partial — package.json version present, no formal release record
§6 Software maintenance process Maintenance plan Yes Missing
§7 Software risk management process Risk management file (also under ISO 14971) Yes DRAFT in 12-iso-14971-risk.md
§8 Software configuration management process CM records Yes Partial (Git history)
§8.1 Configuration item identification Inventory of CIs (source, third-party, tools) Yes Missing as formal artefact
§9 Software problem resolution process Problem reports + change requests Yes Partial (GitHub Issues) — needs traceability

5. SOUP register (IEC 62304 §5.3.3, §7.1.3, §8.1.2)

SOUP ("Software Of Unknown Provenance") is third-party software incorporated into the medical device that was not developed under an IEC 62304 process. Every SOUP item requires:

  • §5.3.3 — Architectural rationale for inclusion.
  • §5.3.4 — Functional and performance requirements.
  • §7.1.3 — Risk identification associated with the SOUP item.
  • §8.1.2 — Configuration item identification (version, supplier, source).

5.1 EPPA SOUP register — seed

Item Version Supplier Purpose Safety relevance Risk control
Next.js 15.5.15 Vercel Frontend framework Low — UI shell, not analysis kernel Pin major version; regression test on upgrade; security advisory monitoring
React 18.3.1 Meta UI library Low Same as Next.js
FastAPI 0.115.0 Sebastián Ramírez et al. Backend HTTP framework Medium — routes analysis requests Pin version; integration tests must pass before upgrade
NumPy 2.0.2 NumPy maintainers Numerical computation High — used in marker geometry Pin minor version; numerical regression test suite against MATLAB reference
OpenCV (cv2) >=4.8.0 OpenCV maintainers Image manipulation Medium — image preprocessing Pin version; visual regression tests
Pillow not bundled (E3) Pillow maintainers Image I/O Low Pin version
Pydantic 2.9.2 Pydantic Request/response validation Medium — input sanitisation surface Pin major; security advisory monitoring
SQLAlchemy (planned) >=2.0,<3 SQLAlchemy ORM Medium — data integrity Standard advisory monitoring
Argon2-cffi >=23.1 hynek Password hashing Medium — auth (see 50-secdev-checklist.md) Pin version; OWASP ASVS V2 alignment
PyJWT >=2.8 (with crypto extra) maintainers JWT signing/verification (planned) Medium — auth surface Pin version; algorithm pinned to RS256

Authoritative machine-generated SOUP register

The table above is a human-readable seed. The authoritative SOUP register is generated from fronts/eppa/package-lock.json and fronts/eppa/python/requirements.txt with: cd fronts/eppa && python3 scripts/supply_chain.py generate --artifact-dir .supply-chain-artifacts. The generated SBOM and SOUP JSON files are CI/release artifacts and are not committed by default. The pipeline fails if generation finds no components. Policy details and the vulnerability allowlist format are documented in fronts/eppa/docs/security/supply-chain-policy.md.

6. Software Development Plan (skeleton)

The SDP must cover, at minimum:

  1. Scope — what software is covered (EPPA frontend + backend + analysis pipeline; excluded: dev-only tooling).
  2. Lifecycle model — agile-iterative variant compatible with IEC 62304; reference IEC TR 80002-3:2017 for agile in safety-critical software.
  3. Roles and responsibilities — software lead, V&V lead, regulatory lead, clinical reviewer, security lead.
  4. Process inputs — intended use (01-intended-use-statement.md), risk management (12-iso-14971-risk.md), classification (10-eu-mdr-saMD-classification.md), security checklist (50-secdev-checklist.md).
  5. Standards applied — IEC 62304, IEC 82304-1, ISO 14971, ISO 13485, ISO/IEC 27001 (informative), OWASP ASVS L2 (informative).
  6. Tools used — Git, GitHub Actions, vitest, pytest, Playwright, MkDocs Material, etc.; tool validation per IEC 62304 §6.8 (qualification of software tools used in safety-critical workflows).
  7. Deliverables and reviews — for each process clause in §4 above.
  8. Traceability — requirement → design → code → test, maintained in a traceability matrix.
  9. Configuration management — Git as the authoritative CI store; release tags as configuration baselines.
  10. Problem resolution — GitHub Issues as the authoritative system; every problem report has severity, root-cause analysis, and a verified fix.

7. Software Architecture Description (skeleton)

Required content per §5.3:

  • High-level architecture diagram (Next.js client ↔ FastAPI server ↔ Python analysis kernel).
  • Identification of all SOUP (see §5).
  • Identification of software items by safety class.
  • Interfaces (HTTP API, image upload, marker JSON schema).
  • Segregation rationale (none in v1 — entire system Class B; planned isolation of analysis kernel).
  • Architectural risk control measures (e.g. clinician-in-the-loop UI; non-device disclaimer ribbon).

8. Verification and validation plan (skeleton)

Activity IEC 62304 ref EPPA approach
Unit testing §5.5.2 vitest (TypeScript), pytest (Python). Coverage target ≥ 80 % on analysis kernel modules.
Integration testing §5.6 API contract tests (FastAPI TestClient); cross-language tests (frontend → backend round-trip).
System testing §5.7 Playwright e2e covering the four-view capture flow, marker placement, analysis output, CSV/PDF export.
Regression testing §6 (maintenance) Full suite re-run on every release; numerical regression vs MATLAB reference on a fixed image set.
Anomaly handling §9 GitHub Issues with severity labels; root-cause documented.
Tool validation §6.8 Tools used in safety-critical workflow (e.g. NumPy) treated as SOUP; build tools (vitest, pytest, Playwright) recorded with version pins.

Validation, in the IEC 82304-1 sense, is broader: it includes confirmation that EPPA is fit for its intended use in the clinical environment. This overlaps with the clinical evaluation under EU MDR Art. 61, which is not covered here.

9. Change management (IEC 62304 §6, §8, §9)

Change category Trigger Process
Source-code change Pull request PR review by software lead; CI must pass; if change affects safety class, regulatory review.
SOUP version bump Dependabot or manual Update SOUP register; re-run regression; document in change record.
Intended-use change PR to 01-intended-use-statement.md Triggers re-classification (Rule 11), re-DPIA, re-risk-file review, re-translation of disclaimer.
Architecture change Major refactor (e.g. extract analysis kernel) Update SAD; re-review safety-class segregation; re-V&V plan.
Hot fix Production incident Emergency change record; root-cause analysis within 5 working days; backport to mainline.

10. IEC 82304-1 cross-reference (product-level safety and security)

IEC 82304-1 is the product-level companion to IEC 62304 (which is process-level). The relevant clause for EPPA is §6 (general requirements including safety and security).

IEC 82304-1 §6 requirement EPPA approach Reference
§6.1 Product requirements Intended use + indications + contraindications 01-intended-use-statement.md
§6.2 Health software safety Risk management file 12-iso-14971-risk.md
§6.3 Health software security Security checklist (OWASP ASVS L2) 50-secdev-checklist.md
§6.4 Usability Clinical training programme + user manual 01-intended-use-statement.md §7
§6.5 Information for safety Non-device disclaimer + IFU 91-non-device-disclaimer.md

11. Open questions for the software lead

  1. Confirm lifecycle model. Pure-waterfall is impractical; pure-agile is not directly compatible with IEC 62304. Recommend IEC TR 80002-3:2017 tailoring.
  2. Confirm coverage targets. 80 % on the analysis kernel is conventional for Class B; confirm against EPPA's risk file once §10 is signed.
  3. Confirm SOUP cadence. Quarterly review minimum; weekly for security advisories.
  4. Confirm tool validation list. Which tools require validation under §6.8 vs which are off-the-shelf and not safety-relevant.

References