Nieuw multi-tenant zorgplatform voor de thuiszorg

CleverTech AI bouwde vanaf juni 2026 een volledig nieuw zorgplatform, afgesplitst van de legacy-monoliet en niet daarop voortgebouwd. In ongeveer zes weken ontstonden circa 1.334 commits aan nieuwe code.

Waar de eerdere case ging over het redden van het bestaande systeem, gaat dit spoor over de nieuwbouw ernaast.

1. Een multi-tenant zorgplatform als monorepo#

Het platform is een pnpm-monorepo in Node en TypeScript. Daarin zitten de API, een web-admin in React en drie React Native-apps: een voor zorgmedewerkers in het veld, een voor cliënten en hun naasten, en een voor de kraamzorgtak.

De domeinlogica die in de monoliet verweven zat, is uit elkaar getrokken in eigen packages — onder meer voor rooster- en zorggeneratie, factuurregels en de tariefkaart. Persistentie loopt via Prisma op PostgreSQL, end-to-end-tests via Playwright, en de infrastructuur is als Terraform-code vastgelegd in plaats van met de hand ingericht.

Een apart package verdient vermelding: een parity-oracle die het nieuwe platform systematisch vergelijkt met het oude. Dat is geen luxe maar het instrument waarmee de migratie beheersbaar blijft (zie punt 6).

2. Tenant-isolatie afgedwongen door PostgreSQL Row-Level Security#

Het ontwerpprincipe waar alles omheen is gebouwd: een zorgorganisatie mag onder geen enkele omstandigheid data van een andere organisatie zien. Dat is in dit platform geen applicatieregel maar een databasegrens.

• PostgreSQL Row-Level Security is de harde grens. De databaserol waarmee de applicatie in productie draait, kan RLS niet omzeilen — ook niet als er ergens in de code een filter wordt vergeten.
• Een Prisma client-extensie bindt elk inkomend request aan precies een tenant, zodat de applicatielaag en de databaselaag dezelfde grens hanteren.
• pnpm test:isolation draait als verplichte, aparte stap in twee CI-workflows. Faalt die test, dan blokkeert de release. Isolatie is in de projectdocumentatie expliciet vastgelegd als de grens waarvan doorbreking een UK-GDPR-breach zou zijn.

“

Ontwerpdoel van dit spoor: tenant-isolatie is geen instelling die iemand per ongeluk kan uitzetten, maar een eigenschap die de database afdwingt en die de pijplijn bij elke release opnieuw bewijst. Dat is het gestelde ontwerpdoel — geen na oplevering gemeten resultaat.

3. Toegang, secrets en de lessen uit de securityaudit#

Elk kritiek punt uit de audit op de oude omgeving is in de nieuwbouw als ontwerpeis teruggekomen:

• Geen master-password, geen universal-override credential. Dat is geen belofte maar een statisch bewaakte regel: een CI-script laat de build falen zodra er alsnog zoiets insluipt.
• CORS zonder wildcard en per-IP rate limiting op alle credential-endpoints, met een generieke 429 die niet verraadt of een account bestaat.
• Secrets uit een managed store, waarbij de API bewust closed faalt bij een ontbrekend secret in plaats van door te starten met een lege waarde.
• Disaster recovery: nachtelijke, versleutelde back-ups naar twee onafhankelijke off-site locaties.

4. Clinical safety: wat het platform bewust niet doet#

Zorgsoftware in het Verenigd Koninkrijk valt onder CQC-toezicht en onder de clinical-safety-normen DCB0160 en DCB0129, met een aangewezen Clinical Safety Officer. Dat vertaalt zich hier vooral in wat het systeem weigert te doen.

De eMAR-module — de digitale medicatieregistratie — is expliciet record-only: hij legt vast wat er is toegediend, maar berekent geen doses en signaleert geen interacties. Zodra software dat wel doet, verschuift ze naar een zwaardere klinische risicoklasse met bijbehorende verantwoordelijkheid.

De module staat in productie bovendien uitgeschakeld achter een feature flag: een bewuste clinical-safety-keuze, geen onaf werk.

5. Compliance als onderdeel van de oplevering#

Naast software is een compliancepakket meegeleverd: een Data Protection Policy, een BYOD Policy en een Records Retention Policy (versie 1.0, goedgekeurd in juni 2026), plus een volledig ingevuld DSPT v8-zelfassessment. Voor een zorgaanbieder is dat geen bijlage maar een voorwaarde om het platform überhaupt in gebruik te mogen nemen.

6. Wat een maatwerk zorgplatform kost — en waarom de migratie stapsgewijs gaat#

De eerlijke stand van zaken: dit platform is nog geen system of record. De migratie loopt.

Een drieweg-parity-audit in juli 2026 zette 332 capabilities van het oude systeem naast het nieuwe en kwam uit op 124 gebouwd, 136 gedeeltelijk, 47 ontbrekend, 21 bewust geschrapt en 4 wel ontworpen maar niet gebouwd. Er staan nog 14 tot 15 cutover-blockers open.

Dat is precies waarom die audit bestaat. Het security- en compliancefundament staat en wordt door CI afgedwongen; de functionele migratie gaat stapsgewijs, met per capability zicht op wat er nog mist.

Een zorgorganisatie kan niet halverwege ontdekken dat de zorgplanning van volgende week nergens staat.

Dat verklaart ook waar het geld in een maatwerk zorgplatform naartoe gaat. Het zwaartepunt ligt niet bij de schermen, maar bij isolatie die door de database wordt afgedwongen, bij een testsuite die een release durft te blokkeren, bij compliance-documentatie en bij het aantoonbaar migreren van jaren aan bestaande zorgdata.

Concrete bedragen zijn onderdeel van de vertrouwelijke afspraken met deze opdrachtgever en staan hier niet.