Een digitale gezondheidsapp bouwen in 2026 lijkt niet meer op wat infrastructuurarchitecten vijf jaar geleden kenden. Variabele infrastructuurkosten, Europese en Arabische regelgeving, druk op een korte time-to-market en de noodzaak om in meerdere jurisdicties te werken, maken ontwerpkeuzes vanaf maand een cruciaal. Voor DossiMed kozen we een volledig serverless-architectuur rond drie technische pijlers. Dit artikel legt die keuzes en hun praktische gevolgen uit, zonder interne configuratiedetails vrij te geven.
Waarom serverless in digitale gezondheid
Het meest zichtbare argument voor serverless is financieel: je betaalt alleen wat je echt verbruikt. Voor een zorgplatform met ochtendpieken (innamemeldingen) en avondpieken (dossierinzage), en bijna geen nachtverkeer, sluit dit model rechtstreeks aan op het gebruikspatroon. Infrastructuur die 24/7 op piekbelasting is afgestemd, verspilt structureel middelen.
Maar de diepere reden ligt elders.
Serverless dwingt een strikte scheiding af tussen gevoelige bedrijfslogica en de client. Als zorgsoftwareleverancier kun je niet toestaan dat een gecompromitteerde mobiele client toegang krijgt tot secrets, externe API-sleutels of de volledige database. Serverless maakt die grens natuurlijk: de client roept gehoste functies aan en ziet alleen het resultaat. Secrets blijven per ontwerp aan de serverzijde.
Het derde argument is time-to-market. Een nieuwe functionaliteit uitrollen betekent een kleine stateless functie deployen, niet een Kubernetes-cluster herwerken. Voor een healthtech-startup die snel product-market fit moet vinden, is dat doorslaggevend.
Pijler 1 - De database als eerste beveiligingslaag
De meest voorkomende fout in zorgprojecten is data alleen op applicatieniveau beveiligen. Applicatiecode controleert of gebruiker A document B mag lezen, en men hoopt dat geen vergeten pad die controle omzeilt. Dat is onvoldoende. Een enkele endpoint zonder autorisatiecheck kan alle dossiers blootleggen.
Onze keuze: toegangsbeveiliging direct in de database-engine plaatsen, via PostgreSQL Row Level Security (RLS). Concreet wordt elke business-tabel beschermd door een policy die automatisch bij elke query wordt afgedwongen, dieper dan applicatielogica. De regel is eenvoudig: een gebruiker kan alleen rijen lezen of wijzigen die van hem zijn. De database handhaaft dit, niet de app.
De praktische impact is groot. Als een ontwikkelaar morgen een functie toevoegt die data opvraagt zonder identiteit te valideren, blokkeert de database nog steeds rijen die niet bij die gebruiker horen. Beveiliging hangt dan niet meer af van geheugen of code review.
Waarom RLS het verschil maakt
- Bescherming blijft gelden, ook als een functie zonder autorisatiecontrole wordt blootgesteld
- Nieuwe ontwikkelaars erven SQL-guardrails in plaats van kwetsbare app-conventies
- Het patroon overleeft teamwissels en houdt stand bij security-audits
- Sinds PostgreSQL 9.5 standaard beschikbaar, maar nog onderbenut in zorgomgevingen
Pijler 2 - Edge functions als laag voor gevoelige logica
Alle logica die secrets vereist, leeft in serverless edge functions in TypeScript. Geen enkele sleutel komt op het toestel van de gebruiker terecht. De mobiele client ziet alleen HTTP-endpoints die een geldige gebruikers-JWT vereisen.
Edge functions dekken alle gevoelige processen:
- OCR en gestructureerde extractie van medische documenten
- Generatie van behandelplan
- Verzenden van herinneringen via notificaties
- Escalatie naar conversatiekanalen (WhatsApp, spraak)
- Validatie van externe webhooks en cryptografische handtekeningen
- Afhandeling van in-app aankopen
- Volledige accountverwijdering (AVG recht op vergetelheid)
- Genereren van tijdelijke deel-links voor artsen
Deze scheiding heeft twee grote voordelen. Ten eerste wordt secret-rotatie eenvoudig: wanneer een provider een API-key roteert, update je een environment variable in de edge runtime - zonder client-update of app-store release.
Ten tweede worden security-audits gerichter. Het gevoelige oppervlak blijft klein, traceerbaar en geïsoleerd. Auditors hoeven één functions/-gebied te bekijken in plaats van tienduizenden regels Flutter- en webcode.
Pijler 3 - Private storage met cryptografisch begrensde toegang
Afbeeldingen van medische documenten en bijlagen worden opgeslagen in private buckets zonder publieke URL's. Toegang verloopt uitsluitend via kortlevende signed URLs die server-side on demand worden gegenereerd.
Ook de padconventie voorkomt laterale datalekken: elke resource start met de eigenaar-gebruikers-ID. Gecombineerd met storage policies zorgt dit ervoor dat gebruikers per ontwerp alleen in hun eigen namespace kunnen lezen en schrijven.
Voor artsen die gedeelde dossiers openen is de flow anders: zij gebruiken een link met een tijdelijk token. De server valideert de token-hash, past patiëntbeperkingen toe (documentcategorie, periode, specialisme), genereert tijdelijke signed URLs en rendert de pagina. De arts ziet nooit permanente bestands-URL's.
Hosting in een passende jurisdictie
De primaire server van DossiMed draait in Zwitserland (regio Centraal-Europa). Deze keuze dekt meerdere eisen tegelijk.
EU-adequacy. Zwitserland heeft een adequaatheidsbesluit van de Europese Commissie onder artikel 45 AVG. Datatransfers vanuit de EU naar Zwitserland vragen daardoor geen extra contractmechanismen - in tegenstelling tot veel VS-regio's sinds Schrems II.
Afstemming met nFADP. De vernieuwde Zwitserse privacywet is sterk afgestemd op de AVG. Een AVG-conform platform sluit dus ook aan bij nFADP-eisen.
Geografisch optimum MENA + Europa. De latency vanuit Zurich naar Frankrijk, Belgie, Duitsland, Italie, Noord-Afrika en het Midden-Oosten is sterk. Voor meertalige Europa+MENA-uitrol is dit een praktisch middenpunt.
De architectuur is bewust portable. Edge functions draaien op standaard Deno, de database is PostgreSQL en storage is S3-compatibel. Migreren naar een andere regio of provider vraagt uren configuratie en dagen testwerk, geen volledige herschrijving.
De asynchrone pipeline
OCR plus gestructureerde extractie duurt meestal enkele seconden tot een minuut. Een geblokkeerd scherm tijdens wachten is onaanvaardbaar voor de gebruikerservaring.
Ons patroon werkt in drie stappen:
- De mobiele client uploadt het beeld en schrijft een rij met status pending
- De client abonneert zich realtime op mutaties van die rij
- De edge function draait op de achtergrond, schrijft gestructureerd resultaat en zet status op processed - waarna de client meteen update krijgt
Dit PostgreSQL+realtime patroon voelt direct aan, terwijl de verwerking asynchroon blijft. Het vermijdt long polling, custom websockets en complexe gedistribueerde state.
Meertaligheid als infrastructuurkeuze
Meertaligheid in zorgapps wordt vaak beperkt tot UI-vertaling. Dat is onvoldoende voor Europa- en MENA-markten, waar taal direct vertrouwen beinvloedt.
DossiMed behandelt meertaligheid als een architecturale parameter. Uitgaande communicatie - pushmeldingen, WhatsApp-berichten en voice scripts - wordt in de engine gelokaliseerd, niet in clientcode. Voorkeurstaal staat in de database en wordt gebruikt door edge functions die template, TTS-stem en schrijfrichting kiezen. Document-AI verwerkt Arabisch, Frans, Engels en regionale varianten.
Zo krijgt een Arabischtalige gebruiker een herinnering in de moedertaal via een systeem dat meertalig is ontworpen vanaf de basis.
Compliance by design
Europese regelgeving rond gezondheidsdata legt rechten en plichten op die veel teams te laat implementeren. Ze vanaf de ontwerpfase meenemen is veel goedkoper.
Onze compliance-discipline steunt op enkele eenvoudige regels:
- Elke business-tabel bevat minimale traceerbaarheid (user ID, created/updated timestamps)
- Gebruikersverwijdering triggert volledige cascade naar child-tabellen
- Storage buckets volgen dezelfde ownership-per-user conventie
- Volledige data-export per gebruiker is JSON per tabel plus bestandsinventaris
Deze discipline was geen reactie op een audit, maar een ontwerpprincipe vanaf dag één - waarschijnlijk een van de beste investeringen in het project.
Wat een volwassen architectuur toont aan kopers
Voor technische teams die een zorgplatform evalueren voor integratie of overname, tellen sommige signalen meer dan UI-demo's:
- Kwaliteit en consistentie van SQL-migraties
- Volledige RLS-dekking op business-tabellen
- Strikte client/server-scheiding zonder exposed secrets
- Portabiliteit naar elke doelregio
- Afwezigheid van historische technische schuldpatronen
Deze elementen tonen het werk van een team dat met discipline heeft gebouwd.
Een meertalige, AVG-conforme serverless architectuur in een passende jurisdictie, die in uren naar elke doelregio kan worden uitgerold, is geen abstract technisch argument. Het is een belofte van operationele vrijheid voor wie haar overneemt.
DossiMed wordt uitgegeven door REC, een volledig exportgerichte Tunesische eenpersoonsvennootschap. Het platform is gehost in jurisdicties die als adequaat gelden onder artikel 45 AVG. Voor commerciele of strategische partnerschappen: contact@dossimed.ai.