Hi,

I could need clarification on attribute (0040,A370) "Referenced Request SQ" in SR(-like) objects.
I'm struggling with the right interpretation when it must be used.

Unless I've missed the actual interpretation, I have arrived at two potential conclusions on how to use this attribute:

A ) If a Requested Procedure demanded the creation of the SR(-like) object as a mandatory part of completing the RP then (0040,A370) shall be implemented.
Requested either as a specific task, e.g. via a Unified Procedure Step.
Or implicitly as an integral part of a procedure, but without which the RP would not be satisfied and thus could not be billed, otherwise.
Hence, the SR could not be just an object on the sides, for convenience or as some added value.

B ) Whichever RP the PPS of the SR(-like) object is assicated with shall be entered here. Equivalent to RP info in (0040,0275) "Request Attributes SQ" in images.
Hence, every SR(-like) object created during a scheduled imaging procedure requires (0040,A370) to be filled, even if they are vendor specific or not relevant to the RP or not for diagnostic use.

I do see pro and cons for either interpretation. So, I would appreciate some help with my struggle.
I can even imagine that its purpose has changed over time. Or that some SR(-like) objects have become an integral part of a procedure (e.g. X-Ray Dose SR mandatory for X-Ray imaging procedures?).

Thanks in advance,
Peter

*push*

appreciate any help.

You can also leave a comment if you can relate to this concern.
Maybe it becomes worth a CP for some rephrasing.

Hi Peter

If I recall correctly, the intent was that when SR was a either report of a requested procedure, or some image-like artifact that was generated during a procedure like ultrasound measurements, then the information about the request is expected to be recorded here, regardless of whether it was associated with any particular Scheduled Procedure Step (unlike Request Attributes Sequence in images, which are to tied to a particular MWL SPS). The new Attribute and Macro were created in recognition that there might be no scheduled step for the report generation step itself, for example (as distinct from SPS for acquiring the images that were the subject of the report).

In most real-world cases of the radiologist-generate report, "implicitly as an integral part of a procedure" as you suggested would apply.

There is obviously a lot of overlap in the Attributes between C.17.2.8 Referenced Request Macro [1] and 10.6 Request Attributes Macro [2] though, so in retrospect this distinction was probably not one of our best efforts. And one could argue that measurements during an SPS could have been handled with Request Attributes Sequence.

The text that describes the Attribute and its condition [3] is intended to cover both the radiologist report (completely?) and the technologist or machine generated work product (partially?), but in attempting to cover multiple scenarios turns out to be pretty nebulous.

The bottom line is pretty simple though - if procedures were requested, fill it in with as much as possible in every SR ("every SR(-like) object created during a scheduled imaging procedure ... even if they are vendor specific or not relevant to the RP or not for diagnostic use"), and that includes for RDSRs (worst case one can argue MBPO).

Not really sure how an SR in Study can be "not relevant to the RP".

David

1. https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.17.2.8.html
2. https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_10..6.html
3. https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.17.2.html#para_ea44dd7b-fa6d-4f86-9641-877813541a06

On Monday, July 24, 2023 at 6:30:10 AM UTC-4, Peter Chripunow wrote:
> Hi,
>
> I could need clarification on attribute (0040,A370) "Referenced Request SQ" in SR(-like) objects.
> I'm struggling with the right interpretation when it must be used.
>
> Unless I've missed the actual interpretation, I have arrived at two potential conclusions on how to use this attribute:
>
> A ) If a Requested Procedure demanded the creation of the SR(-like) object as a mandatory part of completing the RP then (0040,A370) shall be implemented.
> Requested either as a specific task, e.g. via a Unified Procedure Step.
> Or implicitly as an integral part of a procedure, but without which the RP would not be satisfied and thus could not be billed, otherwise.
> Hence, the SR could not be just an object on the sides, for convenience or as some added value.
>
> B ) Whichever RP the PPS of the SR(-like) object is assicated with shall be entered here. Equivalent to RP info in (0040,0275) "Request Attributes SQ" in images.
> Hence, every SR(-like) object created during a scheduled imaging procedure requires (0040,A370) to be filled, even if they are vendor specific or not relevant to the RP or not for diagnostic use.
>
> I do see pro and cons for either interpretation. So, I would appreciate some help with my struggle.
> I can even imagine that its purpose has changed over time. Or that some SR(-like) objects have become an integral part of a procedure (e.g. X-Ray Dose SR mandatory for X-Ray imaging procedures?).
>
> Thanks in advance,
> Peter

Hi David,

Thank you very much for your answer. I appreciate it.

What has added to my struggle is that the wording of the attribute's description is much different in the SR Document General Module from that in the Key Object Document Module.
And at the same time the description of (0040,0275) is just so much more simple.
So, for those differences in wording/phrasing/framing, I felt I have to assume that there must be some difference in the intended use.

The SR always is relevant to the performed procedure, of course. They connect by referencing the PPS Instance in (0008,1111) "Referenced Performed Procedure Step SQ".
However, this does not imply that the SR is relevant to the request for this procedure.

As I also have been reading through IHE in hope of getting a pointer to good practice, the IHE-RAD REM profile would only insist on (0008,1111), but not mention (0040,A370).
And there's no reference to integration critical attributes or to tables that apply to the IHE-RAD ED profile which does demand (0040,A370). Nor are there relevant Cross-Profile Considerations either.
This kind of suggested that the Dose SR may indeed be treated more loosely if the Evidence Document profile is not claimed in addition.

Anyhow, bottom line, as you've said, if there is information about the RP the PPS of an SR belongs to, then the attribute shall be implemented.
Even if it's just for safe measure.

Thank you & kind regards,
Peter

David Clunie schrieb am Dienstag, 19. September 2023 um 23:03:23 UTC+2:
> Hi Peter
>
> If I recall correctly, the intent was that when SR was a either report of a requested procedure, or some image-like artifact that was generated during a procedure like ultrasound measurements, then the information about the request is expected to be recorded here, regardless of whether it was associated with any particular Scheduled Procedure Step (unlike Request Attributes Sequence in images, which are to tied to a particular MWL SPS). The new Attribute and Macro were created in recognition that there might be no scheduled step for the report generation step itself, for example (as distinct from SPS for acquiring the images that were the subject of the report).
>
> In most real-world cases of the radiologist-generate report, "implicitly as an integral part of a procedure" as you suggested would apply.
>
> There is obviously a lot of overlap in the Attributes between C.17.2.8 Referenced Request Macro [1] and 10.6 Request Attributes Macro [2] though, so in retrospect this distinction was probably not one of our best efforts. And one could argue that measurements during an SPS could have been handled with Request Attributes Sequence.
>
> The text that describes the Attribute and its condition [3] is intended to cover both the radiologist report (completely?) and the technologist or machine generated work product (partially?), but in attempting to cover multiple scenarios turns out to be pretty nebulous.
>
> The bottom line is pretty simple though - if procedures were requested, fill it in with as much as possible in every SR ("every SR(-like) object created during a scheduled imaging procedure ... even if they are vendor specific or not relevant to the RP or not for diagnostic use"), and that includes for RDSRs (worst case one can argue MBPO).
>
> Not really sure how an SR in Study can be "not relevant to the RP".
>
> David
>
> 1. https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.17.2.8.html
> 2. https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_10.6.html
> 3. https://dicom.nema.org/medical/dicom/current/output/chtml/part03/sect_C.17.2.html#para_ea44dd7b-fa6d-4f86-9641-877813541a06