Hello,
I have a question about updating the RDSR: an SCU creates 2 RDSR for exam A and exam B, sends them to the SCP and then the SCU makes a change such as moving a single dose from exam A to exam B. When sending the RDSR to the SCP what is the correct way to handle this situation? Does SCU send the same RDSR (same StudyUID, same SeriesInstanceUID and same SOP Instance of RDSR) but with different irradiation events? Should it send all irradiation events?
Does the SCP overwrite the RDSR with the new radiation data? Or can it make a decision based on the UIDs of the irradiation event? So does the SCU have to send both the RDSRs of exam A and exam B or is the RDSR of B with the extra dose enough?

Thank you very much
Matteo

On Tuesday, May 25, 2021 at 7:57:50 AM UTC-7, Matty wrote:
> Hello,
> I have a question about updating the RDSR: an SCU creates 2 RDSR for exam A and exam B, sends them to the SCP and then the SCU makes a change such as moving a single dose from exam A to exam B. When sending the RDSR to the SCP what is the correct way to handle this situation? Does SCU send the same RDSR (same StudyUID, same SeriesInstanceUID and same SOP Instance of RDSR) but with different irradiation events? Should it send all irradiation events?
> Does the SCP overwrite the RDSR with the new radiation data? Or can it make a decision based on the UIDs of the irradiation event? So does the SCU have to send both the RDSRs of exam A and exam B or is the RDSR of B with the extra dose enough?
>
> Thank you very much
> Matteo

Hi Matteo,
Your question spans a couple of relevant issues. For naming purposes, let's call your first two RDSR objects A1 and B1.

First, you should not send the revised objects using the SOP Instance UIDs of A1 and B1.
A premise of DICOM is that two instances with the same SOP Instance UID have the same content.
(Yes there are exception cases but those have to be described and handled very carefully)
So the receiving system may see the "new" incoming object as a resend of the original A1 and choose to discard the new one as a duplicate.
Also, if the original A1 has been retrieved by anyone there are now two (or many) copies of the SOP Instance and if they have different contents, then the situation rapidly gets confusing.
So the new objects should have new SOP Instance UIDs of A2 and B2.
A2 will have the same Study UID as A1 since they still belong to the same study, and B2 will have the same Study UID as B1.
A2 would likely use the same Series UID as A1 since your pattern is likely to put all RDSRs together in a series, but you could put it in a new series..

In this scenario, A2 and B2 should contain all the irradiation events for exam A and exam B respectively.
That means A2 contains one less irradiation event, and B2 contains one more irradiation event.
In a simpler scenario where exam C and exam D were completed correctly and C1 and D1 were sent, then there was a request for an additional exposure in exam D, you could send RDSR D2 with only the single new irradiation event or you could include all the exam D events.
Since RDSRs include an Irradiation Event UID (0008,3010) for each irradiation event, later analysis can load all the RDSRs and recognize any duplicate events from their UIDs.

The final question is what to do with the "bad" RDSRs (A1 and A2).
Most PACS have manual tools and exception queues for cleaning up bad data, so you could arrange to have A1 and B1 deleted.
Some PACS are starting to support the IHE IOCM Profile (Imaging Object Change Management) which allows "bad" objects to be flagged and automatically sequestered and/or deleted by the PACS, and allows for such flags to be passed along to federated PACS systems.
https://wiki.ihe.net/index.php/Imaging_Object_Change_Management

Hope that's helpful.

Best Regards,
Kevin O'Donnell
Canon Medical

Kevin O'Donnell wrote:
"So the receiving system may see the "new" incoming object as a resend of the original A1 and choose to discard the new one as a duplicate. "

For my own clarification, my understanding is that the receiving system could alternately choose to discard the old one and replace it with the new one, and that it is implementation dependent because the DICOM specification allows either. (Personally I see arguments in favor of either choice.)

Furthermore, the receiving system does not have to mention this in its conformance statement, though it would be nice if they did.

Is that correct?

Thanks - Jim Irrer

On Tuesday, June 15, 2021 at 6:14:00 AM UTC-7, Jim Irrer wrote:
> Kevin O'Donnell wrote:
> "So the receiving system may see the "new" incoming object as a resend of the original A1 and choose to discard the new one as a duplicate. "
> For my own clarification, my understanding is that the receiving system could alternately choose to discard the old one and replace it with the new one, and that it is implementation dependent because the DICOM specification allows either. (Personally I see arguments in favor of either choice.)
>
> Furthermore, the receiving system does not have to mention this in its conformance statement, though it would be nice if they did.
>
> Is that correct?
>
> Thanks - Jim Irrer

Hi Jim,

Yes, I'd agree with all of your stated facts (and I agree with your stated opinions too for whatever that's worth :-) )

Cheers,
Kevin

Il giorno lunedì 14 giugno 2021 alle 20:15:40 UTC+2 Kevin O'Donnell ha scritto:

>
> First, you should not send the revised objects using the SOP Instance UIDs of A1 and B1.
> A premise of DICOM is that two instances with the same SOP Instance UID have the same content.
> (Yes there are exception cases but those have to be described and handled very carefully)
> So the receiving system may see the "new" incoming object as a resend of the original A1 and choose to discard the new one as a duplicate.
> Also, if the original A1 has been retrieved by anyone there are now two (or many) copies of the SOP Instance and if they have different contents, then the situation rapidly gets confusing.
> So the new objects should have new SOP Instance UIDs of A2 and B2.
> A2 will have the same Study UID as A1 since they still belong to the same study, and B2 will have the same Study UID as B1.
> A2 would likely use the same Series UID as A1 since your pattern is likely to put all RDSRs together in a series, but you could put it in a new series.
>
> In this scenario, A2 and B2 should contain all the irradiation events for exam A and exam B respectively.
> That means A2 contains one less irradiation event, and B2 contains one more irradiation event.
> In a simpler scenario where exam C and exam D were completed correctly and C1 and D1 were sent, then there was a request for an additional exposure in exam D, you could send RDSR D2 with only the single new irradiation event or you could include all the exam D events.
> Since RDSRs include an Irradiation Event UID (0008,3010) for each irradiation event, later analysis can load all the RDSRs and recognize any duplicate events from their UIDs.
>
> The final question is what to do with the "bad" RDSRs (A1 and A2).
> Most PACS have manual tools and exception queues for cleaning up bad data, so you could arrange to have A1 and B1 deleted.
> Some PACS are starting to support the IHE IOCM Profile (Imaging Object Change Management) which allows "bad" objects to be flagged and automatically sequestered and/or deleted by the PACS, and allows for such flags to be passed along to federated PACS systems.
> https://wiki.ihe.net/index.php/Imaging_Object_Change_Management
>
> Hope that's helpful.
>
> Best Regards,
> Kevin O'Donnell
> Canon Medical

Hi Kevin,
thank you very much for your complete and helpful answer and sorry for my late reply...
My last question is about the Scope of Accumulation of RDSR: does this element affect the reasoning of the SCP?
Is possible to make decisions using the Scope? Using your last example, the SCP receive the RDSR D2 with only one event and then if the Scope is Study it should decide that the exam has now only one event (and also delete old RDSR and Events linked to it), instead if the Scope is different from Study (Step or Event) the SCP should only add this event to the others previously received. Is it correct?

Thanky you again and Best regards
Matteo Airaghi

This is an interesting discussion, and I would like to add a hypothesis/question.

For sure, IOCM is a relevant building block for a perfect solution but as Kevin outlined, it is not (yet) available everywhere. In my understanding the SR itself allows to indicate that a given SR instance is an "update" of another SR instance. The Predecessor Documents Sequence (0040, A360) in the SR Document General Module is a 1C attribute on the instance level, It...

(PS3.3, Table C.17-2.)
"References to SOP Instances (e.g., prior or preliminary reports) whose content has been wholly or partially included in this document with or without modification.
One or more Items shall be included in this Sequence.
Required if this document includes content from other documents.
Note
The amendment process of an existing SR Document may be described using the Purpose of Reference Code Sequence."

So I would say that regardless of whether you can delete the previous report via IOCM, you should reference that report in this sequence and give (DCM, 121360, "Replaced report") as the purpose of reference.

Obvioulsy this would require to re-send the RDSRs for exam A _and_ B and include _all_ irradiation events in these reports (not just the changed one).