Missing StudyInstanceUID in DCM file metadata results in 409 about dicom-server

[StevenBorg]

Thank you, @brunoterkaly ! I'm looking through the return responses, and trying to determine one that telegraphs a "Your DICOM file didn't pass validation". We've settled on Conflict, but that's not necessarily a good one. A client could assume a file has already been uploaded (Conflict), but in actuality, it's a malformed / non-complaint DICOM file, and is just being rejected.

The following workflow would be necessarily to handle the returned value.

1. Client uploads a file and gets a 409
2. Client must retrieve the metadata for that a matching file (or query and check results) to ensure that the file actually is on the server.
3. Client uses result of get to determine if they need to fix and re-upload (for bad file), delete and re-upload (to update file), or skip further processing (to leave existing file).

That's not ideal. It would be better to have an explicit return code, or barring that, a reason for the return code.

[StevenBorg]

OK. Upon additional research we do return an additional error which provides specific context as to the upload error. Here's the code file, which maps the numeric error codes to strings. https://github.com/microsoft/dicom-server/blob/b3b7336eb35eaf69b99fc3cd4c00223c0f688c74/src/Microsoft.Health.Dicom.Core/Features/Store/FailureReasonCodes.cs

It can also be found in the conformance document here: https://github.com/microsoft/dicom-server/blob/master/docs/resources/conformance-statement.md#store-failure-reason-codes

@brunoterkaly, can you see if you're getting the error codes returned when you get a 409 for DICOM files without StudyInstanceUID? You should be seeing a 43264 error returned for a DICOM file which will fail validation.

If you're getting that code returned, I'm hoping that will resolve your issue cleanly. Here are the codes (from the conformance link above) which highlight what errors we discover:

Code	Description
272	The store transaction did not store the instance because of a general failure in processing the operation.
43264	The DICOM instance failed the validation.
43265	The provided instance StudyInstanceUID did not match the specified StudyInstanceUID in the store request.
45070	A DICOM instance with the same StudyInstanceUID, SeriesInstanceUID and SopInstanceUID has already been stored. If you wish to update the contents, delete this instance first.
45071	A DICOM instance is being created by another process, or the previous attempt to create has failed and the cleanup process has not had chance to clean up yet. Please delete the instance first before attempting to create again.

[jackliums]

This behavior is actually defined by the DICOMWeb spec: http://dicom.nema.org/medical/dicom/current/output/html/part18.html#sect_10.5.3

If the request itself is malformed, the server should return 400. If the request is formed correctly but the server cannot store the instance for any reasons, then 409 is returned with the response body containing data structure describing the error: http://dicom.nema.org/medical/dicom/current/output/html/part18.html#chapter_I

[StevenBorg]

After speaking with @brunoterkaly I'm planning on closing this issue. As @jackliums mentioned, we're likely aligned with the DICOM standard. But more importantly, we are providing a response error code that @brunoterkaly was able to use to determine why the request failed, eliminating the need for the additional server call noted above.