Working with FHIR
The FHIR R4 server listener, scheduled polling, R4B subscriptions, and what the FHIR destination can do.
Last updated August 12, 2026
On this page
There are four FHIR-shaped connectors in the engine: a server listener, a poller, a subscription endpoint, and a destination. They solve different problems, and picking the wrong one is a common early mistake.
FHIR server listener — available in the cloud
An inbound endpoint that accepts FHIR resources and bundles, R4 and STU3. Use it when the other system is willing to push to you.
This is the one to reach for by default. It is available in the IntuCloud beta today, it fits the gateway model, and the sending system controls delivery timing.
FHIR Poll — engine-supported
A scheduled search against a remote FHIR server, paging results into the channel. Use it when the other system will not push and only exposes a read API.
Polling is engine-supported and available when self-hosting; it is not yet exposed in the IntuCloud beta. See Connector overview.
FHIR Subscription (R4B) — engine-supported
Receives notifications from a server you have subscribed to, using the R4B subscription model. Lower latency than polling and less load on the source system, when the counterparty supports it.
Also engine-supported rather than cloud-exposed at beta.
FHIR destination — available in the cloud
Writes to a FHIR server: create, update, and conditional upsert operations. The conditional upsert is the one that matters most in practice — matching on an identifier so a repeated ADT feed converges on one Patient rather than creating duplicates.
Each FHIR destination has its own transformer, so you can produce exactly the resource shape that server expects, and its own response transformer, so you can decide what its OperationOutcome actually means.
Writing FHIR transformers
npm type packages give you real resource types in the editor. A transformer that builds a Patient from an HL7 v2 PID segment gets completion on every field and a type error when you misspell one. See Writing TypeScript transformers.
Versions
R4 is the common case. R4B matters specifically for the subscription model. STU3 is supported on the server listener for systems that have not moved. Engine-level detail on version handling lives in the intu-dev docs.