Status first
The Imaging Persona is a goal. It is named in the January 2026 status deck as the fourth level of the data structure hierarchy and appears nowhere else in the project. No schema, no sample, no code. Everything below is what the deck states.1
What the deck describes
The deck’s slide is headed “Imaging Persona (big picture)” and gives four categories of context that would surround a patient’s Imaging Problem List.1
| Category | Contents named |
|---|---|
| Clinical context | orders, indications |
| Medical baseline | problem list, allergies, laboratory results |
| Specialized history | oncology, treatments |
| Surgical history | operative records, pathology, implants |
None of that is imaging results. The Imaging Problem List is the structure the project builds; the persona is the argument that a problem list on its own does not answer the questions radiology actually gets asked. Three of the four categories come from the electronic medical record rather than from radiology, which makes the persona as much an integration claim as a data structure.
Why: the imaging life cycle
The deck argues for it through a separate slide on what the Imaging Problem List enables at each stage of the imaging life cycle. The uses named there are the ones that need context the problem list does not carry.1
| Stage | Uses the deck names |
|---|---|
| Planning | magnetic resonance safety, mobility, prior authorization |
| Intra-exam | rules-based protocoling |
| Interpretation | findings-oriented views in the picture archiving system, real-time quality control |
| Post-interpretation | passive screening, research, outcomes |
Read against the four categories, the dependency is concrete. Magnetic resonance safety screening is a question about implants, which is surgical history. Prior authorization is a question about the order and the indication. Rules-based protocoling needs both the prior imaging findings and the clinical question. Passive screening needs the medical baseline to know whether a finding matters for this patient. A problem list alone answers none of these; a problem list plus that context answers all four.
The 2024 site post on the data model made a related claim earlier and in wider terms, listing observations, current report text, imaging studies, patient, order, prior studies, tracked observations, and electronic health record data as the elements the model organizes.2 The persona is that list narrowed to the patient-context half and given a name.
A related unimplemented idea
One adjacent design note exists in the repositories, on an unmerged branch of the early extraction prototype. FHIR_Example_Structure sketches longitudinal persistence of findings: each finding becomes “a tracked entity with a FHIR ID that persists,” so a second report describing the same liver lesion links to the existing resource and adds a new dated value rather than creating a second finding.3 The note’s worked timeline shows one lesion at 1.6 cm, 2.1 cm, and 2.8 cm across three reports, and its query examples are “show me the timeline for liver lesion” and “how has the renal calculus changed?”.
It is a different idea from the persona. It addresses identity of a finding over time, which the current Imaging Problem List approximates by grouping on finding code and location rather than by tracking a lesion. It is recorded here because it is the only written treatment anywhere in the repositories of persisting a patient’s imaging story as durable resources, which is the substrate a persona would need. It sits on a single-commit branch of a superseded prototype and was never merged; see IPL-MVP extraction.
What would have to be decided
Nothing about the persona has been specified, so this section states only what the deck leaves open rather than proposing answers. The deck does not say whether the persona is a stored structure or a query-time assembly, which systems own each of the four context categories, how it would be encoded, or who would maintain it. Those questions are carried in open questions and the direction in the 2026 roadmap.