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 generation time. For most FHIR uses, v4 is the right default. For a small set of specific patterns, v7 pays off. Knowing the split is a five-minute investment. The site's fullUrl UUID spinner currently emits v4. For the wider FHIR framing, the FHIR tooling roundups has more.
What v4 Actually Gives You
- 122 random bits per id
- Collision probability effectively zero at any realistic scale
- No leaked information — timestamps, MAC addresses, sequence numbers
- Well-supported everywhere; every language and library has a v4 generator
Default choice. Safe choice. Right for almost every FHIR workload.
What v7 Adds
- Millisecond timestamp in the high 48 bits
- Random low bits
- Ids sort by creation time when compared lexically
- Slightly better cache locality on some database engines
That is the whole benefit. It comes with a small cost: the timestamp is a piece of leaked information, and ids created in the same millisecond may cluster on shared random bits.
When v7 Wins
- Time-series-style workloads where you scan resources by creation time
- Database engines that benefit from monotonic keys (some B-tree implementations)
- Workflows where sorting ids gives you rough chronological order for free
If your Observations flow at high volume and you frequently scan by creation time, v7 can produce measurable database performance improvements.
For the wider multi-tenant collision question, collision-free UUIDs in a multi-tenant FHIR deployment is the entry.
When v4 Wins
- Every other workload
- Anywhere the timestamp in v7 would leak information (privacy-sensitive contexts)
- Environments with clock drift or unreliable time sources
- Deployments that mix generation across many nodes without coordinated clocks
The default. Do not switch away from v4 without a specific reason.
Cryptographic Strength
Both v4 and v7 are cryptographically strong when generated with a proper RNG. Both are unpredictable to attackers who cannot observe generation.
The v7 timestamp is not an attack vector on its own — it just narrows the window an attacker would need to guess. But for FHIR resources where the id ends up in URLs, the timestamp becoming public is a minor information leak.
Compatibility
Both formats fit Resource.id's 1-64 character rule. Both encode as 36 characters with hyphens. Consumers that treat UUIDs as opaque strings do not care which version they receive.
For the id-vs-identifier question, when to use a UUID for a FHIR resource id vs a natural identifier is the entry.
Generation Considerations
v7 requires a monotonically-increasing millisecond clock. Nodes with clock skew produce v7 ids that break sort ordering — the id sorts "before" other ids created after it on a different node.
If your generation is distributed and clock skew is real, v7's sort benefit collapses. Stay on v4.
For the edge vs server question, generating UUIDs at the edge vs at the server is the entry.
The Short Version
Default to v4. Consider v7 only when scanning by creation time is a hot path and clocks are trustworthy. Both formats fit FHIR's id datatype. The performance win from v7 is modest and workload-specific.
Sources
- IETF RFC 9562 canonical UUID formats specification - IETF RFC 9562 canonical UUID formats specification including v7