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