Unio federates any number of openEHR repositories behind a single endpoint, whether they sit in one institution, a hospital group or a whole region. Clinicians see one history. Every record stays in the system that created it.
The federation at a glance in the operator console: Unio, the organisations it federates and the repository behind each. Every member is probed once a minute and each edge carries the result.
Give every clinician in the network one view of the patient, without a central data warehouse and without a migration programme.
Find out moreJoin a shared record while keeping your own repository and applications, or federate the several CDRs you already run inside one institution.
Find out moreBuild against one openEHR endpoint for the whole federation instead of one per repository. Existing openEHR applications need no changes.
Find out moreApplications talk to Unio exactly as they would to a single clinical data repository. Unio finds the records across the federation, queries each member in place and returns one answer.
An application sends an ordinary openEHR request to Unio, exactly as it would to a single CDR.
Unio matches the patient centrally and works out which members hold a record. Members that hold nothing are not asked.
Each repository is queried over its standard openEHR interface. A slow or unreachable member does not block the others.
Results are merged in time order and deduplicated. Each entry names its source. If a member could not be reached, the response says so.
Applications that speak FHIR rather than openEHR get the same federated record. openFHIR sits in front of Unio and exposes a FHIR API. A FHIR query is translated into AQL, Unio runs it across the member repositories, and the merged openEHR result is mapped back into FHIR resources on the way out.
openFHIR is also a SYNTARIC product, so the two are built to work together. Unio joins the openEHR repositories into one record; openFHIR opens that record to the FHIR world, including national exchange platforms and the European Health Data Space. Together they give a federation one openEHR endpoint and one FHIR endpoint, both backed by the same data, with one team behind them.
The operator console shows how the federation is behaving: which members are reachable, how quickly each one answers, and every request that crossed an organisational boundary. It stores no clinical data and no patient identifiers.
Unio is the shared record for any set of openEHR repositories whose owners keep their own systems: the departments of one institution, the hospitals of a group, or the care organisations of a region. Three capabilities make that work.
The gateway accepts standard openEHR requests, including AQL, and resolves them across the member repositories. Applications do not need to know which organisation holds which record.
Every request is recorded with the requesting principal, the members asked and the time each took. Patient identifiers are replaced before the record is written. No request or response bodies are stored.
Data stays with its owner. Care recorded in one system is written to that system's repository and nowhere else. Joining and leaving the federation are configuration changes, and a member that leaves takes nothing away from anyone else.
Unio sits in front of the federation and speaks to each member repository over the openEHR interface it already exposes. There is nothing to install on the member's side.
The questions programme leads and IT directors ask in the first meeting.
No. You keep the repository you have. Unio queries it over the standard openEHR REST API it already supports. Nothing is installed on your side.
Any repository that exposes the standard openEHR REST API can be a member. Our demonstration environment federates EHRbase and FerroEHR repositories.
No. Applications built against a single openEHR repository work against the federation through Unio without modification. There is no federation-specific API to adopt.
Yes, by putting openFHIR in front of Unio. openFHIR exposes a FHIR API, translates FHIR queries into AQL for the federation and maps the merged openEHR result back into FHIR resources. The member repositories stay plain openEHR and need no FHIR server of their own. openFHIR is also developed by SYNTARIC, so the two products are designed and supported together.
No. Unio keeps only request metadata: counts, statuses, latencies, errors and member URLs. Patient identifiers are replaced before a request is written to the log, and no request or response bodies are stored.
Unio is delivered as a Docker image and runs on Linux. The organisation operating the federation deploys and runs it in the infrastructure of its choice.
Each member has its own timeout. A member that does not answer in time is reported as unreachable, the other members' results are returned, and the response is marked as partial. The outage is visible in the operator console.
Yes. Because nothing was copied out of the member's repository, leaving is a configuration change on the gateway. The member's records are already, and only, in its own system.
Tell us what you are looking at and we will set up the right session: a demonstration for a region or hospital group, a technical briefing for IT, or commercial information.
