FHIR is how health data moves. We have been building on it since it replaced HL7v2 in our clients' roadmaps — servers, profiles, capture workflows, migrations, and the mapping layer into openEHR persistence.
Deploying and extending FHIR R4/R5 servers, and putting FHIR facades in front of systems that will never speak it natively.
Questionnaire and QuestionnaireResponse workflows following the SDC implementation guide — the practical route from a paper or PDF form to structured, queryable data.
Adding FHIR connectivity alongside legacy HL7v2 interfaces without breaking them, so migration is incremental rather than a cutover.
Working to national and international implementation guides, including appointment and scheduling profiles, and IHE profiles for cross-enterprise exchange.
FHIR workflow resources for orders, requests and tasks — the layer that turns a data model into an operational process.
OAuth2 and OIDC against hospital identity providers, token-based service access, and role models aligned to existing directory structures.
This is the part most teams underestimate, and the reason projects stall at the boundary between exchange and persistence.
EEHRxF and EHDS are FHIR-shaped. The clinical data repositories being tendered underneath are openEHR. Both are correct choices, and they do not natively speak to each other.
Declarative, reviewable mapping definitions implementing the FHIR Connect specification — not hand-written per-project glue that nobody can audit two years later.
FHIR in, openEHR composition out, for capture and persistence. openEHR in, FHIR out, for exchange, patient summaries and cross-border sharing.
Interoperability claims are cheap. Testing them in public is not.
If you are moving from HL7v2, standing up a FHIR facade, or trying to get FHIR capture into an openEHR repository, that is the work we do most.