Add report reconciliation: compare official radiologist report against image analysis

[Liohtml]

Part of #51. Builds on the cross-validation step (#52). This is the
market-differentiating feature — no existing consumer product does it.

Summary

Let the user provide the official radiologist report (paste text, or ingest a
DICOM SR / PDF), and have MedCheck reconcile it against its own image-derived
findings and the ML signals: which official findings the model can localize, where
they are, and any regions the model flagged that the report did not mention — each
framed as "ask your doctor about this," never as a contradiction or a new
diagnosis.

Why (research-backed)

Market research found the landscape is siloed and nobody reconciles report vs.
image for patients:

• Text explainers (Scanslated, Read My MRI, ChatGPT) explain the words but
  never read the pixels → can't validate anything.
• Viewers (Horos, Weasis, OHIF) show pixels but explain nothing.
• Second-opinion services (DocPanel, Mediphany $95–300) do both but are paid,
  slow, closed, human.
• The closest research prototype (ReXplain) only highlights image regions; it's
  unreleased.

Reconciliation also has clinical grounding: subspecialty second reads find
~20–25% clinically significant discrepancies, and everyday radiology
discrepancy is ~3–5% — so "here's what your report says, here's where it is, and
here's something to ask about" is genuinely useful, while staying on the safe side
of the regulatory line (it explains/locates an existing human report rather
than issuing findings).

⚠️ Positioning / safety (see epic #51)

• Frame strictly as comprehension + question-preparation: "Your report
  mentions X — here is the region" and "the analysis also looked at Y; the report
  doesn't mention it — consider asking your doctor."
• Never state the radiologist is wrong, never present a model finding as a
  diagnosis, never say a region is normal/abnormal definitively.
• This keeps MedCheck in the educational track; presenting autonomous image
  findings to a patient as truth would make it a regulated device.

Proposed implementation

• Report ingest: a lightweight util/provider to accept the official report as
  (a) pasted/loaded text, (b) DICOM SR (parse via highdicom, see Add structured standards export: FHIR DiagnosticReport + DICOM SR #54),
  or (c) PDF text extraction. Run PHI scrubbing (Add robust DICOM de-identification step (tag scrubbing + burned-in PHI + optional defacing) #57) on ingested text.
• New file src/medcheck/pipeline/reconcile.py → ReconcileStep(PipelineStep),
  after vision_analysis/validate, before report.
• Match official-report findings (NLP + RadLex term normalization) to MedCheck's
  StructureFindings and segmentation regions (Add anatomy segmentation grounding step (MONAI / TotalSegmentator total_mr) #53) to produce:
  • Corroborated (report finding the analysis also supports + located),
  • Report-only (in report, analysis didn't surface — "your radiologist noted
    this; the tool didn't independently flag it"),
  • Analysis-only (model flagged, not in report — "ask your doctor").
• Extend PipelineContext with reconciliation: [...]; render a clear
  side-by-side section in the report (especially the patient report mode Add patient-friendly plain-language report mode #56).

Acceptance criteria

• Accepts an official report (text minimum; SR/PDF as follow-ons).
• Produces corroborated / report-only / analysis-only buckets with locations
  where available.
• All output uses question-preparation framing; no contradiction/diagnosis
  language (unit-tested phrasing guardrails).
• Ingested report text is PHI-scrubbed (Add robust DICOM de-identification step (tag scrubbing + burned-in PHI + optional defacing) #57).
• Tests: matching logic (synonyms via RadLex), three buckets, framing guard,
  empty-report no-op.

Dependencies

Strong synergy with #52 (validation), #53 (segmentation locations), #54 (DICOM SR
parsing), #57 (PHI scrubbing of ingested text).

Effort

~2–3 days. No heavy deps for the text path.

References (session research)

Consumer-tool market gap analysis; subspecialty second-read discrepancy ~20–25%;
everyday radiology discrepancy 3–5%; ReXplain (arXiv 2410.00441).

[Liohtml]

Assessment

Value: High — comparing the AI-generated report against an official radiologist report is genuinely useful for both quality assurance and patient education.

Complexity: Moderate — the comparison logic itself is straightforward (diff two structured texts); the hard part is parsing the official radiologist report, which arrives as unstructured text or PDF.

Fits architecture: Yes — another pipeline step (reconcile or compare), triggered only when an official report is provided.

My take

This is one of the more compelling features for the core use case. A patient who has already received a radiology report wants to cross-check it — seeing where the AI agrees, disagrees, or found something additional is genuinely actionable. It's also useful for radiologists doing QA.

The approach I would take:

1. Accept an optional --reference-report path (CLI) or reference_report field (API) containing the official radiology text.
2. Add a ReconcileStep that sends both the AI-generated structured findings and the reference report text to the LLM with a reconciliation prompt: "Compare these two reports. Identify: (a) findings present in both, (b) findings in the AI report not in the reference, (c) findings in the reference not in the AI report. Be specific about structure names and severity."
3. Add a reconciliation section to the report output.

Concerns

• Legal/liability: The reconciliation output must be framed as "educational comparison" not "second opinion" or "correction." The reference report is from the treating radiologist; implying the AI found something they "missed" could cause unnecessary patient anxiety or erode radiologist trust.
• Parsing the reference report: Official radiology reports are unstructured text, sometimes with proprietary formatting. A simple text pass to the LLM is probably fine for MVP, but expect edge cases.

This is worth building — I'd put it in the backlog after the DICOM de-identification (#57) and consent issues (#63, #66) are resolved.