FHIR-compatible means little about a clinical workflow until the supplier identifies what information is exchanged, with which system, under which permissions and in which direction. A standards-based connection can be valuable without completing the intended task. Ask for an end-to-end demonstration, including corrections and failure, rather than accepting the standard's name as proof of integration.
Ask for the nouns and verbs
FHIR's official overview, checked on 19 September 2026, describes a standard for electronic healthcare-information exchange built around resources. It also explains capability statements and profiles that describe or constrain implementations.
A practical supplier conversation should therefore move from "we support FHIR" to "we read these resources, from this endpoint, using this implementation guide, and write this output after this review step". The relevant version and local constraints matter; the version of a public specification page does not establish the version used in a deployment.
Do not assume that reading a patient record includes permission or capability to write a note, create an order or update a problem list. Each action needs its own explanation and evidence.
Follow an original fictional workflow
Imagine a clinical AI tool intended to prepare a draft summary before an outpatient appointment. The supplier demonstrates that it can retrieve information and produce text.
The buyer should ask what information was retrieved, how current it was and whether the patient identity was established correctly. Then ask where the draft goes, how the clinician reviews it and what happens after a correction.
A successful text response proves only that this part of the demonstration worked. It does not establish that the receiving record preserves the correction, attributes the author correctly or prevents a draft being mistaken for an approved clinical note.
The demonstration should finish where the real task finishes, not where the AI model stops generating.
Inspect the data contract
Request a concrete account of supported resources and fields, mandatory inputs, missing-data behaviour and any extensions or local mappings. A resource label alone may not establish that all the information needed for the clinical task is available.
Ask how the system distinguishes historical from current information, patient-reported from clinician-recorded data and a missing value from a negative finding. Those distinctions can affect the meaning of a generated summary even when the exchange is technically valid.
Where information arrives from more than one system, establish how conflicting values are handled. A supplier should not silently choose the most convenient source without a documented rule and appropriate user visibility.
This is an original integration-review framework, not a claim that FHIR prescribes one clinical reconciliation policy for every application.
Authentication and permission are part of the workflow
Who is the system acting for: an individual clinician, a service account or another authorised process? What information can it access, and how is that access limited to the intended task?
Ask what happens when a user's role changes or access is revoked. A connection that worked during a demonstration may not behave the same way under ordinary organisational permissions.
Also distinguish authentication from clinical authority. A system can be authorised technically to send information without that information being clinically reviewed. The user interface and receiving workflow must preserve the distinction between generated draft, human amendment and final approval.
Avoid accepting a broad claim that "the record system handles security" without an account of responsibilities across the organisations and suppliers involved.
Make provenance visible
For a generated summary, establish which source records informed it and which version was available at the time. The reviewer should be able to inspect consequential source information rather than trust an unexplained synthesis.
Ask how the destination records authorship, timestamps and amendments. If the clinician changes the draft, can a later reviewer distinguish the generated text from the approved record where that distinction is needed? If a source record changes, does the system detect the change or continue showing an old draft?
These questions do not require retaining every possible input indefinitely. Retention and traceability need an appropriate governance design. The objective is enough evidence to understand the clinical output without creating unnecessary copies of sensitive information.
Test failure before approving success
Use a controlled, non-patient test environment to examine an unavailable source system, a denied permission, an incomplete response and a failed write. The following are proposed test cases, not results from any supplier.
If the read fails, does the user see a clear limitation or an apparently complete summary? If the write fails, is the draft preserved safely and is the clinician told that filing did not occur? If the operation is retried, can it create duplicate entries?
Test recovery as well as failure. A temporary connection problem should not leave ambiguous ownership of a clinical action. Establish what the user must do and what the system will do automatically.
A supplier that can explain those boundaries may offer a more usable integration than one with a longer list of nominally supported systems but no documented failure behaviour.
Agree responsibility across the chain
The NCSC cloud-security principles, checked on 19 September 2026, provide a foundation for examining supplier responsibilities, operation and assurance. They do not replace a clinical integration assessment or certify an individual workflow.
Write down who owns configuration, access, monitoring, incident response and changes. If the record-system vendor changes an interface, who tests the effect? If the AI supplier changes its output structure, who confirms that the destination still handles it correctly?
The contract, technical documentation and clinical workflow should describe compatible responsibilities. Gaps between those documents are more important than whether every presentation uses the word interoperable.
Where iatroX fits in this discussion
This article is published by iatroX as technical and clinical-safety analysis. It does not claim that iatroX has an available FHIR integration, record-writing capability or connection to a named electronic record system.
The Insights service described on 19 September 2026 provides an appropriate route for discussing advisory and evaluation work. For buyers, the useful next step is a defined workflow and evidence request. For suppliers, it is a demonstration that includes the awkward parts, not just a successful API response.
Frequently asked questions
Does FHIR compatibility guarantee integration with my record system?
No: versions, profiles, permissions and supported operations must align with the local implementation. The intended workflow still needs testing.
Is read access equivalent to write-back capability?
No: they are different operations with different permissions and risks. Ask exactly what the supplier can retrieve, create, amend and file.
Does this article announce an iatroX FHIR integration?
No: it provides an evaluation framework and makes no undocumented integration claim. Product availability must be established separately.
Discuss a clinical AI integration assessment with iatroX Insights →