DICOM SR to HL7how the report reaches the hospital record
The hospital record reads HL7, not DICOM Structured Reports. When a report is verified, the Report Manager converts it into an unsolicited HL7 ORU^R01 message. This page maps the DICOM attributes to the HL7 fields and segments, as IHE defines it.
28 rows
The message
One ORU^R01 per request in the SR. Only verified, final reports are exported.
| Item | IHE RAD-28 |
|---|---|
| Trigger | The Report Manager has verified and finalized a DICOM Structured Report. It then sends an unsolicited ORU. |
| Message type | MSH-9 = ORU^R01, HL7 v2.3.1 chapter 7. |
| Segments | MSH, PID, optional PV1, OBR, and one or more OBX. |
| PV1 | Required when the region or country requires the visit number in PV1-19. |
| Several requests in one SR | If the SR has several items in its Referenced Request Sequence, a separate ORU is generated for each item. |
| Report text | Plain ASCII. The Report Manager renders the SR consistent with its content and the limits of ASCII. Special formatting characters are avoided and spaces are used for column alignment, because tab characters may not be valid at the final display device. |
| Acknowledgement | Each message is acknowledged with an HL7 ACK. |
No rows match the filter in this table.
MSH, PID and PV1: the patient and the message
Required fields and where the DICOM values come from.
| HL7 field | Name | DICOM source | Notes |
|---|---|---|---|
MSH-18 | Character Set | Specific Character Set (0008,0005) | Conditional. |
PID-3 | Patient Identifier List | Patient ID (0010,0020) | Required. |
PID-5 | Patient Name | Patient's Name (0010,0010) | Required. |
PID-7 | Date/Time of Birth | Patient's Birth Date (0010,0030) | Required if known. |
PID-8 | Sex | Patient's Sex (0010,0040) | Required if known. |
PID-10 | Race | Ethnic Group (0010,2160) | Required if known. |
PID-18 | Patient Account Number | Not in the SR | The Report Manager supplies it. At least one of PID-18 and PV1-19 has to be valued. |
PV1-2, PV1-19, PV1-51 | Patient Class, Visit Number, Visit Indicator | Not in the SR | PV1-19 is conditional. PV1-51 is V when the visit number is present. |
No rows match the filter in this table.
The other required MSH fields (sending and receiving application and facility, message control ID, processing ID, version ID) are filled in by the sender as for any HL7 message.
OBR: the order and the result status
Fields of the OBR segment that tie the result to the order.
| HL7 field | Name | DICOM source | Notes |
|---|---|---|---|
OBR-1 | Set ID | None | One OBR per ORU. |
OBR-2 | Placer Order Number | Referenced Request Sequence: Placer Order Number (0040,2016) | If the SR does not have it, the Report Manager is assumed to know it. |
OBR-3 | Filler Order Number | Referenced Request Sequence: Filler Order Number (0040,2017) | If the SR does not have it, the Report Manager is assumed to know it. |
OBR-4 | Universal Service ID | Not in the SR | The Report Manager supplies the Universal Service ID of the original order. |
OBR-7 | Observation Date/Time | Observation DateTime (0040,A032), otherwise Content Date (0008,0023) and Content Time (0008,0033) | Required. |
OBR-25 | Result Status | Fixed value F | Final result. Only final reports are exported. |
OBR-32 | Principal Results Interpreter | The Person Observer Name (0040,A123) of the content item related to the root with HAS OBS CONTEXT and concept (121008, DCM, "Person Observer Name") | Optional. |
No rows match the filter in this table.
OBX: the UIDs, the image references and the text
The OBX segments come in three groups. All have the result status `F` in OBX-11, and no context is assumed between OBX segments.
| Group | OBX-2 value type | OBX-3 identifier | OBX-5 value | Notes |
|---|---|---|---|---|
| First OBX | HD | ^SR Instance UID | The SR SOP Instance UID (0008,0018) | Always present, Set ID 1. |
| Each image content item: Study UID | HD | ^Study Instance UID | Study Instance UID (0020,000D) from the matching evidence item | The content item only has the SOP Class and SOP Instance UID. Study and Series UID are found in the Current Requested Procedure Evidence or Pertinent Other Evidence Sequence, matched on the SOP Instance UID. |
| Each image content item: Series UID | HD | ^Series Instance UID | Series Instance UID (0020,000E) from the matching evidence item | Same four OBX share one Observation Sub-ID in OBX-4, starting at 1 and increasing for each image. |
| Each image content item: SOP Instance UID | HD | ^SOP Instance UID | Referenced SOP Instance UID (0008,1155) | Lets the enterprise repository look up the referenced image. |
| Each image content item: SOP Class | HD | ^SOP Class ID | Referenced SOP Class UID (0008,1150) | Completes the reference. |
| Report text | TX | ^SR Text | The report text from the SR object | One or more OBX segments, in plain ASCII. |
No rows match the filter in this table.
The four OBX segments of an image reference repeat for each IMAGE content item in the SR. The text OBX segments follow them.
Glossary
- ORU^R01
- The HL7 v2 message that reports an observation result. Unsolicited means it is sent without a query.
- Enterprise Report Repository
- The IHE role that receives the exported HL7 results, in practice the hospital record or its result store.
- Result status
- OBR-25 and OBX-11 say how final a result is. `F` means final.
- OBX
- The HL7 segment for one observation. A report is sent as several OBX segments: identifiers first, then text.
- HD
- The HL7 hierarchic designator value type, used here for UIDs.
- Observation Sub-ID
- OBX-4. Groups OBX segments that belong together, here the four OBX of one image reference.
Summary
- RAD-28 sends each verified SR as an unsolicited
ORU^R01(HL7 v2.3.1):MSH,PID, optionalPV1,OBRandOBX. - The patient fields come from the SR patient attributes.
PID-18(account number) and the Universal Service ID inOBR-4come from the Report Manager. OBR-2andOBR-3carry the placer and filler order numbers from the Referenced Request Sequence.OBR-25isF.- The first
OBXcarries the SR Instance UID, fourOBXper referenced image carry its UIDs, andTXOBX segments carry the report text. - The text is plain ASCII with no tabs, so it can be shown on any receiving system.
Common questions
Which HL7 message carries a radiology report?
In the IHE profile an unsolicited ORU^R01 (HL7 v2.3.1), sent by the Report Manager to the Enterprise Report Repository once the DICOM Structured Report is verified and finalized. The segments are MSH, PID, optionally PV1, OBR and one or more OBX.
Where does the report text go in the HL7 message?
In OBX segments with value type TX and the observation identifier ^SR Text, after the OBX segments that carry the UIDs. The text is plain ASCII, and when several OBX segments are used no context is assumed between them.
How are the images the report refers to identified in HL7?
With four OBX segments of value type HD per image: ^Study Instance UID, ^Series Instance UID, ^SOP Instance UID and ^SOP Class ID. They share one Observation Sub-ID, which starts at 1 and increments per image. The first OBX of the message carries the SR Instance UID.
Are draft reports exported?
Not by this transaction. The Structured Report Export is triggered when the Report Manager has verified and finalized the report, and the result status in OBR-25 and OBX-11 is F. Drafts may be issued to a Report Repository with a C-STORE, but they are not exported as HL7 results.
What happens to a report that is corrected after export?
The corrected report is a new DICOM SR with a new SOP Instance UID that points back to the original. Once it is verified it is exported again like any report, with its own SR Instance UID in the first OBX. How the receiving system treats a result that replaces an earlier one depends on the receiver. The RAD-28 mapping itself defines only final results.
Is this the same as the order mapping from HL7 to DICOM?
No, it is the reverse direction and a different transaction. The order mapping (HL7 order to DICOM worklist) is in the DICOM and HL7 mapping lesson. This one maps a DICOM report to an HL7 result and is defined by IHE RAD-28.