The state of the area
There is no exam type artifact. No registry, no curated code list, no exam-to-body-part mapping, and no code anywhere in the Open Imaging Data Model (OIDM) repositories that parses an exam name into modality and anatomy axes. What exists is a goal stated three times across four years, one written design that has not been implemented, and three places where a bare LOINC code does real work today.
The area as it stands is described in exam types, and the inventory of what a future effort would start from is in existing building blocks. This document collects the goals and the open questions.
The goal as the project lead states it
In the 2026-09-20 planning interview recorded in the knowledgebase build plan, the project lead described the intended work in three parts.1
- Wrapper tooling around an existing knowledge graph, namely the graph represented by the LOINC/RSNA Radiology Playbook together with RadLex, rather than a new vocabulary.
- A set of preferred high-level entries, at the granularity clinicians and systems actually use, the examples given being CT Chest, MRI Brain, and X-ray Knee, each marked as the preferred entry among the many Playbook codes describing variants of the same study.
- Tight coupling to anatomic locations, with typed edges from an exam type to the structures it covers, distinguishing anatomy that is always included, which may be expressed as a hierarchy rather than a flat list, anatomy that is usually included, and anatomy that is possibly included and must be checked.
The third part is what would make the artifact more than a code list. It answers the question both a report reader and an extraction pipeline need answered: given this study, what could have been assessed?
The same goal, stated earlier
The idea predates the current work in nearly the same words, twice.
The curated anatomic location set’s roadmap lists, among content tasks, work on “a companion for exam types based on LOINC/RadLex Playbook exam definitions that specify all included body parts for the exam.” That page has not changed since January 2023.2
The site post “Data Model: Structure and Function” of 2024-01-25 names two utility libraries alongside the core model: anatomic locations for standardized body part terminology, and an exam type library based on the LOINC and RSNA Playbook, linked to anatomic locations.3 The anatomic location library was built. The exam type library was not. The post is summarized in site articles.
The one written design
The most developed written design is in the terminology tool’s product roadmap, which proposes replacing an ever-growing default search with named, inspectable domain profiles. Its radiology profile makes the Playbook first-class: RadLex, LOINC weighted toward the Playbook, SNOMED CT, and FMA, with UMLS as the crosswalk hub.4
Four Playbook-specific implications are stated in it: rank procedure and orderable queries toward Playbook terms and finding queries toward the other vocabularies; teach the crosswalk the Playbook correspondences, linking a LOINC code to its historic RPID and to RadLex anatomy and modality attributes, recording that in the mapping provenance; detect RPID codes as well as LOINC-shaped codes; and do not treat every LOINC hit as radiology.4
None of it is built. The repository’s issue backlog follows a six-phase design as one tracking issue plus eleven focused ones, of which only typed provider failures is closed; the profile mechanism is part of that backlog, not a released capability.5 See med-ontology-lookup.
Two facts from the next-generation vocabulary analysis constrain any such effort and are worth stating with the goals. The Playbook is “actively governed, and freely licensed for commercial and non-commercial use,” shipping twice yearly under joint Regenstrief Institute and RSNA governance, and it “is a separate artifact” from RadLex.6 Current Playbook content carries ordinary LOINC codes; RPID identifiers are legacy and appear only as historical codes a crosswalk would need to recognize.4
What is unanswered
Four questions have no answer in any source, and are carried in open questions.
The curated list does not exist. The Exam Finding List specification requires exam information “keyed by a curated list of LOINC codes.”7 That list has never been published. Every producer of an Exam Finding List today chooses its own code.
LOINC descriptions are inconsistent in the data. Across the twelve sample Exam Finding Lists, one code, 29252-4, carries two different description strings in different files, and two different codes, 36952-0 and 72133-2, carry descriptions naming the same study, an abdomen and pelvis CT without contrast. Both are the kind of thing a curated list would resolve, and neither is resolved.
Preferred display names exist only as an application convenience. The viewer shortens long exam descriptions through a seven-entry lookup table keyed by the description string rather than by the LOINC code, so two description strings in the data fall through unshortened.8 This is the closest thing in the repositories to a preferred name per exam type.
Nothing checks finding model scope against an exam type. The authoring guidance states that “the scope of a finding model should match what’s assessable on a given exam type, not broader.” That rule is applied by judgment today, because no coded artifact exists to check against. See exam types.
Who owns this area is also unstated. No repository claims it, no issue tracks it, and the three statements of the goal come from three different repositories.
Footnotes
-
Exam type goals stated by the project lead in the 2026-09-20 planning interview ↩
-
anatomiclocations.org roadmap ↩
-
“Data Model: Structure and Function”, 2024-01-25 ↩
-
GitHub issue backlog, med-ontology-lookup ↩
-
Current understanding, ACR-RSNA-CDEs next-gen-2026 ↩
-
imaging-problem-list README, main branch ↩
-
Viewer exam type display mapping table, dev branch ↩