Question about MWL's and MPPS

109 views
Skip to first unread message

Stephen Douglas Scotti

unread,
Apr 6, 2022, 11:25:40 PMApr 6
to
I've been using Orthanc for about 1-year or more now, including the built-in MWL server with some customization. It works pretty well without the MPPS feature (not part of Orthanc) for several Modalities that we are using, but someone has a GE Healthcare BRIVO XR 385 that it doesn't work on. I'd have to get more details, but it sounds like the GE modality can query the MWL, but it doesn't actually populate the tags with the tags from the MWL, presumably because MPPS is implemented. We are also working with an Esaote G-Scan Brio for which the Orthanc implementation does work. MPPS is turned off and not implemented on the G-scan, but it does populate the study tags with the supported tags from the MWL file.

There is some basic information about the Orthanc MWL plug-in here:

https://book.orthanc-server.com/plugins/worklists-plugin.html#worklists-plugin

I've written my own orthanc Python plug-ins to allow the creation of MWL files/data from a JSON via REST API, based somewhat on what I have here using pydicom:

https://github.com/sscotti/python_script_library

That has a relatively nice little recursive function that does that such that you can store the JSON, dataset and other data to a DB, or just the dataset to the filesystem.

I might try to write a Python Plugin for Orthanc or just a free-standing Python based MPPS server using pynetdicom to try to deal with that, but just wondering if there is a way to get the GE device to work using the native Orthanc Plug-in or if it requires that MPPS be supported.

Thanks.

Marco Eichelberg

unread,
Apr 8, 2022, 1:51:13 AMApr 8
to
stephen....@gmail.com schrieb am Donnerstag, 7. April 2022 um 05:25:40 UTC+2:
> I've been using Orthanc for about 1-year or more now, including the built-in MWL server with some customization. It works pretty well without the MPPS feature (not part of Orthanc) for several Modalities that we are using, but someone has a GE Healthcare BRIVO XR 385 that it doesn't work on. I'd have to get more details, but it sounds like the GE modality can query the MWL, but it doesn't actually populate the tags with the tags from the MWL, presumably because MPPS is implemented.

If enabling MPPS breaks the MWL functionality, that would be a major bug either in Orthanc or in the modality. The two services are used at different times and I see absolutely no reason why one should affect the other. Your best option is probably to create a Wireshark capture of the communication between the modality and the worklist server and to check if everything is OK there, of if for example the modality queries for certain keys that the MWL server (which seems to be the standard DCMTK worklist server tool) does not support.

Stephen Douglas Scotti

unread,
Apr 9, 2022, 11:15:13 AMApr 9
to
Marco, thanks for feedback. I don't have access to the environment, but my colleague does. I'd have to get him to do the network sniffing, but the Orthanc Log file I think does show this as the find request. I am pretty sure that his current MWL setup does not create .wl files that have all of those tags, just a subset. You are probably correct that maybe Orthanc (which I think uses dcmtk) does not support one of those tags, although it is generating and returned a response to the request. The response is a subset of what is requested. Is that enough to "break it" ? The person who I am working with is in Kenya. The last time we spoke it sounded like the MWL's were showing up in the "pick list", but the tags for the study were not getting populated. I'll have to check back with him and see if they made any more progress.

They do have to ability to customize what is in the generated MWL files. It seems to be working already on multiple other modalities. It is just the GE DR unit that does not work.

T0326 18:24:31.147323 FindScp.cpp:216] (dicom) Received C-FIND Request:

# Dicom-Data-Set
# Used TransferSyntax: Little Endian Explicit
(0008,0005) CS [ISO_IR 100] # 10, 1 SpecificCharacterSet
(0008,0050) SH (no value available) # 0, 0 AccessionNumber
(0008,0090) PN (no value available) # 0, 0 ReferringPhysicianName
(0008,1110) SQ (Sequence with explicit length #=1) # 24, 1 ReferencedStudySequence
(fffe,e000) na (Item with explicit length #=2) # 16, 1 Item
(0008,1150) UI (no value available) # 0, 0 ReferencedSOPClassUID
(0008,1155) UI (no value available) # 0, 0 ReferencedSOPInstanceUID
(fffe,e00d) na (ItemDelimitationItem for re-encoding) # 0, 0 ItemDelimitationItem
(fffe,e0dd) na (SequenceDelimitationItem for re-encod.) # 0, 0 SequenceDelimitationItem
(0008,1120) SQ (Sequence with explicit length #=1) # 24, 1 ReferencedPatientSequence
(fffe,e000) na (Item with explicit length #=2) # 16, 1 Item
(0008,1150) UI (no value available) # 0, 0 ReferencedSOPClassUID
(0008,1155) UI (no value available) # 0, 0 ReferencedSOPInstanceUID
(fffe,e00d) na (ItemDelimitationItem for re-encoding) # 0, 0 ItemDelimitationItem
(fffe,e0dd) na (SequenceDelimitationItem for re-encod.) # 0, 0 SequenceDelimitationItem
(0010,0010) PN [*] # 2, 1 PatientName
(0010,0020) LO (no value available) # 0, 0 PatientID
(0010,0030) DA (no value available) # 0, 0 PatientBirthDate
(0010,0040) CS (no value available) # 0, 0 PatientSex
(0010,1010) AS (no value available) # 0, 0 PatientAge
(0010,1030) DS (no value available) # 0, 0 PatientWeight
(0010,2000) LO (no value available) # 0, 0 MedicalAlerts
(0010,2110) LO (no value available) # 0, 0 Allergies
(0010,21c0) US (no value available) # 0, 0 PregnancyStatus
(0020,000d) UI (no value available) # 0, 0 StudyInstanceUID
(0020,0010) SH (no value available) # 0, 0 StudyID
(0032,1032) PN (no value available) # 0, 0 RequestingPhysician
(0032,1060) LO (no value available) # 0, 0 RequestedProcedureDescription
(0032,1064) SQ (Sequence with explicit length #=1) # 40, 1 RequestedProcedureCodeSequence
(fffe,e000) na (Item with explicit length #=4) # 32, 1 Item
(0008,0100) SH (no value available) # 0, 0 CodeValue
(0008,0102) SH (no value available) # 0, 0 CodingSchemeDesignator
(0008,0103) SH (no value available) # 0, 0 CodingSchemeVersion
(0008,0104) LO (no value available) # 0, 0 CodeMeaning
(fffe,e00d) na (ItemDelimitationItem for re-encoding) # 0, 0 ItemDelimitationItem
(fffe,e0dd) na (SequenceDelimitationItem for re-encod.) # 0, 0 SequenceDelimitationItem
(0038,0010) LO (no value available) # 0, 0 AdmissionID
(0038,0050) LO (no value available) # 0, 0 SpecialNeeds
(0038,0300) LO (no value available) # 0, 0 CurrentPatientLocation
(0038,0500) LO (no value available) # 0, 0 PatientState
(0040,0100) SQ (Sequence with explicit length #=1) # 156, 1 ScheduledProcedureStepSequence
(fffe,e000) na (Item with explicit length #=13) # 148, 1 Item
(0008,0060) CS (no value available) # 0, 0 Modality
(0032,1070) LO (no value available) # 0, 0 RequestedContrastAgent
(0040,0001) AE (no value available) # 0, 0 ScheduledStationAETitle
(0040,0002) DA (no value available) # 0, 0 ScheduledProcedureStepStartDate
(0040,0003) TM (no value available) # 0, 0 ScheduledProcedureStepStartTime
(0040,0006) PN (no value available) # 0, 0 ScheduledPerformingPhysicianName
(0040,0007) LO (no value available) # 0, 0 ScheduledProcedureStepDescription
(0040,0008) SQ (Sequence with explicit length #=1) # 40, 1 ScheduledProtocolCodeSequence
(fffe,e000) na (Item with explicit length #=4) # 32, 1 Item
(0008,0100) SH (no value available) # 0, 0 CodeValue
(0008,0102) SH (no value available) # 0, 0 CodingSchemeDesignator
(0008,0103) SH (no value available) # 0, 0 CodingSchemeVersion
(0008,0104) LO (no value available) # 0, 0 CodeMeaning
(fffe,e00d) na (ItemDelimitationItem for re-encoding) # 0, 0 ItemDelimitationItem
(fffe,e0dd) na (SequenceDelimitationItem for re-encod.) # 0, 0 SequenceDelimitationItem
(0040,0009) SH (no value available) # 0, 0 ScheduledProcedureStepID
(0040,0010) SH (no value available) # 0, 0 ScheduledStationName
(0040,0011) SH (no value available) # 0, 0 ScheduledProcedureStepLocation
(0040,0012) LO (no value available) # 0, 0 PreMedication
(0040,0020) CS (no value available) # 0, 0 ScheduledProcedureStepStatus
(fffe,e00d) na (ItemDelimitationItem for re-encoding) # 0, 0 ItemDelimitationItem
(fffe,e0dd) na (SequenceDelimitationItem for re-encod.) # 0, 0 SequenceDelimitationItem
(0040,1001) SH (no value available) # 0, 0 RequestedProcedureID
(0040,1003) SH (no value available) # 0, 0 RequestedProcedurePriority
(0040,1004) LO (no value available) # 0, 0 PatientTransportArrangements
(0040,3001) LO (no value available) # 0, 0 ConfidentialityConstraintOnPatientDataDescription

Stephen Douglas Scotti

unread,
Apr 12, 2022, 7:49:14 AMApr 12
to
This is a formatted version of the request from the device, followed by the first response sent by the Orthanc MWL Plug-in, with some values stripped out. Could it be that the MWL's on the server have to have all of the tags that are requested by the device, even if they are empty ? The setup now has just a subset of the re

===================== INCOMING DIMSE MESSAGE ====================
Message Type : C-FIND RQ
Presentation Context ID : 1
Message ID : 105
Affected SOP Class UID : FINDModalityWorklistInformationModel
Data Set : present
Priority : medium
======================= END DIMSE MESSAGE =======================
T0326 19:14:31.176369 FindScp.cpp:216] (dicom) Received C-FIND Request:
T0326 19:14:31.178769 FindScp.cpp:327] (dicom) Sending C-FIND Response 1/2:

# Dicom-Data-Set
# Used TransferSyntax: Little Endian Explicit
(0008,0005) CS [ISO_IR 100] # 10, 1 SpecificCharacterSet
(0008,0050) SH [] # 14, 1 AccessionNumber
(0008,0090) PN [] # 32, 1 ReferringPhysicianName
(0010,0010) PN [] # 12, 1 PatientName
(0010,0020) LO [] # 10, 1 PatientID
(0010,0030) DA [] # 8, 1 PatientBirthDate
(0010,0040) CS [] # 2, 1 PatientSex
(0010,1030) DS (no value available) # 0, 0 PatientWeight
(0010,2000) LO (no value available) # 0, 0 MedicalAlerts
(0010,2110) LO (no value available) # 0, 0 Allergies
(0020,000d) UI [] # 38, 1 StudyInstanceUID
(0040,0100) SQ (Sequence with explicit length #=1) # 0, 1 ScheduledProcedureStepSequence
(fffe,e000) na (Item with undefined length #=7) # u/l, 1 Item
(0008,0060) CS [MR] # 2, 1 Modality
(0040,0001) AE [] # 10, 1 ScheduledStationAETitle
(0040,0002) DA [20210704] # 8, 1 ScheduledProcedureStepStartDate
(0040,0003) TM [110000] # 6, 1 ScheduledProcedureStepStartTime
(0040,0007) LO [MRI BRAIN / BRAIN STEM - WITHOUT CONTRAST] # 42, 1 ScheduledProcedureStepDescription
(0040,0008) SQ (Sequence with explicit length #=1) # 0, 1 ScheduledProtocolCodeSequence
(fffe,e000) na (Item with undefined length #=3) # u/l, 1 Item
(0008,0100) SH [] # 6, 1 CodeValue
(0008,0102) SH [] # 2, 1 CodingSchemeDesignator
(0008,0104) LO [] # 10, 1 CodeMeaning
(fffe,e00d) na (ItemDelimitationItem) # 0, 0 ItemDelimitationItem
(fffe,e0dd) na (SequenceDelimitationItem for re-encod.) # 0, 0 SequenceDelimitationItem
(0040,0009) SH [] # 4, 1 ScheduledProcedureStepID
(fffe,e00d) na (ItemDelimitationItem) # 0, 0 ItemDelimitationItem

Marco Eichelberg

unread,
Apr 19, 2022, 5:04:17 AMApr 19
to
stephen....@gmail.com schrieb am Dienstag, 12. April 2022 um 13:49:14 UTC+2:
> This is a formatted version of the request from the device, followed by the first response sent by the Orthanc MWL Plug-in, with some values stripped out. Could it be that the MWL's on the server have to have all of the tags that are requested by the device, even if they are empty ?

It is the normal behavior of a DICOM MWL server to not send attributes in the response if they are optional (according to the DICOM standard) and not supported by the MWL server.
A modality needs to be able to handle this, which of course does not mean that every modality does that correctly. In any case, I cannot see any obvious issue with the response from the server.
Reply all
Reply to author
Forward
0 new messages