The new WEASIS is not grouping studies from the same Patient

[Jon Ander Zuccaro]

Hi, this problem was not present before 3.7.1

I launch the first study like this:

weasis://$dicom:close --all $dicom:get -w "link to custom manifest"

The manifest looks like this:

<?xml version="1.0" encoding="ISO-8859-1" ?>
<manifest xmlns="http://www.weasis.org/xsd/2.5" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<arcQuery additionnalParameters="" arcId="1633801760560" baseUrl="https://my-serverxxx" requireOnlySOPInstanceUID="false">
<Patient PatientID="3434343434" PatientName="Hilary Williams" PatientBirthDate="19810424" >
<Study StudyInstanceUID="1.2.826.0.1.3680043.9.67.1628690511213.5xxxx" StudyDescription="TORAX AP" StudyDate="20210811" StudyTime="093142" >

....

I know something is weird right away because the patient is listed twice on the DICOM explorer.

I then launch a second study from the same patient... same principle I simply don't issue the close command:

weasis://$dicom:get -w "https://my-server...

The second manifest is identical in terms of the patient information, id, birth date... everything matches and the images from the second study are loaded but I can't see them right away, I actually have to select the second patient from the DICOM explorer, by doing this I am able to see both studies.

What's even weirder is that when I launch a study from a separate patient using the close command the new patient is listed twice and then an entry from the previous patient also remains there so I now have 3 patient entries. The previous patient is empty though, if I click it I get no studies.

This used to work, unless I have to alter the manifest files for this new version.

Apparently all patients are duplicated you just don't notice the issue unless you try to launch a second study from the same patient.

This was tested on a brand new Windows 10 install and installing WEASIS from scratch.

Thank You

[Nicolas Roduit]

Yes, there have been changes to better handle the situation when there are inconsistencies between the manifest and the file metadata.

The patient is built first by the manifest and then reconsolidated by the files. By default it is the PatientID + issuerOfPatientID + PatientName that constitutes the uniqueness of the patient. If these fields vary between 2 studies, it is normal that it has 2 items for patient. Try to check those dicom attribures.

[Jon Ander Zuccaro]

Hi, thanks for the answer.

My problem was that I was no writing the patient name to the manifest using the PN DICOM format, apparently,  the name form the manifest has to match the DICOM Tag exactly now.

I also noticed that, if the patient has as an Issuer of Patient ID value we need to add that now to the manifest using the IssuerOfPatientID attribute.

I am struggling to understand the purpose of this... if WEASIS is going to merge patients using the DICOM tags anyway, what's the point of adding this redundant information to the manifest? If I download both studies to disk and open them by double clicking them I don't get  any duplicates and WEASIS handles the merge of patients with and without Patient ID issuers flawlessly.

I also noticed that patientComparator.buildPatientPseudoUID property from the code you linked, is this some kind of undocumented feature? I created my own comparator by adding that that to the ext-config.properties file and solved my problem.

It would actually be great if we could instruct WEASIS what comparator strategy to use from the manifest file.

As a side note, I understand that this is probably an artifact that remains from a mismatched manifest and DICOM values but the fact that an entry for the previous patient remains on the patient list when I open a second study  is weird.

Thanks!

[Nicolas Roduit]

See my comments below.

Le Monday, October 11, 2021 à 4:31:27 PM UTC+2, jonzu...@gmail.com a écrit :

Hi, thanks for the answer.

My problem was that I was no writing the patient name to the manifest using the PN DICOM format, apparently,  the name form the manifest has to match the DICOM Tag exactly now.

Yes, at least for parameters required for the identification of Patient/Study/Series/Instance. However, Weasis should support most of the inconsistencies but can lead to having several items (or empty items).

I also noticed that, if the patient has as an Issuer of Patient ID value we need to add that now to the manifest using the IssuerOfPatientID attribute.

 

Yes, it is not a mandatory field but can be used by default for building a patient item. I will change that in the next major release.

I am struggling to understand the purpose of this... if WEASIS is going to merge patients using the DICOM tags anyway, what's the point of adding this redundant information to the manifest? If I download both studies to disk and open them by double clicking them I don't get  any duplicates and WEASIS handles the merge of patients with and without Patient ID issuers flawlessly.

Because this information allows to build the whole structure in the explorer (display description information, sort by date, series number, instance number ...) before the images are downoaded. This allows to change the priority of the downloads at any time. There is also a mode in Weasis where by default images are not downloaded automatically, the user can choose which series to download. 

I also noticed that patientComparator.buildPatientPseudoUID property from the code you linked, is this some kind of undocumented feature? I created my own comparator by adding that that to the ext-config.properties file and solved my problem.

 

Yes, it is a bit deliberate because the default mode follows the recommendation of the standard (IHE BIR) and changing it can have impacts in the grouping of a patient's exams.

It would actually be great if we could instruct WEASIS what comparator strategy to use from the manifest file.

You can add the patientComparator.buildPatientPseudoUID property but it is not recommended. Providing similar values in the manifest is the best option.

As a side note, I understand that this is probably an artifact that remains from a mismatched manifest and DICOM values but the fact that an entry for the previous patient remains on the patient list when I open a second study  is weird.

Yes, downloading and loading are asynchronous and concurrent processes, so changing the unique identifier during this process can have consequences.