FAIL-19 Invalid modification of session modality via archive process. Data may require a manual merge.

[dev]

Hi,

I run xnat 1.7.5.6.

An existing MR project (prj1) contains a subject (sub1), a session (sess1), and a scan (scan1).

While importing an other dicom (in prj1, sub1, sess1, scan2) with a different modality PET in xnat with 'review and archive' button from prearchive, this message is displayed :

FAIL-19 Invalid modification of session modality via archive process. Data may require a manual merge.

It can be forced by changing the session name (sess2 instead of sess1), but it creates a velocity bug with the name of sessions in the subject list (sub1). See screenshoot.

What is the best practice for this ?

Is it possible to ignore this error, and to force the 2nd scan (scan2) to go in the first session (sess1) ?

velocity.log :

2021-06-21 17:56:07,304 [http-apr-8080-exec-7] ERROR velocity - Left side ($create_projects.size()) of '>' operation has null value at /screens/xnat_subjectAssessorData/sharing.vm[line 14, column 29]

[Moore, Charlie]

Hello there,

Disclaimer: I'm assuming that scan1 and scan2 have the same value for (0020,000D) Study Instance UID. If that's not true, this is a route you probably don't want to go down.

This is what you could classify as a "cross modality merge". Your project already contains an xnat:mrSessionData object in the archive. When uploading the second scan to the prearchive, XNAT only sees PT modality DICOM, so it creates an xnat:petSessionData object. The problem comes in when XNAT tries to merge them because their types don't match. There are various reasons why XNAT doesn't want to let you do this:

1. The fields extracted at the study [session] level won't be consistent between the two data types.
2. XNAT has a defined hierarchy of modalities when assigning an overall session "modality" (yes, this is not a real concept in DICOM). For example, a session with both PT and CT data always gets classified as a "PET Session". If XNAT allowed this type of merge, the data type of the session would just be whatever got archived first. Some people depend on the strict hierarchy, and this would become unreliable.
3. In the same spirit as the above one, some pipelines/containers are only designed to launch on certain session types.

If the above issues don't bother you, there's a solution in 1.8.X. There's a new configurable setting that lets you specify whether you want to permit this type of merge.

As for the velocity bug, unfortunately I have no idea on that.

Thanks,

Charlie

---

From: xnat_di...@googlegroups.com <xnat_di...@googlegroups.com> on behalf of dev <icm.inst...@gmail.com>
Sent: Monday, June 21, 2021 10:59 AM
To: xnat_discussion <xnat_di...@googlegroups.com>
Subject: [XNAT Discussion] FAIL-19 Invalid modification of session modality via archive process. Data may require a manual merge.

 

* External Email - Caution *

--
You received this message because you are subscribed to the Google Groups "xnat_discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to xnat_discussi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/xnat_discussion/aa5a63f8-e7ba-4bee-9bed-8fe22c89585en%40googlegroups.com.

 

---

The materials in this message are private and may contain Protected Healthcare Information or other information of a sensitive nature. If you are not the intended recipient, be advised that any unauthorized use, disclosure, copying or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this email in error, please immediately notify the sender via telephone or return mail.

[dev]

Thanks Charlie,

This is exactly the case : scan1 and scan2 have the same value for (0020,000D) Study Instance UID, it is a "cross modality merge".

I'll make some tests in 1.8.X and then see if we force it.