AMBOSS states that its healthcare integrations are built on FHIR and intended to work across major electronic health record systems rather than a single proprietary platform. Understanding what FHIR actually is, in plain terms, matters for judging what this claim genuinely promises and what it leaves entirely open.
FHIR, explained plainly
FHIR, Fast Healthcare Interoperability Resources, is a common technical standard for exchanging structured healthcare information between different systems. In practical terms, it allows one system to retrieve specific categories of data, medicines, observations, conditions, results, from another system through a standardised interface, rather than each pair of systems needing a bespoke, custom-built connection to talk to each other at all.
The potential workflow this enables
A FHIR-based integration could plausibly work as follows: the EHR identifies which patient is currently active in the clinician's session, relevant patient data are shared with the connected clinical AI application through the standard FHIR interface, that application retrieves related medical knowledge based on the shared data, and the clinician receives guidance shaped by the actual patient in front of them rather than a generic answer requiring manual context.
Three genuinely different levels of FHIR-based access
It is worth distinguishing three things that FHIR can, in principle, support, since a headline claim of "FHIR-based integration" does not specify which of these is actually in place. FHIR launch and single sign-on allows a clinician to open a connected application from within the EHR without re-entering credentials, a genuine convenience improvement with no patient-data exchange involved at all. Read-only patient-context access allows the connected application to retrieve specific patient data to inform its response, without any ability to alter the record. And full write-back capability allows the connected application to send structured data back into the EHR, the most consequential and most tightly governed of the three.
The genuine benefits of this kind of interoperability
Several real advantages follow from FHIR-based integration done well. Reduced manual transcription, since data already present in the chart does not need to be retyped into a separate tool. Better use of existing chart data, since information a clinician might otherwise forget to mention becomes automatically available to inform a response. And greater interoperability more broadly, since a standard-based integration can, in principle, work across multiple different EHR systems rather than requiring separate bespoke builds for each one.
The genuine risks worth naming directly
Several risks accompany this kind of integration, regardless of which specific product implements it. Excessive data access, where a connected system retrieves more patient information than its specific task actually requires, raises both privacy and security concerns. Mismatched codes, where the same clinical concept is represented differently across systems using different coding standards, can cause a connected application to misread or fail to find relevant data entirely. Incorrect unit interpretation, a genuinely common source of clinical error even without AI involved, becomes a new risk vector when an automated system is reasoning over unit-labelled values it retrieves programmatically. Incomplete medicine reconciliation, given how notoriously difficult keeping an accurate, current medicines list actually is across care settings, can leave a connected system reasoning from an incomplete picture. And variation between different EHR implementations of the same nominal FHIR standard, a genuinely common practical problem in healthcare interoperability, means a standard-based integration does not automatically behave identically everywhere it is deployed.
A UK-specific complication worth adding
NHS interoperability is genuinely fragmented across primary and secondary care, with different systems, different data models, and different levels of FHIR maturity across GP systems, hospital electronic patient records, and various national services. A UK implementation of this kind of integration would need to account for that fragmentation directly, rather than assuming a single, unified national record architecture equivalent to what a more centralised health system might offer.
Where iatroX could plausibly sit within such an architecture
A UK knowledge service such as iatroX could, in principle, function as the clinical-knowledge layer within a future FHIR-based architecture, supplying UK-specific guidance in response to patient context shared by a connected NHS system. This is worth stating clearly as strategic potential rather than a current integration; iatroX does not today read patient data from any EHR, and this article makes no claim otherwise.