Healthcare software development
A referral generated in one system, a result produced in another, a patient record held in a third and a claim submitted from a fourth: healthcare estates are built from systems that were never designed to talk to each other directly, and the interfaces that do exist — IM1 pairing, GP Connect, HL7 v2 feeds between hospital systems — each permit a different, narrower set of operations than a buyer usually assumes.
We build and maintain the integration layer between EMIS Web, TPP SystmOne, Vision and hospital estates of PAS, RIS, PACS and LIMS systems, mapping data to FHIR UK Core and SNOMED CT where the target system expects it, handling HL7 v2 where it does not, and matching patients correctly on NHS number through the Personal Demographics Service before any clinical data is written or displayed against the wrong record.
The workflow this replaces
Where no integration exists, or an existing one covers only part of what is needed, staff close the gap by rekeying, printing, faxing or manually cross-checking, and each workaround carries its own patient safety risk.
Step 01
A referral generated in a GP clinical system arrives at a hospital as a document or a fax rather than a structured message, and a hospital administrator rekeys patient demographics and the reason for referral into the PAS by hand, introducing a fresh opportunity for a transcription error every time it happens.
Step 02
A diagnostic result produced by a LIMS or a RIS-PACS pairing is exported as a PDF and emailed or faxed to the referring clinician's system, where it is filed manually against what staff believe is the correct patient, rather than matched automatically on a verified identifier.
Step 03
A digital health product that could write a structured entry back into the GP record instead asks the GP practice to do it manually, because the supplier has not established which IM1 interface mechanism permits write-back for that data type, or because the practice has not explicitly authorised it.
Step 04
Where a message arrives without a verified NHS number, staff match it to a patient using name, date of birth and address, a process prone to error for common names, recently changed addresses or blended families, and one that a Personal Demographics Service trace would resolve automatically in most cases.
Step 05
One system records a diagnosis as a SNOMED CT code and another records the same clinical concept as free text or a local code list, so anyone querying across both systems either misses records or has to manually reconcile terminology before any analysis is trustworthy.
Step 06
An HL7 v2 message that fails to parse, or a FHIR resource rejected for a validation error, is written to a technical log that clinical and operational staff never see, so the failure is discovered only when someone notices a result or referral never arrived.
Step 07
When a data quality or safety incident requires tracing who wrote what to a record and when, staff have to search across the logs of several separate systems with no unified audit trail, which slows down an investigation that should take hours into one that takes days.
What we build
Implements GP Connect capabilities where they cover the required data and operation, and negotiates and builds against IM1 pairing where a bespoke or deeper interface with EMIS Web or TPP SystmOne is required, with the permitted scope of each documented rather than assumed.
Maps clinical data into FHIR UK Core resources — patient, condition, medication statement, observation and others — for systems that consume the national FHIR profile, validating each resource against the UK Core specification rather than a generic FHIR base profile.
Handles admission, discharge and transfer, order and results messaging between PAS, RIS, PACS and LIMS systems in hospital estates, where HL7 v2 remains the dominant message format despite the move toward FHIR elsewhere in the estate.
Matches incoming records to a patient using NHS number as the primary identifier, verified against the Personal Demographics Service, with a documented fallback matching process and an escalation path for records that cannot be matched automatically.
Translates between SNOMED CT, dm+d and any local code lists in use, maintaining a mapping table reviewed as terminology releases update, so a diagnosis or medication is not silently lost or misrepresented when it crosses a system boundary.
Enforces which fields an external system may write into the clinical record, based on the specific interface mechanism authorised, and records patient consent status where write-back concerns anything beyond routine administrative data.
Routes every message that fails to parse, validate or match to a queue with the reason for failure, distinguishing errors that can be resolved automatically from those requiring a person with clinical or administrative judgement to review.
Records every message received, transformed, matched and written, with the identity of the sending and receiving system and, where applicable, the acting user, producing a single queryable audit trail across what would otherwise be several systems' separate logs.
Integrations
Primary care clinical systems
National services
Hospital estate systems
Standards
The interface mechanism available for a given data type or write-back scenario depends on the clinical system supplier's current published offering; we confirm and document the specific route during discovery rather than quoting against an assumed capability.
Data and compliance
Architecture note
The integration layer is built around a message broker and interface engine that normalises inbound HL7 v2 and FHIR UK Core traffic into a common internal model before any patient matching, terminology translation or business logic runs, so downstream modules do not need to know which wire format a given source system used.
Patient matching runs as a dedicated service consulted before any clinical data is filed, verifying NHS number against the Personal Demographics Service where a live trace is available and falling back to a documented demographic matching algorithm with a confidence threshold, below which the record is queued for manual review rather than filed automatically.
Terminology translation is maintained as versioned mapping tables rather than embedded logic, because SNOMED CT and dm+d releases change over time and a mapping that was correct at build time can silently become wrong months later if it is not reviewed against each new release.
Every message, whether successfully processed or not, is written to an audit store keyed on the patient identifier and the source and destination system, which is what makes it possible to answer a safety investigation's question about who saw or wrote what, and when, without cross-referencing several separate systems' logs by hand.
Timeline
Weeks 1–5
Identify every system in scope, confirm which capabilities are reachable via GP Connect, IM1 pairing or HL7 v2 feed, and document exactly what read and write-back permissions are available for each.
Weeks 5–9
Design the PDS-based matching service and fallback algorithm, and build the initial SNOMED CT and dm+d mapping tables for the data types in scope.
Weeks 8–18
Build the HL7 v2 and FHIR UK Core interface engine against sandbox or test instances of the connected systems, starting with the highest-volume message types.
Weeks 16–22
Implement write-back permission enforcement and consent checks for any interface that writes into a clinical record, reviewed against the authorised IM1 interface scope.
Weeks 18–24
Build the reconciliation queue and unified audit trail, and test failure handling against deliberately malformed and mismatched test messages.
Weeks 22–30
Run the integration alongside existing manual processes for a defined pilot period, review error queue volume and matching accuracy, then cut over fully.
Indicative cost
Bands assume UK NHS-connected systems with existing published interfaces. Bespoke IM1 negotiation with a supplier, or integration with legacy hospital systems without a documented interface, increase scope and are estimated separately.
Where this sits
Questions
GP Connect is a national, standardised set of FHIR-based capabilities — access record structured, appointment management, send document — available to any accredited consumer without a bespoke agreement per practice. IM1 pairing is a direct interface agreement with a specific clinical system supplier, used when the required data or write-back permission falls outside what GP Connect currently exposes.
Write-back is permitted only through specific interface mechanisms the supplier has published, and only for the data types and scenarios those mechanisms cover. We identify exactly what write-back is technically and contractually available during discovery, because it varies by supplier, by interface version and by what the practice has authorised.
Matching is attempted on NHS number first, verified where possible against the Personal Demographics Service, with a documented fallback process using name, date of birth and address when the NHS number is missing or unverified. Every match, and every case that fails automatic matching, is logged for review rather than resolved silently.
Yes. Hospital estates still run substantial HL7 v2 traffic between PAS, RIS, PACS and LIMS systems for admissions, orders and results, and an integration programme that only speaks FHIR UK Core will miss most of an acute trust's actual message volume. We build interface engines that handle both.
It is written to an error queue with the reason for failure, rather than dropped or retried silently, and a defined reconciliation process — automated where the fix is deterministic, manual where clinical judgement is needed — resolves it. Every failed and resolved message is retained in the audit trail.
Send the problem, not a brief. We will tell you whether it is a project we should be involved in.
Talk to us