Mapping of StudyDescription when using an MWL

This question is just a general observation about something I’ve noticed when using MWL’s for studies with various modalities. With one of the MR modalities I’ve been working with the StudyDescription tag is not populated from the MWL. This seems to be the case with some other vendors as well.

For the MR unit in question, there is an option for the technologist to manually enter something on the modality console for the StudyDescription value, but if left blank it remains undefined, and there is no fallback mapping to something else. I have the conformance statement for that modality, and they do map some other MWL entries to a tag in the instance produced that could be referenced to populate the StudyDescription Tag itself.

e.g.

0040,0275 (RequestAttributesSequence): []

  • »Item 1
    • 0032,1060 (RequestedProcedureDescription): MRI SHOULDER (L)

    • 0040,0007 (ScheduledProcedureStepDescription): MRI SHOULDER (L)

and I think if the StudyDescription is entered manually it gets mapped to the PerformedProcedureStepDescription tag and possibly also to the StudyDescription tag.

If the technician uses the MWL and leaves the StudyDescription field empty on the console, then it is NULL for created instances. That can be fixed by some post-processing or by a Lua script or Python script that populates the StudyDescription when the instance is received or when the study is completed, but it would be nice to not have to process the instances.

The behavior seems to be quite inconsistent across vendors since their implementation varies. Using MPPS might be a way to deal with that, but there is no support for that within Orthanc yet.

Just wondering if other people have encountered that sort of issue and how they have dealt with it.

I’ve seen this with a recent customer of ours - there are certain attributes that are missing from the study and it’s very vendor specific. The only way we’ve been able to deal with it is to deal with it internally within our application. I hadn’t thought of processing this on the Orthanc side though which would (at least for the time being) be a better option IMHO.