DICOM unsupported attributes

Question

I just got in charge for development of a Dicom system that got a few years on its neck (Developed in 2009). And a user now wants to use an attribute (Dicom-tag) that has never been used within the system before: "(0010,0021) IssuerOfPatientID".

Our system is only responsibly for transporting patient data from HIS/RIS to the modality.

The modality sends a C-Find RQ to the SCP with this specific attribute, among others ofcourse. The SCP respond to the C-find RQ with a C-Find RSP, it includes all attributes from the RQ except the (0010, 0021). The other attributes gets a value or if no information is found they appears as "", as intended. The (0010,0021) is completely removed from the SCP response.

The above has been confirmed by Wireshark-logs. The attribute is requested with a zero-length attribute which should match anything.

As I´m unable to access these servers in anyway, I cannot confirm anything with my own eyes. But they assure me that the value for (0010,0021) is being sent from their HIS/RIS to the Worklist Collector and is saved in the Worklist database. As of this, I´m also unable the view the systems logs.

So I started to read about unsupported attributes. It appears that the attribute is optional and/or is not supported by the system somehow. The manufacturer told our common client that they could use this attribute without any problems, but well.. It´s not working.

As a developer is there anything I can do about this to make the attribute supported? Or is this controlled by the device Conformance Statement?

I´m sure you have noticed, I´m a novice with both Dicom and our system.

Thanks in advance!

[EDIT] The attribute is requested as optional as far as i know. It should not be a required, but we still want it to appear in the RSP either with a value or a as "". How can i do that?

[EDIT FOLLOWUP] This problem is resolved. The actual problem was that the Worklist Collector did not add the attribute due it was missing in the "Taglist" (Tag class). When added the attribute to the taglist, and also added support for the tag in the Worklist collector, it do now work.

This could have been solved alot easier with just one query in the database, but as i earlier said, i had no access to the database, and my client had a hard time getting the IT-team to look this up.

Answer 1

If you don’t have access to SCP code to make the necessary changes, you can create a proxy SCP that will forward the query request from Modality to the Work-List SCP and will insert the Issuer of Patient ID (0010, 0021) tag with no value to the matching query response (where status is pending) before sending it to the Modality.

However, it is strange that Modality is requiring you to return an optional key. DICOM standard is very clear about this. Please refer to PS3.4 section C.2.2.1.3 of the DICOM standard “(SCP) does not support the existence of the Optional Key, then the Attribute shall not be returned in C-FIND responses”