Chapter 18: Build so that a machine can use it¶
In this chapter you will learn to:
- Explain what open standards and a common data model make possible.
- Map free-text values to a standard vocabulary and record the version used.
- Decide which registry tasks AI may touch and which need a named person.
Case study: A Network Study Built in the Open¶
The previous chapter ended with a registry whose fields only its builders could interpret. The other way to build is on open standards that anyone, and any tool, can read. In my own work that usually means the OMOP Common Data Model, maintained by the OHDSI community.
Converting data to OMOP is substantial work. Once it is done, the return is speed and openness. With the OMOP standardized vocabularies, searchable in the free Athena browser and built into every OMOP instance, I can look up a standard concept, include everything below it in the hierarchy, exclude what does not belong, and have a cohort quickly. Questions that are slow to answer in a bespoke data set become a cohort definition: who has infantile spasms, hypsarrhythmia, or West syndrome coded in any of its forms, together with intellectual disability and a feeding tube; or who has any diagnosis in a family of epilepsies, any cardiac diagnosis, or any diabetes diagnosis. The same process exposes problems in the mappings, including outdated ones, that would otherwise go unnoticed.
I contributed to a network study, led by Dr. Cindy Cai at Johns Hopkins, of semaglutide and nonarteritic anterior ischemic optic neuropathy (NAION). It ran across 14 databases in the OHDSI network, both administrative claims and electronic health records (Cai et al., 2025). Because every site had its data in the same model, every site could run the same queries, and the paper came together quickly, though it was still a great deal of work. Everything was done with free, publicly available tools and published in the open: the protocol, the cohort definitions, the concept sets, and the mappings. Anyone with an OMOP database can run the same protocol against their own data. When I want to see how a data set I am working with compares with that paper, I can take the concept sets from the study's GitHub repository, load them, and run them against my own instance.
That openness is also what makes the work easier for AI. Most of the vocabularies can be downloaded freely (a few require a license), the tools are documented, and training is available. A tool working with OMOP data does not have to guess at a proprietary structure that only its builders understand. The same is true of other open standards, including schema languages such as LinkML, which are a more advanced step for teams ready to take it.
OMOP does not solve every problem, and it is not the right model for every research question. Until electronic health record data capture everything a registry asks in surveys, through digital measures, and in conversation, a registry needs multimodal data, and in many cases multimodal data are the answer. The only way to know what the record holds is for a person to read it (Chapter 4). No AI can stand in for the human layer here: someone has to plan the structure, choose the standards, and decide what to tell the tool.
A coffee shop that keeps its recipes in standard measures can train a new barista, or open a second location, and serve the same drink. A registry built on open standards can share its protocol the same way.
Lessons for registry leaders¶
Open standards take work to adopt, and they return it as speed, reproducibility, and data that people and tools outside the registry can use. They do not replace multimodal collection or human judgment; they make both easier to share.
The rules¶
- Give an AI tool the same documents you would give a new analyst: the synopsis, the data dictionary, the tier definitions, and the curation log.
- Build on open standards wherever they fit: a common data model such as OMOP for health record data, and standard vocabularies such as HPO, Mondo, RxNorm, and LOINC, with ISO 8601 dates. Record the vocabulary version, because mappings change.
- Use the vocabulary hierarchies. Define cohorts by a standard concept and its descendants, with explicit exclusions, rather than by lists of local codes.
- Publish protocols, cohort definitions, and concept sets openly where you can, so another team can run them against its own data, and use theirs to check yours.
- Review mappings on a schedule; converting to a standard model shows which local codes map poorly or to outdated concepts.
- Keep multimodal collection. A common data model organizes the health record; surveys, digital measures, interviews, and biosamples answer what the record does not.
- Follow the FAIR principles as practical groundwork for AI, not only as an ethical commitment.
- Keep raw, curated, and derived data separate and labeled, so a tool cannot mistake one for another.
- Decide which tasks AI is allowed to touch in your registry and which require a named person, record the decision, and revisit it each year.
- Keep a person with lived experience in the loop whenever AI is used on community data.
What AI can do, and what only a person can do¶
What AI can do¶
The better the registry is built on open standards and documented, the more AI can do. It can draft concept sets and cohort definitions for review, and suggest vocabulary mappings for a person to check.
What only a person can do¶
Decide the standards; own the dictionary and the mappings; judge which questions the record can answer and which need another modality; be accountable for what the tool was allowed to do.
Take-home¶
Open standards make a registry's data readable by other people and by AI, without replacing multimodal collection or human judgment; nothing in this book replaces shoe leather, and everything in it is what makes AI useful on your data.
Practice¶
Exercise¶
- The
seizure_typesfield in the synthetic Lantern Registry export holds free text. List every distinct value, then map each to a term in the Human Phenotype Ontology (HPO). Record the term, its identifier, and the HPO release you used. - Decide what to do with a value that is not a seizure type at all.
- Fill in the AI use register for your registry: which tasks AI may do, which require a named person, and who reviews.
Check your work
| Value in the export | Standard label | Note |
|---|---|---|
| epileptic spasms, spasms | Epileptic spasm (HP:0011097) | Infantile spasms (HP:0012469) is more specific where onset in infancy is documented |
| infantile spasms | Infantile spasms (HP:0012469) | |
| focal | Focal-onset seizure (HP:0007359) | A more specific child term applies when awareness is documented |
| febrile | Febrile seizure (HP:0002373) | Confirm the current label in the release you use |
| tonic, GTC, bilateral tonic-clonic, absence | Look these up in the current HPO release | Record each identifier and the release |
| none | No term | Contradicts the seizure count for LR-018; raise a query |
| status epilepticus x2 | Not a seizure type as entered | An event count typed into a type field; record events in their own table |
Vocabularies change, so the release you used is part of the answer.
Your workbook page¶
The AI use register page of the Slow Registry Workbook applies this chapter to your own registry. Fill it in online or print it and work by hand. The AI prompt library has a prompt for this chapter's topic, paired with the step only a person can do.
Check your understanding¶
Why does a common data model such as OMOP make a network study faster?
Every site holds its data in the same structure with the same standard vocabularies, so the same protocol, cohort definitions, and concept sets run everywhere and can be shared openly.
Does a common data model remove the need for surveys and other data?
No. Until health record data capture everything a registry asks in surveys, through digital measures, and in conversation, a registry needs multimodal data.
Up next: The closing chapter walks the whole route once more, from planning through execution and the troubleshooting that never ends. Continue to the closing chapter.