Serverless architecture for digital health: infrastructure choices that matter

Building a digital health application in 2026 no longer looks like what infrastructure architects knew five years ago. Variable infrastructure costs, European and Arab regulatory requirements, pressure for short time-to-market, and the need to operate across multiple jurisdictions all force design decisions that carry weight from month one. For DossiMed, we chose a fully serverless architecture structured around three technical pillars. This article explains those choices and their practical consequences, without exposing internal configuration details.

Why serverless in digital health

The most visible serverless argument is financial: you only pay for what is actually consumed. For a health platform with morning peaks (medication reminders) and evening peaks (record consultation), plus near-empty traffic overnight, this model aligns directly with usage curves. An infrastructure provisioned for peak load 24/7 is structurally wasteful.

But the deeper reason is elsewhere.

The third argument is time-to-market. Shipping a feature means deploying a small stateless function, not reworking a Kubernetes cluster. For a health startup that must reach product-market fit before runway pressure, this is decisive.

Pillar 1 - Database as the first security layer

The most common mistake in health projects is protecting data at the application layer only. App code checks whether user A can read document B, and teams hope no forgotten path bypasses controls. That is not enough. A single endpoint without authorization checks can expose every user record.

Our choice: place access security directly in the database engine, via PostgreSQL Row Level Security (RLS). In practice, each business table is protected by a policy automatically executed on every query, deeper than any app-layer logic. The rule is simple: a user can only read or modify rows they own. The database enforces this rule, not the app.

The practical impact is dramatic. If a developer introduces a new function tomorrow that queries data without validating caller identity, the database still blocks rows that do not belong to that user. Security no longer depends on developer memory or review quality.

Pillar 2 - Edge functions for sensitive logic

All logic requiring secrets lives in serverless edge functions written in TypeScript. No key ever ships to the end-user phone. The mobile client only sees HTTP entry points requiring a valid user JWT.

Edge functions cover all sensitive workflows:

• OCR and structured extraction of medical documents
• Treatment-plan generation
• Reminder delivery through push notifications
• Escalation to conversational channels (WhatsApp, voice)
• Third-party webhook signature validation
• In-app purchase handling
• Full account deletion (GDPR right to erasure)
• Ephemeral doctor-sharing links

This separation brings two major benefits. First, secret rotation becomes painless: when a provider rotates an API key, we update one environment variable in edge runtime, with no client update and no app-store deployment.

Second, security audits become focused. Sensitive surface area remains small, traceable, and isolated. Buyers or auditors can inspect one functions/ area instead of searching across tens of thousands of Flutter and web lines.

Pillar 3 - Private storage with cryptographically bounded access

Medical document images and patient attachments are stored in private buckets with no public URL exposure. Access is granted only through short-lived signed URLs generated server-side on demand.

Path conventions are also designed to prevent lateral leaks: each asset starts with the owner user ID. Combined with storage policies, this ensures users can only read/write within their own namespace by construction.

For doctors accessing shared records, the flow differs: they open a link containing an ephemeral token. The server verifies the token hash, applies patient-defined restrictions (document categories, period, specialty), generates temporary signed URLs for allowed resources, and renders the page. Doctors never receive persistent file URLs.

Hosting in an adequate jurisdiction

DossiMed's primary server is hosted in Switzerland (Central Europe region). This satisfies several constraints at once.

EU adequacy decision. Switzerland benefits from a European Commission adequacy decision under GDPR Article 45. Transfers from the EU to Switzerland are treated similarly to intra-EU transfers and do not require extra contractual mechanisms - unlike many US regions, which require SCC-heavy workflows since Schrems II.

Alignment with nFADP. Switzerland's revised Federal Data Protection Act (effective September 1, 2023) is broadly aligned with GDPR. A GDPR-compliant platform is also aligned with nFADP expectations.

MENA + Europe geographic optimum. Latency from Zurich to France, Belgium, Germany, Italy, North Africa, and the Middle East remains strong. For multilingual Europe+MENA deployments, this is currently a practical midpoint.

The asynchronous pipeline

OCR and structured extraction of medical files typically takes a few seconds to a minute. Blocking users on a frozen screen is unacceptable.

Our pattern has three steps:

1. The mobile client uploads the image and inserts a row with status pending
2. It subscribes in realtime to mutations on that row
3. The edge function runs in background, writes structured output, and sets status to processed - the client receives the event and updates immediately

This simple PostgreSQL + realtime channel pattern feels instant while staying fully async. It avoids long polling, custom websocket orchestration, and distributed state complexity.

Native multilingual support at infrastructure level

Multilingual support in health apps is often treated as UI-only translation. That is insufficient when targeting Europe and MENA, where language strongly impacts patient trust.

DossiMed treats multilingualism as an architectural parameter. Outbound communications - push notifications, WhatsApp messages, voice scripts - are localized in the engine, not in client code. Preferred language is stored in the database and consumed by edge functions that pick templates, TTS voice, and writing direction. Document AI models process Arabic, French, English, and regional variants.

As a result, an Arabic-speaking user can receive a voice reminder in their native language through a system designed multilingual-first rather than translated afterward.

Compliance by construction

European health-data regulation imposes rights and obligations many teams add too late, usually after audits or legal pressure. Implementing them at design time is far cheaper.

Our compliance discipline follows a few simple rules:

• Every business table includes baseline traceability attributes (user ID, created/updated timestamps)
• User deletion triggers full cascading cleanup across child tables
• Storage buckets follow the same ownership-by-user convention
• Full user data export is straightforward JSON extraction per table plus file inventory

This discipline was not a reaction to audit findings; it was a first-day design principle - likely one of the highest-return decisions in the project.

What mature architecture signals to buyers

For technical teams evaluating a health platform for integration or acquisition, some signals matter more than polished UI demos:

• SQL migration quality and consistency
• Full RLS coverage across business tables
• Strict client/server boundary with no exposed secrets
• Portability to any target region
• Absence of historical technical debt patterns

These elements tell the story of a team that built with discipline.

DossiMed is published by REC, a fully export-oriented Tunisian single-member company. The platform is hosted in jurisdictions considered adequate under GDPR Article 45. For commercial or strategic partnership inquiries, contact contact@dossimed.ai.