Structured Reporting in Radiology: How DICOM SR and AI-Generated Findings Actually Work Together

Radiology AI demos love screenshots. Real operations care about what object lands in PACS, which codes travel downstream, who can edit the finding before signature, and whether the EHR still receives a report humans can defend in peer review. That gap—between a model heat-map and a durable clinical artifact—is exactly where DICOM Structured Reporting (SR) sits.

Influrion Solutions is a software development and healthcare IT company that builds DICOM/PACS, HL7/FHIR, and imaging-AI integration work for hospitals and health-tech product teams. This article explains how DICOM SR and AI-generated findings are supposed to work together: the object model, the workflow handoffs, the buyer questions that matter, and the failure modes that turn “AI-assisted reporting” into free-text dump with better marketing.

What “structured reporting” means in practice

In radiology, “structured reporting” is often used loosely for any template-driven narrative (pick-lists in the reporting system, macros, organ-system checklists). That UI pattern helps consistency, but it is not the same as DICOM Structured Reporting.

Layer	What it is	Why buyers care
Reporting UI templates	Pick-lists / macros inside RIS or reporting software	Faster dictation, local style guides
Discrete EHR fields	Mapped report sections / impressions into EHR	Downstream analytics, CDS, billing hooks
DICOM SR	A DICOM SOP class: tree of coded content items + evidence references	Interoperable, queryable findings tied to images

You can have excellent UI templates with no SR objects. You can also generate SR objects that never appear in the radiologist’s signed workflow. Product demos often blur these layers. Architecture reviews should keep them separate.

DICOM SR stores clinical observations as a hierarchical document of content items (text, codes, numeric measurements, image references, containers) using concept names from controlled vocabularies (commonly coded with DICOM Context Groups / SNOMED CT / LOINC where templates specify). Templates—TID (Template ID) patterns in the DICOM standard—define expected trees for measurement reports, CAD, key object selection, and more.

AI that only emits a PDF or a blob of prose is skipping the layer that makes findings reusable across PACS archives, AI registries, and analytics pipelines.

How AI findings become SR content (not magic paste)

A clean imaging + AI + SR path looks like this:

1. Acquire / store images — DICOM series in PACS or a VNA, with stable SOP Instance UIDs.
2. Run inference — model outputs candidates: lesions, scores, measurements, laterality, anatomy labels.
3. Encode evidence — preferred pattern: AI results as DICOM objects (often SR and/or secondary capture / SEG / GSPS depending on product design), referencing source images by UID.
4. Present for review — radiologist sees suggestions in the reporting or viewer workflow with accept / edit / reject.
5. Finalize — signed narrative report (HL7 ORU / FHIR DiagnosticReport / PDF as configured) plus durable SR (or updated SR) that reflects what was accepted.
6. Downstream use — tumor boards, longitudinal tracking, research de-identification, quality programs consume coded items—not OCR of prose.

The critical design choice is step 3 and 4: does the AI write opaque text into the report draft, or does it create coded content items the reporting system can display, edit, and re-serialize?

What belongs in the SR tree

For AI-assisted findings, teams usually want:

• Finding concept (coded) — e.g., nodule, hemorrhage, fracture class as the product allows
• Anatomic site / laterality when clinically relevant
• Measurements as numeric content items with units
• Confidence / CAD descriptors when the template supports them (and when clinicians actually want them visible)
• Image references — SOP Instance UIDs (and optionally frame numbers) so a click jumps to evidence
• Device / algorithm identity — manufacturer, model, version, software versions when regulations and local policy require provenance

What should not be the only artifact: a free-text paragraph that cannot be queried, versioned, or linked back to pixels without brittle NLP.

TID templates and why product teams argue about them

DICOM defines many TID patterns. Buyers do not need to memorize every template ID, but they do need vendors to state which templates they write, which they read, and which their reporting/PACS stack can display.

Common conversation buckets:

Intent	Typical SR / related objects	Buyer question
Measurements / quantitative	Measurement report–style SR trees	Can we trend sizes without re-dictating?
CAD / AI detection	CAD SR patterns + evidence links	Are false positives rejectable without polluting the record?
Key images	Key Object Selection (KOS)	Can tumor board pull the same keys next week?
Segmentation overlays	SEG (+ optional SR)	Is the overlay archived or ephemeral in the viewer?
Presentation state	GSPS	Are hanging protocols / annotations portable?

If a vendor says “we support DICOM SR” without naming write, read, and display paths—and without naming template families—treat that as incomplete. Display is often the weakest link: archives may store SR that reporting UIs ignore.

Workflow ownership: AI proposes, radiologist decides

Structured reporting fails socially before it fails technically when ownership is fuzzy.

Radiologist / reporting workflow owns:

• Accept, edit, or reject each AI suggestion
• Final impression language and signature semantics
• Communication of critical results per institutional policy

AI / inference platform owns:

• Deterministic encoding of outputs (or clear versioning when models change)
• Provenance metadata (model ID, version, run parameters where required)
• Failure modes when inference is late, partial, or unavailable

PACS / VNA owns:

• Durable storage, query/retrieve of SR and evidence objects
• Access control consistent with images

RIS / EHR owns:

• Order linkage, report distribution, discrete data mapping contracts

A healthy RFP sentence: “AI findings are stored as DICOM SR (or equivalent coded objects) referencing source SOP UIDs; the reporting system presents them for human accept/edit/reject before signature; rejected findings are not silently written into the permanent clinical narrative.”

Integration checklist for radiology directors and CIOs

Use this in demos and vendor reviews:

1. Object inventory — Which SOP classes are produced for a typical AI exam (SR, SEG, SC, GSPS, PDF encapsulation)?
2. UID integrity — Do findings reference exact instance UIDs from the study the radiologist is reading (including multi-frame edge cases)?
3. Template honesty — Which TIDs are written today (not “on the roadmap”)?
4. Edit path — If the radiologist corrects a measurement, does the stored SR update, or only the narrative?
5. Reject path — Where do rejected AI candidates go (audit log only vs soft-deleted content items)?
6. Latency — Is SR available before report open, or only after batch overnight jobs?
7. Prior comparison — Can longitudinal SR support “same lesion over time,” or is everything exam-isolated?
8. EHR discrete data — Which coded items map to EHR fields vs remain imaging-archive-only?
9. Regulatory posture — Is the AI cleared/indicated for the claimed use; how is device labeling reflected in the record?
10. Degrade gracefully — What does the radiologist see when AI/SR is missing—empty panel, delayed badge, or blocked workflow?

Score vendors on evidence, not slideware. Ask for a live study with SR objects retrieved via your archive tools—not only the vendor’s proprietary viewer.

Pitfalls that create free-text chaos

1. Treating SR as optional decoration

If the “source of truth” remains prose while SR is a side export nobody queries, you paid for a second copy of the problem. Decide which systems consume coded items before go-live.

2. Dumping model prose into Impression

Large language models can draft fluent paragraphs. Fluent is not structured. If generation bypasses codes and image references, you recreate dictation variance with a new dependency. Prefer: coded SR + optional assisted narrative that the radiologist edits.

3. Orphan findings (no image links)

A finding without reliable SOP references becomes hard to defend and hard to teach. Require clickable evidence in acceptance testing.

4. Template mismatch across vendors

Vendor A writes a custom private tree; Vendor B expects a standard TID; your analytics team assumes SNOMED codes that never appear. Publish a content profile for your enterprise: allowed templates, required concept names, and forbidden private-only encodings for shared workflows.

5. Ignoring model version churn

When the model updates, measurement definitions or thresholds can shift. Persist algorithm identity and version on SR (or adjacent provenance). Without that, longitudinal dashboards lie quietly.

6. Blocking the reading room on AI

If SR generation is mandatory and the inference service times out, productivity collapses. Design non-blocking UX with clear status and a documented catch-up path.

7. Confusing secondary capture with structure

A burnt-in PNG of boxes is easy to demo and painful to mine. Secondary capture can supplement communication; it does not replace coded SR for analytics.

Buyer comparison: approaches you will actually see

Approach	Pros	Cons	When it fits
AI → proprietary JSON only	Fast product iteration	Weak archive interoperability	Early pilot inside one viewer
AI → secondary capture overlays	Visible to most PACS	Poor query/analytics	Temporary teaching aids
AI → DICOM SR (+ refs)	Archive-native, coded	Needs display/edit support	Enterprise durable findings
AI → SR + SEG/GSPS	Rich evidence + structure	Heavier integration	Oncology / quantitative programs
AI → free-text draft only	Familiar dictation UX	No structure, weak provenance	Avoid as sole strategy

Most serious programs converge on SR (and related DICOM evidence) plus human-owned narrative, with proprietary JSON allowed only as an internal wire format—not the long-term clinical store.

FAQ

Does DICOM SR replace the radiology report?

No. SR encodes structured observations and evidence links. The signed report (narrative plus institutional distribution) remains the clinical communication artifact most referring clinicians and legal processes expect. Mature designs keep them aligned: accepted SR findings should match what the report asserts.

Can we use FHIR Observation instead of DICOM SR?

You can expose findings as FHIR for EHR/app ecosystems, but imaging evidence still lives in DICOM space. Many architectures keep DICOM SR (or SEG) in the archive and project selected items to FHIR DiagnosticReport / Observation for enterprise APIs. Choosing “FHIR only” for pixel-linked AI findings usually means you deferred the imaging object problem.

What if our PACS “supports SR” but radiologists never see it?

Storage ≠ workflow. Confirm the reporting application and diagnostic viewer can render, navigate, and edit the content items you care about. Archive support alone is insufficient for AI-assisted reporting.

How should we handle AI suggestions the radiologist rejects?

Persist enough audit detail for quality and safety review, but do not leave rejected candidates in the signed clinical narrative or in “accepted findings” analytics. Agree on retention with compliance early.

What should an RFP demand in one sentence?

Require vendors to demonstrate DICOM SR (named templates) with image SOP references, human accept/edit/reject before signature, algorithm provenance, and a non-blocking degrade path—validated against your PACS/reporting stack, not only theirs.

Closing

Structured reporting and AI only “work together” when findings are encoded as durable, coded, image-linked objects—and when radiologists remain clearly in charge of what becomes the signed record. DICOM SR is the standards-shaped place for that contract inside the imaging archive; UI templates and EHR fields are adjacent layers, not substitutes.

If your team is designing an AI-assisted radiology workflow, a PACS/VNA content profile, or a reporting integration that must survive vendor changes, contact Influrion Solutions—we help hospitals and product teams turn imaging AI outputs into interoperable DICOM and platform designs, not demo-only screenshots.