The category crosswalks
For each priority category, the interoperability component keeps a
crosswalk: the eHealth Network dataset, the Xt-EHR logical model and the HL7
Europe profiles element by element, held to the vendored packages by a test.
The component is the eehrxf crate, published from FerroHEALTH/FerroBRIDGE
and pinned exactly here, so its crosswalks are described on
FerroBRIDGE’s crosswalk page: the patient summary, the
prescription and dispensation, the discharge report, the laboratory report
and the imaging study and report. This page keeps what the gateway does with
them: its reading of the patient summary against the Xt-EHR D6.1 draft and
the section queries that select the openEHR content each document is written
from. Where the component stands as a whole is on
Regulatory status.
Two elements of the patient summary crosswalk have no openEHR content named to feed them, so they are open in the clinical safety risk file (hazard I-03) and the gateway writes them as unavailable: the medical alert (A.2.1.2), which a producer must be able to populate, and the functional status (A.2.3.4).
Against the Xt-EHR D6.1 draft
The Commission has adopted no Art 15(1) act and published no draft of one, so the patient summary is also read against the Xt-EHR deliverable D6.1 (Patient Summary: implementation guides on the EEHRxF, published in 2026-05), the closest published text of the specifications that act will lay down. It defers its datasets to the Xt-EHR logical models, which the crosswalk above is read from, and adds these points for an EHR system:
| D6.1 | What it asks | What the gateway does |
|---|---|---|
| §9.1 | a summary compiled from several sources is generated by a system connected to every relevant EHR system | the section queries go to every member that holds the patient, and a member that does not answer makes the summary incomplete (Completeness) |
| §9.1.2 | results from different sources say where and when they were documented | one Provenance per mapped composition names the composition and the member, and each member authors the sections it feeds |
| §9.3.2 | every section the summary supports has a narrative, and every content section keeps the guideline’s contents in a flat structure, with a travel history section of its own | every section carries a generated narrative; the travel history is a crosswalk row with no section query, because the International Patient Summary template has no section for it |
| §9.3.2, §9.3.4.1 | every section suggested to be supported carries an empty list reason, as the IPS 2.0.0 guide does, in place of the MyHealth@EU content-model null flavour | a section with no entry carries emptyReason, nilknown only when every member answered and none holds content for it, and unavailable otherwise |
| §9.2.1.2 | no code system or value set is mandatory; profiles may impose some | the terminology rules prefer the eHN code systems and keep a code in no preferred system as recorded (Terminology), and a received document is held to the bindings of its profiles (Receiving documents) |
D6.1 asks nothing the gateway does not do, and changes no decision. The summary is read again against the adopted act (FerroHEALTH/FerroBRIDGE#1327).
The patient summary’s section queries
Each section openEHR content feeds has a stored query the gateway holds
itself, read-only, under the namespace eu.ferrofed.eehrxf at the one
version 1.0.0 (§12.7, N44). The crate app/ferrofed-eehrxf, the
federation half of the interoperability component, builds them; eehrxf
links nothing of the gateway. The queries are:
eu.ferrofed.eehrxf::patient-summary-allergies-and-intoleranceseu.ferrofed.eehrxf::patient-summary-problemseu.ferrofed.eehrxf::patient-summary-medication-summaryeu.ferrofed.eehrxf::patient-summary-medical-devices-and-implantseu.ferrofed.eehrxf::patient-summary-procedureseu.ferrofed.eehrxf::patient-summary-immunisationseu.ferrofed.eehrxf::patient-summary-social-historyeu.ferrofed.eehrxf::patient-summary-pregnancy-historyeu.ferrofed.eehrxf::patient-summary-advance-directiveseu.ferrofed.eehrxf::patient-summary-observation-resultseu.ferrofed.eehrxf::patient-summary-care-plans
Each one selects, from every member, the whole compositions that contain one
of the archetypes the openEHR International Patient Summary template names
for its section, each composition once with its uid and its template id,
because a FHIRconnect mapping is chosen per template. The patient is the
$patient and $namespace parameters alone, so the query passes the
stored-query admission and the gateway’s rewrite asks each member by its own
ehr_id. The section-to-archetype table, and the four sections no query
feeds, are in the clinical safety risk file.
Vital signs, which the EPS composition carries in a section of its own, feed
the Xt-EHR observation results. Running a query by name and the reserved
namespace are described under
the gateway’s own queries.
The FHIR face of Annex II 2.1 assembles the patient summary from their
answers (The patient summary over FHIR,
#809); the document
list names it beside each member’s own summary
(#810).
The laboratory report’s section query
One stored query selects the laboratory reports,
eu.ferrofed.eehrxf::laboratory-report, held beside the patient summary’s
and in their shape: every whole composition that contains an
openEHR-EHR-OBSERVATION.laboratory_test_result.v1, the entry the openEHR
international Clinical Knowledge Manager’s template “Generic lab test result
example simple” names (CKM cid 1013.26.408, asset version 3). That
template is a DRAFT CKM has not reviewed or published, so a reviewed
template that names other entries would change the query; it is vendored
by scripts/vendor/openehr-ckm.sh with its status recorded. A test holds the
query to the template’s entries. The mapping of laboratory results is the
laboratory mapping eehrxf ships, built in FerroBRIDGE (issue
FerroHEALTH/FerroBRIDGE#1324,
now closed), and the FHIR face writes a member’s report with it
(Laboratory reports over FHIR).
The discharge report and the imaging report have no section query yet. Building each report from the members’ answers, and the FHIR face, are planned as the gateway half of each category (#1404, #1405, #1406), after the component work in FerroBRIDGE.