Hi Andreas,
I must admitt, I am not a 100% sure, but maybe Jörg or Marco may correct me if I am wrong.
AndreasKnopke wrote:
My question is: is it correct behaviour that all attributes in the expanded sequence are empty (or at least might be empty)?
Yes that's totally legal. Sending an empty attribute is called "Universal Matching", and in Worklist Information Model it is denoted as "Return Key". That means that every attribute sent empty by the SCU must be filled by the SCP with the value from a matching worklist entry. As this is allowed for single attributes inside and outside sequences (most of the worklist attributes are placed in sequence items), it is legal doing so for every attribute. DICOM places no restrictions on that. IHE is saying this explicetly (where in DICOM it is more implecetly said):
IHE Radiology TF, Vol II, 4.5.4.1.2.2 wrote:
(IHE-1): SCU implementations may choose to obtain the values contained in attributes that are part of the Scheduled Procedure Step sequence in either one of three ways. The first one is to request a universal match on the sequence attribute (zero length attribute). The second one is a universal sequence match (zero length item) for all attributes of the Scheduled Procedure Step sequence. The third one is to request a universal attribute match for selected attributes contained in the Scheduled Procedure Step sequence.
(IHE-2): SCP implementations shall support, per the DICOM Standard, three ways to let the Query SCU obtain the values contained in attributes that are part of the Scheduled Procedure Step sequence. The first one is to support a universal match on the sequence attribute (zero length attribute), and all managed attributes will be returned. The second one is to support a universal sequence match (zero length item) for all attributes of the Scheduled Procedure Step sequence, and all managed attributes will be returned. The third one is to support a universal attribute match for selected attributes contained in the Scheduled Procedure Step sequence, and the managed attributes that were selected will be returned.
AndreasKnopke wrote:
Our SIEMENS Aristos DR system expects non empty attributes in case the sequence was expanded. That's why it will only work with wlscpfs.exe with -nse (no sequence expansion) parameter. Is this correct behaviour?
I guess Siemens is right here. The issue is that the attributes Code Value and Coding Scheme Designator in der Requested Procedure Code Sequence are type 1 Return Keys, so they must be filled by the SCP with a value when requested by an empty search key for that attribute, wich is what happens through sequence expansion.
Requested Procedure Code Sequence is type 1
C, which means that either Requested Procedure Code Sequence or Requested Procedure Description must be supported by an SCP, wlmscpfs supports both. So Code Value and Coding Scheme Designator are type 1 Return Keys in wlmscpfs and must return non-empty values.
Probably the problem is that wlmscpfs does not get any values by the provided worklist source files. It tries copying (did not verify that) those values from the worklist files but does not seem to complain that they are missing. So the response values stay empty, which is actually an invalid worklist response. I guess you must provide those values in the worklist files. However, it would be nice if wlmscpfs would print a warning, of course. Actually I am wondering that wlmscpfs did not reject those incomplete worklist files. If you did not enable option "--disable-file-reject" then there should be one, because the following attributes are usually checked by wlmscpfs (copied from wlmfsim.cc):
Code: Select all
OFBool WlmFileSystemInteractionManager::DatasetIsComplete( DcmDataset *dataset )
// Date : May 2, 2005
// Author : Thomas Wilkens
// Task : This function checks if the given dataset (which represents the information from a
// worklist file) contains all necessary return type 1 information. According to the
// DICOM standard part 4 annex K, the following attributes are type 1 attributes in
// C-Find RSP messages:
// Attribute Tag Return Key Type
// SpecificCharacterSet (0008,0005) 1C (will be checked in WlmDataSourceFileSystem::StartFindRequest(...); this attribute does not have to be checked here)
// ScheduledProcedureStepSequence (0040,0100) 1
// > ScheduledStationAETitle (0040,0001) 1
// > ScheduledProcedureStepStartDate (0040,0002) 1
// > ScheduledProcedureStepStartTime (0040,0003) 1
// > Modality (0008,0060) 1
// > ScheduledProcedureStepDescription (0040,0007) 1C (The ScheduledProcedureStepDescription (0040,0007) or the ScheduledProtocolCodeSequence (0040,0008) or both shall be supported by the SCP; we actually support both, so we have to check if at least one of the two attributes contains valid information.)
// > ScheduledProtocolCodeSequence (0040,0008) 1C (see abobve)
// > > CodeValue (0008,0100) 1
// > > CodingSchemeDesignator (0008,0102) 1
// > ScheduledProcedureStepID (0040,0009) 1
// RequestedProcedureID (0040,1001) 1
// RequestedProcedureDescription (0032,1060) 1C (The RequestedProcedureDescription (0032,1060) or the RequestedProcedureCodeSequence (0032,1064) or both shall be supported by the SCP; we actually support both, so we have to check if at least one of the two attributes contains valid information.)
// RequestedProcedureCodeSequence (0032,1064) 1C (see abobve)
// > > CodeValue (0008,0100) 1
// > > CodingSchemeDesignator (0008,0102) 1
// StudyInstanceUID (0020,000D) 1
// ReferencedStudySequence (0008,1110) 2
// > ReferencedSOPClassUID (0008,1150) 1C (Required if a sequence item is present)
// > ReferencedSOPInstanceUID (0008,1155) 1C (Required if a sequence item is present)
// ReferencedPatientSequence (0008,1120) 2
// > ReferencedSOPClassUID (0008,1150) 1C (Required if a sequence item is present)
// > ReferencedSOPInstanceUID (0008,1155) 1C (Required if a sequence item is present)
// PatientsName (0010,0010) 1
// PatientID (0010,0020) 1
// Parameters : dataset - [in] The dataset of the worklist file which is currently examined.
// Return Value : OFTrue in case the given dataset contains all necessary return type 1 information,
// OFFalse otherwise.
If you provided Requested Procedure Description instead of Requested Procedure Code Sequence (as noted both are 1C, either one of both or both must be supported), then wlmscpfs will not reject those files. But then it would be a bug in wlmscpfs if the non-supported (non given worklist attributes in source, here the sequence) is not removed from the response. However, in IHE both must be supported, which may be also "best practice" in any non-IHE environment.
I think the same explanation applies to the Scheduled Protocol Code Sequence.
Hope that helps,
Regards Michael