Traditional RDSR and Enhanced RDSR encode largely equivalent information in different ways and have a number of similarities. This section will discuss details of these encodings and advantages of using one or the other.
Traditional RDSR encodes the information based on the concept of individual Irradiation Events, which are defined by a single continuous actuation of the equipment's irradiation switch, from the start of the X-Ray tube loading time of the first pulse until the loading time trailing edge of the final pulse. In projection X-Ray devices, an irradiation event is often analogous with a pedal press or button press. On scanners like CT systems, the irradiation event may not necessarily have a one-to-one correlation with a button press depending on the protocol and acquisition settings. Any on-off switching of the irradiation during the event (e.g., pulsing, pausing for cardiac motion) is not encoded as separate Irradiation Events. In the Traditional RDSR, the Irradiation Event is the smallest information entity recorded.
Enhanced RDSR decouples the Traditional RDSR dependence of reporting information based solely on the beginning and end of an Irradiation Event. For example, values that change infrequently within the scope of the RDSR (e.g., Focal Spot Size) may be encoded with a single value over a time period spanning multiple Irradiation Events. Alternatively, certain values that change within an Irradiation Event (e.g., Tube Current, X-Ray Source Position during CBCT) may be encoded at finer intervals than the Irradiation Event to allow for greater precision when performing dose calculation.
In Enhanced RDSR, the Irradiation Events and the encoding intervals of the parameters are timestamped. This allows relating the values of the parameters to their corresponding Irradiation Event.
Figure UUUU.4.1.1.1-1 shows a simplified example of a short XA procedure meant to illustrate the basic encoding concepts of the Enhanced RDSR timing vs. Traditional RDSR. Enhanced RDSR uses the same encoding methodology for all modalities and procedures.
In this figure, the "Real World Exposures" box shows the imaging modes, gantry position, and pedal presses (i.e., X-Ray switch on/off) of an XA system. There are four presses of the pedal in regular fluoroscopy mode, two presses in DSA mode (Digital Subtraction Angiography), and one press in CBCT mode (Cone Beam CT).
The "Sample Encoding of Traditional RDSR" box shows a simplified encoding of a Traditional RDSR. Each pedal press results in a separate Irradiation Event, and all parameters are encoded within each Irradiation Event.
The "Sample Encoding of Enhanced RDSR" box shows a simplified encoding of an Enhanced RDSR. The encoding is decoupled from the Irradiation Event, allowing content to either span multiple Irradiation Events or to be encoded multiple times within a single Irradiation Event. Parameter values are encoded with a start and end DateTime, rather than being associated with an Irradiation Event. The frequency of the encoding is implementation dependent.
For example, the Technique (tube current, in this example) encodes a single item for all the fluoroscopy events (100 mA for Irradiation Events 1-4), and a second item for the DSA events. The CBCT mode (Irradiation Event 7) tube current is modulating and is encoded as many times as needed for dosimetry purposes (four in this example).
Similar to the Technique, the Source Position is encoded a single time for the first six Irradiation Events since it is not moving, and then encoded multiple times for Irradiation Event 7 to reflect the fact that it is rotating around the patient.
In this example, the implementation choses to encode one radiation output value grouping the four fluoroscopy events since the Source Position is fixed, and to encode multiple radiation output values during the CBCT event to provide a more granular record of the dose at the several positions of the X-Ray source. This granularity allows a more accurate mapping of the dose values to the different parts of the patient body, E.g., for skin dose calculations.
Information in the Enhanced RDSR is organized using SR Templates (identified by TIDs). Each Template is designed to contain related information which typically changes at similar frequencies. Information contained in two different Templates could change at different frequencies.
Multiple inclusions of each Template may be encoded at different intervals from the Irradiation Events at whatever frequency is required to provide sufficient temporal resolution of the Template Content Items.
Within certain Templates, some Content Items are permitted to be encoded as either a single value (Value Type NUM) or a table of values (Value Type TABLE) with associated DateTimes. Note when such Templates are included multiple times, it is not required that they all use the same encoding. E.g., one inclusion could use a single value encoding while another inclusion of the same Template could use a table encoding.
Figure UUUU.4.1.1.2-1 illustrates the structure of encoding Content Items within the Templates, as well as the use of the TABLE Value Type to encode a Content Item with multiple values, and for Air Kerma mixing encoding types. For a complete example of RDSR encodings see the examples in Section UUUU.5.
For TABLEs with DateTime Started as the first column, the DateTime Started of the first row matches the DateTime Started of the Template in which the Content Item resides. Subsequent times within each TABLE do not necessarily match each other. This is illustrated by the tube potential and tube current TABLES: each has starting time of t0, but the next value for tube current is t1, while it is t2for tube potential. The time t1may be equal to t2but is not required to be. The final DateTime Started listed in the TABLE is not after the DateTime Ended of the Template. In this example, the Template for Radiation Technique is used only a single time, with all additional temporal information provided using the TABLE Value Type.
For TABLEs with DateTime Ended as the first column, the DateTime Ended of the first row is not before the DateTime Started of the Template in which the Content Item resides. For the Radiation Output Template in this example, it is used twice. In the first case, the Air Kerma at the Output Measurement Point is provided as a single value, where in the second case it is provided in a TABLE. As described earlier, in the case of using the TABLE VT for Air Kerma at the Output Measurement Point, the value provided is the Air Kerma accumulated over the period of time between the DateTime Ended listed in the table. For the first value, it is the Air Kerma accumulated between the DateTime Started listed in Row 2 of the Radiation Output Template and the DateTime Ended in the first row of the TABLE.
Although the encoding of Traditional RDSR and Enhanced RDSR is different, both RDSRs contain largely equivalent information. Table UUUU.4.1.2-1 provides a general comparison between the Traditional and Enhanced RDSRs and explains where various information is contained within each RDSR type.
Table UUUU.4.1.2-1. Comparison Between Traditional and Enhanced RDSR
|
Root TID 10040 |
||
|---|---|---|
|
Same TID 10041 for all modalities, which includes accumulated data of each modality. |
||
|
The technical data is described either once for the Irradiation Event (as average or a single measurement point) or for every pulse in the Event.
|
TID 10042 provides summary data for each Irradiation Event for all modalities. Technical data for all modalities is described in TIDs included in TID 10043 based on the time periods through the whole RDSR. |
|
|
(See Figure UUUU.4.1.1.1-1 and Figure UUUU.4.1.1.1-1 for further details) |
Irradiation Event (start time, duration).
|
Individual time period at the beginning of each TID included in TID 10043, or for each row of a TABLE Value Type. These time periods do not necessarily align with the Irradiation Event time periods, as they can be defined at X-Ray pulse level, or across many Irradiation Events. Overall DateTime Started and Ended is listed in TID 10043, providing the complete time period for all events within the Scope of Accumulation. |
|
(Positioner, Table, Patient Orientation, Collimator, Attenuators in the beam) (See Section UUUU.4.5 for further examples) |
Distances, angles, areas, typically patient-based.
|
Equipment or Room Coordinate-based description of positions and shapes in TID 10050 and TID 10052 for all modalities. X-Ray Source Coordinate-based description of positions and shapes in TID 10049 (e.g., collimator) and TID 10051 (e.g., Reference Point) for all modalities. |
Information that may be required by various regulatory, accreditation, and government agencies (e.g., directly or through standards like IEC) appears in both Traditional RDSR and Enhanced RDSR but in different TIDs.
Regulatory agencies sometimes state requirements for particular information by specifying particular TID numbers to be recorded by devices that create RDSRs. During maintenance of the DICOM Standard, it is rare but possible for TID numbers to be redefined. Users and regulators should refer to the current DICOM Standard for the appropriate TID numbering.
Each RDSR Instance of both Traditional RDSR and Enhanced RDSR includes information of the Irradiation Events within its scope of accumulation, as well as accumulated dose data within that scope.
Each Irradiation Event is uniquely identified by its Irradiation Event UID.
For a given Procedure Step or a given Study, several RDSR Instances might be created. The way RDSR creators organize the Irradiation Events across instances of RDSR is implementation dependent. Consider two cases: Overlapping RDSR and Non-Overlapping RDSR, depending on whether or not any Irradiation Event appears in more than one RDSR.
Some implementations may duplicate Irradiation Events that exist in prior RDSR Instances in the subsequent RDSR Instances to provide a "complete" record at each point in time. In that case, there will be multiple RDSR Instances that are overlapping in the sense that some Irradiation Events are duplicated.
It is important for RDSR consumers to carefully track Irradiation Event UIDs to correctly distinguish duplicate events from new events. Duplicate Irradiation Events will have the same Irradiation Event UID allowing them to be readily identified to avoid double-counting the recorded dose.
Consider the following examples of overlapping RDSR:
-
"Real Time" procedure dose tracking:
-
After each Irradiation Event, the equipment creates a new RDSR Instance with a Scope of Accumulation = Procedure Step to this pointcontaining all the Irradiation Events since the beginning of the Procedure Step.
-
At the end of the Procedure Step, the equipment creates one final RDSR Instance with the Scope of Accumulation = Procedure Stepcontaining all the Irradiation Events of the whole completed Procedure Step.
-
Procedure Step and Study level accumulation:
-
At the end of the first Procedure Step, the equipment creates a first RDSR Instance containing all the Irradiation Events of the first Procedure Step with a Scope of Accumulation = Procedure Step.
-
At the end of the second Procedure Step (e.g., continue the study for the same patient), the equipment creates a second RDSR Instance for the whole study (Scope of Accumulation = Study) containing all the Irradiation Events of both procedure steps.
-
-
-
At the end of the Study, the equipment creates one RDSR Instance containing all the Irradiation Events of that study with a Scope of Accumulation = Study.
-
The Study is reopened to perform more imaging on the same equipment (e.g., because of additional Mammo views, patient complications in XA, or CT anatomic coverage issues).
-
After the new imaging is performed, the equipment creates an additional RDSR Instance with a Scope of Accumulation = Study, containing all the new Irradiation Events and all the previous Irradiation Events since the beginning of the Study.
-
-
4. Mixed Traditional and Enhanced RDSR:
-
For interoperability reasons, two RDSR consumers expect different forms of RDSR.
-
At the end of the Study, the equipment creates one Traditional RDSR Instance and one Enhanced RDSR Instance, both containing the same Irradiation Events.
-
Consumers that prefer Enhanced RDSR or Traditional RDSR can Query Retrieve appropriate Instances based on the SOP Class.
-
Some implementations might not duplicate prior Irradiation Events in the subsequent Instances. In this case, there will be multiple non-overlapping RDSR Instances in the sense that the Irradiation Events in one RDSR Instance are not duplicated within other RDSR Instances.
Consider the case where an external device wishes to display dose in "real time". After each Irradiation Event, the equipment creates a new non-overlapping RDSR Instance with a Scope of Accumulation = Irradiation Event containing only the dose information of that individual Irradiation Event. During the case, the external device consumes the RDSR Instances as they become available. After the case, since dose consumers would otherwise have to retrieve all of the RDSR Instances, the equipment might be likely to create a complete overlapping RDSR at the end of the procedure step, with higher level of Scope of Accumulation, e.g., Procedure Step, Series, or Study.
The IHE REM Profile provides guidance on these Irradiation Event UIDs and populating the Predecessor Documents Sequence (0040,A360) to process related RDSR Instances.
Refer to Section 4.62.4.1.1 in the following link:
http://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf
Dose analysis should exclusively be based on the information of the Irradiation Events contained in the RDSRs created during and after a procedure.
DICOM RDSR Instances are designed to accurately and completely capture irradiation dose information for subsequent dose analysis and QA processes.
DICOM Image Instances are designed to accurately and completely capture medical imaging information for clinical presentation and processing. While the Image Instance metadata may contain dose-related details that are supportive of presentation and processing, they are not sufficiently complete for dose analysis purposes.
Further, some Irradiation Events (which are all captured in DICOM RDSR Instances) do not result in DICOM Image Instances. For example:
On the other hand, an Irradiation Event might result in multiple images (e.g., original and processed images, 3D reconstructions, etc.), so estimating dose based on image metadata would incorrectly overestimate dose.
Images are a useful part of dose management. Dose analysis should take into account the trade off between dose reduction and image quality. In order to allow proper association of images with their corresponding Irradiation Events, the Irradiation Event UID is also encoded within the image metadata.
To summarize, the RDSR contains all the irradiation events that occurred during the scope of accumulation regardless of whether the irradiation resulted in any stored images. Additionally, for those Irradiation Events that resulted into DICOM stored image(s), the RDSR provides means to refer to the UID(s) of such image(s).
However, it might happen that the DICOM Image Objects were created but then rejected and also possibly deleted before being stored for long term archiving. In order to document such situation, the RDSR provides means to label each Irradiation Event indicating if the related acquisition was rejected, and if it was the result of a repeated irradiation.
If an acquisition is a rejected because it was unsatisfactory, this may be recorded along with a coded reason. This is intended to help with subsequent analysis by providing a priori information about why the study might be flagged as an outlier with higher dose exposure values than usual for the type of study.
If an acquisition is a repeat because an earlier acquisition was unsatisfactory, this may be recorded along with a coded reason and the earlier acquisition's irradiation event UID. This is intended to help with subsequent analysis by providing a priori information about why the study might be flagged as an outlier with higher dose exposure values than usual for the type of study.
Note that several Irradiation Event UIDs may be rejected consecutively, i.e., the repeated acquisition may be also rejected in turn.
The Image UID corresponding to an Irradiation Event is encoded in TID 10003A, (113795, DCM, "Acquired Image"). The requirement Type is "MC" and the condition is IFF Image Object is created for this irradiation event.
The information about whether the acquisition of an Irradiation Event was rejected is in TID 10003 and TID 10013, (130503, DCM, "Is Rejected Acquisition"). If the value is (373066001, SCT, "Yes") the reason for rejection is in (130504, DCM, "Reason for Rejecting Acquisition").
The information about whether the Irradiation Event was due to a repeated acquisition is in TID 10003 and TID 10013, (128551, DCM, "Is Repeated Acquisition"). If the value is (373066001, SCT, "Yes") the reason for repeating is in (128552, DCM, "Reason for Repeating Acquisition"), and the information about the previously rejected acquisition of an Irradiation Event UID resulting into this new Irradiation Event is in (113769, DCM, " Irradiation Event UID").
The Image UID corresponding to an Irradiation Event is encoded in TID 10042, (113795, DCM, "Acquired Image"). The requirement Type "U" with no condition.
The information about whether the acquisition of an Irradiation Event was rejected is in TID 10042, (130503, DCM, "Is Rejected Acquisition"). If the value is (373066001, SCT, "Yes") the reason for rejection is in (130504, DCM, "Reason for Rejecting Acquisition").
The information about whether the Irradiation Event was due to a repeated acquisition is in TID 10042, (128551, DCM, "Is Repeated Acquisition"). If the value is (373066001, SCT, "Yes") the reason for repeating is in (128552, DCM, "Reason for Repeating Acquisition"), and the information about the previously rejected acquisition of an Irradiation Event UID resulting into this new Irradiation Event is in (113769, DCM, " Irradiation Event UID").