A timeout does not mean an EHR write failed. The remote system may have committed the change and lost the response on its way back. If the integration immediately sends a new request, it can create a second referral, appointment, or document. If it marks the first attempt failed, staff may repeat work that already reached the chart.
The safe response is to treat a timeout as an unknown outcome until the integration can prove what happened.
Give the intended write a durable identity
Create an operation ID before the network call and persist it with the intended action, source record identifier, target patient, payload hash, and current state. Every retry and reconciliation attempt should refer to that same operation. A queue redelivery must not manufacture a new identity for the same work.
This makes the local record the source of truth for intent. The remote resource ID becomes evidence that the intent completed, not the only evidence that the work ever existed.
Use the server's duplicate protection
Prefer an API guarantee over a client-side guess. When a FHIR server supports it, conditional create lets a client create a resource only when an equivalent resource does not already exist. The request uses If-None-Exist with search criteria that define equivalence. Check the server's capability statement first because support varies.
The search key should be a stable business identifier controlled by the integration, not a patient's name and birth date. For updates, keep the remote resource ID and version so a stale writer cannot quietly replace a newer edit.
Model the unknown state explicitly
A useful write state machine can stay small: queued, sent, confirmed, unknown, and needs review. A timeout moves the operation to unknown. A reconciliation worker then looks for the expected remote result by its stable identifier and compares the material fields or payload hash.
Do not label unknown as failed just to keep a dashboard tidy. That shortcut is how an operational question becomes duplicate clinical data.
An illustrative timeout test
Assume an integration sends a referral at 14:03. The EHR creates it, but the response is dropped. The client times out after 30 seconds.
- If reconciliation finds exactly one referral with the operation's source identifier and expected content, mark it confirmed and store the remote ID.
- If it finds none, resend the same intent using the same duplicate-protection key.
- If it finds multiple matches or one with conflicting content, stop and route the operation to review.
The expected test result is one referral, one durable operation record, and a visible trail from the timeout to confirmation. Run the same test with the connection dropping before the server receives the request; the final state should still be one referral after recovery.
Retry according to evidence
- 2xx response: confirm the operation and store the returned resource ID and version.
- 400, 401, or 403: stop the blind loop. Correct the request or access problem before another write.
- 409 or 412: read the current resource and reconcile the conflict.
- 429 or 5xx: back off and retry only when duplicate protection is in place. Otherwise reconcile first.
- Timeout or dropped connection: mark the outcome unknown and look for the remote result before replaying the write.
Leave enough evidence to investigate
Record the operation ID, request hash, endpoint, attempt count, timestamps, response status, returned resource ID and version, and the reconciliation result. Keep protected health information out of general-purpose logs unless it is necessary and handled under the system's data controls.
The recovery path should be tested before writeback goes live. A timeout is routine distributed-systems behavior. The integration's job is to make its outcome knowable without asking staff to inspect two systems and guess.