Anatomic location data model

Scope

This document describes the record: what an anatomic location carries and what each field means. The verbatim JSON Schema and the full runtime field list live in the anatomic location record format reference. Two datasets exist and are not reconciled with each other, so both are described here; lineage and current implementation says which is current and why.

Dataset	Records	Version	Field naming
body_parts.json, the original curated set	2,890	1.0.0-rc.1	radlexId, containedById, leftId
anatomic_locations_noembed.json, the current curated set	2,926	undeclared	_id, containedByRef, leftRef

The identifier

Every record is keyed by a RadLex identifier. The original schema constrains it to the pattern ^RID\d+(_RID\d+)*$, which admits both a plain identifier and a composite one.¹

A composite identifier is how a sided variant is named. RadLex has modifier concepts for left (RID5824) and right (RID5825), and a sided structure joins the base to the modifier with an underscore. The left uterine adnexa is RID294_RID5824; the right is RID294_RID5825. Of the 2,926 current records, 1,910 carry a plain RadLex identifier and 1,016 are composite. The original set has 1,880 plain identifiers among its 2,890 records.

Composite identifiers are a local convention, not RadLex content. The next-generation vocabulary work records them as “the exception the RadLex track will remove by minting real ids.”²

Descriptive fields

Field	Both lineages	Meaning
description	required	Lowercase display name, one per record
synonyms	optional	Clinical shorthand; 1,126 records in the original set, 1,156 in the current one
definition	current set only	A brief definition with its source in brackets, on 278 records
sexSpecific	optional	Male or Female; 110 records in both sets

sexSpecific is present in the current data but absent from that lineage’s field reference, along with a stray anatomicLocationsId on a single record.

The two hierarchies

Every record carries a containment parent. The distinction between the two hierarchies is stated on the original project’s code page: the contained-by hierarchy is “physically contained in,” as a kidney is in the retroperitoneum, and the part-of hierarchy is “a component of a larger structure or system,” as the adnexa are part of the female genital system.³ See contained by and part of.

Relation	Original field	Current field	Coverage in the current set
Spatial parent	containedById (required)	containedByRef	2,926, every record
Spatial children	not stored	containsRefs	186
Mereological parent	partOfId	partOfRef	1,123
Mereological children	not stored	hasPartsRefs	334

The original set stores parent pointers only and lets a library derive children. The current set stores both directions as {id, display} reference objects, so a consumer can read a node’s children without indexing the whole file. Containment is a rooted tree from RID39569, whole body. The part-of relation covers fewer than half the records and is not a tree.

Two data defects are visible in the current file and are worth knowing before traversing it. 111 records carry a partOfRef pointing at themselves, and one carries a self-referential leftRef. The build process already expects self-referential containment at the root, which is legitimate, but self-referential part-of on 111 nodes is not.⁴

Laterality triads

A sided structure is represented by three records, not by a flag on one. The generic record carries leftRef and rightRef; each sided record carries unsidedRef back to the generic one and a reference to its counterpart. The full convention, including the containment and synonym rules for sided entries, is in laterality conventions. See also laterality.

Field	Original set	Current set
Left variant	leftId, 1,611	leftRef, 1,625
Right variant	rightId, 1,611	rightRef, 1,625
Generic variant	unsidedId, 1,584	unsidedRef, 1,597

Classification

The current set adds a region to every record, one of nine values. The runtime model exposes it as an AnatomicRegion enumeration with exactly those nine members.⁵

Region	Records	Region	Records
Head	869	Abdomen	212
Upper Extremity	582	Pelvis	152
Lower Extremity	579	Breast	46
Neck	235	Body	25
Thorax	226

The field reference for the curation format lists "Spine" among the common region values, but no record uses it and the runtime enumeration has no spine member.

Three further classification fields exist on the runtime model and are empty in the data: location_type (structure, space, region, body part, system, group), body_system (ten systems), and structure_type (roughly forty finer types, set only when the location type is structure).⁶ The next-generation vocabulary analysis confirms this, recording that “the package’s structure-type, body-system, and location-type fields exist but are empty in this data,” and names the absence of a type relation over locations as “the major shortcoming” for scope statements of the form “applies to tendons.”² See anatomic scope.

External codes

Both sets cross-reference other terminologies. The original set puts every code in one codes array of {system, code}. The current set promotes SNOMED CT to its own pair of fields with a display name, adds an ACR Common identifier, and leaves the rest in codes.

Code	Original set	Current set
SNOMED CT	1,732 in codes	1,782 as snomedId with snomedDisplay
FMA	1,643	1,649
UMLS	578	580
MeSH	232	233
ACR Common	absent	2,025 as acrCommonId
Any code at all	2,282 of 2,890	2,318 of 2,926

SNOMED coding follows one rule without exception: of the Structure, Entire, and Part concepts in a SNOMED anatomy triad, use the “Structure of” concept, because that is what SNOMED intends for finding sites and procedure sites.⁷

A real record

The current format, unchanged from the data file. It shows containment, part-of, a synonym, three codes, and a definition with its source.

{
  "_id": "RID10021",
  "acrCommonId": "4013944",
  "snomedId": "81502006",
  "snomedDisplay": "Hypopharyngeal structure",
  "description": "hypopharynx",
  "region": "Neck",
  "containedByRef": { "id": "RID7488", "display": "neck" },
  "synonyms": ["laryngopharynx"],
  "partOfRef": { "id": "RID13211", "display": "pharynx" },
  "codes": [
    { "system": "FMA", "code": "54880" },
    { "system": "MESH", "code": "A14.724.490" },
    { "system": "UMLS", "code": "C0014540" }
  ],
  "definition": "The portion of the pharynx between the inferior portion of the oropharynx and the larynx. [MeSH]"
}

From record to usable object

The curation format is what an editor changes. The package that consumes it normalizes each record into an AnatomicLocation object, resolves the reference objects, adds a laterality enum, and precomputes a materialized containment path and part-of path so that ancestry, descendants, and the “is X inside Y” test are string comparisons rather than recursive walks.⁴ A location converts to an index code with system anatomic_locations, its RadLex identifier as the code, and its description as the display, which is the form it takes when attached to a finding model.⁶

Footnotes

1. body_parts_schema.json, anatomiclocations.org ↩

2. The anatomy axis, current state, ACR-RSNA-CDEs next-gen-2026 ↩ ↩²

3. anatomiclocations.org data file description ↩

4. Rich anatomic location DuckDB with relationships ↩ ↩²

5. Anatomic location enumerations, anatomic-locations package ↩

6. AnatomicLocation runtime model, anatomic-locations package ↩ ↩²

7. Anatomic Locations source JSON field reference, findingmodel ↩