The stated direction
The project lead stated on 2026-09-21, recorded in the knowledgebase build plan, that the MGB exam-oriented sub-taxonomies are the immediate direction for all finding model content, and that they are expected to replace many of the Gamuts-derived models that currently make up 1,933 of the corpus’s 2,382 definitions.1
That is a change in how content is chosen. The Gamuts import brought in whatever the source ontology contained, which is a differential-diagnosis ontology, so a large share of the resulting definitions name diagnoses rather than findings. The sub-taxonomies instead enumerate what a radiologist reading a particular exam type actually reports, organized by that exam type. The artifacts themselves, their columns, counts, and hierarchy semantics, are described in the sub-taxonomies reference.
No plan document in the findingmodels repository yet describes how or when Gamuts-derived models would be superseded. The statement is direction, not a scheduled workstream.
The triage task
The sub-taxonomy export minted no identifiers. Rows were matched by exact name against the identifier registry across all branches, plus identifiers previously written back into the old lists.2
| Rows | |
|---|---|
| Total across the six files | 3,789 |
| Carrying an existing OIFM identifier | 1,028 |
| Blank, awaiting triage | 2,761 |
The README names the next task in one sentence: “Blank rows are the ones needing triage.”2 Match rates are uneven, from 86 percent on head CT and 76 percent on chest radiography down to 10 percent on the combined chest, abdomen, and pelvis CT file and 3 percent on mammography. No plan document assigns the triage work, and no issue tracks it.
Content batches in flight
Five findingmodels branches carry unmerged content work. None has an open pull request. Counts are of new definition files against main.
| Branch | Last commit | New definitions | What it is |
|---|---|---|---|
content/chestcts | 2026-06-19 | 1,822 | CT chest conversion from the CDEStaging corpus, using a three-agent merge, create, and review pipeline |
content/headcts | 2026-06-03 | 419 | Head CT batch, reviewed through the terminal review tool, with its own source taxonomy CSV |
| a second head CT review branch | 2026-05-13 | 76 | Overlapping review passes for the extrinsic, orbit, and temporal bone regions, sharing the head CT source taxonomy |
| a clinician-request branch | 2025-12-12 | 59 | A requested batch for an intracranial problem list application |
findingmodels-metadata | 2026-06-01 | 0, modifies 78 | Applies an approved metadata enrichment baseline to existing definitions |
The CT chest branch is the live front of that pipeline. Its plan records the refactor from one monolithic agent into three focused ones with Python-level orchestration, with phases 1 through 3 complete and two follow-ups open: the create agent extracts fewer attributes than the single-agent version did, and the sub-findings schema is unresolved.3 Its progress document is explicit about how far the batch has run: 205 total sources, chunked into 21 groups of 10, with chunk 1 complete and chunks 2 through 21 pending.4
The head CT branch’s one plan document is marked complete for the soft tissue category: four new models created, nine mappings made to existing models, review done, identifiers written back, validator clean.5
An earlier CT chest branch, cde_to_finding, holds 1,915 definitions from the same source corpus and is 103 commits behind main. It is superseded by the three-agent branch, not a parallel effort.
The definition cleanup plan
A draft plan on main, still marked “DRAFT - for review,” covers cleaning the existing corpus against the authoring conventions. It scopes 2,379 models: 1,934 Gamuts, 264 OIDM already reviewed, 115 from the common data element work, 47 from MassGeneral Brigham, and 19 from Microsoft.6
It gives an ordered execution sequence with counts.
| Order | Category | Models | Nature of the work |
|---|---|---|---|
| 1 | Capitalization and parentheticals | 133 | Mechanical: lowercase names, acronyms and brand names move to synonyms |
| 2 | Missing standard attributes | 124 | Add presence and change from prior as the first two attributes, with clinically appropriate direction-of-change values |
| 3 | Population qualifiers | 84 | Strip age or population from the name, tag instead, and later migrate the tags to explicit age ranges |
| 4 | Synonym audit | not counted | Run the synonym strictness rules across the corpus |
| 5 | ”With” clauses | 71 | Case-by-case clinical judgment |
| 6 | Comma, slash, and and-or compounds | 18 | Individual attention |
| 7 | Gamuts reclassification | to be determined | ”needs broader design discussion about what model types we support” |
The 71 “with”-clause models are all Gamuts-derived and the plan splits them into three kinds. Some are a finding plus an associated finding that should become two models, as in “arthritis with soft-tissue nodules.” Some are a finding plus a qualifier that is really an attribute, as in “bowel wall thickening with heterogeneous enhancement.” And some are genuinely Gamuts constructs, radiographic patterns used to narrow a differential, such as “acyanotic congenital heart disease with increased pulmonary vascularity.” For that third kind the plan records that they “may be better modeled as gamuts (differential diagnosis patterns) rather than finding models” and flags them for discussion.6
Two standing rules accompany the plan. Changes to Gamuts models preserve the original name as a synonym so existing Gamuts references still resolve. And each phase runs through the mechanical lint plus language-model review process before committing.6
A second open plan on main, the finding skills rebuild, has phases 0 through 8 complete and phases 9 and 10, end-to-end verification and the final plan update, outstanding.7
The evidence-gated metadata branch
The metadata branch in the content repository operates under rules that are themselves a stated direction for how generated content enters the corpus. Its consolidated plan history states that “Human review is authoritative,” that generated definition, markdown, and index changes are “untrusted until approved evidence is safely captured,” that generated source diffs “are not gold,” and that approved changes are reapplied “only through an explicit approved-output application path.”8
The review evidence it protects: a 150-item pilot review yielding 46 approved and 104 requiring feedback, refined after a 30-item follow-up to 67 approved and 83 requiring feedback.8 The tooling side of this work is in the enrichment pipeline.
Open content issues
Five of the ten open findingmodels issues are content batches. None is closed by any branch in flight, though two overlap with one.
| Issue | Asks for | Relation to work in flight |
|---|---|---|
| 15 | A script that converts a markdown definition file, merging with an existing model where one exists and reusing identifiers and synonyms, adding the right contributor | Answered by unmerged work. The triage and conversion scripts on the CT chest branch read the same source directory and write validated definitions, but nothing proposes merging them, so whether the issue is closed as filed is unresolved |
| 16 | Knee MRI findings, starting from a spreadsheet and finding an automatable format | No branch |
| 19 | Abdomen CT findings from an MGB-contributed list, checked against the Gamuts content and updated or created as needed | No branch |
| 20 | Chest CT “green” findings plus chest radiograph device and post-operative lists | No branch |
| 25 | A converter from common data element JSON version 1.0 into finding models, with a stated identifier mapping (RDES195 to OIFM_CDE_000195, RDE1300 to OIFMA_CDE_001300), an index code back to the original at every level, and detailed value-mapping rules | Conceptually overlaps the stale CDE-to-finding branch |
Two further open issues, 17 and 32, ask for a static marketing site and a static catalog site for the content; the catalog site exists and is profiled in the finding models site.
How the corpus is organized and browsed today is in the content catalog, and the identifier scheme that governs writebacks is in identifiers.9 Where sources disagree about corpus counts and content classification, see open questions.
Footnotes
-
Knowledgebase build plan, recording the project lead’s statement of 2026-09-21 ↩
-
MGB exam-oriented sub-taxonomies README, taxonomy-export-2026-08-15 branch ↩ ↩2
-
Three-agent pipeline plan, content/chestcts branch ↩
-
CDEStaging CT chest batch progress, content/chestcts branch ↩
-
Soft tissue head CT batch plan, content/headcts branch ↩
-
Rebuild finding skills plan, findingmodels main branch ↩
-
Metadata enrichment plan history, findingmodels-metadata branch ↩ ↩2
-
ids.json, findingmodels main branch ↩