Getting Error: 409 conflict on uploading a DICOM image

[Mamta92]

I'm trying to upload an image at www.yourdomain.com/dcm4chee-arc/ui2/study/study but getting 409 conflict on uploading an DICOM image. We've installed the docker composer which has lapd, psql, arc images. Everything is running properly and all necessary tables and sequences are also created.

Can anybody tell what is the issue?

The main goal is to be able to integrate the DCM4CHEE with an open source medical imaging viewer. Any help appreciated. Thanks

[jbocce]

@Mamta92 if this is concerning OHIF, then there may be an issue and associated PR that might help you here

[vrindanayak]

I'm trying to upload an image at www.yourdomain.com/dcm4chee-arc/ui2/study/study but getting 409 conflict on uploading an DICOM image. We've installed the docker composer which has lapd, psql, arc images. Everything is running properly and all necessary tables and sequences are also created.

Can anybody tell what is the issue?

What do you see in the server.log?

[wayfarer3130]

I'm not seeing anything at all in the server log, it just seems to silently reply with conflict. It depends on exactly how I send the study - sometimes it works, and sometimes it fails with nothing that I can tell between them to be different.

[wayfarer3130]

It is data from OHIF, but the data contains the Patient Name, which was causing the earlier issue which Joe reported.

[vrindanayak]

I'm not seeing anything at all in the server log

Do you see something at least then in Browser Inspect - Network tab - Response section on receiving 409 - Conflict?

[wayfarer3130]

It has an empty Retrieve AE URL - don't have it running exactly right now.
I did find out the issue - it is the Study Time formatting - in the version failing to be received it has 3 extra 0 padding digits, to pad out to microseconds.

[wayfarer3130]

I tried adding various coercion attributes and setting info level logging, but it still seems to just reply quietly without any information on what has gone wrong.

[vrindanayak]

Using the sample SR object from OHIF/Viewers#3648 (comment) didn't throw any errors when I uploaded it to my local archive. So I couldn't reproduce the issue as mentioned in OHIF/Viewers#3648 (comment). The object does get uploaded and stored to archive, although with incorrectly formatted name, but the archive didn't throw 409 - Conflict or 500 - Internal Server Error

As a second test, I also cleaned up the DB and created a study / patient matching the patient identifier in the sample SR and then uploaded this SR as a second study without any issues.

409 - Conflict was reproducible only when I already have a study stored to archive with a different Study Instance UID than the one present in the sample SR which is uploaded as a second series to the same study.

15:23:18,692 INFO  [org.dcm4chee.arc.stow.StowRS] (default task-6) Process POST /dcm4chee-arc/aets/DCM4CHEE/rs/studies/1.2.840.113674.514.212.200?irwf=UNSCHEDULED&00100020=TCGA-50-5072 from null@127.0.0.1:36584
15:23:18,693 INFO  [org.dcm4chee.arc.stow.StowRS] (default task-6) storeInstances: Extract Part #1{content-location=[file/SR000000.dcm], content-type=[application/dicom]}
15:23:18,695 INFO  [org.dcm4chee.arc.store.impl.StoreServiceImpl] (default task-6) 127.0.0.1@127.0.0.1->DCM4CHEE: Received Instance[studyUID=1.3.6.1.4.1.14519.5.2.1.6450.9002.339372202011004731829363267423,seriesUID=2.25.383696878853813963374437833214855470894,objectUID=2.25.397495553495691623566912242597685830238] does not match requested studyUID=1.2.840.113674.514.212.200
15:23:18,696 INFO  [org.dcm4chee.arc.stow.StowRS] (default task-6) 127.0.0.1@127.0.0.1->DCM4CHEE: Failed to store Enhanced SR Storage: org.dcm4che3.net.service.DicomServiceException
        at deployment.dcm4chee-arc-ear-5.33.1-psql.ear.dcm4chee-arc-store-5.33.1.jar//org.dcm4chee.arc.store.impl.StoreServiceImpl.store(StoreServiceImpl.java:218)
        at deployment.dcm4chee-arc-ear-5.33.1-psql.ear.dcm4chee-arc-store-5.33.1.jar//org.dcm4chee.arc.store.impl.StoreServiceImpl$Proxy$_$$_WeldClientProxy.store(Unknown Source)
        at deployment.dcm4chee-arc-ear-5.33.1-psql.ear.dcm4chee-arc-war-5.33.1-unsecure.war//org.dcm4chee.arc.stow.StowRS.storeDicomObject(StowRS.java:576)
        at deployment.dcm4chee-arc-ear-5.33.1-psql.ear.dcm4chee-arc-war-5.33.1-unsecure.war//org.dcm4chee.arc.stow.StowRS$Input$1.readBodyPart(StowRS.java:540)
        at deployment.dcm4chee-arc-ear-5.33.1-psql.ear.dcm4chee-arc-war-5.33.1-unsecure.war//org.dcm4chee.arc.stow.StowRS.lambda$store$1(StowRS.java:345)
        at org.dcm4che.mime@5.33.0//org.dcm4che3.mime.MultipartParser.parse(MultipartParser.java:76)
        at deployment.dcm4chee-arc-ear-5.33.1-psql.ear.dcm4chee-arc-war-5.33.1-unsecure.war//org.dcm4chee.arc.stow.StowRS.store(StowRS.java:338)
        at deployment.dcm4chee-arc-ear-5.33.1-psql.ear.dcm4chee-arc-war-5.33.1-unsecure.war//org.dcm4chee.arc.stow.StowRS.storeInstancesJSON(StowRS.java:280)
        at deployment.dcm4chee-arc-ear-5.33.1-psql.ear.dcm4chee-arc-war-5.33.1-unsecure.war//org.dcm4chee.arc.stow.StowRS$Proxy$_$$_WeldClientProxy.storeInstancesJSON(Unknown Source)

On 409 - Conflict, you would see a decimal value for the Failure Reason (0008,1197) in the Failed SOP Sequence (0008,1198). Converting it to hex and checking in Storage Application C-STORE Response Status Return Reasons should give you some clues