eehrxf 0.1.131

The European interoperability software component of an EHR system under Regulation (EU) 2025/327: the format-neutral dataset model of the priority categories read from the Xt-EHR EHDS logical models, and the European electronic health record exchange format in FHIR R4, mapped from openEHR by FHIRconnect
Documentation

eehrxf

The European interoperability software component of an EHR system under Regulation (EU) 2025/327 (the European Health Data Space), in Rust: the European electronic health record exchange format of Art 15, as its published proxies carry it until the Art 15(1) implementing act is adopted.

  • dataset: the format-neutral dataset model. A DatasetModel reads the Xt-EHR EHDS Logical Information Models package (xtehr.eu.ehds.models, a FHIR package archive) as data: every logical model keyed on its canonical URL, every element on its element path (EHDSPatientSummary.allergiesAndIntolerances), and every obligations profile with what a producer and a consumer must do with each element. No element is a Rust type of its own.
  • category: one Cargo feature per priority category of Art 14(1) (patient-summary, prescription, dispensation, imaging, laboratory, discharge), each naming the logical model and the obligations profile of its dataset.
  • crosswalk: per category, the rows from the Xt-EHR element paths to the eHealth Network element ids and to the elements and slices of the HL7 Europe profile, with the producer obligation and the profiles a FHIRconnect context may map to in order to feed each. Crosswalk::check holds the rows to the packages they name, and Category::crosswalks names a category's crosswalks, one per dataset. The patient summary (crosswalk::patient_summary, feature patient-summary), the electronic prescription (crosswalk::prescription, feature prescription), the electronic dispensation (crosswalk::dispensation, feature dispensation), the imaging report and the imaging study (crosswalk::imaging, feature imaging, against the HL7 Europe Imaging Report 1.0.0-ballot composition with its DiagnosticReport, and its ImagingStudy), the laboratory report (crosswalk::laboratory, feature laboratory) and the discharge report (crosswalk::discharge, feature discharge) carry one, the two medication ones against the HL7 Europe MPD 1.0.0 MedicationRequest-eu-mpd and MedicationDispense-eu-mpd profiles, the laboratory report against the HL7 Europe Laboratory Report 2.0.0 Composition-eu-lab with its DiagnosticReport-eu-lab companion (Crosswalk::check_with), and the discharge report against the HL7 Europe Hospital Discharge Report 1.0.0 composition-eu-hdr profile.
  • fhir-r4: the FHIR R4 serialisation of the exchange format. It compiles the R4 resources and no openEHR crate.
  • mapping (feature openehr, which turns on fhir-r4): FHIRconnect 1.0.0 context mappings compiled once against an openEHR operational template and run in process, through the fhirconnect engine, over a canonical-JSON composition. The answer is a FHIR R4 Bundle of the mapped resources with one Provenance covering them.
  • medication (feature fhir-r4 with prescription or dispensation): the electronic prescription and dispensation datasets as Rust records. Prescription::read reads a member's MedicationRequests, one per item, and Dispense::read its MedicationDispense, each strictly against FHIR R4 and with a typed refusal for an element the dataset requires and the resource lacks; Prescription::requests and Dispense::resource write them back in the MPD form. Mpd checks a resource, and each Medication it contains, against the vendored MPD profiles by the rules of the receive check. The number of dispensations an item has left travels in the extension https://ferrobridge.eu/fhir/StructureDefinition/remaining-dispensations on dispenseRequest, written only when a value is given; its FHIR R4 StructureDefinition is REMAINING_DISPENSATIONS_DEFINITION, which the FerroBRIDGE site serves at that URL.
  • receive (feature fhir-r4): a document received in the exchange format (Annex II 2.2 and 2.3). ReceivedDocument::read decodes it against FHIR R4, holds it to the document rules of the R4 Bundle (bdl-9, bdl-10, bdl-11), resolves its subject to its Patient entry and keeps its text byte for byte. ReceivedDocument::check walks a Bundle and a Composition profile read from the vendored package over it: cardinalities, fixed[x] and pattern[x] values, and slices, with every constraint it cannot evaluate listed. ReceivedDocument::category names the priority category whose document profile fixes a Composition.type coding of the document, and Category::profiles the profiles a document of it is held to. With openehr, Mapping::to_openehr maps the document into one canonical composition through FHIRconnect and keeps the document in the composition's FEEDER_AUDIT.original_content; ReceivedComposition::model is the composition as the RM model holds it.
  • terminology (feature fhir-r4): the terminology rules. With openehr, transcode turns an openEHR text item into FHIR codings and narrative: a code in a preferred system as recorded, a TERM_MAPPING of match = as a second coding, every other match in the narrative, an archetype-local code displayed with its term from the operational template (local), and any other code in no preferred system under eHN PS Art 10(7). system writes each coding's system as a FHIR URI: a local code under its archetype's code system (https://ferrobridge.eu/fhir/CodeSystem/archetype-local/ followed by the archetype id, described at that base), the openEHR names SNOMED-CT, LOINC and ICD10 as their URIs, and a code of a terminology with no known URI as no coding, in the narrative and reported as unmapped. ehn holds the eHN Patient Summary §4 preferred systems, the default set. Expansions reads the value set expansions of a package, and bindings::check_required holds the required bindings of a profile to them, naming every binding it cannot evaluate. Terminology is the optional FHIR terminology server ($translate, taking only equivalent and equal, $lookup, $validate-code) behind the TerminologyServer seam; with none configured every operation fails closed.

The crate authors no mapping language and no profile mapping: the mapping files are its input. It depends on no logging component and on no application, so the two harmonised software components stay independent of each other (Art 2(2)(n), (o)).

Licence

Business Source License 1.1 (LICENSE): free for every non-production use and for non-commercial production use; a commercial licence for other production use; Apache License 2.0 four years after each version.