Lineage repositories

Why this document exists

Twelve repositories came before the current three-layer structure. Some are dead ends; several hold the precedent that later work still follows, and one of them is still the project’s CDE data source. Each section below gives the repository’s purpose, its dates, its status in the repository map, what survives, and what replaced it.

The FHIR precedent

Two lineage repositories together define how OIDM maps onto FHIR, and nothing since has replaced them.

The Observation class. OpenImagingDataModel.py contains an explicit Pydantic re-implementation of the FHIR primitives Identifier, Coding, CodeableConcept, and Reference, and an Observation resource with resourceType, code, status, subject, bodySite as a CodeableConcept, derivedFrom as a list of references, and component as a discriminated union keyed on the FHIR value[x] naming convention.¹ Its docstring states plainly that the class models FHIR Observation objects. This is the direct ancestor of the Observation in the current hierarchy.

The worked example. FHIRSamples holds four hand-built resources for a lung cancer screening scenario.²

File	Resource	What it shows
example1OIDMreport.json	DiagnosticReport	Category coded in SNOMED CT and HL7 v2 table 0074, code coded LOINC 87279-6 for screening chest CT, an inline ImagingStudy, result referencing three Observations, and a SNOMED-coded conclusion
example1OIDMaifinding.json	Observation	An AI-produced finding, status preliminary, code.coding pointing at radelement.org with the CDE set code RDES195 for pulmonary nodule, derivedFrom the ImagingStudy, and component entries whose codes are individual RDE element codes with the chosen value code as valueCodeableConcept
example1OIDMradiologist.json	Observation	The same finding as confirmed by a radiologist, distinguished only by status final
example1OIDMradiologistLungRADS.json	Observation	A second-order assessment Observation that is derivedFrom both the ImagingStudy and the radiologist’s finding Observation, carrying the Lung-RADS category (RDES267) as a component

Three patterns come out of this example and recur throughout later work. The chain from CDE set code to element code to value code, all through the radelement.org coding system, is what “CDE-labeled FHIR Observation” means concretely. The status field is what separates a machine-produced finding from a radiologist-confirmed one, rather than a separate resource type. And the second-order observation, an assessment built on top of a finding observation, is the precedent for any later assessment or category modeling, including the reporting-system categories the 2026 roadmap names.

Two absences in the example are worth recording. No bodySite coding appears on the finding Observations, because the anatomy was implicit in the CDE definition rather than explicit on the resource. No Patient resource is included; subject.reference is a bare reference. Both gaps are addressed in the current model, where anatomic location is an explicit field. See FHIR mapping for where the current structures stand.

Reference implementations

OpenImagingDataModel.ts. Created 2023-04-27, last commit on the default branch 2023-10-22. A pnpm monorepo with cde_set, observation, and findingModel packages, all typed with Zod schemas.³ Status: lineage. Its Zod schemas are the cleanest early type definitions for a CDE set, a CDE element, an index code, and a body part, and they are the only place the project expressed these shapes in TypeScript. No FHIR imports appear anywhere in it. Superseded by the Python implementation and then by the findingmodel package.

OpenImagingDataModel.py. Created 2024-03-08, last commit on the default branch 2024-11-13. Subpackages cde_set and observation.¹ Status: lineage, but the most consequential of the group. Besides the Observation class above, finding_model.py defines a FindingModel with a name, a description, and a list of attributes discriminated into choice and numeric types with a required flag.⁴ Its docstring, “The definition of a radiology finding … along with definitions of the relevant attributes that a radiologist might use to characterize the finding in a radiology report”, survives verbatim into the current finding model class in findingmodel. What the early class lacked is exactly what the current format adds: identifiers, synonyms, tags, index codes, anatomic locations, and contributors. Its set.py, element.py, and set_factory.py mirror the RadElement schema. Superseded by the findingmodel package.

Content and schema

openimagingdata.org (the repository). Created 2023-02-20, last commit 2023-06-27. Status: lineage. This is where the project’s first name lives: the README titles it “Open Radiology Data Model” and points at a domain that no longer serves the project. Two things survive. The schemas/ directory holds the CDE Set JSON schema and minimal sample CDE set and Observation fixtures. More useful is schema_differences.md, a precise gap analysis between the CDE Set RelaxNG schema and the RadElement JSON API: array wrapper naming, index_code.url against the API’s href, a system enum constrained in the schema but not the API, authors interleaved in the schema but split into arrays in the API, and presence mismatches on modality, biological sex, age range, parent set, question, references, and body parts.⁵ That analysis is still live; the same gap is the subject of an open issue in CDEStaging. See CDEs and RadElement. Superseded as a site by the hosted blog at the same domain.

common_data_elements. Created 2025-02-21, content uploaded 2025-06-04. Status: maintenance, not lineage: this is still the project’s local snapshot of RadElement. It holds roughly 140 CDE set definitions as JSON, indexed in the README by clinical topic with their set identifiers, and the canonical cde.schema-1.0.json and cde.schema-1.1.json files that the gap analysis above refers to.⁶ The README notes that the definitions conform to schema version 1.0, not the newer 1.1.

UseCases. Created 2023-09-07, last commit 2024-02-26. Status: lineage as an activity, but its content is the fullest enumeration of application ideas anywhere in the project.⁷ It holds roughly 25 one-line use case ideas and the six value categories used to tag them. Migrated in full to the use case catalog. Nothing superseded it; the deck’s application pillar and the 2026 roadmap cover related ground without reusing the catalog.

Demonstrations and conversions

CDETemplateDemo. Created 2023-05-31, last commit 2023-06-15, default branch master. Status: lineage. A working proof of concept that renders a structured Observation into report prose through a Mustache template.⁸ The pattern survives as the clearest precedent for the reporting SDK direction; see CDE template rendering. Its own Observation shape, a flat string-keyed record of components, is looser than the FHIR-based one and is superseded by it.

SARTemplatesToCDEs. Created 2023-12-30, last commit 2024-03-11. Status: lineage, stalled at proof of concept. The stated goal was to use a language model to convert Society of Abdominal Radiology reporting templates into CDE sets, starting with rectal cancer staging. No conversion code was committed. What survives is Changes_vs_RDES11.md, an itemized redesign of the MR rectal tumor imaging CDE set against a 2016 baseline: an element renamed, mucinous composition given finer granularity, T-category and sphincter-invasion elements restructured, and new elements for tumor morphology, extramural vascular invasion, tumor deposits, and lymph nodes, each with explicit value sets.⁹ It remains the most detailed single-CDE-set redesign in the lineage. The conversion approach itself is superseded by the batch content pipelines in findingmodels; see extraction approaches.

Extraction and ontology tooling

These four are covered in depth in extraction approaches; their status is summarized here.

template_extraction. Created 2025-06-05, last commit 2025-06-16. Status: lineage. A short script and a corpus of 281 RadReport templates spanning CT, MR, ultrasound, nuclear medicine, and fluoroscopy across most body regions, plus two CDE-labeled test templates.¹⁰ The corpus is the asset; it is an unused candidate vocabulary for exam types as well as findings. Not superseded by anything; the work simply moved to converting CDE staging content instead.

ReportFindingRefiner. Created 2024-12-31, last commit 2025-05-23. Status: lineage, and the most mature of the extraction family. A privacy-first pipeline running local models: ingest report text, split into header, findings, and impression sections, embed with sentence transformers, store in a vector database, search, then generate finding model outlines with a local language model and persist them.¹¹ Superseded by the extraction platform on the imaging-problem-list dev branch, which pursues the same goal with a chunked, multi-provider, verbatim-quote-validated design.

get_ontology_findings. Created 2025-03-27, last commit 2025-03-27. Status: lineage. A minimal script plus a RadLex export, aimed at finding ontology entries that correspond to imaging findings so they can become finding models or CDEs.¹² Superseded in scope by med-ontology-lookup.

ontology_tools. Created 2025-03-02, last commit 2025-03-02. Status: dead. The repository contains a README naming three target ontologies, Anatomic Locations, SNOMED CT, and RadLex, and nothing else.¹³ med-ontology-lookup is a replacement, not a continuation; there is nothing here to carry forward except the three-ontology scope statement, which that project widened to five.

What connects them

No lineage repository depends on another as a package, and none names another by URL. The connective tissue is shared external vocabulary: RadElement set and element codes thread through the CDE snapshot, the FHIR samples, the TypeScript sample data, the template demo’s sample observations, and the SAR redesign. The CDE set and element shape is independently re-implemented three times. The finding model concept is defined independently in the TypeScript and Python implementations with near-identical shape and reimplemented a third time inside ReportFindingRefiner. That independent convergence is why the current format could consolidate them without contradiction.

Footnotes

1. OpenImagingDataModel.py observation.py, the FHIR Observation model ↩ ↩²

2. FHIRSamples lung cancer screening example, four FHIR resources ↩

3. OpenImagingDataModel.ts, the TypeScript reference implementation with Zod schemas ↩

4. OpenImagingDataModel.py finding_model.py, the earliest FindingModel class ↩

5. openimagingdata.org schemas/schema_differences.md, CDE Set schema versus RadElement API ↩

6. common_data_elements README, the RadElement snapshot and its schema versions ↩

7. UseCases Index.md, the living list of use case ideas ↩

8. CDETemplateDemo, Observation to prose rendering ↩

9. SARTemplatesToCDEs itemized CDE redesign for MR rectal tumor imaging ↩

10. template_extraction, a corpus of RadReport templates ↩

11. ReportFindingRefiner README, the retrieval-augmented extraction architecture ↩

12. get_ontology_findings README ↩

13. ontology_tools README, the entire contents of the repository ↩