Topics discussed:

• OMOP's person_id is an integer — not even a big integer — so hashing FHIR ids into it risks collisions in a space far too small to hash into safely. The leaning was to copy what OMOP already does with its own concept IDs: a lookup table that hands out counter-style surrogate keys, with the original id preserved in person_source_value. Compact integer keys are the point of the column, since everything in OMOP is joined on them.
• OMOP only pays off if every code is mapped into its standard vocabulary — that is the whole "write the query once, run it on any dataset" promise, and it doesn't hold otherwise. The gap is that no OMOP concept IDs exist for FHIR code systems, so *_source_concept_id is left empty and the original coding is simply lost. Two ways out were floated: load FHIR code systems into OMOP and assign them concept IDs, or have Usagi emit a FHIR ConceptMap alongside the mapping table it already produces, so a translate() in FHIRPath could use it.
• The mismatches aren't mechanical. OMOP's SNOMED is a concatenation of versions rather than the FHIR code system, so the URIs don't line up. US Core splits race into a category and a detailed race while OMOP has a single race concept — coarser than detailed, finer than category — so somebody has to decide the fallback. OMOP has one location per person while FHIR addresses repeat, so you pick one and invent an id for it. And several resource types feed that one location table, which a single-resource ViewDefinition cannot express at all.
• That list adds up to a wish list — translate(), a date-part function, something like coalesce — and the group leaned against all of it. Flatten with ViewDefinitions into intermediate tables and finish in plain SQL or a DBT-style pipeline, because the database already has date extraction and conditionals. (Date components do exist in FHIRPath, as trial-use functions in the current build — the FHIRPath spec itself hasn't been published in years.) The sharper argument was cost: every FHIR server would have to implement translate() and hold the ConceptMaps, which is a lot to ask and would cut adoption.
• For the functions that don't make the cut, someone proposed borrowing JSON Schema's habit of draft keywords: not required, not part of the spec, but with a definition and test cases in a separate folder, so promoting one later is a file move. The worry on the other side is implementations forking by extension — and a related gap, that the spec says nothing about what a runner should do when it meets FHIRPath outside the core subset.