EU Health Data API
1.0.0-ballot - ballot 150

This page is part of the EU Health Data API (v1.0.0-ballot: STU1 Ballot 1) 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

Resource Access

Overview

Resource access provides query and read access to individual clinical FHIR resources. This is a parallel path to FHIR Document Exchange.

A vaccination registry that serves Immunization resources, or a medication system that serves MedicationStatement resources, uses resource access without necessarily producing complete priority documents. Systems declare which resources they support.

Resource access for resources that also appear within FHIR Documents (e.g., Conditions referenced in a Patient Summary) is permitted but not required.

Data models for resource access inherit from HL7 Europe Core. This path corresponds to Resource Interoperability Profiles in the Xt-EHR D8.1 conformance framework, aligned with the Xt-EHR Logical Models.

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 Publisher? Click for more Resource publication 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 International Patient Access (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

This is a core subset of resources for ballot. Ballot feedback is requested on whether this set is appropriate. See Open Issue #9.

Supported Resources

Following International Patient Access (IPA), 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 (see Capability Discovery). 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.

Scopes

system/AllergyIntolerance.rs
system/Condition.rs
system/Observation.rs
system/DiagnosticReport.rs
system/MedicationRequest.rs
system/MedicationDispense.rs
system/MedicationStatement.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.

References

International Patient Access vs QEDm

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