Migrating a FHIR deployment from sequential integer ids to UUIDs is a two-quarter project done well and a two-year cleanup done poorly. Every existing reference has to be rewritten, every downstream cache invalidated, every audit log...

FHIR gives the client and the server both the option of picking a resource id. POST to a type endpoint asks the server to assign one. PUT to an instance endpoint carries the client's choice. That flexibility is deliberate, and choosing...

A UUID is stable by construction — the id itself never changes. What is not stable, and what teams get wrong, is the mapping from a resource in one environment to the same resource in another. Dev, staging, and production each have their...

UUID collisions are theoretically possible and effectively impossible with a properly-generated v4 across every FHIR workload short of the entire industry writing to one namespace. The real problem in multi-tenant deployments is not the...

UUID v4 is the workhorse — 122 bits of randomness in a fixed layout, cryptographically strong when generated with a proper RNG, no ordering information. UUID v7 is newer — it embeds a millisecond timestamp in the high bits so ids sort by...

Bundle.entry.fullUrl is where a Bundle assembles entries that reference each other atomically. The urn:uuid: prefix in that field is what makes cross-entry references work in a transaction Bundle where the resource ids do not exist yet. It...

FHIR has two id-shaped fields on almost every resource, and they do different jobs. Resource.id is the server's logical id — where the resource lives. Resource.identifier[] is the business identity — the MRN, order number, or external...

Every FHIR resource has a logical id. It can be a UUID, a sequential integer, a natural business key, or anything else that satisfies the id datatype rules. The choice is not academic. A resource id is what every reference in the graph...