Anatomic locations and RadLex

Incorporation into RadLex

The January 2026 deck states that the anatomic locations are “being formally incorporated into RadLex by an RSNA committee.”¹ The evidence for that statement is one tracking issue, RSNA/RadLex issue 3, “Add Anatomic Locations,” opened 2026-08-10 and open. Its exit criterion is a single line: “100% coverage of the Anatomic Locations terminology in RadLex.”²

No code, commit message, or document inside the RSNA/RadLex repository mentions anatomic locations, body parts, or OIDM. The relationship exists at the issue level; the ontology content is not there yet. The issue has no comments and no sub-issues. See RadLex integration.

The overlay agreement

A more specific agreement, dated 13 September 2026, is recorded in the next-generation vocabulary work on the next-gen-2026 branch of ACR-RSNA-CDEs. The anatomic locations file is an overlay on RadLex, not a replacement and not the sole source: RadLex concepts and predicates sit underneath, and the file adds identifiers RadLex lacks, its own containment and part-of hierarchies, and laterality.³

Two consequences are already written into that vocabulary. An anatomic location carries one identifier, its RadLex identifier, and a RadLex code is never shown beside it, because the location code is the RadLex code. And the compound identifiers for sided variants that RadLex lacks, such as RID1363_RID5825, are an acknowledged exception the RadLex track is expected to remove by minting real identifiers.³

The same record states that the overlay file is “the basis of the RadLex anatomy axis going forward,” because the RadLex anatomy track is editing it rather than the published release.³

Two framings of the relationship are therefore in force, and nobody has reconciled them. The issue’s exit criterion, full coverage of the terminology in RadLex, reads as absorption. The September agreement describes an overlay that RadLex edits in place. The two are compatible but not identical, and no source says which governs. It is carried in open questions.

The scale of the sided-variant exception is worth stating with it: 1,016 of the 2,926 records carry a composite identifier, so more than a third of the set is not resolvable as a RadLex identifier until real ones are minted.

What is owed in each direction

The gap log on that branch is the tracking artifact, kept deliberately separate from the wider design discussion so it can move independently.⁴ The full list of node requests, with the reason and date for each, is reproduced in RadLex integration. Two items are worth naming here because they are structural rather than individual concepts.

From OIDM to RadLex: real identifiers for sided variants. Raised 2026-09-13, needed by every sided Observation.

From RadLex to OIDM: an is-a relation and structure-type nodes. Raised 2026-08-19 and restated 2026-09-13 as the top priority. The curated set has no is-a relation and no structure-type nodes, which is recorded as its major shortcoming, because it blocks any scope statement of the form “applies to tendons.” RadLex 4.3 has an is-a chain for every one of the 1,910 plain-identifier locations, and the stated work item is a derived, pinned overlay file handed to the anatomic locations track. Two cautions accompany it: RadLex’s own release note warns that some is-a categorizations were converted from part-of and may be wrong, and the FMA-style chain is not the clinically useful layer.³

Coverage of external codes is uneven and is recorded as a gap rather than assigned as work: SNOMED CT on 1,782 of 2,926 records, with 608 records carrying no codes at all.⁴

The two datasets

Two lineages coexist and are not synchronized: the original 2,890-node set published at anatomiclocations.org with its two wrapper libraries, and the 2,926-record dataset inside the anatomic-locations package in findingmodel, which the build plan names as current.⁵ The differences and the open questions between them are set out in lineage and current implementation.

Reconciling the record counts is stated nowhere as work. No document says what the extra 36 records are, and no process syncs edits in either direction.

Items carried forward from the original libraries

The clearest statement of intent for the original lineage is the TODO list added to BodyPartIndex.py on 2024-02-03. None of its items is done in that repository, and several were done independently in the current package.⁶

Item	Status
Move the repository to the openimagingdata organization	Not done. The three original repositories remain under the project lead’s personal account
Update to use the ACR Common codes	Not done anywhere
Update to acknowledge the DICOM codes	Not done anywhere
Add the ability to track URLs of various kinds	Not done
Rework BodyPart as a Pydantic model	Done in the current package, not in the original library
Reconfigure the index as a proper singleton	Not done
Make the website tree browser better, and add a way to submit suggestions about a specific node	Not done. The site still lists a hierarchy browser and search among features not yet built7

The site roadmap additionally lists finishing BodyPartIndex.py and publishing it to PyPI, which has not happened.⁷

Tooling

The project lead stated in the 2026-09-20 planning interview that the area needs tooling for the people who work with anatomic locations, meaning curators and coders rather than library consumers.⁵ What exists today, the package, its command-line interface, the curation skill, and the older wrappers, is described in tooling.

Four concrete items sit in the findingmodel repository against that surface.

• Hierarchy-aware related models. A task on dev records that related_models() requires an exact identifier match today and therefore misses hierarchy-aware relations.⁸
• Graph representation research. A note on main works through representing the containment and laterality graph in DuckDB and records why the adjacency-list plus recursive-query alternative was not chosen for a read-only database.⁹
• Issue 39, laterality assigned left and right backwards during the build.¹⁰
• Issue 38, anatomic location search returning irrelevant results for multi-word queries.¹¹

Search quality is not a side issue for the RadLex relationship. The search and curation pipeline in the RadLex repository lives on an experiment branch rather than on main, and its search plan names the failure mode any gap list has to avoid: a concept lookup that silently returns nothing leads a consuming agent to conclude the concept is missing, which pollutes a candidate list with duplicates of concepts the ontology already has. Its stated goal is “recall good enough that a MISS is real evidence of an ontology gap rather than evidence of unlucky phrasing.” See RadLex integration.

Four body region enumerations

Body region is enumerated four incompatible ways across OIDM: in the anatomic locations package, in the finding model metadata rewrite, in the extraction schema, and in the viewer’s filter. Thorax against chest, and whether spine is a region at all, are the recurring mismatches. No document reconciles them and no source assigns the reconciliation. It is carried, with the rest of the area’s unresolved items, in open questions.

Footnotes

1. “Open Imaging Data Model 2026 Status Update”, January 2026 ↩

2. RSNA/RadLex issue 3, “Add Anatomic Locations” ↩

3. The anatomy axis, current state, next-gen-2026 branch ↩ ↩² ↩³ ↩⁴

4. Anatomic locations gaps and node requests, next-gen-2026 branch ↩ ↩²

5. Knowledgebase build plan ↩ ↩²

6. BodyPartIndex.py TODO list, 2024-02-03 ↩

7. anatomiclocations.org site homepage and roadmap ↩ ↩²

8. Anatomic-hierarchy-aware related models task, findingmodel dev branch ↩

9. Anatomic locations graph representation research note, findingmodel main branch ↩

10. findingmodel issue 39 ↩

11. findingmodel issue 38 ↩