Topics discussed:

• Nikolai's prototype takes the pragmatic route on terminology: load OMOP's Athena tables straight into the database and query them, rather than re-expressing them as FHIR terminology, which he sees as reinventing the wheel. From those tables he derives a profile for each resource type — the important part being a value set of codes he can prove are translatable — then flattens with a ViewDefinition and joins the Athena mapping table as a second layer. Craig McClendon offered up the mappings he already had: race and gender codes, and FHIR code system URLs to OMOP vocabulary IDs for all the standard ones.
• The value set is the ugly part. For observations it's thousands of codes; for condition_occurrence it would be millions of SNOMED concepts, which there is simply no sensible way to write down. John suggested representing the Athena systems in FHIR properly and using implicit value sets, or something like VCL, so the spec can talk about them without enumerating them — and then, at execution time, you're just running the query against the tables anyway.
• John's warning was political rather than technical: publish a parallel FHIR-to-OMOP mapping and the OHDSI community, who have been working on this for years, will not appreciate it. His preference is to improve the IG that already exists — it just needs ViewDefinitions, SQL and profiles in it. But he also thinks you can't have that conversation with an abstraction; you need a full end-to-end proof of concept first, or people just hear "you want to control what we're doing".
• John's validation loop is worth stealing: he has MIMIC-IV in FHIR, an OMOP database, and hundreds of published MIMIC studies with known cohorts and findings. So a candidate mapping isn't just checked field by field — you transform FHIR into OMOP, run the published analyses, and see whether the findings reproduce. As a side effect it tells you which parts of the CDM anyone actually uses, since some tables turn up in every paper and some appear to have barely been touched.
• Nikolai floated a direction the group hadn't considered: FHIR Group as a cohort. In R6 a Group is a canonical resource with characteristics and an expression, and OMOP has cohorts sitting at the top of everything, so if a Group could point at a Library — a SQL query over ViewDefinitions — you could define a cohort in FHIR terms and let the implementation decide whether to materialise it. Cohorts then compose into other cohorts. What's missing is the link from Group to Library, and Nikolai noted R6 hasn't published yet, so it isn't too late to ask.