Design of a Secure Wearable Health Data Sharing Platform for Region Hovedstaden: A FHIR DK and GDPR-Compliant Service Architecture

This paper proposes a GDPR-compliant, FHIR DK-standardized microservice architecture for Region Hovedstaden to securely integrate continuous wearable health data into the national electronic health record, addressing interoperability gaps and building on stakeholder-identified trust factors to enable safe data sharing.

The Gist

Imagine you have a smartwatch, a fitness ring, or a heart monitor that tracks your health 24/7. It knows your heart rate, how well you sleep, and how much you move. Now, imagine that your doctor in Copenhagen could see this data instantly to help you stay healthy, rather than you having to write it down in a notebook or print out a chart.

That is the dream. But right now, in Denmark's Capital Region (Region Hovedstaden), there is a broken bridge between your watch and your doctor's computer.

This paper proposes building a new, super-secure bridge to fix that problem. Here is the breakdown in simple terms:

1. The Problem: The "Language Barrier" and the "Locked Door"

Right now, three big things are stopping this data from flowing:

• The Language Barrier: Your watch speaks "Apple" or "Google," but the Danish national health record (Sundhed.dk) speaks a specific technical language called FHIR. They don't understand each other. It's like trying to order coffee in English at a shop that only speaks Danish.
• The Locked Door: There is no safe way for you to prove who you are using your Danish digital ID (MitID) to let the data through. Currently, your health data is stuck inside your phone's "walled garden."
• The Trust Issue: People are scared. They worry, "If I share my heart rate, will my insurance company see it? Will my boss see it?" Without a clear way to say "Yes, but only for this doctor, and only for this week," people won't share.

2. The Solution: A "Smart Post Office"

The authors designed a five-layer digital system that acts like a highly secure, automated post office for your health data.

Think of it like this:

• Layer 1 (The Mailbox): Your wearable device drops the data into a secure mailbox.
• Layer 2 (The ID Check): Before the mail moves, a robot checks your MitID (your digital ID) to make sure it's really you.
• Layer 3 (The Translator): The system instantly translates your watch's data into the official Danish medical language (FHIR) so the hospital computers can read it.
• Layer 4 (The Security Guard): This is the most important part. A "Zero Trust" security guard checks your consent. Did you say "Yes" to sharing this specific data with this specific doctor? If you didn't, the guard stops the mail.
• Layer 5 (The Delivery): The data is delivered to the doctor's screen, and a permanent, unchangeable receipt is printed showing exactly what happened.

3. The "Trust" Secret Sauce

The researchers didn't just guess what people wanted; they asked 47 people in Denmark.

• The Finding: People aren't afraid of sharing health data; they are afraid of losing control.
• The Result: 51% of people said they would share their data if they knew it was secure.
• The Key: The study found that transparency is everything. People want to see a "logbook" (audit trail) that shows exactly who looked at their data and when. If you can see the logbook, you trust the system.

4. How It Works in Real Life

Here is a story of how this new system would work:

1. You wake up and your smart ring measures your sleep.
2. You open an app, log in with your MitID, and say, "I want to share my sleep data with Dr. Hansen at Rigshospitalet for the next 3 months."
3. The System locks that permission in a digital vault.
4. The Data flows automatically, translated into the right format, and lands in Dr. Hansen's system.
5. Dr. Hansen sees your sleep patterns and notices you've been sleeping poorly, so he calls you to adjust your medication.
6. You can log in anytime to see a list of who accessed your data. If you change your mind, you hit a button, and the data stops flowing immediately.

5. Why This Matters

This isn't just about cool technology; it's about saving lives and money.

• If doctors can see this data, they can catch problems early (like a heart issue) before you end up in the emergency room.
• The paper suggests this could reduce hospital readmissions by 38%.
• It respects Danish privacy laws (GDPR) by building "privacy" into the bricks of the building, not just painting it on the walls.

The Bottom Line

The authors have drawn up a blueprint for a system that connects your wearable tech to the Danish healthcare system. It uses strict security, clear rules for sharing, and a "digital receipt" system so you always know who saw your data.

It's a plan to turn your smartwatch from a simple gadget into a life-saving tool, provided we build the bridge with trust as the foundation. The next step is to actually build a small version of this and test it in a real hospital.

Technical Summary

1. Problem Statement

The paper addresses a critical interoperability gap in Region Hovedstaden (Denmark's Capital Region), where 1.8 million residents lack a secure, standardized pathway to integrate continuous wearable health data (e.g., from Apple Watch, Oura Ring, Garmin) into Sundhed.dk, the national electronic health record (EHR).

Three primary structural barriers prevent this integration:

• Lack of Standardization: Sundhed.dk currently lacks dedicated FHIR DK v6.0.2 profiles for continuous Patient-Generated Health Data (PGHD).
• Authentication Barriers: There is no pathway for Danish patients to authenticate via MitID (the national digital ID) to share data, leaving consumer health ecosystems (Apple HealthKit, Google Fit) locked in proprietary silos incompatible with the National Service Infrastructure (NSI).
• Regulatory Non-Compliance: Existing solutions fail to meet Datatilsynet's (Danish Data Protection Authority) strict requirements for GDPR Article 25 (Privacy by Design), specifically regarding granular consent, data minimization, and patient-visible audit trails.

2. Methodology

The research follows Aalborg University's Problem-Based Learning (PBL) methodology, utilizing a mixed-methods approach to derive requirements and design the architecture:

• Systematic Literature Review: Analyzed Danish regulatory documents (Sundhed.dk, NSI v3.2, MitID guidelines) and GDPR enforcement cases.
• Platform Benchmarking: Evaluated four existing platforms (Sundhed.dk, Apple HealthKit, Google Fit, Epic MyChart) against four criteria: FHIR DK support, MitID/NSI integration, consent granularity, and clinical workflow feasibility.
• Stakeholder Surveys: Conducted surveys with 47 verified Danish stakeholders (patients, clinicians, and experts) to identify trust factors and adoption barriers. Data quality was ensured by filtering out automated responses.
• Requirements Engineering: Prioritized 14 requirements using the MoSCoW method (Must, Should, Could, Won't) and mapped them to architecture components via a traceability matrix.

3. Key Contributions

The paper proposes a conceptual five-layer microservice architecture designed to bridge the gap between consumer wearables and Danish public healthcare.

A. The Five-Layer Architecture

1. Device Layer: Handles IoT gateways and adapters (BLE/MQTT 5.0) to normalize raw sensor data.
2. API Gateway: Manages MitID/OIDC authentication, FHIR API routing, and consent middleware (using Kong, OAuth 2.1).
3. Business Logic Layer: Contains the Consent Service, Access Control, and Audit Service (Node.js, Kafka Streams) to enforce logic before data processing.
4. Data Layer: Stores data in a FHIR Repository (MongoDB/PostgreSQL) and immutable audit logs (ClickHouse), ensuring compliance with FHIR DK v6.0.2.
5. Presentation Layer: Provides a Patient Portal and Clinician Dashboard (React.js) for data visualization and consent management.

B. Core Technical Principles

• Zero Trust Security: Enforces mutual TLS (mTLS) across all internal service boundaries and re-validates consent for every sensitive read/write operation.
• Event-Driven Integration: Uses Apache Kafka to decouple wearable data ingestion from downstream clinical processing.
• Privacy by Design: Embeds GDPR Article 25 controls directly into the infrastructure, ensuring data minimization and immediate auditability.

C. Requirements Specification

The authors defined 14 prioritized requirements:

• Must-Have (Functional): Secure MitID authentication (F1), granular/revocable consent (F2), FHIR DK import/export (F3).
• Must-Have (Non-Functional): TLS 1.3/AES-256 encryption (NF1), <3s API response time (NF2), 99.9% availability (NF4), and automated DPIA documentation generation (NF6).

4. Results

• Platform Benchmarking: No existing platform satisfied all Danish criteria. Sundhed.dk scored 7.2/10 (lacking wearable profiles), while Epic MyChart scored 8.1/10 (lacking Danish governance alignment).
• Stakeholder Willingness:
  • 51.1% of respondents expressed willingness to share wearable data under secure conditions.
  • 38.3% were conditionally willing, citing audit transparency and control over data access as prerequisites.
  • 80.9% believed such a platform would improve healthcare quality.
• Trust Factors: The primary concerns were non-medical misuse (59.6%, e.g., by insurers/employers) and lack of control (55.3%). This validated the design focus on granular consent (F2) and patient-visible audit logs (F4).
• Adoption Drivers: The study concluded that citizens are not opposed to data sharing but are opposed to sharing without trust mechanisms.

5. Significance and Future Work

• Interoperability Blueprint: The paper provides a traceable, standards-aligned design blueprint for closing the interoperability gap in Danish public healthcare, specifically for Region Hovedstaden.
• Regulatory Alignment: It demonstrates a practical implementation of GDPR Article 25, moving privacy from a theoretical compliance formality to an operational infrastructure requirement.
• Strategic Impact: The architecture supports Denmark's Digital Health Strategy 2025–2028 by enabling remote patient monitoring, which literature suggests could reduce hospital readmissions by ~38%.
• Limitations & Next Steps: The current architecture is conceptual. Future work involves a constrained pilot at Rigshospitalet or Amager Hvidovre Hospital to validate non-functional requirements (latency, scalability) and refine FHIR DK profiles for continuous Observation types (heart rate, sleep, activity).

In summary, this paper offers a comprehensive, GDPR-compliant technical framework to unlock the clinical value of wearable data in Denmark, prioritizing trust, transparency, and standards-based interoperability over raw data collection.