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:

Classificatie: Klasse B - Software die letsel kan veroorzaken, maar niet ernstig letsel.

Onderbouwing:

De software genereert beslisondersteuning, geen autonome beslissingen
Een gekwalificeerde apotheker beoordeelt alle output voordat actie wordt ondernomen
Foutieve output leidt in het ergste geval tot een gemist signaal dat de apotheker handmatig had moeten opvangen - dit is vergelijkbaar met het niet raadplegen van een naslagwerk
Ernstig letsel of overlijden als direct gevolg van softwarefouten is niet aannemelijk gezien het beoogd gebruik (adviserend, met menselijk toezicht)

Klasse C (ernstig letsel/overlijden) is niet van toepassing omdat het systeem geen directe patientinteractie heeft en geen behandelingen initieert.

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	Vastgelegd in `requirements.txt` (backend) en `package.json` (frontend)
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
Standaardvragen: 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	`requirements.txt` (exacte versies via `pip freeze`)
Afhankelijkheden frontend	`package-lock.json` (exacte versies)
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