EU Health Data API
0.1.0 - ci-build 150

EU Health Data API, published by HL7 Europe. This guide is not an authorized publication; it is the continuous build for version 0.1.0 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

Resource Access

Overview

FHIR resource query for direct access to clinical data. This capability is optional - not all implementations support resource access.

Actors

  • Resource Access Provider (server): Provides resource query capabilities
  • Resource Consumer (client): Queries resources

See Actors and Transactions for detailed actor groupings.

Note: What about Resource Producer? Click for more Resource exchange is more complex than document publication, and in many cases has resource and use-case specific considerations. Within the scope of this version of the IG, we assume a precondition that the Resource Access Provider has access to resources and focus on defining how the Resource Access Provider enables a consumer to search and read those resources. For more details and possible approaches, see the Resource Exchange page.

Specifications

This IG aligns with:

Sequence Diagram

sequenceDiagram
    participant Consumer as Resource Consumer
    participant Provider as Resource Access Provider

    Consumer->>Provider: GET /Condition?patient=123&clinical-status=active
    Provider-->>Consumer: Bundle of Conditions

    Consumer->>Provider: GET /Observation?patient=123&category=vital-signs
    Provider-->>Consumer: Bundle of Observations

Constraints

  • Read/search only - No create/update/delete operations.
  • Patient-scoped queries - patient parameter required on all searches
  • Searches without patient parameter are rejected

Core Resources

The following resources are available for read/search access. Data models inherit from HL7 Europe Core. Required search parameters are from IPA.

Resource Required Search Parameters
AllergyIntolerance patient
Condition patient
Observation patient, category
DiagnosticReport patient, category
MedicationRequest patient
MedicationDispense patient
MedicationStatement patient
Immunization patient
Encounter patient

Open Issue #9: We are seeking validation of this core resource set. See Core Resource Set Validation for discussion.

Scopes

system/AllergyIntolerance.rs
system/Condition.rs
system/Observation.rs
system/DiagnosticReport.rs
system/MedicationRequest.rs
system/Immunization.rs
system/Encounter.rs

Example Queries

GET /AllergyIntolerance?patient=123
GET /Condition?patient=123&clinical-status=active
GET /Observation?patient=123&category=vital-signs&date=ge2024-01-01
GET /DiagnosticReport?patient=123&category=LAB
GET /MedicationRequest?patient=123&status=active

Derived Resources

If resources are derived from documents, Provenance SHOULD link to source DocumentReference:

{
  "resourceType": "Provenance",
  "target": [{"reference": "Observation/123"}],
  "entity": [{
    "role": "source",
    "what": {"reference": "DocumentReference/abc"}
  }]
}

The IHE mXDE profile provides more detail on how to extract resources from documents while maintaining provenance.

Supported Resources

Following IPA's approach, Resource Access Providers are not required to support all clinical resources. Servers MAY choose which resources to implement based on their capabilities, use cases, and the regulatory context.

Servers declare which resources they support in their CapabilityStatement. Clients MAY check the server's CapabilityStatement to discover available resources before making requests.

See the Resource Access Provider CapabilityStatement and Resource Consumer CapabilityStatement for detailed capability declarations.

References

IPA vs QEDm

This IG uses IPA as the primary reference for CapabilityStatements and search parameters. QEDm is referenced where compatible with IPA - and QEDm has a stated goal of aligning with IPA.