Topics discussed:

• Nikolai's proposal: store every ID and reference as a native uuid rather than a string — roughly half the disk space in Postgres, and native joins instead of parsing Patient/12345 apart at query time. UUID v5 hashes any string deterministically and has a notion of namespace, so IDs from different sources can be merged into one database without collisions. The worry that this constrains what upstream servers may store was answered: nothing changes upstream, you synthesise the column on load.
• Nikolai had gone further in his own experiments and hashed codings and identifiers into UUIDs too, so half a resource becomes one searchable bag of UUIDs. The objection: plenty of use cases need to see the actual codes and do value-set queries against them, and "an observation is a bag of codes" throws away the data model that scaffolds the vocabulary. It survived as an indexing trick, not a spec proposal.
• Josh asked whether a reference naming a specific version should work. The case for: a questionnaire answer pointing at the demographics as they stood when it was filled in — you don't want to retroactively pretend a different address was given. The case against: joins nearly always want the current patient, and honouring versions means rewriting references whenever anything updates. Agreed to declare it out of scope, but to say so explicitly rather than let it be an accident.
• The minimal transformation list converged on three: IDs, references, and date-times of varying precision. Identifiers got added, because you often need to join an Observation's subject to a Patient by identifier rather than by reference — with the end-user note that someone at a health plan searches by the member's ID number, not by whatever it was hashed into. Dates stayed the hard one; nobody had a concrete proposal, only the idea that every date becomes a start and an end at the appropriate precision.
• Contained resources have no good answer. You can't generate a columnar schema for them in general; in practice people either rely on the data being regular enough to derive one, or dump them into a string and never look inside it again. The tidiest observation was that a contained resource is fully identified by its container's ID plus its own, so any consistent combination of the two will do as a key.