CDE staging

What it is

CDEStaging is where candidate common data element definitions collect before anyone tries to make them official. Its README states the purpose in one line: “a staging area for definitions of radiology common data elements (CDEs) in JSON format … prior to their entering the review pipeline.”¹ The banner above that line gives the concrete goal: “A multi-vendor project to generate a near-complete set of CDE Sets to represent the findings in chest CT reports.”¹

Contributions are organized by contributor. The README says provisional definitions go in the definitions directory “with separate folders for participating vendors.”¹ Three folders are named after participating vendors, five carry a contributor prefix combined with a modality and body region (CT chest, CT abdomen and pelvis, chest radiograph, knee MRI, and O-RADS), and one holds location value lists.

Branch of record is main, at commit b814a10 of 2025-11-25. See the repository map.

What is in it

The definitions/ tree holds 463 files at that commit.

Form	Count	Where
Markdown definitions and finding lists	259	every contributor folder, plus two chest CT and knee MRI list files at the top level
JSON definitions	150	103 in the CT chest folder, 46 in one vendor folder, 1 elsewhere
Plain text value and location lists	39	the locations folder and one vendor folder
PDF source material	15	the O-RADS folder

The largest single collection is the CT chest folder, with 206 markdown files and 103 JSON files.

The JSON files are worth a note, because the README’s framing suggests otherwise. They do not follow the ACR and RSNA cde.schema.json. They carry a finding name, a description, and a list of attributes typed as choice or numeric with named values, which is the shape a finding model uses rather than the shape a CDE set uses. Everything in this repository is a pre-submission draft in whatever form its author found convenient.

Two authoring conventions

The markdown definitions were written under two conventions that coexist and were never reconciled.

Coded .cde.md files. Fourteen files in one vendor folder follow a structured convention: a # Finding: heading, a source and a coding bullet carrying a RadLex identifier, then one ## section per attribute, with coded values, numeric attributes declared as float with a unit, and multi-select attributes marked in the heading.²

# Finding: Cardiomegaly
* source:
* coding: RID1385
 
## Presence
* present, coding: RID5791
* absent
 
## Cardiothoracic ratio (CTR)
* description: Ratio of the width of the cardiac silhouette and the thoracic cavity
* float: cardiac width ... cm
* float: thoracic cavity width ... cm
* float: ratio: ...
 
## chamber enlargement (multiselect)
* right atrium
* left atrium
* left ventricle
* right ventricle

Per-region finding lists. The five region folders use a plainer bullet-list convention: a finding name as the title, then ## sections grouping bolded attribute names with their options separated by slashes. No codes, no types, no units.

# Aberrant Subclavian Artery
 
## Identification
 
- **Presence of Aberrant Subclavian Artery**: Present / Absent
 
## Characteristics
 
- **Side of Origin**: Right / Left
- **Course**: Retroesophageal / Pretracheal / Other

Some of these folders hold only bare finding lists with no attributes at all, one line per finding name, which is how the chest radiograph and knee MRI folders are organized.

docs/Authoring.md was meant to reconcile them. It is two sentences long, points at the upstream schema, and says “the authoring guide will be hosted here as well.”³ It was never written.

The report representation work

A second body of work in the repository asks a different question: given real report text, what does the existing definition set fail to capture? Four documents record the answers.

The extraction process. docs/report_extraction_process.md works one chest CT report end to end, turning its prose into “a list of mini-observations” of the form finding, attribute, value.⁴ It closes with two notes to self: finding, attribute, and value names need to match the project’s own finding definitions, and blanket negative statements such as “Lungs are clear” need separate cataloguing. Both notes became the next two documents.

Composite negative statements. A corpus of roughly 830 words of real negative and composite report sentences, grouped by organ system, collected to work out how absent findings should be modeled.⁵ Many are not simple negations. “Absence of intravenous contrast limits sensitivity for detecting solid organ findings” is a statement about the exam, not about a finding, and it recurs throughout the abdomen section.

Uncovered findings. A gap list of findings pulled out of reports for which no definition exists, each with the attributes the report gave it.⁶ Entries range from ordinary findings with no definition yet, such as pulmonary edema and lymphadenopathy, to compound ones such as “post treatment squamous cells carcinoma” with an appearance attribute.

Missing attributes. The complementary list: report phrases whose finding does have a definition, but whose attributes that definition cannot carry.⁷ Each entry links to the definition file it fails against. The recurring gap is anatomic detail below the level the definition models, such as a sclerotic change at T6 or a nodule in the left fissure.

Alongside them, report_representation/structured_extractions/ holds 52 worked examples, each pairing a real chest CT report excerpt with its extracted finding list and links into the definition files.

The prioritization roadmap

One vendor folder holds a roadmap table covering chest CT findings across nine organ-system sections: pulmonary, pleura, cardiovascular, lymphatic and endocrine, musculoskeletal, abdominal, lines and tubes, devices, and post-operative or treatment changes.⁸ It has 100 finding rows. Each row carries the finding name, a frequency judgment of common, uncommon, or rare, a priority column, a status column holding links to any RadElement sets that already cover the finding, an “in V1” flag, and a RadLex identifier.

At the read commit, 22 rows are flagged for version 1, 18 distinct RDES sets are referenced, and 19 distinct RadLex identifiers appear. The table is the clearest single artifact tying informal staged content to the published RadElement catalog and to RadLex, and it is where the project recorded which findings already had a governed definition and which did not.

The path to RadElement

There is no automated pipeline. The README and the authoring stub both point at RSNA/ACR-RSNA-CDEs for the canonical cde.schema.json and a sample set,¹³ and the roadmap links findings to the RadElement sets that cover them, but nothing in the repository describes a mechanical route from a staged definition to a submitted one. The process is manual curation: draft informally here, harmonize, then submit through the ACR and RSNA review pipeline. See CDEs and RadElement.

How it feeds finding models

The staged content is an input to the finding model corpus, and this connection is more developed than the one to RadElement.

findingmodels issue 15, “Bring in CDE Staging MD content,” opened 2025-05-28 and still open, asks for a script that takes a markdown file, checks whether a definition already exists for that finding, and either converts it or merges it into the existing definition, reusing element identifiers and synonyms where possible, and adding the appropriate contributor.⁹

That work exists on the content/chestcts branch of findingmodels, unmerged at commit 0472a46. A triage script reads the CT chest folder of CDEStaging and compares each source against the finding model search index;¹⁰ a conversion script then runs the survivors through a multi-agent pipeline of merge, create, and review steps and writes validated finding model JSON.¹¹ Both scripts default to the same CDEStaging CT chest directory as input. The content direction is covered in finding model content direction.

Branch state and open issues

All recent work lands directly on main. Fourteen topic branches exist alongside it and eleven carry commits that are not on main. The largest are a report-representation branch of 37 commits and a content branch of 33 commits, both last touched on 2025-01-23. No branch has a commit after 2025-03-22, and no pull request proposes merging any of them.

Two issues are open.

Issue	Opened	Subject
1	2023-02-27	Differences between the RadElement API schema and the published RelaxNG schema12
11	2024-05-06	A request to remove plurality and values from the harmonized pulmonary nodule definition13

Issue 1 is the oldest open item in the repository and the same gap catalogued in the schema comparison reference. It has had no activity since it was opened.

Footnotes

1. CDEStaging README, purpose and layout ↩ ↩² ↩³ ↩⁴

2. Cardiomegaly.cde.md, an example of the coded markdown convention ↩

3. CDEStaging docs/Authoring.md, a stub pointing at the upstream schema ↩ ↩²

4. Manual Report Extraction, the mini-observation worked example ↩

5. Composite Negative Statements, a corpus organized by organ system ↩

6. Uncovered findings, extracted findings with no matching definition ↩

7. Missing attributes, report phrases existing definitions cannot carry ↩

8. Chest CT Findings roadmap, linking findings to RDES and RadLex codes ↩

9. findingmodels issue 15, Bring in CDE Staging MD content ↩

10. CDEStaging triage script, content/chestcts branch of findingmodels ↩

11. CDEStaging CT chest conversion script, content/chestcts branch of findingmodels ↩

12. CDEStaging issue 1 ↩

13. CDEStaging issue 11 ↩