Why finding models

The finding is the unit

A radiology report is prose. Somewhere inside it a radiologist has asserted that a thing is there, or is not there, or is bigger than it was. The Open Imaging Data Model (OIDM) takes that assertion as its atom, and a finding model is the reusable definition of one such assertion type.

The reason to define findings rather than reports is stated plainly in the overview note that governs authoring: finding models “turn that unstructured language into structured, machine-accessible observation objects, each linked to a rich knowledge base of clinical context.”¹ An agent reads a report, matches each finding it recognizes to a definition, and emits an Observation tagged with the finding type and the values of its attributes.

The second reason is time. “A radiology report is a snapshot, but the findings it describes persist across exams. A pleural effusion seen today may be the same one from last week, now larger.”¹ Two reports written a year apart by two radiologists at two institutions can only be compared if both name the same thing the same way. That shared naming is what a finding model supplies, and it is why the Imaging Problem List can organize a patient’s history by finding rather than by date.

What a finding is, and is not

The scope is broader than pathology. The overview note counts as findings: pathologic entities, physiologic observations, devices and hardware, postsurgical states, anatomic variants, and image quality problems. It also refuses to separate description from diagnosis. “Diagnostic terms are first-class findings, do not question whether a diagnosis ‘should’ be a finding.”¹ Both “bilateral perihilar opacities” and “pulmonary edema” are modeled, because radiologists write both.

The test is whether a radiologist would write “there is X” or “no X” as a standalone statement. That test excludes a state of a finding (“stable cardiac silhouette”), a qualified version of one (“large pleural effusion”), normal anatomy, radiographic signs and interpretation techniques, exam metadata, clinical history, and recommendations. The guiding principle is that “a finding is a noun phrase; everything else is an attribute.”¹ The full treatment, with its worked examples of too broad, too narrow, and right level, is in the overview extract.

Negative assertions are inside the scope, not outside it. When a report says “no fracture,” that is an active observation recorded as presence absent, which means the finding was looked for and not found. Models therefore have to exist at the breadth where radiologists make those sweeping statements, which is why “chest wall fracture” and “upper abdominal abnormality” are legitimate models.

What the definition carries

A finding model is a knowledge base entry, not a label. Each definition carries a canonical name, a description written for a radiologist audience, synonyms covering the ways the same observation gets expressed, tags for browsing, index codes linking to SNOMED CT, RadLex, and the Radiology Gamuts Ontology, optional anatomic locations, contributors, and the attribute list.¹²

Attributes are the characterization axes. Two are near-universal and come first by convention: presence, with the values absent, present, indeterminate, and unknown, then change from prior. After those come the domain-specific axes, size, severity, density, morphology, enhancement pattern, and whatever else the finding needs. Each choice value gets its own code, so a stored Observation can cite not just the finding and the attribute but the specific value chosen. Every identifier in that chain is machine-generated and never written by hand. The field-level specification is in the format document.

Quality in these definitions is load-bearing rather than cosmetic. “A sloppy synonym maps the wrong concept to an observation; a nonsensical attribute propagates meaningless data; a poorly scoped model conflates distinct clinical entities. Errors here don’t just look bad, they cause incorrect downstream reasoning about patient care.”¹

What a finding model is not

It is not a report template. Templates were the earlier approach to structured reporting, and a finding model does not prescribe what a report contains or in what order. It defines one finding and leaves composition to whatever produces the report.

It is not a common data element, at least not yet. The January 2026 status deck frames finding models as “the CDE workbench”: rapid, language-model-assisted content creation acting as “a proving ground for formal common data elements,” carrying “rich definitions with embedded relationships and semantic tags that can graduate to standards.”³ The relationship runs from finding model toward common data element, not the other way, and it is worked through in finding models and CDEs.

It is also not an instance. The definition says what a pleural effusion is and how one is characterized. It says nothing about any particular patient. That separation is the whole point of the layering described in architecture.

How the definitions get used

Downstream structures reference finding models only by identifier. An Exam Finding List entry carries a findingCode holding the model’s OIFM identifier, an optional anatomic location, and an attributes array in which each element pairs an OIFMA attribute identifier with a value code drawn from that attribute’s permitted values.⁴ Nothing in the Exam Finding List repeats the definition; a reader that wants to know what OIFM_GMTS_016552 means resolves it against the content repository.

{
  "findingCode": "OIFM_GMTS_016552",
  "findingDescription": "urinary tract calculus",
  "attributes": [
    {
      "attributeCode": "OIFMA_GMTS_707209",
      "attributeValueCode": "OIFMA_GMTS_707209.1",
      "attributeValueDescription": "present"
    }
  ]
}

The same identifiers flow upward into the Imaging Problem List, which groups a patient’s observations by finding code across exams. The details of both structures are in the Exam Finding List document.

An older statement of the same idea, from the 2023 site post that predates the finding model format, describes a radiology finding as a FHIR Observation “semantically labeled with ACR/RSNA Common Data Element identifiers,” with the set identifier naming the finding type and element identifiers naming the attributes.⁵ The shape survived; what changed is that OIDM now mints its own identifiers for the definitions that no common data element covers.

Footnotes

1. “Finding Models: Overview”, findingmodels repository ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

2. FindingModelFull definition, findingmodel repository, main branch ↩

3. Open Imaging Data Model 2026 Status Update, January 2026 ↩

4. imaging-problem-list README, main branch ↩

5. “Findings, CDEs, and Observations”, openimagingdata.org, 2023-06-24 ↩