HL7, FHIR, DICOM, IHE. The standards that let one healthcare system talk to another — and the technical expertise that determines whether your project reaches production or stays in pilot.
A hospital is not a single system. It is dozens of systems — HIS, RIS, PACS, LIS, pathology, pharmacy, departmental systems that a vendor installed fifteen years ago — that have to behave as if they were one. The radiological image a physician sees alongside a report has passed through four systems and half a dozen format transformations without the clinician needing to know it.
That's what interoperability does. And when it fails, the consequence is not a wrong dashboard — it's a diagnostic delay, a duplicate test, data lost between two systems that should have understood each other.
"When interoperability fails, the consequence is not a wrong dashboard. It's a diagnostic delay."
Thirty years after its birth, HL7 v2 remains the most widely used integration standard in hospitals worldwide. ADT for patient movements, ORM/ORU for orders and results, MDM for clinical documents. Understanding it in depth is not having read it — it's having solved in production the specific quirks of the system in front of you. That accumulates over time.
FHIR is reshaping healthcare interoperability globally. REST APIs with JSON resources, subscriptions, profiles for specific use cases, the ability to extend without breaking compatibility. We build FHIR servers and clients, define profiles for specific cases, and integrate with national and European infrastructures — including HCDSNS and the European Health Data Space projects.
DICOM is far more than a file format. It is worklists, store, retrieve, modality performed procedure step, structured reports. And the past decade has added DICOMweb over HTTP to integrate medical imaging into modern architectures without losing compatibility. We work with the full stack, from the radiological workstation to the archive and multi-centre distribution.
IHE (Integrating the Healthcare Enterprise) profiles are the "how these standards apply in a specific case". XDS for sharing clinical documents, XCA between communities, PIX/PDQ for patient identification, ATNA for audit. When an administration includes IHE-compliance in a specification, they know what they're asking for. So do we.
SNOMED CT, ICD-10-ES, LOINC, ATC. The terminological catalogues that make data meaningful. Mapping between coding systems is not a lookup table — it is clinical modelling work that preserves semantics between systems with different ways of representing reality.
Connecting the hospital information system with RIS, LIS, pathology, scheduling, pharmacy. ADT flowing in one direction, orders in the other, results coming back correlated to the correct episode. The layer that makes a hospital function as a coherent system rather than disconnected applications.
Moving medical images between institutions whilst maintaining traceability, authorisation and performance. A radiologist at one centre reading studies from another without depending on physical media. The concrete technology — federated PACS, DICOMweb, cloud storage — adapts to what each environment requires.
The transition to FHIR is not immediate. It is a process spanning several years in which both worlds coexist. We build the mediation layers that allow a new FHIR-based system to communicate with a legacy v2 estate — and vice versa — without interrupting clinical operations in the meantime.
HCDSNS, interoperable electronic prescribing across autonomous communities, European Health Data Space (EHDS) projects. When a system must connect to national or European infrastructure, there is a concrete set of specifications to comply with. We know them in detail.
Capture, validation and submission of data to national or regional registries — screening programmes, rare diseases, cancer registries, epidemiological surveillance. Where data quality and traceability are as critical as the timeliness of submission.
The usual starting point is thinking that the standard solves the work. It does not.
The standard indicates what fields a message can have. It does not say how the specific HIS in front of you interprets the priority field. Or what it does when it receives a catalogue update MFN in the middle of a read. Or how the legacy RIS responds when you send it an ORM with a code it does not recognise.
Real interoperability combines knowing the standard, understanding where the specific vendor has departed from it, comprehending the clinical domain, and having spent time in front of message traces in production. It is patient work and very difficult to acquire in a short time.
We have known this terrain since before FHIR existed. Each new layer of standards is built on a structure we already know from the foundations up.
"Knowing the standard is half. Knowing where the vendor has departed from the standard is the other half."
We build the interoperability layer on two internationally recognised open source stacks in the sector: HAPI — for HL7 v2 messaging and FHIR servers/clients — and dcm4che for the complete DICOM stack. On top of them we build the case-specific logic in .NET or Python depending on context.
We apply the same OpenTelemetry observability to integration flows as to everything else — because a lost healthcare message is lost clinical data, and that cannot be discovered months later.
If what you're facing is integration between heterogeneous systems, a phased migration from HL7 v2 to FHIR, a connection to national or European infrastructure, or a project that has stalled at the integration phase — let's talk.