Modify MWL response?

[dgerni]

We use dcm4chee-arc 5.10.2 in a production environment (regional vet clinic) with several modalities querying dcm4chee's worklist - most of them do successfully. One modality (CT) doesn't understand the answers received by the mwl, and the error messages are not helpful. I can monitor the DICOM traffic and analyze the transmitted data (attached).

The CT's conformance statement refers to the common Modality Worklist Information Model (1.2.840.10008.5.1.4.31) - as does the CS of dcm4chee-arc; and comparing with the received mwl response my only guess is that the tag (0008,0090) Referring Physician's Name is the problem: it is required, but not present in the response.

For testing purposes an alternative mwl server (commercial product) was introduced in the network: the CT accepts its responses - the element (0008,0090) is provided by this mwl server.

Is it possible to modify the structure of the mwl response (by configuration)? How can I add missing tags and see if that helps?

Why does the data structure provided by the mwl not correspond to the requested structure (e.g. patient data not wrapped in a sequence) - I thought that's the purpose of requesting it in the first step?

UPDATE:

I checked again and realised that both dicom attrs:

(0008,0090), Referring Physician Name

(0040,0006), Scheduled Performing Physician's Name

are provided by the alternative mwl (response accepted by the CT), but missing in the dcm4chee mwl response. So, it is not clear which of the two attributes - or both - are crucial.

I also checked the dcm4chee-arc configuration (using web UI), and found an MWL attribute filter (dcm4chee-arc > Archive Device > Child Objects: Attribute Filter) - but this does not seem to be related to C-FIND RSP...

UPDATE 2:

When I query the mwl with dcm4che tool findscu:

./findscu -c {mwl aet}@{host}:{port} -m 00100020={patient ID} -M MWL path_to/mwl_keys.dcm

and provide the returned dicom attrs in the C-FIND response by the file mwl_keys.dcm, or using the -r option, I observe: neither attr (0008,0090) nor (0040,0006) can be managed by this mechanism, while others like (0010,0030), or (0040,0100)/(0040,0001) and (0040,0100)/(0040,0003) can... .

For me, this looks like if the MWL SCP relies on an incomplete implementation of the Modality Worklist Information Model. And I would have expected that this is done by some configuration (i.e. the previously mentioned "MWL attribute filter"). Maybe this config is not accurate - maybe I should just upgrade to the current version?

Any advise?

[vrinda...@j4care.com]

Hello,

Both the attributes you mentioned are Type 2 attributes as per Modality Worklist Attributes table specified in : http://dicom.nema.org/medical/dicom/current/output/html/part04.html#sect_K.6.1.2.2

So if the modality worklist (when it was saved/sent) to the archive :

- did not contain these attributes, archive doesn't send it back in responses of QIDO query/C-Find.

- contained these attributes with empty values, and these attributes are requested in C-Find/QIDO, archive sends back the attribute with empty value.

Handling of attributes with empty values in response is specific to client.

The Attribute Filter list for MWL in Archive Device extension indicates which attributes will be saved in database attributes table when the MWL is saved/sent to the archive.