The radiology reportfrom the reading workstation to the record
A radiology report is more than text. It starts as a draft, becomes complete and then verified, and every change creates a new object. In the IHE profile it is a DICOM Structured Report that moves between a few well-defined roles and is finally exported to the hospital record as an HL7 message.
- DICOM
- HL7 v2
- Internal action
Tip: click an arrow or box in the diagram to jump to that step. Time flows top to bottom.
The radiologist authors the report
Core stepWhat happens
The radiologist reads the images and the Report Creator turns the findings into a DICOM Structured Report. IHE requires at least a Basic Text SR. If the report has numeric values, such as measurements, it has to be an Enhanced SR. How the creator obtains the content (typing, dictation, templates) is outside the IHE profile.
Why it is needed
A structured object is what lets the report be stored, versioned, queried and linked to the images, which plain text cannot do. The report is tied to its study through the Study Instance UID, and a report on several studies is copied into each one.
Technical details
- Basic Text SR Storage 1.2.840.10008.5.1.4.1.1.88.11
- Enhanced SR Storage 1.2.840.10008.5.1.4.1.1.88.22 (when numeric values are needed)
- Content follows the DICOM template TID 2000, with coded entries from the DICOM Content Mapping Resource (PS3.16)
- Recommended: the SR uses the Study Instance UID of the images reported on
- Several studies in one report: one copy per study, each with a different SOP Instance UID and an Identical Documents Sequence (0040,A525)
Report Submission (RAD-24)
Core stepWhat happens
The Report Creator sends the SR to the Report Manager with a normal C-STORE. It may be a draft or a final report. The creator is the Storage SCU. The manager is the Storage SCP, at least of Basic Text SR and optionally of Enhanced SR, and it must store everything it receives (Level 2, Full).
Why it is needed
Draft and final are told apart by two flags in the SR. After the manager has the report, the creator gives up responsibility for it: it may not change that object any more, only create a new one with a new SOP Instance UID.
Technical details
- A final report: Completion Flag (0040,A491) = COMPLETE and Verification Flag (0040,A493) = VERIFIED
- Any other values of the two flags make it a draft
- Report Manager: Storage SCP of Basic Text SR, optionally Enhanced SR, Level 2 (Full) storage
- References to the images the creator used go in the Current Requested Procedure Evidence Sequence (0040,A375) or the Pertinent Other Evidence Sequence (0040,A385)
The manager completes and verifies
Core stepWhat happens
The Report Manager owns the state of the report. It completes a partial report, which sets the Completion Flag to COMPLETE, and verifies a report, which sets the Verification Flag to VERIFIED and fills in the Verifying Observer. It can also create a new report from earlier ones, merge reports, or create a new version when the patient data changes.
Why it is needed
The old report is never edited in place. The new report carries the full content, gets a new SOP Instance UID and points back to the earlier one with the Predecessor Documents Sequence, so the history of the report can always be followed.
Technical details
- Verification: (0040,A493) = VERIFIED and (0040,A073) Verifying Observer Sequence filled in
- The new report is in a different series than the original, unless creator and manager are the same device
- (0040,A360) Predecessor Documents Sequence references the earlier report(s)
- PS3.4 O.3: a new SOP Instance UID is needed when an attribute of the SR Document General or Content module is added, removed or updated, or the Series or Study UID changes
- Basic Text SR becomes Enhanced SR when the manager adds measurements
Report Issuing (RAD-25)
Core stepWhat happens
The Report Manager sends reports to the Report Repository with C-STORE. It can send a draft exactly as received, a new modified or verified report, or both. The repository is the Storage SCP of both Basic Text SR and Enhanced SR.
Why it is needed
The repository is where readers go for reports. Whether drafts are issued is a choice: it makes reports available before they are verified, which some sites require and others find undesirable, so it can be configured.
Technical details
- Report Manager: Storage SCU of Basic Text SR, optionally Enhanced SR
- Report Repository: Storage SCP of both, Level 2 (Full) storage
- When the manager creates a report from reports already in the repository, the repository AE title is the Retrieve AE Title (0008,0054) in the Predecessor Documents Sequence
Export to the enterprise record (RAD-28)
Key detailWhat happens
When a report is verified and finalized, the Report Manager maps the DICOM SR to HL7 and sends it as an unsolicited ORU^R01 to the Enterprise Report Repository, which is where the hospital record gets it. The report text goes as plain ASCII. If the SR refers to several requests, it sends one ORU per request.
Why it is needed
The EHR does not read DICOM Structured Reports. It reads HL7 results. This export is the bridge, and only the verified report goes out, with the result status F (final).
Technical details
- MSH-9 = ORU^R01. Segments: MSH, PID, optional PV1, OBR, OBX
- OBR-25 Result Status = F
- First OBX carries the SR Instance UID; text OBX segments carry the report
- See the HL7 report export lesson for the full mapping
A reader finds the report (RAD-26)
Core stepWhat happens
A Report Reader, typically the viewer on the radiologist's or the clinician's workstation, queries the Report Repository, the Report Manager, or an external repository with a C-FIND on the Study Root model (optionally Patient Root). Besides the usual keys it can match on the report's own attributes.
Why it is needed
A study can have several reports in different states. The flags and the Verification Observer let a reader ask for only the final ones, or for the latest draft.
Technical details
- Study Root Query/Retrieve FIND 1.2.840.10008.5.1.4.1.2.2.1
- SR keys: Completion Flag (0040,A491), Verification Flag (0040,A493), Verifying Observer Sequence (0040,A073)
- Report title: Concept Name Code Sequence (0040,A043)
- Link to the order: Referenced Request Sequence (0040,A370) with Accession Number and Requested Procedure ID
The report is retrieved (RAD-27)
ConfirmationWhat happens
The Report Reader asks for the selected report and the repository sends it. The report arrives as an SR instance, the same kind of object that was stored, and the viewer shows it next to the images it refers to.
Why it is needed
Retrieval of a report is the ordinary retrieve of the Query/Retrieve service. The images the report points to can be retrieved the same way, using the references in the SR.
Technical details
- Retrieval by C-MOVE or C-GET, with C-STORE sub-operations (see the C-MOVE lesson)
- Report Repository, Report Manager or an Imaging Document Source can serve the report
- The same set of Study, Series and SOP Instance UIDs is returned every time for the same report
A final report is corrected
Key detailWhat happens
IHE recommends that amendments to a report are made by creating a new SR that contains the original content plus the amendments, and that refers to the original with the Predecessor Documents Sequence. The new report gets a new SOP Instance UID. If the report has identical copies in other studies, the user may be asked whether the change applies to those too.
Why it is needed
Nothing is overwritten. A reader, an audit or a legal request can always see which version was current when, and who verified it.
Technical details
- New SOP Instance UID, Predecessor Documents Sequence (0040,A360) to the original
- The amended report is verified again: Verification Flag and Verifying Observer Sequence
- Identical Documents Sequence (0040,A525) lists the copies in other studies
- The corrected report is issued and exported again like any other
All steps at a glance
Glossary
- DICOM Structured Report (SR)
- A DICOM object that holds a report as structured content: text sections, coded entries, measurements and references to images. It is stored, queried and retrieved like any other DICOM object.
- Report Creator
- The IHE role that authors the report, usually the reading workstation. It sends the SR to the Report Manager.
- Report Manager
- The IHE role that owns the state of reports: it completes, verifies, amends and issues them, and exports verified ones to the enterprise.
- Report Repository
- The IHE role that stores issued SRs and answers queries for them.
- Report Reader
- The IHE role that queries for reports and retrieves them for viewing.
- Completion Flag and Verification Flag
- Two attributes of an SR, (0040,A491) and (0040,A493). A final report is COMPLETE and VERIFIED; any other combination is a draft.
- Predecessor Documents Sequence
- The SR attribute (0040,A360) that lists the earlier reports a new report is based on. It makes the version history followable.
- ORU^R01
- The HL7 v2 message for an unsolicited observation result. It is how a verified report reaches the hospital record.
Summary
- In IHE the report is a DICOM Structured Report:
Basic Text SRat minimum,Enhanced SRwhen it has measurements. It uses the templateTID 2000. - A final report has the Completion Flag
COMPLETEand the Verification FlagVERIFIED. Anything else is a draft. - Changes never edit a report in place. Each change creates a new SR with a new SOP Instance UID that points to its predecessor.
- The transactions are
RAD-24submission (C-STORE),RAD-25issuing (C-STORE),RAD-26query (C-FIND),RAD-27retrieve (C-MOVE or C-GET) andRAD-28export (HL7ORU^R01). - Only verified reports are exported to the hospital record, as plain text with result status
F.
The 8 steps in plain text
The radiologist authors the report
The radiologist reads the images and the Report Creator turns the findings into a DICOM Structured Report. IHE requires at least a Basic Text SR. If the report has numeric values, such as measurements, it has to be an Enhanced SR. How the creator obtains the content (typing, dictation, templates) is outside the IHE profile.
Why: A structured object is what lets the report be stored, versioned, queried and linked to the images, which plain text cannot do. The report is tied to its study through the Study Instance UID, and a report on several studies is copied into each one.
Report Submission (RAD-24)
The Report Creator sends the SR to the Report Manager with a normal C-STORE. It may be a draft or a final report. The creator is the Storage SCU. The manager is the Storage SCP, at least of Basic Text SR and optionally of Enhanced SR, and it must store everything it receives (Level 2, Full).
Why: Draft and final are told apart by two flags in the SR. After the manager has the report, the creator gives up responsibility for it: it may not change that object any more, only create a new one with a new SOP Instance UID.
The manager completes and verifies
The Report Manager owns the state of the report. It completes a partial report, which sets the Completion Flag to COMPLETE, and verifies a report, which sets the Verification Flag to VERIFIED and fills in the Verifying Observer. It can also create a new report from earlier ones, merge reports, or create a new version when the patient data changes.
Why: The old report is never edited in place. The new report carries the full content, gets a new SOP Instance UID and points back to the earlier one with the Predecessor Documents Sequence, so the history of the report can always be followed.
Report Issuing (RAD-25)
The Report Manager sends reports to the Report Repository with C-STORE. It can send a draft exactly as received, a new modified or verified report, or both. The repository is the Storage SCP of both Basic Text SR and Enhanced SR.
Why: The repository is where readers go for reports. Whether drafts are issued is a choice: it makes reports available before they are verified, which some sites require and others find undesirable, so it can be configured.
Export to the enterprise record (RAD-28)
When a report is verified and finalized, the Report Manager maps the DICOM SR to HL7 and sends it as an unsolicited ORU^R01 to the Enterprise Report Repository, which is where the hospital record gets it. The report text goes as plain ASCII. If the SR refers to several requests, it sends one ORU per request.
Why: The EHR does not read DICOM Structured Reports. It reads HL7 results. This export is the bridge, and only the verified report goes out, with the result status F (final).
A reader finds the report (RAD-26)
A Report Reader, typically the viewer on the radiologist's or the clinician's workstation, queries the Report Repository, the Report Manager, or an external repository with a C-FIND on the Study Root model (optionally Patient Root). Besides the usual keys it can match on the report's own attributes.
Why: A study can have several reports in different states. The flags and the Verification Observer let a reader ask for only the final ones, or for the latest draft.
The report is retrieved (RAD-27)
The Report Reader asks for the selected report and the repository sends it. The report arrives as an SR instance, the same kind of object that was stored, and the viewer shows it next to the images it refers to.
Why: Retrieval of a report is the ordinary retrieve of the Query/Retrieve service. The images the report points to can be retrieved the same way, using the references in the SR.
A final report is corrected
IHE recommends that amendments to a report are made by creating a new SR that contains the original content plus the amendments, and that refers to the original with the Predecessor Documents Sequence. The new report gets a new SOP Instance UID. If the report has identical copies in other studies, the user may be asked whether the change applies to those too.
Why: Nothing is overwritten. A reader, an audit or a legal request can always see which version was current when, and who verified it.
Common questions
What is the difference between a draft and a final report?
In the IHE profile a final report is one where the Completion Flag (0040,A491) is COMPLETE and the Verification Flag (0040,A493) is VERIFIED. Reports with any other values of those flags are drafts. Verifying a report also fills in the Verifying Observer Sequence (0040,A073).
What are Report Creator, Report Manager and Report Repository?
They are actors of the IHE Radiology profile, not DICOM terms. The Report Creator authors the report, the Report Manager owns its state (complete, verify, amend, issue) and the Report Repository stores the issued reports. In a real product several of these can be one system, for example a reporting application that is both creator and manager.
Why does every change create a new report?
PS3.4 says an SR that is modified, by adding, removing or updating attributes of the SR Document General or Content module, gets a new SOP Instance UID. IHE builds on that: the new report refers to the old one with the Predecessor Documents Sequence, so earlier versions stay available and the history can be followed.
Do reports have to be DICOM Structured Reports?
Under IHE Radiology, yes: it defines the reporting workflow on DICOM Structured Reports. Many sites also hold the report as plain text or PDF in the RIS and send it to the EHR over HL7. The export transaction (RAD-28) is the IHE bridge between the two, and your own site may use a different one.
What happens to a report on several studies?
The report is copied into each study, because a DICOM SR belongs to one study. Each copy has its own SOP Instance UID, the same content, and an Identical Documents Sequence that lists the other copies. Changing one copy may mean changing the others, so the user may be asked.
Why can drafts be hidden from readers?
Because sending drafts to the repository makes unfinished reports visible. Some sites need that, so clinicians can see a preliminary report, and others consider it undesirable. In IHE the manager's issuing of drafts can be configured.