This page is part of the HL7 FHIR Implementation Guide: DK Hackathons (v1.0.1: Release) based on FHIR (HL7® FHIR® Standard) R4. This is the current published version. For a full list of available versions, see the Directory of published versions

Track 3: Your Health, Your Data - Building the Personal Health Dataspace

Track lead: Jacob Andersen

Overview

Imagine a health system where the citizen is at the centre — where data follows the person, and where every individual has real control over what is shared, with whom, and for how long.

That future is now encoded in law. The European Health Data Space (EHDS), in force since March 2025, grants every EU citizen the right to access, download, and share their personal electronic health data. It also creates a legal framework for citizens to contribute their data — including patient-generated data (PGHD) from wearables and apps — to research under transparent, revocable consent. The standards are converging. The regulation is in force. What does that actually look like, built in FHIR, running today?

This track invites participants to explore that question by building components of a personal health dataspace: an ecosystem where a citizen's health data — whether sourced from a hospital EHR, a fitness tracker, a blood glucose monitor, or an environmental sensor — can be stored, shared, and optionally donated to research, all under the citizen's own control.

There is no single prescribed task. Participants are free to build whatever component they find most interesting or meaningful. We do, however, encourage participants to communicate their intentions ahead of the hackathon so that components built on the day can potentially be demonstrated together.

---

Goals

This track hopes to demonstrate — at least in prototype form — some of the following propositions:

• A citizen-controlled FHIR-based personal health record is technically feasible using existing open standards and open source tools
• Patient-generated health data (PGHD) from wearables and lifestyle apps can be ingested into a PHR as standard FHIR resources
• Data sourced in a PHR can be shared with a new care provider in a cross-border scenario using FHIR and open identity standards
• Citizen consent for both primary and secondary (research) use of health data can be represented and enforced using FHIR Consent resources and established profiles
• Components built independently by different participants can interoperate, at least at the level of exchanging valid FHIR resources against a shared server

The Shared Platform

---

⚠️ Preliminary section ⚠️

To give participants something to build towards and against, the track will provide a pre-deployed shared FHIR (R4) server running HAPI FHIR, configured with:

• A small set of synthetic test patients (using dk-core Patient profiles)
• SMART on FHIR authorization enabled
• A public read endpoint and authenticated write endpoint

Participants are not required to use this server. Anyone who prefers to run their own FHIR backend (Medplum, another HAPI FHIR instance, Aidbox, etc.) is welcome to do so. The shared server is there to lower the barrier to entry and to enable inter-component demos.

Details of the shared server URL, credentials, and SMART configuration will be shared at the preparatory webinar.

⚠️ Preliminary section ⚠️

---

Component Ideas

The following is an illustrative — not exhaustive — list of components participants could choose to build. They are organized into four groups. Participants are welcome to address problems in any group – or across. Bring-Your-Own-Idea!

Group 1 — Data Sources: Getting data into the PHR

• EHR → PHR connector: A SMART on FHIR client that reads resources from a clinical system exposing an IPA-conformant API and writes them into the shared PHR. A public IPA-conformant sandbox (e.g. Firely Server sandbox or HAPI public test server) can substitute for a real EHR.
• MedCom → PHR adapter: A component that consumes a MedCom FHIR message (e.g. a ConditionList or CareCommunication) and stores the relevant resources in the PHR.
• Apple HealthKit → PHR: An iOS component (Swift) using HealthKitOnFHIR to map HealthKit samples to FHIR Observation resources and POST them to the shared server.
• Google Health Connect → PHR: An Android component using the Health Connect SDK to map exercise, sleep, and vital-sign data to FHIR Observations.
• Withings / Garmin / other wearable → PHR: A backend service (any language) using a device vendor's REST API to pull measurements and convert them to FHIR Observations.
• Environmental data → PHR: A component that pulls open data from DMI's Open Data API (weather, climate) or other indoor or outdoor climate and air quality sources matching the patient's location, and stores values as FHIR Observations in the PHR.

Group 2 — PHR Core: Structuring and validating the dataspace

• IG conformance: Profile and validate PHR resources against the HL7 Personal Health Records IG and/or other key implementation guides (see the list below). Identify gaps, conflicts and challenges.
• IPS generator: A component that queries the shared PHR and produces an International Patient Summary document — the structured cross-border health overview mandated under EHDS priority data categories.
• DK-Core profiling: Extend or validate the PHR content against DK-Core profiles, identifying extension points needed for Danish-specific identifiers (CPR, SKS codes, NPU lab codes).

Group 3 — Identity, Sharing & Consent: Controlling the dataspace

• SMART Health Links issuer: A component that packages selected PHR resources into a SMART Health Link — a secure, time-limited, optionally PIN-protected shareable link or QR code. Demonstrates the cross-border USB-stick scenario: an EU citizen arrives at a Danish GP and presents a QR code containing their IPS.
• FHIR Consent management: A component that records, updates, and evaluates patient consent using the FHIR Consent resource, profiled according to IHE Privacy Consent on FHIR (PCF). The consent should distinguish between clinical use (primary) and research use (secondary).
• EU Digital Wallet integration: An experimental component exploring how the EUDI Wallet (EU Digital Identity Wallet reference implementation) can be used as the identity and authorization layer for a PHR SMART on FHIR flow.

Group 4 — Secondary Use: Donating data for research

• Data donation flow: A component that allows a citizen to select a subset of their PHR data (e.g. six months of Observations from a wearable) and donate it to a research cohort, with a FHIR Consent resource recording the donation decision. Data For Good Foundation is an example of a platform that could be a recipient.
• Consent management service: An integration with gICS (generic Informed Consent Service, open source, FHIR-enabled), demonstrating how a research-grade consent management tool connects to a citizen-controlled PHR.
• Research export: A component that queries the PHR for consented patient data and produces a FHIR Bundle suitable for ingestion into a research platform, respecting the scope encoded in the Consent resource.

Coordination

This track deliberately leaves participants free to choose their own focus. There are no required tasks, and there is no expectation that every participant's work will integrate with everyone else's.

That said, there is real value in knowing what others are building — both to avoid duplication and to enable a more interesting closing demo. Before the hackathon, participants are asked to briefly describe their intended component on the FHIR Zulip #nordics channel. The track lead will compile a simple overview and share it at the preparatory webinar.

During the closing session, participants who wish to attempt a live integration demo are encouraged to identify potential "connection points" with other components — but this is entirely optional and should not drive scope decisions on the day.

Prerequisites

Participants should arrive prepared. Before the hackathon:

• Read the key IGs: Familiarise yourself with IGs relevant to your chosen topic, such as HL7 PHR IG, IPA, and SMART Health Cards & Links. You do not need to read them in full — a 30-minute skim of the relevant sections may be sufficient.
• Set up a local FHIR environment: Have either HAPI FHIR JPA Server or Medplum running locally via Docker, or have access to a cloud-hosted sandbox.
• Obtain API credentials for your data sources: If you plan to work with wearable APIs (Withings, Garmin, Fitbit, etc.) or Google Health Connect, register a developer account and obtain OAuth credentials before the hackathon.
• Prepare test data: Collect (or fake) some data beforehand, so that you are ready to test and demo the component.
• Have a FHIR validator ready: Either the online FHIR Validator or a local installation of the HL7 FHIR Validator CLI.
• Declare your intent: Post a brief description of what you plan to build on the FHIR Zulip #nordics channel before the preparatory webinar.

Expected Outcomes

Participants are not expected to deliver a production-ready system. A successful outcome for any participant is one or more of the following:

• A working or partially working prototype component, with source code in a public repository (GitHub or similar)
• A FHIR resource or Bundle that validates against the relevant IG and can be POSTed to the shared server
• A short write-up (README or a few slides) documenting the approach, the mapping decisions made, and any gaps or surprises encountered in the standards

The track lead will collect links to all repositories and write-ups after the hackathon and compile a summary for the Results page and for the HL7 Denmark pitch session at eSundhedsobservatoriet on October 7.

Resources

Key standards and implementation guides

Resource	Description
HL7 Personal Health Records IG	Core IG for structuring a FHIR-based PHR.
HL7 Personal Health Device IG	Core IG for collecting measurements from personal health devices.
IPA — International Patient Access	Minimum FHIR API a clinical system must expose for patient access.
IPS — International Patient Summary	Cross-border patient summary; one of the six EHDS EEHRxF priority categories.
SMART Health Cards & Links IG	Citizen-controlled, cryptographically verifiable data sharing via QR codes and links.
IHE Privacy Consent on FHIR (PCF)	FHIR Consent profiling with OAuth integration; the most complete consent-enforcement profile available.
EU Health Data API IG (EURIDICE)	Joint HL7 Europe / IHE specification for EHDS Article 15 EHR interoperability component.
HL7 Europe Base/Core IG	Common EU FHIR foundation.
DK-Core IG	Danish base profiles: Patient (CPR), Practitioner, Organisation, etc.
DK SMART IG	Danish SMART App Launch Specification.
MedCom FHIR	Danish healthcare messaging profiles.
Nordic FHIR Terminology Server	Shared terminology server for the Nordic countries.

Open source tools and platforms

Tool	Language	Description
Medplum	TypeScript	Open source FHIR-native platform with SMART on FHIR built in.
HAPI FHIR JPA Server	Java	The canonical open source FHIR server. Stable and well-documented.
gICS — generic Informed Consent Service	Java	Open source (AGPL v3) consent management with FHIR gateway. Used in production in German research networks. Docker-ready.
HealthKitOnFHIR	Swift	Stanford library for mapping Apple HealthKit samples to FHIR Observations.
EUDI Wallet reference implementations	Various	EU Digital Identity Wallet — Android, iOS, and issuer libraries. All open source.
SMART Health Links reference	TypeScript	Reference implementation of the SMART Health Links specification.
openFHIR	TypeScript	Bidirectional openEHR ↔ FHIR mapping engine. Useful if working with openEHR-based systems.
eHealth Reference Clients	Java	Reference client implementations for the DK eHealth infrastructure (FUT).

Data sources

Source	Description
DMI's Open Data API	Danish Meteorological Institute: weather, pollen, climate. Free API key required.
Google Health Connect	Android aggregation layer for wearable and fitness data.
Apple HealthKit	iOS health data platform.
Withings Developer API	REST API for Withings scales, blood pressure monitors, etc.
Garmin Health API	REST API for Garmin wearables.

Context and background reading

Resource	Description
EHDS Regulation (EU) 2025/327	The regulation itself and the EU Commission's summary page.
HL7 Data Access Policies IG	R6-direction for FHIR Permission resource as complement to Consent.
Data For Good Foundation	Danish-based consent-driven data sharing platform; a potential recipient for donated PGHD.
Kanta PHR (Finland)	A national PHR for citizens in Finland; useful as a reference architecture.
FHIR Validator	Online FHIR resource validator.
FHIR Shorthand (FSH)	If you want to define profiles as part of your work.

Results

See the Results page after the hackathon.