Next-generation CDE vocabulary

What this document is

A redesign of the ACR and RSNA common data element model is being drafted on the next-gen-2026 branch of RSNA/ACR-RSNA-CDEs. This document records what that branch defines, read at commit 44836c1 of 2026-09-15.

It is in-progress design work in an allied project. It is not an Open Imaging Data Model (OIDM) specification, it has no open pull request, and its own root glossary says the definitions “express our current ideas … not a jointly settled integration model.”¹ Nothing here is implemented in any OIDM repository. It is documented because the ideas are named as direction for OIDM’s own next steps.

The branch’s working documents state the framing plainly: the project defines the vocabulary of radiology results, meaning the terms available for saying what was seen and how it is characterized, and not the grammar by which an individual result is assembled. The grammar comes from the IHE Imaging Diagnostic Report profile.² See IHE IDR alignment.

The working vocabulary

The branch keeps a root CONTEXT.md defining the terms in use. Each definition below is quoted or condensed from it.¹

Term	Definition
DataElement	”A categorical descriptor whose permissible values may be ordered or unordered.” Semantic ordering is explicit and distinct from display order
Categorization	A distinction expressed either by a categorizing DataElement or by a taxonomy of named classes, “not both for the same distinction in the same model”
Measurement	”A quantitative descriptor, distinct from a DataElement.” Its measurement method is optional and unspecified by default
Element binding	A relationship connecting a definition to a DataElement it uses. A binding may restrict the use to a subset of the element’s permissible values “without changing the shared element or its other bindings”
Selection cardinality	The permitted number of values selected for a DataElement in a use, such as single or multiple selection. Distinct from value ordering and from component counts
Modality applicability	The modalities on which a finding can be seen or a descriptor evaluated. A descriptor’s intrinsic limit “is distinct from its binding-specific applicability and is not an overridable default”
Unspecified modality applicability	Omission alone “means neither applicability to every modality nor exclusion from every modality”
AssessmentScheme	A distinct definition of an assessment system whose descriptive dimensions are ordinary DataElements linked to the scheme
AnatomicLocation	An anatomical reference identified by its RadLex identity, able to bind directly to DataElements and Measurements without a FindingClass
Component-of scope	The finding classes a component class belongs inside, stated on the component class. “A class with a component-of scope is never reported on its own”
Lesion family	A group of related lesion types, usually specific to a location. Component classes are lesion-family specific
Standard clinical metadata	”The seven facts on a class: modality, body region, subspecialty, sex, age, time course, and etiology”
Anatomic scope	The eligible anatomical places, tissue types, or structure types for a definition. A plain list matches any one target by default
Anatomy scope specifier	A concept used to identify eligible anatomy. How the families connect to the location hierarchy “remains open”
Tissue-type scope	A scope family exemplified by pulmonary parenchyma, hepatic parenchyma, and subcutaneous fat
Structure-type scope	A scope family exemplified by solid organs, vessels with artery and vein subtypes, muscles, tendons, and ligaments

Neither scope family, the glossary notes, by itself prescribes a separate graph node type.¹

The graph shape

The model is a graph rather than a document format. Nodes carry only scalars; everything shared is a node, and everything pointing at something shared is an edge. Flat text forms are serializations of the graph, not the model.³

FindingClass and Diagnosis are separate node types. The branch records the separation as a structural decision, and the relationship documents state what is left to distinguish them: with one unrestricted taxonomy spanning both labels, the only structural difference is which relationship types a node can source.⁴ A third negative-only node type, Grouping, exists so that a statement such as “no renal abnormality” has something to point at.³

Relationships are explicit and typed, and each carries its own identifier so that a report-level assertion can cite the standing potential it expresses.³ Eight relationship pairs plus a catch-all make up the finding and diagnosis family.⁴

Relationship	Character
SUBTYPE_OF	Taxonomy. Never propagates another outgoing edge
MAY_HAVE_COMPONENT	Compositional. The target occurs as a described sub-part
MAY_CAUSE	Causal. The source produces the target as a distinct second entity
MAY_MANIFEST_AS	Evidential. The diagnosis shows itself as the target
OCCURS_WITH	Symmetric association, asserting nothing about cause or sequence
MAY_PROGRESS_TO	Temporal. Identity-preserving evolution
ASSESSED_BY	Interpretive. A standardized scheme applies to the source
MAY_BE_RELATED_TO	Symmetric catch-all, “a triage queue, not a home”

Keeping manifestation and causation apart is the load-bearing distinction. Manifestation is constitutive: a striated nephrogram is pyelonephritis appearing on imaging, not a second disease. Causation is consequential: a renal abscess is a new thing pyelonephritis made. The stated test is whether a clinician would say the source “got better” or that “a complication resolved.”⁴

Manifestation edges carry two optional, independent properties. Typicality adopts the HPO and Orphanet frequency scale verbatim, with its percentage anchors, from obligate at 100 percent down to very_rare at 1 to 4 percent and excluded at zero. Specificity has three ordered values, pathognomonic, highly_suggestive, and suggestive, and is omitted entirely when no judgment is recorded.⁴

The differential is a derived view, not an edge. It is computed by traversing the manifestation relation from a finding to the diagnoses that can produce it, filtering by context edges such as age stage, modality, and anatomic scope, and ranking by specificity then typicality. No DIFFERENTIAL_OF edge type exists. The cited precedent is the Radiology Gamuts Ontology, which derives every differential from is-a and may-cause links alone.⁴

The anatomy axis

RadLex is the substrate. The branch’s position, recorded in its anatomy summary, is that the anatomic locations data behind the published anatomic-locations package, 2,926 locations each keyed by a RadLex identifier, is an overlay on RadLex, not a replacement and not the sole source, and is the basis of the RadLex anatomy axis going forward, because the RadLex anatomy track is editing it rather than the published release.⁵ The file is pointed at and pinned to a commit, not copied. A location’s identifier is its RadLex identifier, and no separate RadLex code is written beside it.⁵

A gap log tracks what the overlay cannot yet express and what should be requested upstream.⁶ The major shortcoming is recorded as the absence of any is-a relation over locations and the absence of structure-type nodes, so a scope statement of the form “applies to tendons” cannot currently be made. The log’s running node request list names lung parenchyma, perirenal space with its sided forms, pericardial space, subarachnoid space, and real RadLex identifiers for the 1,016 compound sided variants the file mints locally.⁶ An interim layer derived from RadLex 4.3’s own is-a hierarchy is proposed to cover the gap until the overlay ships one.⁵

See RadLex integration and lineage and current implementation for the OIDM side of the same data.

The display grammar

The branch specifies two generated pictures, both deterministic SVG built from the canonical graph.⁷ The mat is the view of one context object one hop out: the object is drawn in full with a fixed card frame of seven zones, a title line with name and identifier, an anatomy line, definition and synonyms, an attribute table, dotted containers each labelled with one relationship read from the context object’s side, a mappings line of external codes with their preferred terms, and a bottom stat row of seven fixed cells for modality, region, subspecialty, sex, age, course, and etiology; everything connected to the object arrives as a mini-card inside the relevant container, edges carrying typicality or specificity draw as a dotted box around the mini-card with those values on its bottom border, and there are no wires or arrowheads at all, because containment replaces them. The tree is the zoomed-out is-a view of a family: one mini-card per row, indented by subsumption, rooted at a grouping node, with a click layer on the site that boxes every related card. The stated reason for both is that the committee approving the vocabulary is made of radiologists, so a picture earns its place when one of them can look at a real clinical family and either agree or point at what is wrong.⁷

The alpha implementation

An alpha implementation contributed by a collaborating reviewer sits under docs/next-gen-schema/alpha/ and is treated as an external subtree by the branch’s own bundle checker. Its generated shape documentation, built on 2026-09-14, reports a definition graph of 347 nodes and 758 edges across eleven node types.⁸

Node type	Count
Value	155
FindingClass	45
DataElement	36
AnatomicLocation	28
Diagnosis	25
Subspecialty	19
Measurement	16
Etiology	10
Modality	7
AssessmentScheme	5
AnatomicRefinementRule	1

The 45 FindingClasses compile to flat JSON shapes with references resolved, which the shape document names as the vendor-facing deliverable; the OWL serializations are described as a design-time checking instrument rather than something consumers reason over. The document states directly that “there are no instances.”⁸ The alpha’s README states that RadLex is the single source of truth for anatomy, that the generated ontology imports the configured RadLex release directly, and that the model creates no parallel CDE anatomy hierarchy and no CDE replacements for RadLex anatomy predicates; it was built and verified against RadLex release 4.3.⁹ The branch’s handoff document names the alpha as the foundation for the work going forward and lists resolving structural differences, anatomic locations first, as the active direction.¹⁰

A stated direction for finding models

The branch’s notes/ directory carries a copy of a FindingModel source schema version 2 draft, dated 2026-04-20 and marked “a proposed authoring schema, not an implementation-complete contract yet.”¹¹ It proposes splitting a finding model into a source file and a hydrated output, moving shared attributes such as presence and change from prior into canonical attribute files that a source model references instead of redefining, storing only the authored side of a relationship and deriving inverses from a relationship-type registry, and adding a quantity-kind registry and per-model history sidecars.

The relationship documents note that this registry exists only in the version 2 draft, and that the live findingmodels repository implements no relationship mechanism at all.⁴ The draft is a stated direction, not a shipped format.

Why this matters for OIDM

The knowledgebase build plan places these ideas in the roadmap rather than in the specification: the relationship and graph ideas from this CDE work are listed among the inputs to the finding model format evolution roadmap, alongside the canonical metadata rewrite and schema versioning, and the Imaging Problem List data model work is tracked separately as its own roadmap entry.¹² See finding model format evolution and the Imaging Problem List data model system.

Three points of contact are concrete today. The vocabulary terms above are already in this knowledgebase’s glossary, because OIDM documents use several of them. The anatomy overlay named as the basis of the RadLex anatomy axis is OIDM’s own anatomic locations data. And the finding model schema version 2 draft is an OIDM artifact circulated in the CDE work, not a CDE artifact.

Footnotes

1. CDE vocabulary, the working glossary at the root of the next-gen-2026 branch ↩ ↩² ↩³

2. Next-Generation CDE Schema, Current Understanding ↩

3. Draft Structures for Worked Examples, the node and edge catalog ↩ ↩² ↩³

4. The Finding and Diagnosis Relationship Family ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

5. The Anatomy Axis, Current State ↩ ↩² ↩³

6. Anatomic Locations Gaps and Node Requests ↩ ↩²

7. The Mat and the Tree, the display grammar ↩ ↩²

8. The shape of the knowledge graph, generated from the alpha build of 2026-09-14 ↩ ↩²

9. RadElement next-generation alpha, anatomy architecture and rebuild instructions ↩

10. Next Steps and Open Threads ↩

11. FindingModel Source Schema v2 Draft ↩

12. Knowledgebase build plan ↩