Software Lifecycle (IEC 62304)

Versie 1.0.0 - juni 2026

Dit document beschrijft hoe Remedice voldoet aan IEC 62304 (Medische software - Levenscyclusprocessen), vereist voor de medicatiebeoordeling-module als Klasse IIa medisch hulpmiddel.

1. Software safety classificatie

Conform IEC 62304, clausule 4.3 (incl. Amendment 1:2015).

Classificatie: Klasse B - Software die kan bijdragen aan een gevaarlijke situatie die letsel kan veroorzaken, maar waarbij ernstig letsel na risicobeheersing niet aannemelijk is.

1.1 Hazard-analyse en de keuze B versus C

Zonder beheersmaatregelen is een ernstige uitkomst niet bij voorbaat uit te sluiten. De relevante hazards en hun potentiele ernst:

Hazard	Potentiele ernst zonder beheersing	Beheersmaatregel
Gemiste klinisch relevante interactie of contra-indicatie (fout-negatief)	Mogelijk ernstig (bv. bloeding, serotonerge toxiciteit, QT-verlenging)	Apotheker beoordeelt alle output; analyses zijn informatief en nooit uitsluitend; conservatieve (over-)signalering
Onterechte signalering (fout-positief)	Beperkt (extra beoordeling)	Adviserend karakter; apotheker beslist
Onjuiste ATC-verrijking	Indirect, via verkeerde analyse	V1a/V1b-validatie, handmatige correctie, parse-warnings

1.2 Basis voor Klasse B (IEC 62304 4.3 onder a)

IEC 62304 staat indeling in een lagere klasse toe wanneer een risicobeheersmaatregel buiten de software het restrisico zodanig verlaagt dat ernstig letsel niet langer aannemelijk is. Die externe maatregel is hier de verplichte beoordeling door een BIG-geregistreerde apotheker: de software initieert geen behandeling, heeft geen directe patientinteractie, en alle output passeert het klinisch oordeel van de apotheker voordat er actie volgt (zie Beoogd gebruik en Risicomanagement).

Met deze externe beheersmaatregel is het hoogst aannemelijke directe gevolg van een softwarefout een gemist signaal dat de apotheker via zijn eigen beoordeling hoort op te vangen, vergelijkbaar met het niet raadplegen van een naslagwerk. Daarom is Klasse B passend en niet Klasse C.

1.3 Voorwaarde en herziening

De classificatie steunt expliciet op de externe beheersmaatregel (apotheker-in-the-loop). Vervalt die voorwaarde - bijvoorbeeld door functionaliteit die output zonder menselijke beoordeling laat doorwerken - dan wordt de classificatie heroverwogen richting Klasse C. De keuze wordt herzien bij wezenlijke wijzigingen in het beoogd gebruik of de mate van automatisering.

2. Ontwikkelproces

2.1 Planning (IEC 62304, 5.1)

Aspect	Implementatie
Projectmanagement	Taakbeheer via issue tracking
Versiebeheer	Git (gescheiden repositories voor backend, frontend, landing, documentatie)
Branches	Aparte branch per wijziging met pull requests naar main
Code review	Verplicht voor productie-deployments
Omgevingen	Development, staging, productie (Docker-gebaseerd)

2.2 Architectuur en ontwerp (IEC 62304, 5.3-5.4)

Backend:

Python 3 / Django 5.2 / Django REST Framework
Multi-tenant architectuur (django-tenants, PostgreSQL schema-isolatie)
Service-layer patroon: modellen (data), services (logica), views (API)
Analyse-modules als afzonderlijke Python-bestanden in features/medicatiebeoordeling/analyses/

Frontend:

React Native (Expo Router)
Module-gebaseerde mapstructuur (src/features/<naam>/)
Scheiding van screens, components, API-calls en types

Databronnen:

G-Standaard: SQLite lookup-database (lookup.db)
Klinische criteria: JSON-bestanden met versiebeheer (Git)
Bijwerkingen: PostgreSQL model (SideEffectFrequency)

2.3 Implementatie (IEC 62304, 5.5)

Aspect	Standaard
Programmeertalen	Python (backend), TypeScript (frontend)
Coding guidelines	Vastgelegd in CLAUDE.md (projectrichtlijnen)
Afhankelijkheden (SOUP)	Vastgelegd in `requirements.txt` (backend) en `package.json` (frontend); geregistreerd in het SOUP-register
Versleuteling	Fernet (AES-128-CBC + HMAC-SHA256) voor patient- en medewerkergegevens, PBKDF2 voor wachtwoorden
Inputvalidatie	Django REST Framework Serializers, geparametriseerde queries

2.4 Software-unit verificatie (IEC 62304, 5.5.5)

Backend tests:

Django TestCase-framework
Uitgevoerd via Docker: docker compose exec backend python manage.py test --settings=config.settings.test
Testdata in setUpTestData (per class, niet per test) voor performance
Dekking van: parsers, analyses, services, views, permissies

Frontend kwaliteitsborging:

ESLint linting (npm run lint)
TypeScript type-checking
Geen unit tests (conform projectrichtlijnen); focus op linting en type safety

2.5 Software-integratie en integratietest (IEC 62304, 5.6-5.7)

Integratietests via Django test runner met echte database (geen mocks voor DB)
End-to-end dataflow tests: upload -> parsing -> ATC-verrijking -> analyses -> opslag
Tenant-isolatie tests

3. Verificatie en validatie

3.1 Verificatie (IEC 62304, 5.7)

Software verificatie bevestigt dat de implementatie overeenkomt met de specificatie:

Unit tests per analyse-module
Integratietests voor de volledige pipeline
Code review bij elke wijziging

3.2 Validatie (MDR / klinisch)

Klinische validatie bevestigt dat de output klinisch correct is:

Zie validatieprotocollen voor gedetailleerde studieprotocollen per analyse
Onderscheid: technische verificatie (code doet wat bedoeld) vs. klinische validatie (output is klinisch correct)

4. Onderhoud (IEC 62304, 6)

4.1 Probleemoplossing

Bugmelding via issue tracking of gebruikersfeedback
Beoordeling: severity (kritiek/hoog/middel/laag), impact op klinische veiligheid
Fix: code-wijziging, review, test
Deployment: via gecontroleerd releaseproces
Communicatie: bij klinisch relevante bugs wordt de gebruiker geinformeerd

4.2 Databron-updates

G-Standaard: Periodieke update van lookup.db bij nieuwe Z-Index releases
STOPP-NL V2: Update bij publicatie van nieuwe versie criteria
ACB-scores: Update bij publicatie van gewijzigde ACB-lijsten
Maagbescherming: Update bij herziening NHG/KNMP-richtlijnen
Clinical Rules: Beheerbaar door de apotheek via de instellingenpagina

Bij elke databron-update wordt een regressietest uitgevoerd om te verifieren dat bestaande analyses niet onbedoeld veranderen.

5. Configuratiebeheer (IEC 62304, 8)

Item	Methode
Broncode	Git repositories (backend, frontend, landing, documentatie)
Afhankelijkheden backend (SOUP)	`requirements.txt` (exacte versies via `pip freeze`); zie SOUP-register
Afhankelijkheden frontend (SOUP)	`package-lock.json` (exacte versies); zie SOUP-register
Klinische databronnen	JSON-bestanden in Git met versiebeheer
G-Standaard database	Versiebeheer via build-scripts (`build_gstandaard_db.py`, `build_nhg_db.py`)
Infrastructuur	Docker Compose configuratie in Git
Omgevingsvariabelen	Per-omgeving configuratie (niet in Git)

6. Traceerbaarheid

Van	Naar	Methode
Risico (ISO 14971)	Maatregel	Risicomanagement, traceerbaarheidsmatrix
Maatregel	Verificatie	Validatieprotocollen, test suite
Eis (beoogd gebruik)	Implementatie	Functionele specificatie in issues
Implementatie	Test	Test-class per module
Bug	Fix	Issue tracking met commit-referenties