Question about "Bad Parameter type for tag 0010,21c0" error in WML query.

I have a device that is making a MWL query that has this format:

{
“0008,0005” : “ISO_IR 100”,
“0008,0050” : “”,
“0008,0090” : “”,
“0008,1110” : [],
“0008,1120” : [],
“0010,0010” : “*”,
“0010,0020” : “”,
“0010,0030” : “”,
“0010,0040” : “”,
“0010,1010” : “”,
“0010,1030” : “”,
“0010,2000” : “”,
“0010,2110” : “”,
“0010,21c0” : null,
“0020,000d” : “”,
“0020,0010” : “”,
“0032,1032” : “”,
“0032,1060” : “”,
“0032,1064” : [
{
“0008,0100” : “”,
“0008,0102” : “”,
“0008,0103” : “”,
“0008,0104” : “”
}
],
“0038,0010” : “”,
“0038,0050” : “”,
“0038,0300” : “”,
“0038,0500” : “”,
“0040,0100” : [
{
“0008,0060” : “”,
“0032,1070” : “”,
“0040,0001” : “”,
“0040,0002” : “”,
“0040,0003” : “”,
“0040,0006” : “”,
“0040,0007” : “”,
“0040,0008” : [
{
“0008,0100” : “”,
“0008,0102” : “”,
“0008,0103” : “”,
“0008,0104” : “”
}
],
“0040,0009” : “”,
“0040,0010” : “”,
“0040,0011” : “”,
“0040,0012” : “”,
“0040,0020” : “”
}
],
“0040,1001” : “”,
“0040,1003” : “”,
“0040,1004” : “”,
“0040,3001” : “”
}

The device is a GE DX device, and we are having trouble getting the MWL to work with that device specifically, but it is working with multiple other devices such as US, CT, etc. on the network. It seems that maybe the PregnancyStatus tag might be the issue since it is set to null in the request, so that is on the GE side of things. I have not yet tried editing or filtering that from the MWL request with a Python script as suggested in the Orthanc Book, but might try that also.

I did try using a curl like http://localhost:8042/modalities/SELF/find-worklist with the above JSON to make a request (works on my system the way it is configured), and when PregnancyStatus is null it returns:

{
“Details” : “Bad Parameter type for tag 0010,21c0”,
“HttpError” : “Bad Request”,
“HttpStatus” : 400,
“Message” : “Bad type for a parameter”,
“Method” : “POST”,
“OrthancError” : “Bad type for a parameter”,
“OrthancStatus” : 5,
“Uri” : “/modalities/SELF/find-worklist”
}

When PregnancyStatus is and empty string, or a number in quotes, it just return the set of matching datasets as expected.

Just wondering if that is a bug, or something that can be fixed on the MWL plug-in side, or if the GE device request should not have null as a property value. I/we could filter that out or edit it with a Python script to edit the MWL Query as well.

https://book.orthanc-server.com/plugins/python.html#handling-worklist-scp-requests-new-in-3-2

/sds

This might be somewhat related: https://groups.google.com/g/orthanc-users/c/A19gxNIZjOc/m/DFmUqr1DEAAJ[](https://book.orthanc-server.com/plugins/python.html#handling-worklist-scp-requests-new-in-3-2)

A little bit of follow up about this issue. I tried adding the ‘orthanc.RegisterWorklistCallback(OnWorklist)’ script to my Python script, without first disabling the native orthanc MWL Plug-in and got an error in the log file:

I0523 10:53:43.884911 PluginsManager.cpp:161] (plugins) Registering one Python C-FIND SCP for worklist callback
E0523 10:53:43.885709 OrthancException.cpp:58] Error encountered within the plugin engine: Can only register one plugin to handle modality worklists
E0523 10:53:43.887919 PluginsManager.cpp:186] Exception while invoking plugin service 1005: Error encountered within the plugin engine

so I am assuming that one has to disable the native plug-in if one want to use a Python replacement ? I did not see a note about that in the documentation, so if that is the case, you might want to add that so people know you cannot use both.

Another thing I noticed is that there are some various options and flags for the jsonTags printout, e.g. The HUMAN flag makes those alot easier to read in the log file.

jsonTags = json.loads(orthanc.DicomBufferToJson(dicom, orthanc.DicomToJsonFormat.HUMAN, orthanc.DicomToJsonFlags.NONE, 0))
orthanc.LogWarning(‘C-FIND worklist request to be handled in Python: %s’ % json.dumps(jsonTags, indent = 4, sort_keys = True))

In ‘def OnWorklist(answers, query, issuerAet, calledAet):’, query is actually a orthanc.WorklistQuery object, so it isn’t yet clear to me how we can edit the query tags if we want to do that. There are instances during development where we might want to delete a tag completely, add a tag, or otherwise edit a tag.

The example given in the Orthanc Book here https://book.orthanc-server.com/plugins/python.html?highlight=python%20plugin#handling-worklist-scp-requests-new-in-3-2, I take it is sort of a drop-in replacement starter for the MWL Orthanc Plug-in ?

On a side note, I also have MWL’s in JSON and DICOM format in a DB, in addition to being on the file system. Haven’t been using that except for archival purposes, but with this Plug-in might now be possible to add the option of using a DB and other features for MWL’s, although I’ll have to figure out how to use the DB, which might not be that hard really.

Thanks.

/sds

Hi Stephen,

The sample https://book.orthanc-server.com/plugins/python.html?highlight=python%20plugin#handling-worklist-scp-requests-new-in-3-2 is indeed a replacement for the ModalityWorklist written in C++. You can not use it to sanitize an incoming C-Find.

If you want to sanitize a C-Find (which is what I recommend in your case), you can do it in lua with IncomingWorklistRequestFilter.

HTH

Alain.

Tried that and it doesn’t seem to work because I think it doesn’t even run or complete the Lua Script if the incoming request has the PregnancyStatus tag query set to null, which it does for the problem GE device. The Lua Script does otherwise work if I remove the Pregnancy status from the query. I was using the REST API to test using the find-worklist endpoint, so I tried also using findscu, somewhat like this: null is apparently not really an accepting value, although not sure how to set that in the findscu to match what the JSON request was (see the previous messages, ,“0010,21c0” : null shows up in the log as the value for PregnancyStatus when the request is from that GE device.).

findscu 127.0.0.1 4242 -W -k “AccessionNumber”
-k “Modality”
-k “InstitutionName”
-k “ReferringPhysicianName”
-k “ReferencedStudySequence[0]”
-k “ReferencedPatientSequence[0]”
-k “PatientName”
-k “PatientID”
-k “PatientBirthDate”
-k “PatientSex”
-k “PatientAge”
-k “PatientWeight”
-k “MedicalAlerts”
-k “Allergies”
-k “PregnancyStatus”
-k “StudyInstanceUID”
-k “StudyID”
-k “RequestingPhysician”
-k “RequestedProcedureDescription”
-k “RequestedProcedureCodeSequence[0]”
-k “AdmissionID”
-k “SpecialNeeds”
-k “CurrentPatientLocation”
-k “PatientState”
-k “ScheduledProcedureStepSequence[0]”
-k “RequestedProcedureID”
-k “RequestedProcedurePriority”
-k “PatientTransportArrangements” \

-k “ConfidentialityConstraintOnPatientDataDescription”

If I set that to null in the findscu I get: Bad override key/path: PregnancyStatus=null: Corrupted data.
If I use the REST API: “Details” : “While creating a DICOM instance, tag (0010,21c0) has out-of-range value: ""”,

Similar call via the API. I don’t think the issue is with the MWL files, it is with the request having null for PregnancyStatus.

curl -k -d ‘{
“0008,0005” : “ISO_IR 100”,
“0008,0050” : “”,
“0008,0090” : “”,
“0008,1110” : [],
“0008,1120” : [],
“0010,0010” : “*”,
“0010,0020” : “”,
“0010,0030” : “”,
“0010,0040” : “”,
“0010,1010” : “”,
“0010,1030” : “”,
“0010,2000” : “”,
“0010,2110” : “”,
“0010,21c0” : null,
“0020,000d” : “”,
“0020,0010” : “”,
“0032,1032” : “”,
“0032,1060” : “”,
“0032,1064” : [
{
“0008,0100” : “”,
“0008,0102” : “”,
“0008,0103” : “”,
“0008,0104” : “”
}
],
“0038,0010” : “”,
“0038,0050” : “”,
“0038,0300” : “”,
“0038,0500” : “”,
“0040,0100” : [
{
“0008,0060” : “”,
“0032,1070” : “”,
“0040,0001” : “”,
“0040,0002” : “”,
“0040,0003” : “”,
“0040,0006” : “”,
“0040,0007” : “”,
“0040,0008” : [
{
“0008,0100” : “”,
“0008,0102” : “”,
“0008,0103” : “”,
“0008,0104” : “”
}
],
“0040,0009” : “”,
“0040,0010” : “”,
“0040,0011” : “”,
“0040,0012” : “”,
“0040,0020” : “”
}
],
“0040,1001” : “”,
“0040,1003” : “”,
“0040,1004” : “”,
“0040,3001” : “”
}’ https://user:pass@127.0.0.1:8042/modalities/SELF/find-worklist

Seems like maybe the GE device should not have null for the PregnancyStatus in the query, but it doesn’t appear to be possible to filter it out either using IncomingWorklistRequestFilter. Is there another place to scrub the request somehow ?

Not sure, but it seems like the exception is thrown via tag validation in orthanc/OrthancFramework/Sources/DicomParsing/FromDcmtkBridge.cpp:

Here:

case EVR_US: // unsigned short
{
ok = element.putUint16(boost::lexical_cast(*decoded)).good();
break;
}

and here:

if (!ok)
{
DicomTag tag(element.getTag().getGroup(), element.getTag().getElement());
throw OrthancException(ErrorCode_BadFileFormat,
“While creating a DICOM instance, tag (” + tag.Format() +
“) has out-of-range value: "” + (*decoded) + “"”);
}