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.”1 It is the third level of the OIDM hierarchy and the project’s signature structure: the reorganization of a patient’s imaging history by finding rather than by chronology.
Each entry groups the observations of one finding across exams, each observation retaining its source report identifier, exam date, exam type, and presence. The structure it answers is a query: the deck gives the core question as “was finding X present on most recent study?” and lists dynamic tracking of appearance, disappearance, and change as the payoff.2
Grouping key and temporal status are the two things a consumer must get right. On the development branch, observations group by finding code and anatomic location, “so one finding code at distinct sites, for example ascending versus abdominal aortic aneurysm, yields separate entries; consumers key on the IPL finding id, not finding_type_code.”3 Temporal status is computed from the observation list, not stored.
Synonyms and near-synonyms
- IPL is the abbreviation used throughout the sources.
- Problem list in the electronic medical record sense is the clinical analogue this is named after, but it is not the same list.
- Imaging Persona is the next level up, adding clinical context around this.
- FHIR Condition is what the documented mapping uses for each entry.
Identifier form
Each entry carries an id local to the list. That id, not the finding code, is the stable key.
Where it is used
Hierarchy, Imaging Problem List, and Imaging Problem List viewer.
Conflicts
Two documented disagreements. The grouping key differs by branch: the stable specification groups by finding code alone, the development branch by finding code and location.3 And the temporal status model differs between prose and code: the stable branch’s documentation describes three states, present, resolved, and not present or ruled out,4 while the viewer computes four, current, always, resolved, and never. A further known limitation is that generic and specific locations for the same finding code still produce separate entries, which an anatomic-compatibility reconciliation step is meant to address and which has not been started.