Roadmap 2026

What this document is

This is the project-level direction for the Open Imaging Data Model (OIDM), as stated by its sources. The single most complete statement is the January 2026 status deck, extracted in full at status update, January 2026.¹ Below the deck sit the working repositories, whose direction is visible in their unmerged branches, plan documents, and open issues.

Nothing here is a proposal. Each goal is attributed to the deck, an issue, or a plan document that states it. Where a goal has no artifact behind it, that is said. Per-area goals live in the five area roadmaps linked from the roadmap index; unresolved conflicts between sources are collected in open questions.

The three strategic pillars

The deck organizes the whole project under three pillars.¹

1. Semantic foundation. Finding models feeding common data elements, and anatomic location definitions.
2. Data structures. The atomic Observation, then the Exam Finding List, then the Imaging Problem List, then the Imaging Persona.
3. Applications. An Open Imaging Reporting SDK enabling vendor-driven innovation, plus demonstration applications including an Imaging Problem List browser and early draft-generation tools.

The deck’s executive summary states the foundational content as a language-model-built curated anatomic location index plus “nearly 3,000” Open Imaging Finding Models (OIFMs), and names the “workbench effect” as the mechanism: high-velocity language-model-powered content creation acting as a proving ground for formal common data elements.¹ The corpus count the deck gives does not match the count in the repository; see open questions.

The working group proposal

The deck’s call to action names an ACR-OIDM Structured Imaging Results Working Group, to be co-hosted with the American College of Radiology (ACR) as an expert and vendor data structure working group. Two conditions ride with it: structure first, with FHIR and other standards following, and vendor-driven adoption, the deck’s example being reporting software development kits from a reporting vendor.¹

The deck states four ACR priorities the work supports.¹

Priority	What the deck says it needs from OIDM
Recommendation tracking	Structured imaging results carried forward across exams
Artificial intelligence validation	Correlating artificial intelligence Observations against radiologist Observations
Quality metrics	Queryable structured results
*-RADS support	Representation of the assessment reporting systems

No record of the working group being convened exists in any repository read for this knowledgebase. It is a stated intention.

Next steps as the deck states them

Three, in the deck’s own words: host and moderate an academic and vendor “big tent”; run a use-case pipeline feeding the CDE group; standardize the result.¹

The use-case pipeline is the one of the three with existing material behind it. The lineage UseCases repository holds roughly 25 use case ideas organized against the RSNA value categories, described in use cases. The direction the deck states is that such use cases feed the ACR and RSNA common data element group, which is the same direction as the workbench relationship described in finding models and CDEs.

The work edge, repository by repository

Branch inventories taken on 2026-09-21 established what follows; the full detail is in the repository map.² None of the unmerged branches named here has an open pull request.

Repository	Live thread	In flight	Area roadmap
findingmodel	feature/metadata-cleanup (tip 1942b06) on dev	Canonical structured-metadata rewrite: eight optional fields, seven typed assignment agents, dual-database release. Readiness assessment not passing3	Format evolution
findingmodels	taxonomy-export-2026-08-15 (tip a30c3c9) for direction; five content branches	Six per-modality taxonomy CSVs, 3,789 rows, 1,028 matched; 2,761 rows awaiting triage4; CT chest, head CT, and metadata batches unmerged	Content direction
imaging-problem-list	dev (tip 36fa30c), 258 commits ahead of main	Eight active plans on review tooling, evaluation redesign, anatomy-aware viewer, local models. Issue 1 asks for a formal model layer and is unclaimed5	IPL data model system
med-ontology-lookup	main, no branch ahead	A twelve-issue backlog following the repository’s six-phase design; eleven of the twelve are open, plus one filed outside the sequence. The only written exam-type design lives here	Exam types
findingmodel anatomic-locations package, anatomiclocations.org, BodyPartIndex.py	Package inside findingmodel; the original repositories are quiet	Two unreconciled datasets; RSNA RadLex issue 3 tracks incorporation with a 100 percent coverage exit criterion6	Anatomic locations and RadLex
FindingModelForge	dev and feature/model-editing, both unmerged	A peer-review layer finished on dev; model editing answered by AI-assisted iteration on its own branch	No area roadmap; see the Forge profile
CDEStaging	main	All current work lands on main; eleven topic branches unmerged, none touched since 2025-03-22	Content direction
IPL-MVP-ExtractionAndLabeling	main	Three single-commit experiments, including a persistent-FHIR-identity design note	IPL data model system

What the deck names that does not exist

Three items in the deck have no artifact in any repository. They are direction, not status.

• The Open Imaging Reporting SDK. Named as one third of the applications pillar. No repository, no code, no specification. See the reporting SDK.
• The Imaging Persona. Named with four context categories, clinical context, medical baseline, specialized history, and surgical history. No specification. See Imaging Persona.
• The ACR-OIDM working group. Described above.

A fourth item, exam types, is not in the deck at all but has been stated as a goal in three places since 2022 with no artifact produced; see the exam types roadmap.

The implementation status of every piece of the system, built and unbuilt, is tabulated in architecture.

Footnotes

1. “Open Imaging Data Model 2026 Status Update: Realizing Object-Oriented Imaging Results”, January 2026 ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

2. Repository map, work edge section ↩

3. Canonical Structured Metadata and Enrichment Rewrite, feature/metadata-cleanup branch ↩

4. MGB exam-oriented sub-taxonomies README, taxonomy-export-2026-08-15 branch ↩

5. imaging-problem-list issue 1, “Create System of Data Models” ↩

6. RSNA/RadLex issue 3, “Add Anatomic Locations” ↩