Greenfield
Exam types are the one part of the OIDM semantic foundation with no artifact behind them. There is no exam type registry, no curated code list, no exam-to-body-part mapping, and no code anywhere in the OIDM repositories that parses an exam name into modality and anatomy axes. What exists is a goal that has been written down three times across four years, a short list of building blocks that a future exam type layer could stand on, and three working places where a bare LOINC code already does real work.
This document states the goals as goals and the facts as facts. It proposes nothing. The building blocks are catalogued separately in existing building blocks, and the area’s direction is tracked in the exam types roadmap.
The goal as the project lead states it
In the 2026-09-20 planning interview that produced the knowledgebase build plan, the project lead described the intended exam type work in three parts.1
- Wrapper tooling around an existing knowledge graph. The graph is the one represented by the LOINC/RSNA Radiology Playbook together with RadLex, rather than a new vocabulary built from scratch.
- A set of preferred high-level entries. Names at the granularity clinicians and systems actually use, such as CT Chest, MRI Brain, and X-ray Knee, marked as the preferred entry among the many Playbook codes that describe variants of the same study.
- Tight coupling to anatomic locations. Each exam type would carry typed edges 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 makes the artifact more than a code list. It answers the question a report reader and an extraction pipeline both need answered: given this study, what could have been assessed?
The same goal, stated earlier
The idea predates the current work by several years, in nearly the same words.
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.”2 The source spells LOINC as “LOIC” and RadLex as “Radlex”; the intent is unambiguous from the surrounding list. That page has not changed since January 2023.
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 Neither statement has produced an artifact. The anatomic location library was built; the exam type library was not. See site articles for the post in context.
What the Playbook actually is
The Playbook is a real, governed, external artifact, which is why every statement of the goal reaches for it rather than proposing a new vocabulary.
It is the radiology portion of LOINC, developed jointly by the Regenstrief Institute and the RSNA, naming imaging orderables along axes such as modality, anatomy, and technique. The next-generation vocabulary analysis records it as “actively governed, and freely licensed for commercial and non-commercial use,” shipping “twice yearly under joint Regenstrief/RSNA governance,” and stresses that it “is a separate artifact” from RadLex itself.4 RadLex cites the Playbook as free-text provenance on individual concepts, but carries no link to it.
Two consequences matter for anyone reading exam type material in these repositories. Current Playbook content is identified by ordinary LOINC codes, not by a separate scheme: “RadLex Playbook (RPID) was folded into LOINC; new procedure codes are LOINC format, not new RPIDs.”5 Legacy RPID identifiers therefore appear only as historical codes that a crosswalk would need to recognize. And the division of labour between the two RSNA-associated vocabularies is explicit: radiology “orderables live in the LOINC/RSNA Radiology Playbook, while findings, anatomy, and report language live in RadLex.”5
How exam types are used today
Three uses exist now. All three run on a bare LOINC code with no exam type object behind it.
As the exam header of an Exam Finding List. The specification requires that the structure “must also have basic information (keyed by a curated list of LOINC codes) about what exam this is.”6 In the data this is examInfo.studyLoincCode beside studyIdentifier, studyDateTime, and a free-text studyDescription; the domain notes give 72133-2 for CT Abdomen and Pelvis Without Contrast as the worked example.7 The Imaging Problem List carries the same pair forward on every observation as exam_type_code and exam_type_display, which is how a finding’s time course is labelled by study. The curated list of LOINC codes that the specification refers to has never been published.
As the fallback body region for a finding with no anatomy. The anatomic location assignment rules used by the extraction and coding platform put the exam at the bottom of a three-step precedence ladder. Explicit anatomy in the report text or section context wins; otherwise the finding’s own target organ; otherwise, for findings with no anatomic noun at all such as “soft tissue mass” or “generalized osteoporosis,” the rules “fall back to the exam-scoped coarse region (thorax, abdomen, head, …), sided only if the exam is sided.”8 The exam also supplies laterality under a stated source priority of explicit text side, then sided-exam side, then generic, so that a left shoulder radiograph sides its findings while an abdominal CT never introduces a side. The rules carry a small exam-to-region table of RadLex identifiers, reproduced in existing building blocks.
As a display label. The viewer shortens long exam descriptions for its timeline through a lookup table, turning “MR Brain WO and W contrast IV” into “MR Brain w/wo.”9 The table is keyed by the description string, not by the LOINC code.
Exam type as the boundary of a finding model’s scope
Exam types also bound the semantic foundation’s other axis. The finding model overview states the rule directly: “the scope of a finding model should match what’s assessable on a given exam type, not broader.” Its examples are that “fracture” is too broad because it spans the whole body, “chest wall fracture” is appropriately scoped to what is visible on a chest radiograph, and “upper abdominal abnormality” is appropriately scoped for chest CT because the upper abdomen is in the field of view.10 The full passage is preserved in the finding model overview extract.
That rule is applied today by judgment. Nothing checks a finding model’s scope against a coded exam type, because no artifact exists to check it against.
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 ↩
-
Current understanding, ACR-RSNA-CDEs next-gen-2026 ↩
-
imaging-problem-list README, main branch ↩
-
imaging-problem-list domain model, dev branch ↩
-
Anatomic location assignment rules, imaging-problem-list dev branch ↩
-
Viewer exam type display mapping table ↩
-
“Finding Models: Overview”, ACR-RSNA-CDEs next-gen-2026 ↩