MWL - Return Key Attributes of Type 1

[madMorty]

Hi,

at the moment I am currently workling on an MWL SCU and have some questions regarding proper interpretation/handling of the Matching Key Type (optional/required) and the Return Key Types. Maybe someone of you finds time to discuss the following questions a bit further with me:

1. From my understanding the SCP will/should only ever return attributes within its MWL responses that where originally part of the SCU identifier within its C-FIND request and not more. Is this correct?

2. When it comes to Matching Key Types I am currently interpreting the type R and O from Table K.6-1 in K.6.1.2.2 the following ways: R == each SCP is required to support matching against provided values; O == SCPs can support matching against provided values but is not required to support it, but if the Attribute has a Return Key Type of 1, the SCP is required to return it even if it does not support matching against a provided value. (e.g. Requested Procedure ID (0040,1001) is part of my C-FIND query identifier (not as matching key): am I correct to assume that every MWL SCP will return a (valid) value for this attribute since its Return Key Type is 1?)

3. Is it valid for an MWL SCU to send an C-FIND request with an identifier without any provided matching key value (so just a list of attributes with Zero Length values) and expect that the MWL SCP returns its items?

4. Is it safe for the SCU to assume that all returned MWL items by the SCP are in fact completely valid and that no requested attribute of Return Key Type 1 will be included in the MWL responses without an proper value? Should there be an additional check on the SCU side in place to validated that and in case dump such a broken MWL response?

I would really appreciate if a few of you could join me on these questions so that I can finally wrap my head around them.

Kind regards,
madMorty

[Thomas Freier]

> 1. From my understanding the SCP will/should only ever return attributes within its MWL responses that where originally part of the SCU identifier within its C-FIND request and not more. Is this correct?

Correct should not, but expect in practice that some SCPs may return more. So I would implement it to ignore attributes you don't need.

>
> 2. When it comes to Matching Key Types I am currently interpreting the type R and O from Table K.6-1 in K.6.1.2.2 the following ways: R == each SCP is required to support matching against provided values;

Yes. Kind of difficult to read the table ;) but you got it really well.

> O == SCPs can support matching against provided values but is not required to support it,

Optional attribute supported will be listed in the scp conformance statement.

> but if the Attribute has a Return Key Type of 1, the SCP is required to return it even if it does not support matching against a provided value. (e.g. Requested Procedure ID (0040,1001) is part of my C-FIND query identifier (not as matching key): am I correct to assume that every MWL SCP will return a (valid) value for this attribute since its Return Key Type is 1?)
>

Yes correct.

> 3. Is it valid for an MWL SCU to send an C-FIND request with an identifier without any provided matching key value (so just a list of attributes with Zero Length values) and expect that the MWL SCP returns its items?

Good question my opinion , someone with better DICOM knowledge may have a different interpretation.
According to Part 3.4 "An Identifier in a C-FIND request shall contain values​ to be matched against the Attributes of the Entities in a Worklist Information Model." I interpret "contain values" as shall have at minimum one value provided.
Anyway I would not try to do this in practice it may generate failure status or even an abort association. I am curious what is the use-case to query for all worklist items? Especially for an undefined timeframe.

>
> 4. Is it safe for the SCU to assume that all returned MWL items by the SCP are in fact completely valid and that no requested attribute of Return Key Type 1 will be included in the MWL responses without an proper value? Should there be an additional check on the SCU side in place to validated that and in case dump such a broken MWL response?

From my experience you should not expect or restrict too much. Check for the validity of attributes you really need and then accept it. Depends of your specific use-case of course. Generally speaking when creating a DICOM Request implement it strictly to the standard. When receiving a response check it for compliance just as much as you need and ignore the rest. Of course check for valid status.

Best regards
Thomas

[madMorty]

Thanks Thomas for your inital feedback.

> Good question my opinion , someone with better DICOM knowledge may have a different interpretation.
> According to Part 3.4 "An Identifier in a C-FIND request shall contain values​ to be matched against the Attributes of the Entities in a Worklist Information Model." I interpret "contain values" as shall have at minimum one value provided.
> Anyway I would not try to do this in practice it may generate failure status or even an abort association. I am curious what is the use-case to query for all worklist items? Especially for an undefined timeframe.

That is the same point where I am unsure within the standard wether "contain values" means that there must be at least one matching key with a provided value within the identifier or not. Also the text from K.4.1.3.1 ""Worklist" Search Method" could not make it clear to me if at least one matching key value must be provided within the SCU request identifier or not. I tested sending a C-FIND request with an identifier without any matching key value to the ORTHANC MWL plugin and DVTk RIS Emulator and both returned their MWL items. But I would really like to know if that behaviour is valid with the standard and should/can be expected from any MWL SCP. Mabye to give an idea how I came up with that in the first place: I somewhat compare the matching keys to "WHERE" clause in SQL to filter and thought if I do not care about filtering at all, I just send them also with Zero Length (so just like Return Keys).

Regarind the use-case why I came up with such a query: I thought about very small doctors's offices where there are maby about 10-20 examinations scheduled for a day and because of that small amount of examinations there would be not much gained with setting up filters for the MWL query in the first place. And to save those users from the burden to grapple with MWL matching key setup, I just would per default not set any matching/filtering key value options. (For any bigger medical infrastructor I would expect that there is an dedicated IT/DICOM administrator that would not have any problems with setting up the correct matching key options on the device.)

Best regards
Morty