Two lineages
Anatomic locations exist twice in OIDM. The first lineage is the original curated set published at anatomiclocations.org with two wrapper libraries. The second is the anatomic-locations package inside the findingmodel repository, with its own data file. They descend from the same curation effort and hold nearly the same concepts, but they are separate artifacts with different field names, different record counts, and no synchronization between them.
| Original lineage | Current lineage | |
|---|---|---|
| Data file | data/body_parts.json in anatomiclocations.org | notebooks/data/anatomic_locations_noembed.json in findingmodel |
| Records | 2,890 | 2,926 |
| Declared version | 1.0.0-rc.1, December 2022 | none |
| Data last changed | 2023-01-08 | 2026-03-02 |
| Consumers | BodyPartIndex.ts, BodyPartIndex.py | anatomic-locations Python package |
| Distribution | one JSON file plus bundled library data | DuckDB database fetched from a manifest |
The original lineage
Three repositories under the project lead’s personal account, all under the ISC license.
anatomiclocations.org holds the curated data, its JSON Schema, and a Jekyll site. The data changelog records one release, 1.0.0-rc.1 in December 2022, which added the version field and SNOMED links.1 The last commit on main is 2023-01-10, adding a tree view under Hierarchy. Three content-editing branches, add-data, content_update, and content_work, carry JSON edits and were never merged. The site lists a hierarchy browser and a search function as features not yet built.2
BodyPartIndex.ts is the TypeScript wrapper, published to npm as @talkasab/body_part_index with the data bundled in the package. It is the richer of the two wrappers, documenting local-code mapping and every hierarchy accessor.3 Its last commit on main is 2022-12-18.
BodyPartIndex.py is the Python wrapper. Its README says installation from PyPI is pending, and the site roadmap still lists “finish BodyPartIndex.py and publish to PyPI” as an open item.2 Its last commit on main, 2024-02-03, added a TODO list that remains the clearest statement of what that lineage intended next: move the repository to the openimagingdata organization, adopt ACR Common codes, acknowledge DICOM codes, track URLs, rewrite BodyPart as a Pydantic model, and on the website build a better tree browser and a way for people to submit suggestions about a specific node.4 None of those items is done in that repository. Several were done independently in the other lineage.
The current lineage
The anatomic-locations package lives inside findingmodel as one of five workspace packages and is published to PyPI in its own right. Its design was set by a plan completed on 2025-12-31 that replaced the flat export with a normalized model.5 Four things distinguish it:
- A rich Pydantic model.
AnatomicLocationsits at the same level asFindingModelFull, with region, classification fields, a laterality enumeration, and resolved reference objects. - Precomputed hierarchies. Because the database is rebuilt whenever the data changes, containment and part-of ancestry are stored as materialized paths, making ancestors, descendants, and containment tests string comparisons rather than recursive queries.5 A companion research note recorded why the adjacency-list plus recursive-CTE alternative was not chosen for a read-only database.6
- DuckDB distribution. The database is built separately from the JSON source, published to remote storage, referenced from a central
manifest.jsonalongside the finding model index, downloaded on first use, version-checked against the manifest, and cached locally.5 - Hybrid search. Full-text search combined with vector search over embeddings, with keyword-only fallback when no embedding key is available.7
The JSON source data is hosted outside the repository, with the migration tool reading either a dated URL or a local file.5 The copy checked into findingmodel at notebooks/data/anatomic_locations_noembed.json is the version this knowledgebase read, last changed 2026-03-02.
Which is current
The build plan states it plainly: the anatomic-locations package inside findingmodel and its 2,926-record dataset are the current anatomic data, and the original set with its wrapper libraries is lineage.8 Everything built since uses the package. The extraction and coding platform resolves locations through it, the finding model tooling attaches its identifiers to definitions, and the next-generation vocabulary work points at its data file pinned to a commit rather than at the older one.9
The original lineage is not dead content. Its data file is still the download the public site offers, its npm package still installs, and both are still reachable at the addresses published in 2022. It is superseded as the working set, not withdrawn.
What is unresolved
| Question | State |
|---|---|
| Synchronization | No process syncs the two datasets in either direction. Edits to one do not reach the other. |
| Record counts | 2,890 against 2,926. The difference has not been reconciled record by record, and no document states what the extra records are. |
| Repository ownership | Moving the original repositories to the openimagingdata organization was listed as a TODO in 2024 and has not happened.4 |
| Self-referential part-of | 111 records in the current file carry a partOfRef pointing at themselves, and one carries a self-referential leftRef. The build expects self-referential containment at the root, which is legitimate; this is not. |
| The “Spine” region | The curation field reference lists "Spine" among the common region values, but no record uses it and the runtime region enumeration has no spine member. Other parts of OIDM do use a spine region, so it is unclear whether the value was dropped deliberately or never added. |
| Empty classification fields | location_type, body_system, and structure_type are defined on the model and empty in the data, which is recorded elsewhere as the major shortcoming for anatomic scope statements.9 |
These are open questions rather than defects with owners. They are collected with the rest in open questions; the direction for the area is in the anatomic locations and RadLex roadmap. For how to use either lineage today, see tooling; for the record shapes, see the data model.