How to Design GDPR-Compliant Healthcare Video Architecture

GDPR compliance in healthcare video is one of those problems that looks manageable from a distance and reveals its depth only once you’re inside it. A general understanding of data protection principles — consent, minimization, right to erasure — doesn’t translate directly into architecture decisions. The question isn’t whether you understand GDPR. It’s whether your signaling server, your TURN relay, your media storage pipeline, and your subprocessor chain are actually structured to satisfy it.

European healthcare adds another layer. Video consultations in Germany, France, the Netherlands, or the Nordic countries often touch national health insurance frameworks, sector-specific regulations layered on top of GDPR, and certification requirements — KBV in Germany, HDS in France, NEN 7510 in the Netherlands — that have specific technical mandates GDPR alone doesn’t prescribe.

This guide is for engineering teams building video infrastructure that must operate compliantly in the European healthcare market. We cover the specific architectural decisions that determine your compliance posture: data flows, encryption, subprocessor management, retention, the right to erasure, and the special category data treatment that health information requires.

Why Healthcare Video Is a Special Category Problem

GDPR draws a hard line around special category data. Article 9 identifies health data — information relating to the physical or mental health of a natural person — as requiring explicit consent or a specific legal basis, stricter processing controls, and heightened security measures. Video consultations are almost always special category processing.

This matters architecturally because special category data treatment isn’t just about the content of the video. It extends to:

• Metadata — the fact that a specific patient connected to a specific practitioner at a specific time is itself health-adjacent data, even without the video content
• Participant identity — linking video session identifiers to patient records
• Technical logs — server logs that record IP addresses, device identifiers, and session timing for video calls between identified healthcare participants
• AI-processed derivatives — transcripts, clinical note drafts, sentiment analysis outputs generated from the session

Teams that secure the video content but leave session metadata in standard application logs with a 90-day retention policy have not solved the GDPR problem. They’ve just solved the obvious half of it.

Architecture Decision 1: Mapping Every Data Flow Before Writing Code

The single most important compliance activity for a healthcare video platform isn’t a technical implementation — it’s a data flow map. Article 30 of GDPR requires a Record of Processing Activities (ROPA), and building one forces you to answer questions that have direct architectural consequences.

Every data flow in your video system needs to answer:

• What data is processed (including metadata and derived data, not just media content)?
• What is the legal basis for processing it (consent, contract, vital interests, legitimate interests)?
• Where is it processed geographically?
• Which third-party subprocessors handle it?
• How long is it retained?
• What mechanism enforces deletion at the end of a retention period?

Typical data flows in a healthcare video platform:

Building this map before development starts surfaces decisions that would otherwise appear mid-build as surprises: that your chosen TURN provider stores relay logs in the US, that your logging infrastructure has no deletion mechanism, that you’ve assumed consent as a legal basis for metadata processing without a mechanism to capture or withdraw it.

Architecture Decision 2: Data Residency That Is Actually Enforceable

GDPR’s international transfer rules (Chapter V) require that personal data transferred outside the EEA is protected by adequate safeguards — adequacy decisions, Standard Contractual Clauses (SCCs), or Binding Corporate Rules. For healthcare data, the practical requirement is almost always to keep data within the EEA, because the data sensitivity makes international transfer risk assessment difficult to defend.

The residency requirement is harder to satisfy than it appears for video infrastructure specifically:

Every component in the media path needs to be in-region — not just your application servers. The failure modes are:

• TURN servers located outside the EEA. TURN servers relay actual media packets when direct connections fail. If your TURN servers are in Virginia or Singapore, healthcare video data transits those jurisdictions. TURN infrastructure must be deployed in EEA data centers, ideally with geographic affinity to your user base (Frankfurt or Amsterdam for Central Europe, Dublin for Western Europe, Stockholm for the Nordic).
• CDN edge nodes serving recorded video from non-EEA points of presence. Major CDN providers have EEA-only distribution options, but they are not the default — you must explicitly configure geographic restrictions.
• Managed SFU providers with global infrastructure. If you use a managed SFU service, verify that it supports EEA-only media routing, not just that its headquarters are in Europe. Some providers offer region-pinning; others route to the lowest-latency server globally by default.
• AI processing endpoints for transcription or clinical note generation. OpenAI, AWS, Google, and Azure all have EEA regions for their AI services, but the default endpoint in most SDKs is not region-specific. Explicitly configure regional endpoints and verify that model training doesn’t use your healthcare data.
• Subprocessor chains of subprocessors. Your SFU provider may use a cloud provider that uses a CDN provider. Article 28 requires you to have DPAs with direct processors, but you are responsible for ensuring the entire chain is compliant. Ask every vendor for their subprocessor list and update your ROPA when it changes.

What enforces residency in practice:

Infrastructure-as-code with explicit region constraints (Terraform with provider-level region locks) is the most reliable mechanism. Periodic automated audits that query your infrastructure inventory and flag any resources outside approved regions catch drift. Contractual guarantees without technical enforcement are necessary but not sufficient.

Architecture Decision 3: Encryption Architecture for Special Category Data

GDPR Article 32 requires “appropriate technical measures,” including encryption. For health data, the bar for “appropriate” is higher than for general personal data, and the encryption architecture needs to be documented as part of your security measures.

Minimum encryption requirements for healthcare video:

• In transit: TLS 1.2 minimum on all signaling channels; DTLS 1.2 with SRTP for media streams (WebRTC default). TLS 1.0 and 1.1 must be disabled — document this explicitly.
• At rest: AES-256 for stored recordings and clinical data. Database encryption for session metadata and logs. Key management via a dedicated KMS (AWS KMS, Google Cloud KMS, Azure Key Vault) with EEA key storage.
• End-to-end: For maximum protection, SFU in packet-forwarding mode (not decrypting media). Where server-side media access is required (recording, AI processing), document the processing under explicit consent with a DPA covering the server-side processor.

Key management is where implementations fail:

Encrypting data is straightforward. Managing keys over time — rotation, revocation, per-patient key scoping, deletion — is where compliance gets real. If you encrypt a patient’s video recordings with a single platform-wide key and then need to fulfill a right to erasure request, you cannot cryptographically erase that patient’s data without decrypting and re-encrypting everything. Per-patient or per-session key scoping solves this: deletion of a patient record means deletion of their encryption key, rendering their data cryptographically inaccessible without physically deleting every byte.

This architecture decision — per-patient key scoping — is worth making at the beginning of the project. It is expensive to retrofit.

Architecture Decision 4: Right to Erasure in a Video System

Article 17 of GDPR gives data subjects the right to erasure. In a video system handling special category health data, this right is near-absolute — the legitimate interests and legal obligation exemptions that apply to other data types have limited scope for health video.

What erasure actually requires in a video platform:

• Video recordings were deleted from primary storage.
• Recordings deleted from backup storage (or backup cycles documented with a maximum lag period)
• Session metadata (participant identifiers, timestamps, connection logs) deleted or anonymized.
• AI-derived data (transcripts, clinical note drafts) deleted
• Downstream system data (EHR entries generated from the session) is handled per EHR DPA.
• Deletion confirmed with a cryptographically signed audit record (you need to prove deletion happened, even after the data is gone)

The backup problem is where most teams have a gap. Nightly backups that are retained for 30 days mean deleted data persists in backup storage for up to 30 days after erasure. This must be documented in your privacy notice with a stated maximum lag, and the backup system must support targeted erasure or key-based cryptographic erasure.

Implementation pattern that works:

Maintain a deletion request queue with a scheduled job that processes deletions across primary storage, associated metadata, derived data stores, and CDN caches. Generate a signed deletion confirmation record (timestamp, data subject ID, scope of deletion, executing process identifier) stored in append-only audit storage. This confirmation record is not personal data — it’s a compliance artifact — and can be retained indefinitely.

Architecture Decision 5: Consent Management for Video Sessions

GDPR consent for healthcare video has specific requirements: it must be freely given, specific, informed, and unambiguous. In a healthcare context, consent for a video consultation and consent for recording are separate and must not be bundled.

What consent management requires technically:

• Explicit recording consent is captured before the session begins, not buried in the terms of service.
• Consent stored with a timestamp and the exact consent text version that was presented
• Ability to withdraw consent mid-session with immediate effect on recording
• Recording stops and is deleted (or segregated pending deletion) if consent is withdrawn.
• Consent records are retained as legal evidence for the duration of any applicable limitation period.

Consent for AI processing is an additional gate. If you use AI transcription or note generation, this is a separate processing purpose that requires separate consent — you cannot infer consent to AI processing from consent to the video call itself.

The UI/UX of consent is an architectural concern: a consent flow that users click through without reading is not valid GDPR consent. Courts and regulators have found consent invalid where the mechanism made refusal materially harder than acceptance. Consent must be as easy to refuse as to give, and the consequence of refusal (no recording; no AI features; but the consultation proceeds) must be stated.

Jurisdiction-Specific Layers on Top of GDPR

GDPR is the floor, not the ceiling. European healthcare jurisdictions add sector-specific requirements:

Germany and France, in particular, have certification requirements that go beyond documentation — they require technical audits of your infrastructure. If you’re targeting these markets, map the certification requirements before finalizing your infrastructure choices, not after.

The Compliance Architecture Checklist

Before shipping a European healthcare video platform:

• Data flow map completed and ROPA documented for all processing activities.
• All infrastructure components (TURN, SFU, storage, AI endpoints) verified in EEA regions.
• DPAs are in place with every subprocessor, including subprocessor lists reviewed.
• TLS 1.2+ enforced on signaling; TLS 1.0/1.1 disabled and documented.
• AES-256 at rest with EEA key management; per-patient key scoping implemented.
• Consent flows for recording and AI processing are separate and documented.
• Right to erasure pipeline implemented with signed deletion confirmation records.
• Backup deletion lag is documented, and the maximum lag is stated in the privacy notice.
• Jurisdiction-specific certifications identified and timeline assessed.
• Legal basis documented for every data flow in the ROPA.

Building This the Right Way

GDPR-compliant healthcare video architecture isn’t a compliance project bolted onto an engineering project. It’s an engineering project where compliance constraints shape architecture decisions from day one — data residency affects infrastructure choices, key management affects the data model, consent management affects the session flow, and right to erasure affects backup architecture.

Teams that treat compliance as a final review before launch consistently find that the review surfaces architectural decisions that are expensive to change. Teams that build compliance into the architecture from the start find that most of the requirements are straightforward to satisfy — they just need to be considered at the right time.

Trembit designs and builds GDPR-compliant healthcare video infrastructure for European markets, including platforms targeting KBV certification in Germany and HDS in France. We’ve navigated the full stack — TURN infrastructure, SFU configuration, encryption key management, consent flows, and subprocessor DPA chains — in production healthcare environments. If you’re architecting a European healthcare video platform or need a compliance gap assessment on an existing system, we’re the right team to talk to.

Compliance built in from the start is always cheaper than compliance retrofitted under regulatory pressure.