Common Data Models Answer Half the Question

Almost 15 years ago, groups of researchers, ourselves included, thought that the raw data structure was the key organizing principle for cohort building. If the data were organized appropriately, the cohort creation process could work more efficiently and with better data fidelity. Common data models were not a new idea, but they gained prominence. But while they have been useful for some researchers, they could never be considered “widely adopted” — why is that?

Most likely, it is because a formal data model requires processing the entirety of the raw data into an inflexible structure before building a cohort. And since researchers already work with raw data all the time, it seems needlessly cumbersome to work with someone else’s formal process. Or, viewed another way, every research programmer already has their own “common data model” that they know and trust. No formal common data model required. Yet using either path, research is still slow and labor intensive. What are we missing?

It turns out that re-organization is only part of the problem. Creating a cohort requires the answer to two questions — what to search for, and where to search for it. Data organization only answers the second half, about where to look. The first part — what to look for — is defined almost entirely by code sets (ICD-10-CM, NDC, HCPCS, LOINC, etc.) that represent clinical constructs. Those are not defined by the data model in any way.

Code sets are hard to construct, they’re hard to store, they’re hard to update, they’re hard to validate. Ask any researcher how hard it is to source a code set, or how they know which version is the “current” one and whether it is still up to date. Diagnoses, procedures, medications, measurements, and other data all use different, highly complex systems, each with its own release schedule and its own quirks. Since “what to search for” is half of the cohort creation process, code set management is a real, unsolved problem.

It would be unfair to say that no one has tried to solve this issue. In addition to managing the OMOP common data model, OHDSI has created a broad vocabulary management system, and a growing library of shared “phenotype” definitions. However, an OMOP concept set is based on “standardized” concepts, which means the researcher is working with a translation of the clinical codes rather than with the actual codes in the data. So it works, but a colleague working outside OMOP cannot readily adopt it. For those researchers, there are repositories of code sets — VSAC, PheKB, ClinicalCodes.org, the HDR UK Phenotype Library, among others. We built one ourselves: in 2023 we released over 1,000 Jigsaw algorithms publicly and free, precisely because algorithms are hard to find and poorly documented. But ask researchers whether they actually use any of these. Mostly, they don’t.

So why are these existing solutions not enough? Are researchers being difficult? No, not at all. A code set typically exists as a list of codes and very little else — no clear statement of the clinical construct it was meant to capture, no rationale for why a borderline code was included or left out, no note of which vocabulary release it was built against, no indication of who reviewed it or when, and no record of which studies have used it and at which version. A list of codes simply cannot be evaluated. A researcher who declines to trust one is doing good science.

It’s tempting to think we can just push code set creation to AI. That is the worst version of this problem: everyone independently generating undocumented code lists, in seconds, compounding the challenges with human-created code lists. A bare list is no more evaluable for having been produced by AI.

Whether a code set comes from a colleague or from a model, the same thing is missing. The list itself is just a set of facts that nobody really owns. What is worth sharing, and what is worth trusting, is everything around the list: the clinical construct, the inclusion or exclusion deliberation, the vocabulary release, the authorship and review, the version history, the citation if it came from somewhere else, and the studies that have used it. In short, researchers need the full record. Sharing the full record turns “do I trust this” into a question about evidence. Sharing a bare list leaves it a question of faith.

So how do we actually make this work? If creating the record for a code set is a burden, nobody will do it, and there will be nothing meaningful to share. The record has to accumulate as a side effect of doing the work. Using a code set in a study should record the usage. Editing one should create a version. Creating one should generate a reason for each code included, and for each plausible code left out. Pulling one from a shared corpus should carry the citation along with it. What this adds up to is a well-documented, shared knowledge base of scientifically justified, fit-for-purpose code sets.

Not coincidentally, this is where AI earns its place. We can point AI at that knowledge base rather than having it invent from nothing. And we use AI to absorb the drudgery of maintaining the record itself — the rationale, the vocabulary release, the provenance — which is the work nobody has ever been willing to do by hand. Per-code rationale is the clearest case: explaining why each individual code belongs is the most tedious obligation in the entire record, and the one best suited to a model drafting and a human confirming. The burden that made the record impossible is the burden AI is actually good at removing.

We have our own version of a code set catalog coming out, and we hope it addresses the issues we see. It will be freely available, and designed to be used with, and by, AI models while remaining verifiable by humans. Get the code sets right, with their records intact, and they can be queried in any data model — ad hoc, home grown, or formal. Only then will we have fixed the other half of the problem.