Overview
Healthcare data does not live in one system. A patient's clinical record is distributed across the GP practice that holds their primary care history, the hospital that managed their acute episodes, the specialist that holds their outpatient records, the pharmacy that holds their medication dispensing history, and the diagnostic laboratory that holds their test results. Coordinating care across these settings requires data to move between systems — reliably, accurately, and in a form that the receiving system can interpret and act on.
HL7 and FHIR are the international standards that make this data exchange possible. HL7 v2 is the messaging standard that has underpinned clinical data exchange for decades — the ADT messages that notify systems of patient admissions, discharges, and transfers, the ORU messages that carry laboratory results, the ORM messages that carry orders. HL7 FHIR is the modern RESTful standard that is increasingly the basis for new clinical system integrations — a resource-based API model that is designed for web-scale interoperability and that is becoming the mandatory exchange standard for healthcare data in an increasing number of regulatory frameworks.
We build HL7 v2 and FHIR integration solutions for healthcare organisations, health technology companies, clinical system vendors, and any organisation that needs to exchange clinical data with healthcare systems — sending or receiving, building new integrations or maintaining existing ones, working within Dutch healthcare infrastructure or connecting to international clinical systems.
HL7 v2 — The Established Clinical Messaging Standard
HL7 version 2 has been the dominant clinical messaging standard since the 1980s. Despite its age, it remains the most widely deployed clinical data exchange standard in production healthcare environments globally — and in the Netherlands, the majority of clinical system integrations in hospitals and primary care settings still depend on HL7 v2 message exchange.
Message types. The HL7 v2 message type vocabulary covers the full range of clinical data exchange:
ADT (Admit, Discharge, Transfer) messages notify receiving systems of patient movement events — A01 patient admission, A02 patient transfer, A03 patient discharge, A04 outpatient registration, A08 patient information update, A11 cancel admission, and the full range of ADT event codes that clinical systems use to maintain patient location and demographic records in sync across systems.
ORM (Order) and ORU (Observation Result) messages carry clinical orders and their results — laboratory orders and results, radiology orders and reports, medication orders. The ORM/ORU message pair is the primary vehicle for diagnostic result exchange between ordering systems, laboratory information systems, and clinical records.
SIU (Scheduling Information Unsolicited) messages carry appointment scheduling information between scheduling systems and clinical records — appointment bookings, modifications, and cancellations that need to be reflected in the patient's clinical timeline.
MDM (Medical Document Management) messages carry clinical documents — discharge summaries, clinical letters, operative notes — between the systems that produce them and the systems that need to receive and store them.
Message transport. HL7 v2 messages are typically exchanged over MLLP (Minimal Lower Layer Protocol) — a TCP-based transport protocol designed for reliable clinical message delivery. MLLP handles the framing and acknowledgement of HL7 v2 messages, providing the delivery guarantee that clinical data exchange requires. We implement MLLP client and server components in both sending and receiving configurations, with the connection management, acknowledgement processing, and error handling that reliable HL7 v2 message exchange requires.
Encoding and parsing. HL7 v2 message encoding — the pipe-delimited format that defines the structure of HL7 v2 messages — is not complex but its implementation details matter for interoperability. Field delimiter variations, encoding character handling, optional segment presence, Z-segment extensions used by specific vendors, and the profile variations that different clinical systems apply to the base HL7 v2 specification all affect whether a message parses and processes correctly at the receiving system. We parse and generate HL7 v2 messages with attention to the profile variations that the specific systems being integrated apply, rather than assuming strict specification conformance from every source.
Transformation and mapping. HL7 v2 messages arriving from clinical systems do not always contain data in the structure or coding system that the receiving application needs. Diagnosis codes in ICD-9 that need to be mapped to ICD-10. Patient identifiers in one identifier domain that need to be correlated with identifiers in another. Observation results with local coding that needs to be mapped to LOINC. Transformation and mapping logic handles these conversions, ensuring that the receiving application gets data in the form it requires rather than the form the sending system happened to produce.
HL7 FHIR — The Modern Clinical Interoperability Standard
FHIR (Fast Healthcare Interoperability Resources) is the HL7 standard for modern clinical data exchange. Where HL7 v2 is a messaging standard that defines message structures for specific clinical events, FHIR is a RESTful API standard that defines resource types representing clinical entities — Patient, Encounter, Observation, Condition, Medication, Procedure, DiagnosticReport, and many others — and a standard API for creating, reading, updating, and querying those resources.
FHIR is becoming the required standard for clinical data exchange in multiple regulatory contexts — the US 21st Century Cures Act mandates FHIR for patient data access, the Dutch MedMij standard for patient-controlled health data exchange is FHIR-based, and the European Health Data Space regulation is driving FHIR adoption across EU healthcare systems.
FHIR resource model. FHIR defines over 150 resource types covering the full range of healthcare data:
Clinical resources — Patient demographics, Encounter records, Condition diagnoses, Observation measurements and lab results, Procedure records, MedicationRequest prescriptions, AllergyIntolerance records, Immunization records, DiagnosticReport result reports.
Administrative resources — Organization records, Practitioner credentials, PractitionerRole assignments, Location definitions, Schedule and Slot availability, Appointment bookings.
Infrastructure resources — Bundle collections for transaction and search result sets, OperationOutcome error responses, CapabilityStatement server declarations.
FHIR API operations. The FHIR REST API defines standard operations across all resource types — read, create, update, delete, search, and history. Search parameters are defined per resource type and allow filtering by clinical and demographic criteria — patient identifier, date range, code value, status, and the many other search dimensions that clinical queries require. The FHIR API's standard operations and search parameters enable client applications to query FHIR servers in a consistent way regardless of which vendor has implemented the server.
FHIR profiles and implementation guides. The base FHIR specification is intentionally flexible — it defines what data elements a resource can contain but leaves many elements optional. FHIR implementation guides constrain the base specification for specific use cases — mandating specific elements, restricting value sets, and defining extensions for data elements not in the base specification. The Dutch FHIR implementation guides — the ZIB-based (Zorginterface-bouwstenen) profiles used in Dutch healthcare — define the specific FHIR profiles that Dutch healthcare data exchange requires. We implement FHIR integrations that conform to the applicable implementation guides, not just the base FHIR specification.
MedMij. MedMij is the Dutch standard for patient-controlled health data exchange — enabling patients to access their own health data from healthcare providers and share it with applications of their choice. MedMij is built on FHIR and defines specific information standards for different categories of health data — medication records, GP records, laboratory results, and other data categories. Healthcare providers participating in MedMij need FHIR API implementations that conform to the MedMij information standards and authentication requirements. We build MedMij-compliant FHIR endpoints for healthcare organisations that need to participate in the MedMij framework.
Integration Architectures
Point-to-point integration. The simplest integration architecture — a direct connection between two systems, with messages or FHIR resources flowing directly from sender to receiver. Point-to-point integration is appropriate when the integration is between two specific systems, the data flows are defined and stable, and the volume does not require middleware infrastructure to manage.
Integration engine and middleware. When integrations involve many systems exchanging many message types, integration engine middleware provides the routing, transformation, and orchestration layer that manages the complexity. An integration engine receives messages from multiple sources, applies routing logic that determines where each message should go, applies transformation logic that converts the message from the sending system's format to the receiving system's expected format, and delivers to the destination with the acknowledgement processing and error handling that reliable delivery requires.
For organisations with complex clinical system landscapes — hospitals with many systems that all need to exchange patient data — an integration engine approach manages the integration complexity centrally rather than building and maintaining many individual point-to-point integrations.
FHIR server implementation. For organisations that need to expose their clinical data as a FHIR API — to comply with data access requirements, to participate in MedMij, or to enable third-party applications to access clinical data — we build FHIR server implementations that expose the required resource types with the conformance to applicable profiles and implementation guides that the use case requires.
FHIR server implementations include the FHIR REST API endpoint, the search parameter support that the applicable implementation guide requires, the authentication and authorisation layer that controls access to clinical data, and the persistence layer that stores and retrieves FHIR resources.
FHIR client integration. For applications that need to consume clinical data from FHIR servers — pulling patient data from a hospital's FHIR API, querying lab results from a laboratory FHIR endpoint, retrieving medication records from a pharmacy FHIR API — we build FHIR client integrations that handle FHIR authentication flows, resource retrieval and search, bundle processing, and the profile-conformant parsing of returned resources.
Dutch Healthcare Integration Landscape
Clinical data exchange in the Netherlands operates within a specific infrastructure that shapes how integrations are designed and implemented.
VIPP and electronic data exchange. The Dutch Versnellingsprogramma Informatie-uitwisseling Patiënt en Professional (VIPP) programme has driven the adoption of standardised data exchange in hospital and care settings — mandating FHIR-based data exchange for patient-accessible records and driving the adoption of ZIB-based FHIR profiles across Dutch healthcare.
LSP and the national infrastructure. The Landelijk Schakelpunt (LSP) is the national health information exchange infrastructure for the Netherlands — enabling GP practices, hospitals, and pharmacies to share patient data with treating clinicians who have the patient's consent. Connecting to the LSP requires conformance to the LSP's specific message format requirements and authentication infrastructure.
Koppeltaal. Koppeltaal is the integration standard for connecting eHealth applications to clinical information systems in the Netherlands — enabling digital therapeutics, patient portals, and mental health applications to exchange data with clinical systems. Koppeltaal is FHIR-based and defines specific profiles for the mental health and eHealth application context.
ZIBs (Zorginformatiebouwstenen). The Dutch clinical building blocks — ZIBs — define the information models for Dutch clinical data exchange. FHIR profiles for Dutch healthcare are derived from ZIB definitions. Building FHIR integrations for Dutch healthcare requires understanding and implementing the ZIB-based profiles, not just the base FHIR specification.
Data Quality and Clinical Safety
Clinical data exchange has patient safety implications that general data integration does not. A laboratory result delivered to the wrong patient record. A medication allergy not transmitted to the prescribing system. A discharge summary delayed beyond the clinical window where it affects care decisions. These are not just data quality problems — they are clinical safety risks.
We design clinical data integrations with explicit attention to the data quality and clinical safety requirements they carry:
Patient identity matching. The most critical correctness requirement in clinical data exchange is matching the incoming data to the correct patient record. Identity matching logic that relies solely on name and date of birth is insufficient — patients with common names share these attributes, and data quality variations in name spelling and date format create matching ambiguity. We implement patient identity matching using all available identifying attributes — BSN (Burgerservicenummer) where available, combined demographic matching where it is not — with explicit handling of ambiguous matches and non-matches rather than defaulting to the nearest-match or silently dropping unmatched records.
Acknowledgement and error handling. HL7 v2 message acknowledgements and FHIR OperationOutcome responses carry the information about whether data was received and processed correctly. Integration components that ignore acknowledgements or do not handle error responses leave data exchange failures invisible until they manifest as missing clinical data. We implement acknowledgement processing and error response handling that surfaces failures for investigation rather than allowing them to accumulate silently.
Message ordering and sequencing. Clinical events have a natural sequence — a patient is admitted before they are discharged, an order is placed before a result is received. Messages that arrive out of sequence and are processed in arrival order produce incorrect clinical data. We implement sequence-aware processing for clinical data flows where ordering matters.
Technologies Used
- C# / ASP.NET Core — HL7 v2 MLLP client and server, FHIR server implementation, transformation engine, NHapi for HL7 v2 parsing
- Rust / Axum — high-throughput FHIR API backends, high-volume HL7 v2 message processing
- React / Next.js — integration monitoring dashboards, message inspection interfaces, configuration management
- TypeScript — type-safe frontend and FHIR client code
- SQL (PostgreSQL, MySQL) — message store, FHIR resource persistence, audit trail
- Redis — message queuing, processing state, integration monitoring
- HL7 v2 / MLLP — established clinical message exchange
- FHIR R4 / R5 — modern clinical resource exchange
- ZIB profiles — Dutch clinical building block conformance
- MedMij — Dutch patient-controlled health data exchange
- Koppeltaal — Dutch eHealth application integration
- SMART on FHIR — OAuth2-based FHIR authentication for third-party application access
- Auth0 / SAML — identity management for clinical system authentication
- REST / Webhooks — non-HL7 integration for connected systems
Integration Is Not the Interesting Part
Clinical data exchange infrastructure is not the part of a healthcare system that patients or clinicians interact with. It is the plumbing that makes the parts they do interact with work correctly. When it works, it is invisible. When it does not, the consequences show up as missing results, duplicate records, delayed information, and the clinical inefficiency that healthcare staff and patients experience as degraded care.
Building HL7 and FHIR integrations correctly — with the patient identity matching, the acknowledgement handling, the transformation accuracy, and the clinical safety discipline that healthcare data exchange requires — is the work that keeps the plumbing invisible.
Clinical Data Exchange That Works
Healthcare interoperability is a solved problem at the standards level. The implementation is where it becomes complex. Whether you are connecting a new application to the Dutch healthcare infrastructure, building a FHIR server to comply with data access requirements, or replacing a fragile point-to-point HL7 v2 integration with something more robust — we have the clinical standards knowledge and the implementation experience to do it correctly.