Hello,

I'm new to this community and to DICOM, and first of all I would like to thank you all for your great answers in here. It has been a great help for me.

My question: In the MWL query response specification, the attribute "scheduled procedure step sequence" in table Table K.6-1 in part 4 [1] has the remark: "The Scheduled Procedure Step Sequence shall contain only a single Item."

I'm confused by this, since I've read in many places that the relationship between Requested Procedures and Scheduled Procedure Steps is one-to-many.

The only way I could make sense of it so far would be that since this query is coming for a single modality, and the one-to-many would be serving the use case where a study is to be created by many modalities, that there would be a single SPS for each
modality, therefore a single element in there for each modality.

I have read somewhere else that there is the use case that a RP would have two SPS for the same modality, for example with different protocols. That would void my explanation.

Does anybody have some idea how to interpret that remark?

Thanks & best,
Alon

[1] http://dicom.nema.org/medical/dicom/current/output/chtml/part04/sect_K.6.html

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Alon,

it is true that there is a one-to-many relationship between RP and SPS. The SPS may span across different modalities, there may also be several SPS for the same modality in the scope of one RP (though I would expect this to be the less common case).
However, this does not require one worklist item (which corresponds 1:1 to an SPS) to have more than one SPS. There can be two SPS for the same RP and for the same modality resulting in two worklist entries. The advantage of this is that each SPS can be
separately identified (SPS ID) and performed (MPPS messages).

Note that for each SPS there is a 1:n relationship to the scheduled protocols. E.g. for 2 CT scans, one with and one without contrast agent, one would rather schedule one 1 SPS (e.g. "CT Abdomen") with 2 protocols ("With Contrast Agent", "Native"). For
scheduling a CT head and a CT abdomen for the same patient, one would probalby schedule two different SPS. DICOM does not specify however which granularity is applied for SPS and protocols. It is left to the user of the equipment to define an optimal way
of scheduling that fits best for supporting charge posting in the scheduling system and efficient protocol selection at the modality.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Alon,

it is true that there is a one-to-many relationship between RP and SPS. The RP may span across different modalities, but there may also be more than one SPS for the same modality in the scope of one RP (though I would expect this to be the less common
case). However, this does not require one worklist item (which corresponds 1:1 to an SPS) to have more than one SPS. There can be two SPS for the same RP and for the same modality resulting in two different worklist entries. The advantage of this is that
each SPS can be separately identified (SPS ID) and performed (MPPS messages).

Note that for each SPS there is a 1:n relationship to the scheduled protocols. E.g. for 2 CT scans, one with and one without contrast agent, one would rather schedule one 1 SPS (e.g. "CT Abdomen") with 2 protocols ("With Contrast Agent", "Native"). For
scheduling a CT head and a CT abdomen for the same patient, one would probalby schedule two different SPS. DICOM does not specify however which granularity is applied for SPS and protocols. It is left to the user of the equipment to define an optimal way
of scheduling that fits best for supporting charge posting in the scheduling system and efficient protocol selection at the modality

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Markus,

thank you very much for your quick and competent answer.It makes sense to me now.

Best regards,
Alon
On Thursday, July 15, 2021 at 8:05:07 AM UTC+2, marku...@gmail.com wrote:

Hi Alon,

it is true that there is a one-to-many relationship between RP and SPS. The RP may span across different modalities, but there may also be more than one SPS for the same modality in the scope of one RP (though I would expect this to be the less common

case). However, this does not require one worklist item (which corresponds 1:1 to an SPS) to have more than one SPS. There can be two SPS for the same RP and for the same modality resulting in two different worklist entries. The advantage of this is that
each SPS can be separately identified (SPS ID) and performed (MPPS messages).

Note that for each SPS there is a 1:n relationship to the scheduled protocols. E.g. for 2 CT scans, one with and one without contrast agent, one would rather schedule one 1 SPS (e.g. "CT Abdomen") with 2 protocols ("With Contrast Agent", "Native"). For

scheduling a CT head and a CT abdomen for the same patient, one would probalby schedule two different SPS. DICOM does not specify however which granularity is applied for SPS and protocols. It is left to the user of the equipment to define an optimal way
of scheduling that fits best for supporting charge posting in the scheduling system and efficient protocol selection at the modality
Hi M

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

I know this is an old post, but I have similar question. I've been developing using Orthanc and have an implementation where there is a single SPS per MWL. That seems to work OK with how things are configured, but we are using a single SPSS for say an
MRI Brain w/ and w/o contrast and for say an MRI Brain without contrast, just different titles, codes etc. From what you are saying, it sounds like it is possible to have 1 or more SPSS per MWL ? For example, sequence[0] could be the w/o study and
sequence[1] could be the w/ study, both within the same MWL file vs. having a single SPSS that is for both studies combined ? Having more than 1 SPSS per MWL would be a little bit more convenient for billing purposes and even when performing the study
since it separates out components of more complex studies for billing purposes and for the technician.

I've never actually tried doing that with Orthanc. Orthanc does not yet support MPPS, but that is a different topic.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)