Observation
The atomic unit of OIDM data: one finding, seen or explicitly excluded, on one exam. The 2026 deck describes it as “what + where + attributes,” a finding tag plus an anatomic location plus lesion characteristics, carrying presence indicators, change from prior, and measurements in “a universal structure across systems.”1
In the current Exam Finding List format an observation is one entry in the findings array, with an observationId, a findingCode and description, an attributes array, an optional anatomicLocation, and an optional verbatim reportText. Repeat instances are separate observations: “the same finding type may appear multiple times, for example multiple kidney stones, and each gets its own entry with a unique observationId.”2
The FHIR lineage is direct. The 2024 reference implementation’s Observation class states “the Observation class is the model for FHIR Observation objects,” with code, status, subject, bodySite, derivedFrom, and a discriminated union of components.3
Synonyms and near-synonyms
- Finding instance and extracted finding name the same thing at different stages; issue 1 proposes an Extracted Observation subtype for the pipeline case.4
- FHIR Observation is the interchange encoding, not the OIDM object.
- Finding model is the definition; an observation is an occurrence of it.
- IHE IDR uses “observation” more narrowly, for “a feature or characteristic that is visible in an image,” closer to a single attribute value than to this whole object.5
Identifier form
No cross-system identifier. observationId is unique within its Exam Finding List.
Where it is used
Hierarchy, Observation, and Exam Finding List.
Conflicts
There is no published Observation schema. Issue 1 calls for Pydantic models for Observation, Exam Finding List, and Imaging Problem List with JSON Schema export, and the schema URL referenced in sample files does not yet resolve.4 The name also collides with IHE IDR’s narrower sense, which the next-generation notes flag explicitly as a vocabulary collision.5