Living Data

The patients keep living. New encounters, observations, and claims land on a schedule — so delta polling, subscriptions, and demos behave like a production integration instead of a frozen snapshot.

The problem with a static corpus

A sandbox that never changes cannot test the half of your integration that deals with change. Incremental sync, cursor handling, duplicate suppression, out-of-order arrival, and empty-delta behavior are all untestable against a fixed dataset — so they get written, never exercised, and discovered in production at a customer site.

The change feed

Resources carry honest meta.lastUpdated stamps, so _lastUpdated=gt{timestamp} on a type-level search and Patient/{id}/$everything?_since={timestamp} both return real deltas. The $everything delta is assembled per resource type and returns a Bundle whose meta.lastUpdated is the cursor for your next poll — it deliberately does not advance past data it could not return, so "always use the returned cursor" is safe unconditionally.

Other renditions of the same events

The same clinical events are emitted as HL7v2 messages and C-CDA documents, not just FHIR — because most real integrations still meet at least one of those on the wire. See inbound and subscriptions for the receiving direction: POST HL7v2, C-CDA, or a Redox message in and watch it land as FHIR.