Architectuur-besluiten

Waarom we bouwen zoals we bouwen.

Architectural Decision Records (ADR's) leggen vast waarom een keuze gemaakt is — niet alleen wat. Wij publiceren ze openbaar zodat uw architect en CIO kunnen beoordelen of onze afwegingen bij uw organisatie passen, vóór een tender.

Iedere ADR volgt de standaard context → besluit → consequenties-structuur. Aanvaard = besluit is in productie geïmplementeerd. Wijzigingen zijn versie-beheerd; vervanging gebeurt via een nieuwe ADR die de oude superseden.

ADR-001

2025-09

Aanvaard

Modulaire monolith over microservices

Context

Voor een initieel-kleine zorgsoftware met krappe ontwikkelcapaciteit zijn microservices operationeel te duur. Tegelijkertijd moeten modules onafhankelijk geactiveerd kunnen worden per klant.

Besluit

We bouwen een modulaire monolith op .NET 10 met strikt afgebakende modules (Application/Domain/Infrastructure per module), die in één deployable wordt uitgeleverd. Modules zijn intern feature-flagged per tenant.

Consequenties

Eenvoudiger deployment en lagere infrastructuurkosten. Latere splitsing naar separate services is mogelijk maar niet gepland. Risico: discipline op module-grenzen vereist code-reviews en architectuurtests.

ADR-002

2025-10

Aanvaard

FHIR R4 als canonieke uitwisselings-format

Context

Nederlandse zorgketen beweegt naar verplichte interoperabiliteit (Wegiz, MedMij). HL7v2 is legacy; eigen formaten betekenen lock-in en aansluiting met de keten frustreren.

Besluit

FHIR R4 (niet R5) is de canonieke representatie voor cliënt, dossier, observaties en medicatie aan de API-grens. Intern blijft de relationele structuur eigen — FHIR is een grens-format, geen opslag-format.

Consequenties

Publieke API en sandbox documenteren FHIR R4. Bij overgang naar R5 staat compatibiliteits-onderhoud vooraan. Nederlandse profielen (Nictiz zib-mapping) worden incrementeel toegevoegd.

ADR-003

2025-11

Aanvaard

NL-hosting (Azure West-Europe) — geen exceptie

Context

Zorgaanbieders eisen aantoonbaar dat zorggegevens niet buiten de EER worden verwerkt. Cloudflare-edge-caching voor de marketing-site is acceptabel; voor de zorg-applicatie niet.

Besluit

De zorg-applicatie (app.coheza.nl) draait uitsluitend in Azure West-Europe met backup binnen NL. Geen secondary regions in andere geografieën. Sub-verwerker-lijst wordt 30 dagen vóór wijziging gecommuniceerd.

Consequenties

Hogere latency voor non-EU-bezoekers (irrelevant voor NL-zorg). Failover-strategie is regionale-availability-zones, niet cross-region. Disaster-recovery is geografisch beperkt — bewust binnen NL-grenzen.

ADR-004

2025-12

Aanvaard

BSN-encryptie per tenant met AES-256-GCM

Context

BSN is bijzonder persoonsgegeven onder AVG art. 9 én gespecificeerd onder Wabvpz. Versleuteling op kolom-niveau biedt verdediging-in-diepte boven volledige database-encryptie.

Besluit

BSN wordt encrypted opgeslagen via AES-256-GCM, met sleutel per tenant beheerd in Azure Key Vault. Sleutel-rotatie elk kwartaal. Search via deterministisch hash-veld (separate kolom) om gelijkheids-queries mogelijk te houden zonder decryptie.

Consequenties

Index-scans op BSN vereisen het hash-veld, niet de encrypted kolom. Bulk-data-export decrypteert lazy. Performance-impact gemeten <5ms per lookup. Bij sleutelverlies is herstel via Key Vault recovery-policies.

ADR-005

2026-02

Aanvaard

Nis2Care als zustermerk in plaats van inline-module

Context

NIS2-compliance is een eigen specialisme met diepe verticals (Z-CERT, IGJ-meldplicht, MDR-asset-tracking) die niet noodzakelijk in Coheza's EPD-scope horen. EPD-klanten willen wel de compliance-overlay.

Besluit

NIS2-functionaliteit wordt uitgewerkt als separaat product (Nis2Care), gepositioneerd als complementair aan elk EPD — niet alleen Coheza. Coheza refereert alleen `Nis2Care.Zorg.Contracts` (publieke NuGet) voor data-uitwisseling.

Consequenties

Coheza blijft EPD-zuiver; Nis2Care krijgt eigen marketing en kan ook met Nedap/Pluriform/SDB worden gekoppeld. Twee codebases, twee release-cadansen. Klanten kopen ze samen of apart — dat is een commerciële keuze.

Mist u een onderwerp?

Architectuur-vragen ontvangen we graag rechtstreeks. Bijvoorbeeld: hoe wij hot-fix-deploys structureel valideren, wat onze stand op event-sourcing is, of waarom we bewust geen Kubernetes draaien. Mail architectuur@coheza.nl — antwoord binnen 1 werkdag.

Wilt u ons architectuurplaat zien?

In het procurement-pakket zit een geannoteerde architectuurplaat (PDF) met netwerk-zones, data-flow en sub-verwerkers. Geen lead-gate, geen NDA.

Demo aanvragen Stel een vraag