Extraction

Deriving structured findings from narrative radiology report text using a language model. It is the first half of the pipeline that turns a report into OIDM data: “an agent reads a radiology report and identifies findings mentioned in the text,” and each finding is then matched to a definition.¹ The deck states the goal that an Imaging Problem List be “automatically extractable from narrative report text via LLMs.”²

Extraction output is uncoded. Its schema names a finding, asserts presence as one of present, absent, indeterminate, or possible, gives an optional location of body region, specific anatomy, and laterality, a list of key-value attributes with standard keys such as size, acuity, change from prior, severity, count, and morphology, and a verbatim report_text quote.³ Assigning identifiers is a separate job; see coding.

Three design decisions shape the current implementation: long reports are semantically chunked and extracted concurrently then merged and deduplicated, output quotes are validated as verbatim both during and after generation, and a reviewer sub-agent can flag issues and trigger targeted re-extraction of specific chunks.⁴

Synonyms and near-synonyms

• Finding extraction and report extraction are the same activity.
• Coding is the separate downstream step that assigns identifiers.
• Mapping is the older MVP pipeline’s word for coding by embedding similarity.
• Mini-observation is the staging repository’s term for one extracted finding, attribute, and value tuple.

Identifier form

None. Extracted findings carry names and quotes, not identifiers, until coding runs.

Where it is used

Report extraction platform, IPL MVP extraction, and Extraction approaches.

Conflicts

The failure modes extraction guards against are stated in the validator prompt and are worth naming as part of the definition: content unsupported by the chunk text, which is hallucination; report text describing a finding that no structure represents, which is a missed finding; a finding described as present when it is not, or absent when it is possible; a finding name more specific than the text supports; incorrect representation of a blanket negative; and wrong, too specific, or too general location information.⁵ Separately, the extraction presence value set does not match the finding model one; see presence.

Footnotes

1. “Finding Models: Overview” ↩

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

3. Initial extraction plan ↩

4. imaging-problem-list architecture notes ↩

5. Validator prompt example ↩