Hi, I have a Connector that is connecting with a Medical CT scanner. My Connector provides Modality Worklist (MWL) to this scanner. I am facing a problem which is raised by clients. When technicians have 3 different MWLs named MWL1, MWL2, MWL3. They chose to process MWL3 before MWL2 and sometimes, the Scanner send to our PACS 2 studies from 2 MWLs with the same Study Instance UID. According to what I'v known, I think that there might be some issues with this Scanner or my Connector. If someone faced this problems, please help me!

That's not a "problem" but actually what the Study-Level is supposed to be. If you look at this picture: https://dicom.nema.org/dicom/2013/output/chtml/part03/chapter_7.html, you see that a study can span across several procedure steps (which correspond to a worklist item) and which may even be created by different equipment (i.e. the same Study Instance UID is present in different worklist items for different devices).
The PACS should be able to handle this by means of the Series Instance UID which the devices are generating for each sequence of images.

Think that there is not enough information in the description to make this kind of statement, the fact that Dicom supports multiple series doesn't mean that this is correct behavior here.

Questions I have:
- Are these MWL responses returned in response to the MWL query related to each other?If so, can you describe the relationship?
- What are the differences in study and series level information attributes in the images sent by modality in response to the MWLs?

Regards, Jouke Numan

Op woensdag 30 maart 2022 om 08:20:23 UTC+2 schreef marku...@gmail.com:
> That's not a "problem" but actually what the Study-Level is supposed to be. If you look at this picture: https://dicom.nema.org/dicom/2013/output/chtml/part03/chapter_7.html, you see that a study can span across several procedure steps (which correspond to a worklist item) and which may even be created by different equipment (i.e. the same Study Instance UID is present in different worklist items for different devices).
> The PACS should be able to handle this by means of the Series Instance UID which the devices are generating for each sequence of images.

To @Jouke Numan
- These two studies have no relationships with the other one. Both of them are returned in one request from Scanner. The only common thing I can point in here is they come from the same Worklist Server.
- Actually I don't understand your question, I mean the Study Instance UID and Series Instance UID are different all the time, right.

To @marku...@gmail.com
I mean the series are separated from 2 patients, the only common thing is the Study Instance UID

truong...@gmail.com schrieb am Freitag, 1. April 2022 um 09:10:18 UTC+2:
> I mean the series are separated from 2 patients, the only common thing is the Study Instance UID

Are you saying that the same Study Instance UID is used for 2 MWL records for 2 different patients? That is certainly a mistake.

El viernes, 1 de abril de 2022 a las 9:15:39 UTC+2, marku...@gmail.com escribió:
> truong...@gmail.com schrieb am Freitag, 1. April 2022 um 09:10:18 UTC+2:
> > I mean the series are separated from 2 patients, the only common thing is the Study Instance UID
> Are you saying that the same Study Instance UID is used for 2 MWL records for 2 different patients? That is certainly a mistake.
Agree with Mark, there seems to be some problem with the generation of those Study Instance UID, if those studies have nothing to do with each other (and even more being from different patients), they should not have the same Study Instance UID.
Who is generating those Study Instance UID? the MWL system, the Connector or the machine itself?

Vào lúc 14:26:41 UTC+7 ngày Thứ Sáu, 1 tháng 4, 2022, Jose Maria Veneroso Benitez đã viết:
> El viernes, 1 de abril de 2022 a las 9:15:39 UTC+2, marku...@gmail.com escribió:
> > truong...@gmail.com schrieb am Freitag, 1. April 2022 um 09:10:18 UTC+2:
> > > I mean the series are separated from 2 patients, the only common thing is the Study Instance UID
> > Are you saying that the same Study Instance UID is used for 2 MWL records for 2 different patients? That is certainly a mistake.
> Agree with Mark, there seems to be some problem with the generation of those Study Instance UID, if those studies have nothing to do with each other (and even more being from different patients), they should not have the same Study Instance UID.
> Who is generating those Study Instance UID? the MWL system, the Connector or the machine itself?
The Study Instance UID is generated from the Scanner itself, so I can say that the problem is the machine?

In case of MWL isn't it mandatory that the MWL SCP always provides a valid value for Study Instance UID to the modality (the Scanner in this case), since this attribute is of return key type 1?
So I would assume that the scanner should have to carry over the provided UID.

Otherwise it could hint in the direction that the Scanner does not correctly generate new Study Instance UIDs, does it's Conformance Statement present any information how & when it handles the generation of UIDs locally?

Maybe to elborate a bit more on the 'valid' description:
Since you pointed out that the MWL entries related to the problem came from the same MWL SCP and are for different patients, their Study Instance UID must have been different. Otherwise their could have been a problem at the side that generated the MWL entries (as both Markus and Jose also pointed out).

Just out of cuiosity:
Was there any correction/change of key demographics (Patient name, patient ID) at the Scanner involved?

madMorty schrieb am Freitag, 1. April 2022 um 11:03:31 UTC+2:
> In case of MWL isn't it mandatory that the MWL SCP always provides a valid value for Study Instance UID to the modality (the Scanner in this case), since this attribute is of return key type 1?
> So I would assume that the scanner should have to carry over the provided UID.
>
> Otherwise it could hint in the direction that the Scanner does not correctly generate new Study Instance UIDs, does it's Conformance Statement present any information how & when it handles the generation of UIDs locally?

truong...@gmail.com schrieb am Freitag, 1. April 2022 um 09:37:48 UTC+2:
> The Study Instance UID is generated from the Scanner itself, so I can say that the problem is the machine?

And as far as I understand the situation now, I would say that there are event 2 problems on the machine:
1) As MadMorty pointed out, the scanner should transfer the Study Instance UID from the worklist item to the images. Though this is not explicitly required for claiming DICOM conformance, it is common practice and explicitly required by IHE.
2) It seems that the *Unique* identifiers generated for the studies on the scanner are actually not unique if the same UID is generated for two different patients.

Op vrijdag 1 april 2022 om 12:14:19 UTC+2 schreef marku...@gmail.com:
> truong...@gmail.com schrieb am Freitag, 1. April 2022 um 09:37:48 UTC+2:
> > The Study Instance UID is generated from the Scanner itself, so I can say that the problem is the machine?
> And as far as I understand the situation now, I would say that there are event 2 problems on the machine:
> 1) As MadMorty pointed out, the scanner should transfer the Study Instance UID from the worklist item to the images. Though this is not explicitly required for claiming DICOM conformance, it is common practice and explicitly required by IHE.
> 2) It seems that the *Unique* identifiers generated for the studies on the scanner are actually not unique if the same UID is generated for two different patients.

Hi Truong,

I see a number of assumptions on what is happening and then conclusions are based on those assumptions. Also, I have trouble understanding your answers to my questions (which could may be also better phrased, sorry on that!).

Can you provide (anonymized!) content of the three MWL responses and the study/series level attributes created/mapped from those MWL responses?

This would help greatly to understand what is happening and hopefully allow us to answer the questions you have.

I agree with Markus that if different patients, the study instance uid should never be same, similar holds for accession number as it is linked to a single patient. For any series sent in with same Study Uid, the Patient and Study level attributes should have same values. Obviously, if you provide the StudyInstanceUid in your MWL responses, these should be different as well!

What is the "one request from Scanner" in "These two studies have no relationships with the other one. Both of them are returned in one request from Scanner"?

Regards, Jouke

Vào lúc 18:51:04 UTC+7 ngày Thứ Sáu, 1 tháng 4, 2022, Jouke Numan đã viết:
> Op vrijdag 1 april 2022 om 12:14:19 UTC+2 schreef marku...@gmail.com:
> > truong...@gmail.com schrieb am Freitag, 1. April 2022 um 09:37:48 UTC+2:
> > > The Study Instance UID is generated from the Scanner itself, so I can say that the problem is the machine?
> > And as far as I understand the situation now, I would say that there are event 2 problems on the machine:
> > 1) As MadMorty pointed out, the scanner should transfer the Study Instance UID from the worklist item to the images. Though this is not explicitly required for claiming DICOM conformance, it is common practice and explicitly required by IHE.
> > 2) It seems that the *Unique* identifiers generated for the studies on the scanner are actually not unique if the same UID is generated for two different patients.
> Hi Truong,
>
> I see a number of assumptions on what is happening and then conclusions are based on those assumptions. Also, I have trouble understanding your answers to my questions (which could may be also better phrased, sorry on that!).
>
> Can you provide (anonymized!) content of the three MWL responses and the study/series level attributes created/mapped from those MWL responses?
>
> This would help greatly to understand what is happening and hopefully allow us to answer the questions you have.
>
> I agree with Markus that if different patients, the study instance uid should never be same, similar holds for accession number as it is linked to a single patient. For any series sent in with same Study Uid, the Patient and Study level attributes should have same values. Obviously, if you provide the StudyInstanceUid in your MWL responses, these should be different as well!
>
> What is the "one request from Scanner" in "These two studies have no relationships with the other one. Both of them are returned in one request from Scanner"?
>
> Regards, Jouke

Sorry for late reply.

About the MWL, Can I send you later and in text format, because the Scanner receive them in the DICOM format.
About the `What is the "one request from Scanner" in "These two studies have no relationships with the other one. Both of them are returned in one request from Scanner"?`, so sorry if it makes you confused. What I mean in my case is:
- There are 3 different MWL named MWL1, MWL2, MWL3 in that order.
- If the technologist choose the MWL3 then MWL2 to process, the Study2 from MWL2 and Study3 from MWL3 have the same StudyInstanceUID. But this case showed randomly.
- Sometimes, the duplicated case happens when MWLs come from different patients: name, id...
- We just provide: Patient's Information like name, address, age; Requested procedure. The StudyInstanceUID is generated from the Scanner.

We think the problem is the Scanner but the Clinic this issue is ours, so tired...

Op dinsdag 12 april 2022 om 05:35:16 UTC+2 schreef truong...@gmail.com:
> Vào lúc 18:51:04 UTC+7 ngày Thứ Sáu, 1 tháng 4, 2022, Jouke Numan đã viết:
> > Op vrijdag 1 april 2022 om 12:14:19 UTC+2 schreef marku...@gmail.com:
> > > truong...@gmail.com schrieb am Freitag, 1. April 2022 um 09:37:48 UTC+2:
> > > > The Study Instance UID is generated from the Scanner itself, so I can say that the problem is the machine?
> > > And as far as I understand the situation now, I would say that there are event 2 problems on the machine:
> > > 1) As MadMorty pointed out, the scanner should transfer the Study Instance UID from the worklist item to the images. Though this is not explicitly required for claiming DICOM conformance, it is common practice and explicitly required by IHE.
> > > 2) It seems that the *Unique* identifiers generated for the studies on the scanner are actually not unique if the same UID is generated for two different patients.
> > Hi Truong,
> >
> > I see a number of assumptions on what is happening and then conclusions are based on those assumptions. Also, I have trouble understanding your answers to my questions (which could may be also better phrased, sorry on that!).
> >
> > Can you provide (anonymized!) content of the three MWL responses and the study/series level attributes created/mapped from those MWL responses?
> >
> > This would help greatly to understand what is happening and hopefully allow us to answer the questions you have.
> >
> > I agree with Markus that if different patients, the study instance uid should never be same, similar holds for accession number as it is linked to a single patient. For any series sent in with same Study Uid, the Patient and Study level attributes should have same values. Obviously, if you provide the StudyInstanceUid in your MWL responses, these should be different as well!
> >
> > What is the "one request from Scanner" in "These two studies have no relationships with the other one. Both of them are returned in one request from Scanner"?
> >
> > Regards, Jouke
> Sorry for late reply.
>
> About the MWL, Can I send you later and in text format, because the Scanner receive them in the DICOM format.
> About the `What is the "one request from Scanner" in "These two studies have no relationships with the other one. Both of them are returned in one request from Scanner"?`, so sorry if it makes you confused. What I mean in my case is:
> - There are 3 different MWL named MWL1, MWL2, MWL3 in that order.
> - If the technologist choose the MWL3 then MWL2 to process, the Study2 from MWL2 and Study3 from MWL3 have the same StudyInstanceUID. But this case showed randomly.
> - Sometimes, the duplicated case happens when MWLs come from different patients: name, id...
> - We just provide: Patient's Information like name, address, age; Requested procedure. The StudyInstanceUID is generated from the Scanner.
>
> We think the problem is the Scanner but the Clinic this issue is ours, so tired...

Hi Truong,

I'm no MWL expert, but if I read the Table in PS 3.4 on MWL Attributes and the sections K.2.2.1.1.2 correctly, the SCP must (Return Key Type equals 1) return a
valid Study Instance UID if the Modality has put an empty (0020,000D) attribute in the request:

K.2.2.1.1.2 Optional Matching Key Attributes
In the Worklist Information Model, a set of Attributes may be defined as Optional Matching Key Attributes. Optional Matching Key Attributes contained in the Identifier of a C-FIND request may induce two different types of behavior depending on support for matching by the SCP. If the SCP

- does not support matching on the Optional Matching Key Attribute, then the Optional Matching Key Attribute shall be ignored for matching but shall be processed in the same manner as a Return Key Attribute.

So question is if modality is requesting for the StudyInstanceUID and what is your MWL server returning?

Regards, Jouke

Le mercredi 13 avril 2022 à 10:36:27 UTC+2, Jouke Numan a écrit :
> Op dinsdag 12 april 2022 om 05:35:16 UTC+2 schreef truong...@gmail.com:
> > Vào lúc 18:51:04 UTC+7 ngày Thứ Sáu, 1 tháng 4, 2022, Jouke Numan đã viết:
> > > Op vrijdag 1 april 2022 om 12:14:19 UTC+2 schreef marku...@gmail.com:
> > > > truong...@gmail.com schrieb am Freitag, 1. April 2022 um 09:37:48 UTC+2:
> > > > > The Study Instance UID is generated from the Scanner itself, so I can say that the problem is the machine?
> > > > And as far as I understand the situation now, I would say that there are event 2 problems on the machine:
> > > > 1) As MadMorty pointed out, the scanner should transfer the Study Instance UID from the worklist item to the images. Though this is not explicitly required for claiming DICOM conformance, it is common practice and explicitly required by IHE.
> > > > 2) It seems that the *Unique* identifiers generated for the studies on the scanner are actually not unique if the same UID is generated for two different patients.
> > > Hi Truong,
> > >
> > > I see a number of assumptions on what is happening and then conclusions are based on those assumptions. Also, I have trouble understanding your answers to my questions (which could may be also better phrased, sorry on that!).
> > >
> > > Can you provide (anonymized!) content of the three MWL responses and the study/series level attributes created/mapped from those MWL responses?
> > >
> > > This would help greatly to understand what is happening and hopefully allow us to answer the questions you have.
> > >
> > > I agree with Markus that if different patients, the study instance uid should never be same, similar holds for accession number as it is linked to a single patient. For any series sent in with same Study Uid, the Patient and Study level attributes should have same values. Obviously, if you provide the StudyInstanceUid in your MWL responses, these should be different as well!
> > >
> > > What is the "one request from Scanner" in "These two studies have no relationships with the other one. Both of them are returned in one request from Scanner"?
> > >
> > > Regards, Jouke
> > Sorry for late reply.
> >
> > About the MWL, Can I send you later and in text format, because the Scanner receive them in the DICOM format.
> > About the `What is the "one request from Scanner" in "These two studies have no relationships with the other one. Both of them are returned in one request from Scanner"?`, so sorry if it makes you confused. What I mean in my case is:
> > - There are 3 different MWL named MWL1, MWL2, MWL3 in that order.
> > - If the technologist choose the MWL3 then MWL2 to process, the Study2 from MWL2 and Study3 from MWL3 have the same StudyInstanceUID. But this case showed randomly.
> > - Sometimes, the duplicated case happens when MWLs come from different patients: name, id...
> > - We just provide: Patient's Information like name, address, age; Requested procedure. The StudyInstanceUID is generated from the Scanner.
> >
> > We think the problem is the Scanner but the Clinic this issue is ours, so tired...
> Hi Truong,
>
> I'm no MWL expert, but if I read the Table in PS 3.4 on MWL Attributes and the sections K.2.2.1.1.2 correctly, the SCP must (Return Key Type equals 1) return a
> valid Study Instance UID if the Modality has put an empty (0020,000D) attribute in the request:
>
> K.2.2.1.1.2 Optional Matching Key Attributes
> In the Worklist Information Model, a set of Attributes may be defined as Optional Matching Key Attributes. Optional Matching Key Attributes contained in the Identifier of a C-FIND request may induce two different types of behavior depending on support for matching by the SCP. If the SCP
>
> - does not support matching on the Optional Matching Key Attribute, then the Optional Matching Key Attribute shall be ignored for matching but shall be processed in the same manner as a Return Key Attribute.
>
> So question is if modality is requesting for the StudyInstanceUID and what is your MWL server returning?
>
> Regards, Jouke
Dear all,
you have probably noticed the massive spam on this group. It makes it impossible to actually use it, and there doesn't seem to be an easy fix.
I have thus created a new group available here: https://groups.google.com/g/it-protocols-dicom
but new users must be granted access. If, like me, you think the DICOM Google group has been and still is useful, don't hesitate to join.
I'm updating a bunch of threads with this same message in the hopes you'll receive the update by email. Apologies if you receive this multiple times.
Cheers
Thomas