Bulk Merge Conflicts in Prearchive

[akluiber]

I have 150+ existing sessions in a project for which I need to pull down additional series using the DQR plugin. Subsequently, they all land as conflicts in the pre-archive. The "archive" action button does not merge these, but instead spits them back as conflicts again. Is there a way I can merge these into the existing sessions in one bulk action?

[Charlie Moore]

Hi there,

You could try setting the project's prearchive setting to the most aggressive merge/autoarchive option like this (in the Manage tab on the project page) and then repeating the "Archive" operation:

Definitely do it on a development server and make sure it does what you want first though.

Thanks,

Charlie Moore

[akluiber]

Unfortunately, that does not seem to work. Perhaps edits the settings, wipe out the pre-archive and re-pull the images?

[Charlie Moore]

Definitely worth a try; I would hope that would work here.

Thanks,

Charlie Moore

[akluiber]

Sadly, that still does not help. I assume I should not need to restart the tomcat service for changes to take effect? Running version 1.8.7.1, build: 30

If it helps, the specific error is: CONFLICT-5: Invalid modification of session UID via archive process.

[Charlie Moore]

Right, you shouldn't need to bounce tomcat. Is there UID remapping going on in anonymization somewhere? From taking a look at the code, that looks like it's going to happen when the StudyInstanceUID doesn't match between existing and incoming data. If that's true, it shouldn't merge data like that. Or is something causing the label to be different from your previous import such that it's trying to merge into the wrong session?

Thanks,

Charlie Moore

[akluiber]

The session label is the same, defined via the CSV I'm using with DQR.

I do alter the UIDs in the project's anonymization script (section below). This script has been unaltered since the original import, so I believe the UIDs should ultimately wind up with the same values as the already archived sessions. Should I temporarily set the UIDs at the site level anonymization script instead, or would that make a difference?

// Reassign UIDs
(0020,000D) := hashUID[(0020,000D)]     // Study Instance UID
(0020,000E) := hashUID[(0020,000E)]     // Series Instance UID
(0008,0018) := hashUID[(0008,0018)]     // SOP Instance UID
(0008,1155) := hashUID[(0008,1155)]     // Referenced SOP Instance UID
(0008,3010) := hashUID[(0008,3010)]    // Irradiation Event UID
(0020,0052) := hashUID[(0020,0052)]    // Frame of Reference UID

[Charlie Moore]

> I believe the UIDs should ultimately wind up with the same values as the already archived sessions.

This is true. Unfortunately, what's going on here is that project-level anonymization happens pretty "late" into the process. At this point in the code, it's seeing that the existing study instance UID for the session in the archive is hash(X) and the incoming data has UID X.

> Should I temporarily set the UIDs at the site level anonymization script instead, or would that make a difference?

If this is an option, it should indeed solve your problem. With site-level anonymization, the UID remapping happens earlier where the merge will no longer complain.

I tried out a DQR import/merge with your anon setup and can replicate the initial problem [and the problem going away when anon is moved to site-wide], but as always I'd recommend double checking on a dev server first rather than taking my word for it :).

Thanks,

Charlie Moore

[akluiber]

Yep, that does seem to work. Good enough for me. At least I don't have to manually merge 150 sessions then.

Appreciate the help figuring this out.