Ga naar inhoud

Change Management (NEN 7510-2 §12.1.2)

Versie 1.0.0 - mei 2026

NEN 7510-2 §12.1.2 vereist dat wijzigingen aan informatie- of softwaresystemen die patient-data raken traceerbaar, geautoriseerd en achteraf reproduceerbaar zijn. Dit document beschrijft hoe Remedice die eis invult op codeniveau, deployment en runtime-configuratie.

1. Code-changes

Aspect Maatregel
Versiebeheer Git, separate repo's voor backend/, frontend/, landing/, documentation/
Branchstrategie Aparte branch per wijziging, gemerged via PR naar main
Review-eis Minimaal één human review (PR-approval) voor elke merge naar main
Geautomatiseerde checks Linting (ruff, eslint), backend-testsuite (django.test) en migratie-detectie draaien voor merge
Audit-trail git log is canoniek. Iedere commit bevat auteur, timestamp en gewijzigde bestanden; squash-merging is uitgeschakeld zodat de individuele commit-historie behouden blijft
Sign-off Iedere release-tag wordt door de eindverantwoordelijke geplaatst (git tag -a vX.Y.Z)

2. Database-migraties

  • Migraties zijn versionable artefacten in backend/features/<module>/migrations/.
  • Iedere migratie is gegenereerd via manage.py makemigrations; geen handgeschreven migratie-files (zie CLAUDE.md "Schema & Migrations").
  • Backwards-incompatibele migraties (NOT NULL, drop column) worden in twee stappen uitgerold: kolom optioneel toevoegen + backfill (release N), constraints aanzetten (release N+1).
  • manage.py migrate wordt alleen gedraaid via een gecontroleerd deployment-script door de eindverantwoordelijke.

3. Configuratie-changes

  • Niet-secret configuratie staat in backend/config/settings/{base,dev,prod,test}.py en is dus onderdeel van de Git-historie.
  • Secrets staan in .env (per omgeving) en worden niet in Git opgenomen.
  • Wijzigingen aan settings-bestanden volgen dezelfde PR-flow als applicatiecode.

4. Deployment

  • Productiedeploys gaan via een gepinde container-build met de Git-commit-SHA als image-tag, zodat een running pod altijd terugkoppelt naar een specifieke commit.
  • Rollbacks gebeuren door re-deployment van een eerdere image-tag; nooit door directe wijziging op de productie-server.
  • Sentry registreert release-tag bij elke ingestion, waardoor errors aan de juiste codeversie kunnen worden gekoppeld.

5. Audit en bewaartermijn

  • Git-historie blijft onbeperkt bewaard (origin + back-up).
  • Audit-events op runtime-effects (data-toegang, mutaties) staan in CloudWatch log-groepen /remedice-<env>/audit/* met retentie conform NEN 7513.
  • Combinatie van Git-commits, deployment-tags en CloudWatch audit-logs maakt het mogelijk om voor iedere productie-incident achteraf vast te stellen welke code-versie actief was, wie die heeft gemerged en welke patient-data-acties op dat moment plaatsvonden.

6. Verantwoordelijkheid

Rol Verantwoordelijkheid
Ontwikkelaar Schrijft code-wijziging conform repo-conventies, voegt tests toe
Reviewer Beoordeelt PR op functionaliteit, security en compliance-impact
Eindverantwoordelijke Mergt naar main, plaatst release-tag, draait migrate en deployment

Dit proces wordt jaarlijks herzien en bij significante wijzigingen in de organisatie of toolchain.