A sonographer scanning a first-trimester fetus places calipers on a dozen structures before the exam ends: biparietal diameter, femur length, crown-rump length, each one a number captured at the instant of measurement. Ultrasound reporting software takes that same set of numbers into a structured report without a second data-entry step.
DICOM Structured Reporting: Turning Findings Into Data closes on a section called “Why SR Adoption Still Lags.” Its reasons, mostly that structuring a finding costs a radiologist time they do not have mid-study, hold up everywhere a human has to do the structuring by hand. Ultrasound is the modality where that cost mostly disappears, and the reporting software built around it shows exactly why.
What Ultrasound Reporting Software Has to Turn Into Data
An ultrasound exam runs from a worksheet. A sonographer scanning a carotid artery or a fetal anatomy survey is not composing a narrative. She is filling in a fixed set of fields the protocol already defines: a diameter here, a velocity there, a checklist of structures confirmed present. The measurement happens while the probe is still on the patient, calipers placed on a frozen frame before the next view starts.
That sequence matters because the numbers already exist in structured form before anyone thinks about a report. A biparietal diameter is not a sentence waiting to be dictated. It is a value the machine captured, tied to the frame it was measured on, at the moment the sonographer set the second caliper. Ultrasound reporting software has to carry that value into the finished document exactly as captured, not re-key it from a printed worksheet or a screenshot.
That is a different job than reading a narrative note and coding it after the fact. It is closer to routing data that was already discrete at the source.
PS3.16 Gives Ultrasound Its Own Templates, Not a Shared One
PS3.16, DICOM’s Content Mapping Resource, does not ask ultrasound to reuse a generic measurement report built for CT or MR. It defines a dedicated root template for each ultrasound subspecialty instead. TID 5000, the OB-GYN ultrasound procedure report added through Supplement 26, states its scope plainly: “This is the Template for the root of the Content Tree for the OB-GYN ultrasound procedure report.” Underneath it sit sections built around the actual OB worksheet: fetal biometry, fetal biometry ratios, long bones, cranium, early gestation.
Vascular ultrasound gets the same treatment through a separate family. TID 5100 is, in the standard’s own words, “the Template for the root of the Content Tree for the vascular ultrasound procedure report,” with sections split by vessel and laterality: carotid, renal, upper and lower extremity artery and vein, each pulling from its own coded value set. Cardiac ultrasound has its own template family again, TID 5200, the echocardiography report, covered separately because cardiology’s reporting requirements extend well past a coded measurement tree.
None of these three templates is optional scaffolding a vendor can skip. OB-GYN, vascular, and cardiac ultrasound each measure different anatomy against a different coded vocabulary, and a single shared template would force incompatible fields to sit under the same heading.
Where the Structuring Cost Disappears
The adoption problem the DICOM SR piece describes comes down to who pays to structure a finding, and when. A radiologist selecting a coded finding by hand, one item at a time, pays that cost on every study. That is a real reason adoption lagged wherever a human had to do the selecting after the fact.
Ultrasound breaks that pattern because the person taking the measurement is already touching the pixels directly. Placing a caliper on a frozen frame is the same action that measures the anatomy; there is no separate step where someone later decides what to structure. The coded unit, the value, and the anchor back to the image arrive together the instant the second caliper lands. The measurement tool the sonographer is already using produces all three as a byproduct of that click, not as a second task afterward.
That is the specific condition DICOM SR needed to spread past a specification and into routine use. It needed a workflow where structuring a finding is not extra work layered on top of the exam, but the same motion that performs it.
Where SR Took Hold, and What One Site Measured
This is not only a theoretical fit. A 2022 HIMSS and SIIM collaborative white paper in the Journal of Digital Imaging names ultrasound in the part of SR that did take hold. The DICOM Structured Report family of objects, it reports, “has been widely adopted in clinical practice for encoding data during the exam acquisition process such as dose data from a CT exam or measurements from an ultrasound.” The same paper scopes that success precisely: it holds “as a format between modalities and PACS,” and the authors expect SR not to become the messaging format between report authoring systems and EHRs.
So the producing half is settled, and the open engineering question is what reads the object afterward. One documented answer: at the University of Pennsylvania Health System, ultrasound scanners and a mini-PACS were configured to generate and accept DICOM structured reports, with the coded values feeding dictation templates through mapped merge fields. That work was presented at the 2014 Society for Imaging Informatics in Medicine meeting. Radiologists still reviewed and signed every report; what changed was who typed the numbers in first.
That project tracked real reporting volume over roughly a year and compared conventional dictation against the autofilled version. The clearest time savings landed on first-trimester obstetric studies, the exams with the most individual measurements to carry into a report by hand, with smaller but still measurable savings on second- and third-trimester studies. One site’s integration is not an adoption rate, and it is not offered as one here. What it shows is that the coded object survives the whole path, from caliper to signed report, once something downstream is built to read it.
Vascular Ultrasound’s Own Coded Vocabulary
A vascular duplex study does not report a bare number for flow speed. DICOM’s Ultrasound Blood Velocity Measurement context group defines the coded concepts a vascular measurement can carry: among them Peak Systolic Velocity, End Diastolic Velocity, and Velocity Time Integral. Each one is pinned to a specific concept name rather than a generic figure the reader has to interpret from context.
That coded vocabulary is what lets a downstream system compare a carotid peak systolic velocity across two visits without a human confirming the two numbers mean the same thing. A free-text report reading “peak velocity 220 cm/s” trusts the reader to know which measurement that is. A coded NUM content item carrying the concept name Peak Systolic Velocity does not need that trust, because the concept travels with the value itself.
Reporting software that only stores this as a formatted paragraph throws that structure away on the way in. Software built to read the coded concept name keeps a carotid stenosis workup queryable years after the report was signed. A DICOM viewer does the same thing for pixels, rendering a measurement back onto its source image instead of trusting a caption.
What Ultrasound Reporting Software Still Has to Get Right
Ultrasound reporting still stops short of automatic. A worksheet template has to match what the sonographer actually measured, field for field, or the SR object arrives with empty sections a reader has to fill in by hand anyway. TID 5000 alone lists a dozen candidate sections for a single obstetric exam, and a reporting system that hardcodes one fixed layout will not match every practice’s worksheet.
Endoscopy reporting solves an entirely different capture problem: a continuous video feed and captured clips, not a series of discrete caliper measurements taken against a fixed worksheet. The two workflows share a DICOM SR destination for their findings, but almost nothing about how those findings get captured in the first place. That is why a platform built for one does not automatically cover the other.
A reporting system built only for OB and vascular worksheets will not extend to cardiac or procedural ultrasound without separate engineering, even though all of them ultimately write to the same content-tree model.
Match the Platform to the Worksheet
A product or engineering team evaluating ultrasound reporting software should ask questions specific to the worksheet, not a generic “does it support structured reporting” check. Does the platform read and write TID 5000 sections that match your OB protocol, or a fixed subset that will need custom mapping for every new field? Does a vascular measurement arrive as a coded concept a downstream system can query, or as a formatted number a human has to re-interpret?
Does the reporting layer receive that structured data as a byproduct of the exam, the way caliper placement itself produces it? Or does someone still open a separate authoring tool once the scan is done? That second question decides whether the software saves the time DICOM SR was built to save, or just moves the same manual structuring step one screen over.
Ultrasound did not solve DICOM SR adoption everywhere. What it settled is the producing half. The person taking the measurement and the person who benefits from its structure sit close enough in the workflow that the coded object gets made as a byproduct. Reading that object back out is still a build decision someone has to make, which is where most of the engineering time on this goes.
It is also the decision a partner scopes against the platform it ships on, EBM Fabric™ included.