Building a Telemedicine Platform Under GDPR

What Makes Healthcare Software Different

Building a telemedicine platform is not an ordinary software project. It looks like one at the start: a web application, video calls, a scheduling system, user accounts. Then you encounter GDPR, medical device regulation, patient consent frameworks, and data retention policies, and you realise that the compliance layer is as complex as the application itself.

This article walks through the architecture and compliance decisions involved in building a telemedicine platform for the EU market. It is based on our experience building WeTalk, a telemedicine platform for virtual therapy and consultations, and on the lessons we learned about what healthcare software requires beyond standard web application development.

A standard SaaS application handles user data under GDPR's general provisions. A healthcare application handles special category data under GDPR Article 9, which imposes stricter requirements for processing, storage, consent, and breach notification. The practical implications touch every layer of the system.

Data classification changes everything

Patient health data is classified as special category data under GDPR. This means:

Processing requires explicit consent or another Article 9 legal basis (not just legitimate interest)
The data protection impact assessment (DPIA) is mandatory, not optional
Breach notification to the supervisory authority must happen within 72 hours
The right to erasure applies, but conflicts with medical record retention requirements
Data minimisation must be demonstrable: you collect only what is necessary for the specific medical purpose

For developers, this translates to: every database field that stores patient information needs a documented purpose, a defined retention period, and a mechanism for deletion or anonymisation when the retention period expires. This is not a feature you add at the end; it is a schema design decision you make at the start.

Video consultations add real-time complexity

Telemedicine platforms live or die on video quality. A therapy session interrupted by buffering, or a consultation where the practitioner cannot see the patient clearly, is not just a bad user experience; it is a clinical risk. At the same time, the video stream contains medical information (the consultation itself is health data), which means the real-time communication layer must be encrypted end to end.

The architecture challenge: deliver low-latency, high-quality video while maintaining encryption and logging metadata (who connected, when, for how long) without recording the actual consultation content unless the patient explicitly consents.

Architecture Decisions for a GDPR-Compliant Telemedicine Platform

1. Data residency and infrastructure placement

GDPR does not require that data stays in the EU, but it requires adequate protection when data leaves the EU. For healthcare data, the practical reality is simpler: keep it in the EU. Most healthcare regulators, insurance frameworks, and enterprise clients expect EU data residency as a baseline.

For WeTalk, we deployed on AWS with the Frankfurt (eu-central-1) region as primary. All patient data, consultation metadata, user accounts, and media files reside within EU boundaries. The infrastructure-as-code setup enforces this: there is no configuration option that allows data to be stored outside the designated region.

This decision has operational implications: CDN configuration must respect residency boundaries, backup replication stays within EU regions, and any third-party services must either process data within the EU or receive only anonymised data.

2. Consent management as a first-class system

Consent in a telemedicine platform is not a single checkbox. A patient may consent to:

Creating an account and storing basic profile data
Sharing health information with a specific practitioner
Recording a video consultation for review purposes
Receiving follow-up communications via email or SMS
Sharing anonymised data for research purposes

Each consent is independent, revocable, and must be logged with a timestamp and the specific version of the consent text the patient agreed to. When a patient withdraws consent for a specific purpose, the system must stop processing data for that purpose while continuing to process data under other valid consents.

We built WeTalk's consent management as a standalone service within the backend: a Symfony module that every other service queries before accessing patient data. The consent service answers one question: does this patient currently consent to this specific data processing purpose? Every data access path in the application checks consent before returning results. This is enforcement by design, not by policy.

3. Video consultation architecture

The video layer is the most technically demanding component. The requirements:

End-to-end encryption between patient and practitioner browsers
Low latency (under 200ms for real-time conversation)
Graceful degradation on poor connections (adaptive bitrate, audio priority over video)
No server-side recording unless explicitly consented and separately encrypted
Session metadata logging (start time, end time, participants) without content capture

We used WebRTC for peer-to-peer video with a TURN server for NAT traversal. The signalling server handles session setup and teardown. The media stream itself never touches our servers in the default configuration; it flows directly between the two browsers. When recording is consented, the stream is captured client-side and uploaded encrypted to a dedicated storage bucket with a separate access policy.

The fallback architecture matters: when peer-to-peer fails (corporate firewalls, restrictive networks), the TURN server relays traffic. In relay mode, the server sees encrypted media packets but cannot decrypt them. This is by design: even in the worst-case network scenario, the server never has access to unencrypted consultation content.

4. Authentication and session security

Healthcare platforms require stronger authentication than standard web applications. Practitioners access sensitive patient data; patients access their own medical records. Both need secure access patterns.

Practitioner authentication: SSO integration with the clinic's identity provider where available, MFA enforced for direct login
Patient authentication: email-based magic links for initial access, with optional MFA for returning patients
Session management: automatic timeout after inactivity, re-authentication required for sensitive actions
Audit logging: every access to patient data is logged with user identity, timestamp, data accessed, and purpose

The audit log is immutable: once written, entries cannot be modified or deleted. This is a regulatory expectation. If a data protection authority requests evidence of who accessed a specific patient's records, the answer must be complete and trustworthy.

5. Data retention and the right to erasure

Healthcare data retention creates a direct conflict with GDPR's right to erasure. A patient can request deletion of their data, but medical record retention laws in most EU countries require that certain records be kept for 10 to 30 years. The platform must resolve this conflict systematically.

Our approach: separate medical records from account data. When a patient requests account deletion:

Account data (email, name, login history) is deleted or anonymised within 30 days
Medical records are retained for the legally mandated period but decoupled from the deleted account (pseudonymised)
Consultation metadata is retained in anonymised form for compliance and auditing
Video recordings (if any) follow the consent-specific retention policy

This requires a data architecture that cleanly separates identity from clinical content, which is another decision that must be made at schema design time, not retrofitted later.

Compliance Beyond GDPR

GDPR is the foundation, but not the full picture. Depending on the market and the type of telemedicine service, additional requirements may apply:

Medical device regulation (MDR): if the platform includes diagnostic tools, decision support, or triage logic, it may be classified as a medical device under EU MDR
National healthcare regulations: each EU member state has additional rules about telemedicine practice, prescribing via video, cross-border consultations, and insurance reimbursement
ISO 27001 / ISO 13485: many enterprise healthcare clients require these certifications as a procurement condition
Penetration testing: annual penetration testing is a de facto requirement for healthcare platforms

What It Costs and How Long It Takes

A GDPR-compliant telemedicine platform with video consultations, patient management, practitioner portals, and subscription billing is a substantial build:

Discovery, compliance review, and architecture: 8 to 10 weeks
Core platform build: 8 to 12 months
Team: 3 to 5 developers, PM, QA, part-time security specialist
Compliance audits and penetration testing: 15,000 to 30,000 EUR (annually recurring)
Total build cost (EU nearshore): 450,000 to 750,000 EUR
Annual ongoing: 80,000 to 150,000 EUR for maintenance, security patches, and compliance updates

The compliance work alone (DPIA, consent management, audit logging, data retention logic, penetration testing) represents roughly 20 to 25 percent of the total development effort. This is the part that most proposals underestimate, and the part that regulators will examine first if something goes wrong.

The Bottom Line

Building a telemedicine platform under GDPR is not a standard web development project with a compliance layer bolted on top. It is a project where compliance decisions shape the architecture from day one: the database schema, the consent model, the video infrastructure, the authentication patterns, and the data retention logic.

The vendors who do this well are the ones who have built healthcare software before and understand that a technically excellent application with inadequate compliance is a liability, not an asset. If you are evaluating partners for a telemedicine project, the most important question is not whether they can build a video calling feature. It is whether they understand what Article 9 means for every data access path in the system.