EU Health Data API
1.0.0-ballot - ballot
150
EU Health Data API
1.0.0-ballot - ballot
150
EU Health Data API, published by HL7 Europe. This guide is not an authorized publication; it is the continuous build for version 1.0.0-ballot built by the FHIR (HL7® FHIR® Standard) CI Build. This version is based on the current content of https://github.com/euridice-org/eu-health-data-api/ and changes regularly. See the Directory of published versions
| Official URL: http://hl7.eu/fhir/health-data-api/CapabilityStatement/resource-access-provider-eu-api | Version: 1.0.0-ballot | ||||
| Active as of 2026-09-28 | Computable Name: ResourceAccessProviderEuApi | ||||
Copyright/Legal: Copyright HL7 Europe. Licensed under Creative Commons public domain (CC0 1.0). |
|||||
Requirements for an EEHRxF Resource Access Provider that serves clinical FHIR resources using IPA patterns.
This CapabilityStatement defines the requirements for the EEHRxF Resource Access Provider actor. The actor serves clinical data resources using International Patient Access (IPA) patterns for direct resource access beyond document exchange.
Following IPA's approach, servers are not required to support every clinical resource listed in this CapabilityStatement. Patient is required for lookup context; servers MAY choose other resources according to their capabilities and use cases.
Recommended resources, chosen according to capabilities, are:
The server's CapabilityStatement declares which resources it actually supports.
This requirements CapabilityStatement supports the IUA or SMART Resource Server role selected by the environment and use case. A deployment instance advertises only its selected protocol; see Authorization.
Resources SHOULD conform to EU Core profiles where available.
Raw OpenAPI-Swagger Definition file | Download
Language: en
json, xmlNote to Implementers: FHIR Capabilities
Any FHIR capability may be 'allowed' by the system unless explicitly marked as 'SHALL NOT'. A few items are marked as MAY in the Implementation Guide to highlight their potential relevance to the use case.
This CapabilityStatement instantiates the CapabilityStatement International Patient Access Server CapabilityStatement
serverThe Resource Access Provider actor responds to queries for clinical data resources following IPA patterns. This enables direct resource access complementing document-based exchange via MHD.
The protected API groups with the IUA Resource Server or SMART FHIR Resource Server selected by the environment and use case. Its Authorization Server remains an independent participant.
This abstract requirements statement does not advertise a fixed security service. A concrete deployment SHALL declare exactly one security-service coding from the EU Health Data API Authorization Security Service ValueSet, selected for its environment. It SHALL NOT advertise both services unless a future profile defines dual conformance. The Resource Server validates access tokens and granted authorization; the independent Authorization Server performs token issuance and any client-assertion validation.
IHE IUA
The provider groups with the IUA Resource Server. The IPA and PDQm interactions in this statement have no IUA MHD transaction scopes; the deployment applies the IUA authorization policy defined for its environment.
SMART Backend Services
For a pre-authorized system-to-system use case, the provider groups with the SMART FHIR Resource Server and accepts
system/scopes for the resources it supports.Interactive SMART
Where an interactive use case applies, the provider groups with the SMART FHIR Resource Server and accepts the corresponding
patient/oruser/scopes for the resources it supports.For the IG-level CT grouping recommendation for SMART server roles, see SMART Server Time Synchronization.
All modes use TLS 1.2 or higher and return errors according to the selected authorization specification.
Resource Flexibility
Following IPA's approach, servers MAY choose which clinical resources to support based on their capabilities and use cases. Patient is required for lookup context; other resources are recommended but servers may implement a subset. The server's CapabilityStatement declares which resources are actually supported.
Scopes for Supported Resources
For SMART Backend Services, servers SHALL accept scopes for the resources they support:
- system/Patient.rs (REQUIRED - read + search Patient)
- system/Condition.rs (if Condition supported)
- system/AllergyIntolerance.rs (if AllergyIntolerance supported)
- system/Observation.rs (if Observation supported)
- system/DiagnosticReport.rs (if DiagnosticReport supported)
- system/ImagingStudy.rs (if ImagingStudy supported)
- system/MedicationRequest.rs (if MedicationRequest supported)
- system/MedicationDispense.rs (if MedicationDispense supported)
- system/Immunization.rs (if Immunization supported)
- system/MedicationStatement.rs (if MedicationStatement supported)
- system/Encounter.rs (if Encounter supported)
- system/Practitioner.r (if Practitioner supported)
- system/Organization.r (if Organization supported)
These are SMART App Launch 2.2 Backend Services FHIR Resource Scopes, not IUA transaction scopes. Interactive SMART uses the corresponding
patient/oruser/forms. See Authorization.
The summary table lists the resources that are part of this configuration, and for each resource it lists:
_include_revinclude| Resource Type | Profile | R | S | U | C | Searches | _include | _revinclude | Operations |
|---|---|---|---|---|---|---|---|---|---|
| Patient | Supported Profiles Patient (EU core) | Y | Y | identifier, _id, active, family, given, telecom, birthdate, address, address-city, address-country, address-postalcode, address-state, gender | |||||
| Practitioner | Y | ||||||||
| Organization | Y | ||||||||
| Condition | Y | Y | patient, clinical-status, category, code | ||||||
| AllergyIntolerance | Y | Y | patient, clinical-status | ||||||
| Observation | Y | Y | patient, category, code, date, status, patient+category, patient+code, patient+category+date, patient+category+code | ||||||
| DiagnosticReport | Y | Y | patient, category, code, date, status, patient+category, patient+category+code, patient+category+date | ||||||
| ImagingStudy | Y | Y | patient | ||||||
| MedicationRequest | Y | Y | patient, status, intent, authoredon | ||||||
| MedicationDispense | Y | Y | patient, status, whenhandedover | ||||||
| Immunization | Y | Y | patient, date, status | ||||||
| MedicationStatement | Y | Y | patient, status, effective | ||||||
| Encounter | Y | Y | patient, date, status, class, patient+date |
readRead Patient by logical ID
search-typeSearch for patients for lookup purposes
Patient resources support patient lookup per PDQm [ITI-78] with identifier as a required search parameter. Note: Patient is used for lookup context, not as a primary clinical data resource in this actor.
| Conformance | Parameter | Type | Documentation |
|---|---|---|---|
| SHALL | identifier | token | Patient identifier (e.g., national ID, MRN) - required for patient lookup |
| SHALL | _id | token | Patient logical ID |
| SHALL | active | token | Whether the patient record is active |
| SHALL | family | string | Patient family name |
| SHALL | given | string | Patient given name |
| SHALL | telecom | token | Telecom details of the patient |
| SHALL | birthdate | date | Patient date of birth |
| SHALL | address | string | A server defined search that may match any of the string fields in the Address, including line, city, district, state, country, postalCode, and/or text |
| SHALL | address-city | string | A city specified in an address |
| SHALL | address-country | string | A country specified in an address |
| SHALL | address-postalcode | string | A postal code specified in an address |
| SHALL | address-state | string | A state specified in an address |
| SHALL | gender | token | Administrative gender of the patient |
readRead Practitioner by logical ID
Practitioner resources provide clinical context for referenced healthcare providers. Read-only access supports resolving practitioner references in clinical resources. Servers SHOULD support this resource but MAY omit it based on their capabilities.
readRead Organization by logical ID
Organization resources provide context for referenced healthcare organizations. Read-only access supports resolving organization references in clinical resources. Servers SHOULD support this resource but MAY omit it based on their capabilities.
readRead Condition by logical ID
search-typeSearch for Condition resources
Condition resources represent problems, diagnoses, and health concerns. If supported, servers SHALL support search by patient and SHOULD support additional filters. Servers MAY omit this resource based on their capabilities.
| Conformance | Parameter | Type | Documentation |
|---|---|---|---|
| SHALL | patient | reference | The patient who has the condition (SHALL support) |
| SHOULD | clinical-status | token | The clinical status of the condition |
| SHOULD | category | token | The category of condition |
| SHOULD | code | token | Code for the condition |
readRead AllergyIntolerance by logical ID
search-typeSearch for AllergyIntolerance resources
AllergyIntolerance resources represent patient allergies and intolerances. If supported, servers SHALL support search by patient. Servers MAY omit this resource based on their capabilities.
| Conformance | Parameter | Type | Documentation |
|---|---|---|---|
| SHALL | patient | reference | The patient who has the allergy or intolerance (SHALL support) |
| SHOULD | clinical-status | token | The clinical status of the allergy or intolerance |
readRead Observation by logical ID
search-typeSearch for Observation resources
Observation resources represent clinical observations including vital signs, laboratory results, and other measurements. If supported, servers SHALL support search by patient+category, patient+code, patient+category+date, and patient+category+code. Servers MAY omit this resource based on their capabilities.
| Conformance | Parameter | Type | Documentation |
|---|---|---|---|
| SHALL | patient | reference | The patient the observation is about (SHALL support) |
| SHALL | category | token | Category of observation (e.g., vital-signs, laboratory) |
| SHALL | code | token | The code of the observation type |
| SHALL | date | date | Obtained date/time. Date modifiers ge, le, gt, lt SHOULD be supported. |
| SHOULD | status | token | The status of the observation |
readRead DiagnosticReport by logical ID
search-typeSearch for DiagnosticReport resources
DiagnosticReport resources represent laboratory results and imaging reports. If supported, servers SHALL support search by patient+category, patient+category+code, and patient+category+date (IHE QEDm; not defined by IPA). For imaging reports, the HL7 Europe Imaging and MADO implementation guides MAY define additional search requirements. Servers MAY omit this resource based on their capabilities.
| Conformance | Parameter | Type | Documentation |
|---|---|---|---|
| SHALL | patient | reference | The patient the report is about (SHALL support) |
| SHALL | category | token | Category of report (e.g., LAB, RAD) |
| SHALL | code | token | The code for the report type |
| SHALL | date | date | The clinically relevant time of the report |
| SHOULD | status | token | The status of the report |
readRead ImagingStudy by logical ID
search-typeSearch for ImagingStudy resources
ImagingStudy resources represent imaging studies available for a patient. ImagingStudy is not profiled in EU Core; resources SHOULD conform to the HL7 Europe Imaging ImagingStudy profile (http://hl7.eu/fhir/imaging/StructureDefinition/ImagingStudyEuImaging). If supported, servers SHALL support search by patient. The MADO implementation guide MAY define additional search requirements. Servers MAY omit this resource based on their capabilities.
| Conformance | Parameter | Type | Documentation |
|---|---|---|---|
| SHALL | patient | reference | The patient the imaging study is about (SHALL support) |
readRead MedicationRequest by logical ID
search-typeSearch for MedicationRequest resources
MedicationRequest resources represent medication orders and prescriptions. If supported, servers SHALL support search by patient. Servers MAY omit this resource based on their capabilities.
| Conformance | Parameter | Type | Documentation |
|---|---|---|---|
| SHALL | patient | reference | The patient for whom the medication was ordered (SHALL support) |
| SHOULD | status | token | Status of the prescription |
| SHOULD | intent | token | The intent of the medication request |
| SHOULD | authoredon | date | Return prescriptions written on this date |
readRead MedicationDispense by logical ID
search-typeSearch for MedicationDispense resources
MedicationDispense resources represent medication dispensing events. If supported, servers SHALL support search by patient. Servers MAY omit this resource based on their capabilities.
| Conformance | Parameter | Type | Documentation |
|---|---|---|---|
| SHALL | patient | reference | The patient for whom the medication was dispensed (SHALL support) |
| SHOULD | status | token | Status of the dispense |
| SHOULD | whenhandedover | date | When the medication was handed over |
readRead Immunization by logical ID
search-typeSearch for Immunization resources
Immunization resources represent vaccination records. If supported, servers SHALL support search by patient. Servers MAY omit this resource based on their capabilities.
readRead MedicationStatement by logical ID
search-typeSearch for MedicationStatement resources
MedicationStatement resources represent a patient's medication usage, including self-reported medications. If supported, servers SHALL support search by patient. Servers MAY omit this resource based on their capabilities.
readRead Encounter by logical ID
search-typeSearch for Encounter resources
Encounter resources represent patient encounters (visits, admissions, etc.). If supported, servers SHALL support search by patient and by patient+date (IHE QEDm). Servers MAY omit this resource based on their capabilities.
IG © 2025+ HL7 Europe.
Package hl7.fhir.eu.health-data-api#1.0.0-ballot based on FHIR 4.0.1.
Generated
2026-11-05
