The ladder
The second of OIDM’s three strategic pillars is a data structure hierarchy. The January 2026 status deck describes it as “the atomic Observation, then the Exam Finding List, then the Imaging Problem List, then the ‘Imaging Persona’.”1
| Level | Scope | What it adds | Key it is organized by |
|---|---|---|---|
| Observation | one finding on one exam | what was seen, where, and how it was characterized | none; it is the atom |
| Exam Finding List | one exam | the exam envelope: report identity, patient, and a LOINC-coded exam type | the exam |
| Imaging Problem List | one patient | time: every observation of a finding across every exam | the finding |
| Imaging Persona | one patient | clinical context around the imaging: orders, baseline, specialized and surgical history | the patient |
An Exam Finding List groups observations by exam. An Imaging Problem List is “organized by finding, meaning pathology, rather than by chronology,”1 allowing a lookup for the deck’s query, “was finding X present on the most recent study?”
Diagram source: hierarchy.excalidraw beside this document, generated by tools/diagrams/build_hierarchy.py.
What each level adds
Observation. The deck describes “what + where + attributes” in “a universal structure across systems.”1 A finding tag, an anatomic location, and lesion characteristics record presence, change from prior, and measurements. Its identity is local to the list that contains it.
Exam Finding List. “In the context of an imaging exam, a list of the findings declared as present/absent on that exam.”2 It “must also have basic information (keyed by a curated list of LOINC codes) about what exam this is,” and “the same finding type may be declared as present multiple times; each time is a separate entry.”2 Three kidney stones therefore produce three observations.
Imaging Problem List. “In the context of a patient, the list of findings that have been described as present/absent in exams of the patient.”2 Each entry holds every observation of that finding, each carrying its source report, exam date, exam type, and presence. On the development branch the grouping key is finding code and anatomic location, so “one finding code at distinct sites (e.g. ascending vs. abdominal aortic aneurysm) yields separate entries.”3
Imaging Persona. The deck proposes adding clinical context, medical baseline, specialized history, and surgical history to the problem list.1 No other project document names it, and no specification or sample exists.
How identifiers thread through
The structures refer to definitions in the semantic foundation by code. Shared codes let systems agree on a finding without sharing a database.
| Identifier | Form | Where it enters | Example |
|---|---|---|---|
| OIFM finding identifier | OIFM_[A-Z]{3,4}_[0-9]{6} | findingCode on an observation; finding_type_code on a problem list entry | OIFM_GMTS_016552 |
| OIFMA attribute identifier | OIFMA_[A-Z]{3,4}_[0-9]{6} | attributeCode inside an observation’s attributes array | OIFMA_GMTS_707209 |
| Attribute value code | the attribute identifier plus a dot and the value’s position | attributeValueCode | OIFMA_GMTS_707209.1 for present |
| RadLex identifier | RID####, with sided structures composite | anatomicLocation.locationId | RID42239, and RID39518_RID5824 for a left shoulder |
| LOINC code | LOINC part number | examInfo.studyLoincCode, and exam_type_code on a problem list observation | 26158-6 |
The letter block in an OIFM identifier is the contributor’s organization code. One exam can use several contributors’ codes. The five-finding worked example combines GMTS, OIDM, and CDE identifiers.4
Implementation status
| Level | Status | What exists |
|---|---|---|
| Observation | Specified as part of the Exam Finding List; no standalone model | The findings[] entry shape, real sample data, and a separate extraction-time Pydantic model on the development branch. A formal Observation model is issue 1, unclaimed.5 |
| Exam Finding List | Specified in prose, with real sample data and generator scripts | Field-level specification on main, ten sample lists for one synthetic patient, and a generator from a working spreadsheet. No published JSON Schema. |
| Imaging Problem List | Specified, generated, and rendered | A generator that aggregates Exam Finding Lists, sample output for two synthetic patients, and a deployed viewer. |
| Imaging Persona | Concept only | Four named context categories in the deck. No artifact. |
| FHIR encoding of any level | Documented only | The mappings are written down and implemented nowhere. See FHIR mapping. |
Issue 1 requests Pydantic models for Observation, Exam Finding List, and Imaging Problem List, with “extensive annotation to generate JSON schemas” and camelCase export aliases for snake_case attributes.5 Prose, samples, and scripts currently define the structures. See the IPL data model system roadmap.