Data Exchange
Overview
All cross-border Patient Summary exchanges in this IG use the FHIR Document Bundle pattern. NCP-A acts as the FHIR server, assembling a Bundle of type document whose first entry is a Composition (constrained by the DocumentMetadata profile) that references all clinical entries. NCP-B acts as the FHIR client, querying NCP-A on behalf of THP-B's EHR. Errors and not-found conditions are communicated via an OperationOutcome.
The sections below map each scenario to the profiles that carry the data at each step.
Scenario 1 — Emergency / Unplanned Care (Occasional Visitor)
Summary: THP-B's EHR needs the complete Patient Summary of a visiting patient with no prior arrangement.
Step-by-step exchange
Step 1 — PS query initiated (THP-B EHR → NCP-B)
THP-B initiates a PS retrieval request by supplying patient identity parameters (family name, given name, date of birth, national or cross-border identifier). These parameters correspond to the elements in the PatientIdentification logical model / profile (eHN A.1.1). No FHIR resource is sent at this step; the EHR passes identity credentials to NCP-B using its national interface.
Step 2–3 — Identity resolution (NCP-B → NCP-A → IdP-A)
NCP-B forwards the identity parameters to NCP-A. NCP-A requests confirmation from IdP-A (eIDAS / national federation). IdP-A returns a confirmed identity token. This step is out of scope for FHIR profiling but is a required precondition for the document retrieve.
Step 4 — PS assembly (NCP-A → Country A EHR)
NCP-A assembles the Patient Summary from the Country A health record. All profiled clinical entries are gathered:
- PatientIdentification — patient demographics (
Patient) - DocumentMetadata — document date, update date, nature of PS (
Composition) - AuthorAndOrganisation — author and legal authenticator (
Practitioner,PractitionerRole,Organization) - InsuranceInformation — EHIC / insurance number (
Coverage) - ContactPersonOrGuardian — guardian or next of kin (
RelatedPerson) - PreferredHealthProfessional — Country A responsible HP (
PractitionerRole) - Allergy — allergies and intolerances (
AllergyIntolerance) - MedicalAlert — medical alerts not captured as allergies
- Vaccination — vaccination / prophylaxis history (
Immunization) - ResolvedProblem — inactive or resolved diagnoses (
Condition) - MedicalHistory — narrative anamnesis (
Condition/ narrative section) - CurrentProblem — active diagnoses, including rare diseases via Orphacode (
Condition) - MedicalDevice — implants and devices (
Device/DeviceUseStatement) - Procedure — clinically relevant procedures (
Procedure) - FunctionalStatus — functional capacity assessments (
Observation) - MedicationSummaryEntry — current and relevant past medications (
MedicationStatement) - SocialHistoryObservation — lifestyle factors (
Observation) - PregnancyStatus / PreviousPregnancy — pregnancy history (
Observation) - TravelHistory — patient-provided travel history (
Observation) - AdvanceDirective — living will / advance directive (
Consent) - ResultObservation — lab, imaging, vital signs (
Observation) - PlanOfCare — plan of care entries (
CarePlan)
Step 5 — PS Bundle transmitted (NCP-A → NCP-B → THP-B EHR)
NCP-A returns a Bundle of type document. The bundle's first entry is a Composition conforming to DocumentMetadata. All clinical section entries are included as subsequent bundle entries, each conforming to the appropriate profile listed above. NCP-B relays the bundle unchanged to THP-B's EHR.
The interaction is a document retrieve (conceptually a read/search on the NCP-A endpoint). The exact transport operation (e.g., $match + document retrieve) is aligned with MyHealth@EU / eHDSI conventions.
Step 6 — Rendering (THP-B EHR)
THP-B's EHR renders the coded entries and the Composition.section.text narrative. The narrative is provided in the Country A language; an English fallback is expected when a Country B translation is not available.
Scenario 2 — Planned Care (Occasional Visitor)
Summary: OHP-A prepares an extended PS before a scheduled procedure or specialist consultation in Country B.
Step-by-step exchange
Step 1 — PS creation / update (OHP-A → Country A EHR / NCP-A)
OHP-A assembles an extended PS that includes all Scenario 1 sections plus the following additional data, enabled by the same profiles:
- ResultObservation — pre-procedure lab results and imaging (
Observation) - FunctionalStatus — functional assessments relevant to the planned procedure
- PlanOfCare — planned interventions and care goals (
CarePlan) - CurrentProblem — rare disease diagnoses coded with Orphacode (
Condition) - PreferredHealthProfessional — specialist or ERN-affiliated HP contacts (
PractitionerRole) - KnowledgeResource — links to clinical practice guidelines / ERN resources (
DocumentReference)
The Legal Authenticator signs the PS; the AuthorAndOrganisation profile carries both the author and the legal authenticator identity and timestamp.
Steps 2–5 — Retrieval (same as Scenario 1, Steps 1–5)
THP-B retrieves the PS bundle via NCP-B/NCP-A. The returned Bundle (document type) is identical in structure to Scenario 1 but contains the richer set of entries described above.
Step 3 — Knowledge resource navigation
When the PS contains entries referencing rare disease guidelines, the KnowledgeResource profile (DocumentReference) carries an external URI and a human-readable description. THP-B's system can surface these links; the linked resources themselves are external and out of scope.
Scenario 3 — Regular Cross-Border Worker
Summary: THP-B retrieves a Country A PS for a patient who also has local Country B records.
Step-by-step exchange
Steps 1–5 — Country A PS retrieval (same as Scenario 1)
The exchange is identical to Scenario 1. THP-B's EHR receives the full FHIR Document Bundle from NCP-A via NCP-B, with all applicable profiles populated.
Step 2 — Local record consultation
THP-B separately consults the Country B local EHR records through national mechanisms. This IG does not profile or mandate that exchange. The IG explicitly does not mandate record merging or reconciliation between the Country A PS bundle and Country B local records.
Scenario 4 — Patient Summary Not Available
Summary: NCP-A cannot find a PS or confirm the patient's identity.
Step-by-step exchange
Steps 1–3 — Query and not-found response (NCP-A → NCP-B → THP-B EHR)
When NCP-A finds no PS or cannot confirm patient identity, it returns an OperationOutcome resource (FHIR core resource, not profiled in this IG) with an appropriate issue code (not-found, informational, or error) and a human-readable diagnostic message. NCP-B relays the OperationOutcome to THP-B's EHR without modification.
THP-B's EHR SHOULD display the diagnostic information clearly so THP-B can document the absence of a PS in the local encounter record and proceed based on patient-reported history.
An empty Bundle with an explanatory OperationOutcome as an entry is an acceptable alternative representation where the transport layer requires a Bundle wrapper.
Scenario 5 — PS Creation / Update by Originating HP
Summary: OHP-A creates or updates the Patient Summary so that it is ready for cross-border retrieval.
Step-by-step exchange
Step 1 — PS authoring (OHP-A → Country A EHR)
OHP-A assembles all required PS sections within the Country A EHR. Every section maps to one or more profiles as listed in Scenario 1, Step 4. The DocumentMetadata profile captures DateCreated, DateOfLastUpdate, and NatureOfPS (human / automatic / mixed, bound to the NatureOfPS-lm value set).
Step 2 — Legal authentication
The Legal Authenticator reviews the draft and provides a legal signature. The AuthorAndOrganisation profile records LegalAuthenticatorName, LegalAuthenticatorOrganisation, and AuthenticationDateTime on the Composition (or associated Provenance resource per national implementation).
Step 3 — Indexing / storage (NCP-A)
NCP-A indexes or stores the authenticated PS Document Bundle so that it is available for subsequent cross-border queries. The interaction type is a create or update (PUT/POST) of the Bundle on the NCP-A endpoint, or an equivalent national document registry operation. The stored artefact is the complete FHIR Document Bundle as described in Scenario 1, Step 5.
Profile-to-Scenario Reference Table
| Profile | Scenario 1 | Scenario 2 | Scenario 3 | Scenario 4 | Scenario 5 |
|---|---|---|---|---|---|
| PatientIdentification | ✓ | ✓ | ✓ | — | ✓ |
| DocumentMetadata | ✓ | ✓ | ✓ | — | ✓ |
| AuthorAndOrganisation | ✓ | ✓ | ✓ | — | ✓ |
| InsuranceInformation | ✓ | ✓ | ✓ | — | ✓ |
| ContactPersonOrGuardian | ✓ | ✓ | ✓ | — | ✓ |
| PreferredHealthProfessional | ✓ | ✓ | ✓ | — | ✓ |
| KnowledgeResource | — | ✓ | — | — | ✓ |
| Allergy | ✓ | ✓ | ✓ | — | ✓ |
| MedicalAlert | ✓ | ✓ | ✓ | — | ✓ |
| Vaccination | ✓ | ✓ | ✓ | — | ✓ |
| ResolvedProblem | ✓ | ✓ | ✓ | — | ✓ |
| MedicalHistory | ✓ | ✓ | ✓ | — | ✓ |
| CurrentProblem | ✓ | ✓ | ✓ | — | ✓ |
| MedicalDevice | ✓ | ✓ | ✓ | — | ✓ |
| Procedure | ✓ | ✓ | ✓ | — | ✓ |
| FunctionalStatus | ✓ | ✓ | ✓ | — | ✓ |
| MedicationSummaryEntry | ✓ | ✓ | ✓ | — | ✓ |
| SocialHistoryObservation | ✓ | ✓ | ✓ | — | ✓ |
| PregnancyStatus | ✓ | ✓ | ✓ | — | ✓ |
| PreviousPregnancy | ✓ | ✓ | ✓ | — | ✓ |
| TravelHistory | ✓ | ✓ | ✓ | — | ✓ |
| AdvanceDirective | ✓ | ✓ | ✓ | — | ✓ |
| ResultObservation | ✓ | ✓ | ✓ | — | ✓ |
| PlanOfCare | — | ✓ | — | — | ✓ |
| OperationOutcome (core) | — | — | — | ✓ | — |