FHIR Data Synchronization Between Hospitals: What to Decide Before You Build

FHIR data synchronization between hospitals sounds like a transport problem: read resources from one server, write them to another. In practice the cost, the delay and the clinical risk come from decisions that sit above the transport. Which patients are shared? Which site owns a record that two sites have touched? How do you know two records are the same person? What happens to a transfer that fails at two in the morning? This guide sets out those decisions so they can be settled before a build contract is signed, not discovered during testing.

Who this guide is for

It is written for health system IT leaders, network and HIE programme managers, and product owners at health technology companies who need clinical data to move between several hospitals' FHIR servers and a shared or central instance, and sometimes back again. It assumes each site already exposes a FHIR API, or will soon. If you already know you need a partner to build it, our FHIR integration services page describes how we deliver this work.

What is at stake

A synchronization service that is built before these decisions are made tends to fail in quiet ways. A patient is never transferred because a record fell between two polling runs. Two sites create the same patient at the same moment and the central record ends up with duplicate or missing identifiers. A result is sent back to the wrong hospital because the routing information was never stored. Each is cheap to prevent on paper and expensive to find in production, because nothing crashes and a clinician is the first to notice.

There is also a compliance dimension. Every transfer moves protected health information between organisations, so you need an audit trail that shows what moved, when and why, and you need to know where copies of that data are held along the way, including inside the tooling that runs the service.

The seven decisions that set cost and risk

1. Which patients are shared, and what triggers it

Sharing every patient is rarely the goal. Most networks share a defined cohort: patients referred to a shared programme, enrolled in a registry or discussed at a joint clinical meeting. Decide what marks a patient as in scope. A clinician action in the source EHR that produces a FHIR resource, such as a Flag or a List entry, gives you a clear, auditable trigger. A bulk extract is simpler but shares more data than you need.

2. Which system owns each shared record

When two hospitals treat the same patient, one central Patient record will receive data from both. Decide which site may change it. A common rule is that the site that opens the case is the leading instance and owns the demographic record; other sites may only add their own identifiers. Write down the edge case too: what happens when two sites create the same patient at nearly the same time.

3. How patients and encounters are matched across sites

Matching is the decision with the most clinical risk. If every participating site records a shared identifier, such as an insurance member number or a regional patient ID, matching can be deterministic, and the service can refuse to transfer a patient who lacks it. If there is no shared identifier, you need a master patient index or a probabilistic matching step, which is a larger project in its own right; our guide to patient matching beyond demographics covers the options. Encounters are harder than patients, because hospitals rarely share a case number. Agree how a second site will reference the first site's encounter.

4. Which way each type of data flows

"Bidirectional sync" is a phrase that hides a great deal of work. For each resource type, decide the direction. Patient and Encounter data might flow only from the hospitals to the centre, while structured results, such as a completed QuestionnaireResponse or a care plan, flow only from the centre back to the sites that took part. One direction per resource type removes most conflict handling. Where a result must return to its sites, the central record has to carry each originating site and its local ID.

5. How changes are detected, and how fresh the data must be

There are three broad options. Scheduled polling asks each server for records changed since the last run; it works with almost any FHIR server and is easy to reason about. FHIR Subscriptions push a notification when a matching record changes, which lowers latency but depends on each server's support and adds endpoints to secure. Bulk export suits nightly or weekly loads. Ask the clinical owner how fresh the data must be. If the honest answer is "within a quarter of an hour", polling is usually the cheapest reliable choice.

6. What happens when a step fails

Tokens expire, servers restart and networks drop. Decide which failures are retried, how many times, and who is told when retries stop. Decide also what the audit record looks like: many teams write an AuditEvent for each completed transfer and expose counts of transfers and failures to their monitoring system. Without this, nobody can answer the question "did this patient's data arrive?" without reading logs.

7. Where the service runs and who operates it

If the network or a platform company will run the service, its delivery standards apply from the first week: container images, deployment charts, how secrets are supplied, which environments exist and who deploys to them. Agree those standards before development starts, and agree access to a test environment that matches production. Waiting for environment access is one of the most common causes of delay.

Decision summary

Common mistakes and what they cost

• A fetch window shorter than the schedule interval. If each run looks back five minutes but runs start ten minutes apart, a record updated in the gap is never picked up. Nothing errors; the patient simply never arrives.
• Matching identifiers loosely. Comparing part of an identifier's system name works on test data and fails when another system contains the same text. The cost is a wrong-patient match, which is a clinical safety incident rather than a bug.
• Treating every error as retryable. A malformed request will fail the same way forever. Retrying it hides the defect and fills the logs, while the data never moves.
• No rule for simultaneous creates. Two sites flag the same patient within seconds and both try to create the central record. Without a rule, the result depends on timing.
• Testing only in the vendor's environment. Many early failures in a client environment are configuration differences: a setting present in one file and not another, a file expected on a volume that is not mounted. Each costs a deployment cycle.

For your engineering team

• Polling. Search with _lastUpdated and keep a persisted high-water mark per site and resource type. Make each window overlap the previous one by more than the schedule interval plus expected clock skew, and page through every result. Overlap means some records are read twice, so writes must be safe to repeat.
• Idempotent writes. Use conditional create (the If-None-Exist header) or search-then-create keyed on the shared identifier, as described in the FHIR R4 RESTful API specification. Update only when content has changed, so that repeated reads do not create new versions.
• Search parameters. Check every parameter against the resource definition and each server's CapabilityStatement. Under the FHIR R4 search rules, servers should by default ignore a parameter they do not recognise, unless the client sends Prefer: handling=strict, so a misspelled parameter can return far more data than intended.
• Identifiers. Compare the full identifier system URI and value. Keep the systems in configuration, not code.
• Error classes. Treat most 4xx responses as permanent failures and route them to a review queue. Retry 5xx responses, timeouts and 429 with backoff and a cap. Bound token retries, so that an unavailable identity server cannot trap a job in a loop.
• Durable workflow engines. Engines that replay workflow history after a restart require workflow code to be deterministic. An ID or timestamp generated from the system clock inside workflow code will break replay; use the engine's own time and ID functions. Workflow history also stores inputs and outputs, which here means PHI, so encrypt payloads or pass references instead. Our note on durable execution for healthcare workflows covers the pattern.
• Observability. Emit metrics for transfers by resource type and direction, failures and durations, and write an AuditEvent per completed transfer.
• Environment parity and release gates. Run a local cluster with the client's chart values and secret layout, keep a documented list of every configuration key, and make a run against the client's example resources a gate for every release to a shared environment.

If your team is weighing change data capture instead of FHIR-level polling, our guide to change data capture for healthcare compares the two.

Checklist before you sign a build contract

• The trigger that puts a patient in scope is defined and produces a FHIR resource.
• The ownership rule for shared records is written down, including simultaneous creates.
• The matching identifier is named, with its full system URI, and every site has confirmed that it records it.
• Each resource type has one agreed direction.
• The clinical owner has stated how fresh the data must be.
• Retry limits, alert recipients and the audit record are agreed.
• The hosting standard is documented and a test environment with realistic data is booked.
• A business associate agreement is in place with every party that will handle PHI.

How to scope a first phase

Keep the first phase narrow enough to prove the hard parts. Connect two sites and the central instance. Move Patient and Encounter in one direction and a single result type back. Use the real matching identifier and the real ownership rule, and deploy to the operator's own test environment, not the vendor's. Define acceptance as a set of named test patients, including a patient at two sites, a patient without the shared identifier and a simultaneous create, each with a known expected outcome. Once that passes, adding sites and resource types is mostly configuration. The largest schedule risk in a first phase is rarely the code. It is access to environments and agreement on the rules above.

Scope your synchronization project with us

Nirmitee's engineers design and build FHIR integrations for health systems and health technology companies. We are ISO 27001:2022 certified, HIPAA-enabled, and we sign BAAs. Our team has built more than 350 interfaces on Mirth Connect, and we work in FHIR-native services and integration engines alike. If you are planning data exchange across several hospitals, book a scoping call. We will work through the seven decisions with your team and leave you with a written first-phase scope, whether or not you build it with us. You can also read more about our FHIR integration services and our wider healthcare interoperability work.