The first time a facility goes live on a state health information exchange, somebody optimises for the happy path. The FHIR server responds in 200ms on the office fibre, the resource validates, the dashboard turns green, and everyone high-fives. Then the facility actually opens, and a nurse tries to file a visit summary on a tablet that is on mobile data, indoors, with a generator that has been off for an hour. That is the connection your exchange was actually built for.
I design for the 10th-percentile connection, not the median, because the median never shows up to a go-live. The median is a lab number. The connection that breaks your system is the one at the bottom of the distribution — the PHC on a rainy Tuesday, the telepharmacy node sharing a router with a billing machine, the field worker whose battery is at 6%. If your architecture cannot complete a transaction under those conditions, you do not have an architecture for this market. You have a demo.
Make the network optional, not rare
Offline-first is not a feature you add at the end; it is the first architectural decision. The clinical dosing companion I built ships the entire reference in the bundle. Sync is an enhancement, never a dependency. A health worker can look up a dose with no connection at all, because the question they are answering — is this dose safe for this patient — does not get to wait for a round-trip to a server.
The same principle scales to the exchange. A facility should be able to record a patient encounter, queue it, and reconcile when connectivity returns. The longitudinal record is eventually consistent, and the user interface has to say so honestly: 'saved locally, will sync' rather than a spinner that implies something is happening when nothing is.
Payload is a latency tax you pay forever
Every kilobyte you ship over a bad connection is a tax you pay on every transaction, forever. FHIR R4 resources are verbose by design — they are built for semantic interoperability, not for bandwidth. That is the right trade-off at the exchange boundary, but it is the wrong trade-off on the last mile to a facility.
The resolution is a tiered payload: full FHIR R4 at the HIE boundary, a compressed projection for the facility client, and a minimal delta for sync. A Patient resource that is 4KB on the wire can be 400 bytes of changed fields when all the facility did was update a phone number. Designing the delta protocol is unglamorous work, but it is the difference between a sync that completes and a sync that times out and retries and times out again.
Idempotency is not optional
Bad connections mean retries. Retries mean duplicate writes. If your endpoint is not idempotent, a retried POST creates a duplicate encounter — and now the longitudinal record has two visits where there was one, and a clinician downstream trusts the data a little less.
Every write path on an exchange in a low-bandwidth market needs a client-generated idempotency key and a server that treats 'I already have this key' as a success, not an error. The facility client should be able to retry aggressively — because that is what the network is forcing it to do — without corrupting the record.
The honesty principle
The hardest part of designing for the 10th percentile is honesty in the interface. A spinner that never resolves teaches a user that the system is broken. A 'saved locally' badge teaches them that the system is working as designed, just deferred. A sync queue with a visible count teaches them that their work is not lost. None of this is technically hard. All of it is easy to skip, because the median connection never embarrasses you for skipping it.
Design for the connection that will be there at go-live, at the worst hour, in the worst facility. Everything else is a bonus.