From Stephen Douglas Scotti@21:1/5 to All on Fri Apr 30 11:16:56 2021
Just found this forum. We have been designing a RIS to be used in conjunction with Orthanc as a PACS server. We now have MRI scanner hooked up to Orthanc. Orthanc comes with a MWL plug-in that basically listens for C-find requests from the modality,
and that is all working as far as sending a response to the scanner, and most of the tags are getting populated from the MWL values.
Apparently, Orthanc does not support MPPS out-of-the-box, see:
but down the road might be nice to implement that with a Python Plug-in as mentioned in that post. For now, mostly interested in using the MWL with one or more SPS's without MPPS yet implemented. The RIS has a way to delete the MWL files once the
requested studies are completed.
First question I have is regarding the StudyInstanceID. The scanner has an option to use the machine generated StudyInstanceID, or it can use one provided in the MWL file. I was examining the tags when using a StudyInstanceID from the MWL and noticed
that the StudyInstanceID is ours, whereas the SeriesUID's and other UID's are using the scanner's root, or so it seems, e.g. Their root looks like: 1.3.76.2.1.1.4.1.3.5388.
Just wondering if that is "normal" behavior, or if the scanner has to be somehow configured to use our root if it is provided as the StudyInstanceUID in the MWL. I have various algorithms to guarantee the uniqueness of our StudyInstanceUID. Also read
somewhere that the StudyInstanceUID should be padded with a NULL byte in some instances ?
I have quite a few other questions about appropriately setting up the MWL template so that it does what is needed. Still playing around with that, so I'll follow up with another post regarding that after further investigation. The scanner is an Esaote
G-scan, and I have looked through the Dicom Conformance statement for some guidance.
Below is a partially 'working' version of the MWL .wl file that Orthanc is serving. That is generated from and HL7 message as a .txt template and then a .wl file is created using dump2dcm. I have a lot of flexibility when it comes to configuring that.
There are some placeholders for some of the values:
# Dicom-Data-Set
# Used TransferSyntax: Little Endian Explicit
(0008,0005) CS [ISO_IR 192] # 10, 1 SpecificCharacterSet
(0008,0050) SH [AccessionNumber] # 14, 1 AccessionNumber
(0008,0090) PN [0002:^^^^] # 30, 1 ReferringPhysicianName
(0008,1030) LO [Daily QC] # 8, 1 StudyDescription
(0008,1080) LO [AdmittingDiagnosesDescription] # 22, 1 AdmittingDiagnosesDescription
(0010,0010) PN [QC^Esaote G-scan^] # 18, 1 PatientName (0010,0020) LO [5388.PatientID] # 14, 1 PatientID (0010,0030) DA [20210415] # 8, 1 PatientBirthDate
(0010,0040) CS [M] # 2, 1 PatientSex (0010,1020) DS [1.8542037108333] # 16, 1 PatientSize (0010,1030) DS [97.5223719555] # 14, 1 PatientWeight (0010,1040) LO [PatientAddress] # 56, 1 PatientAddress
(0010,2000) LO (no value available) # 0, 0 MedicalAlerts (0010,2110) LO (no value available) # 0, 0 Allergies (0010,2180) SH [Occupation] # 10, 1 Occupation (0010,21b0) LT [Daily QC] # 8, 1 AdditionalPatientHistory
(0010,4000) LT [PatientComments] # 16, 1 PatientComments
(0020,000d) UI [1.3.6.1.4.1.56016.1....] # 34, 1 StudyInstanceUID (0032,1060) LO [Daily QC] # 8, 1 RequestedProcedureDescription
(0032,1064) SQ (Sequence with explicit length #=1) # 66, 1 RequestedProcedureCodeSequence
(fffe,e000) na (Item with explicit length #=3) # 58, 1 Item
(0008,0100) SH [CodeValue] # 10, 1 CodeValue
(0008,0102) SH [SCT] # 12, 1 CodingSchemeDesignator
(0008,0104) LO [CodeMeaning] # 12, 1 CodeMeaning
(fffe,e00d) na (ItemDelimitationItem for re-encoding) # 0, 0 ItemDelimitationItem
(fffe,e0dd) na (SequenceDelimitationItem for re-encod.) # 0, 0 SequenceDelimitationItem
(0040,0100) SQ (Sequence with explicit length #=1) # 172, 1 ScheduledProcedureStepSequence
(fffe,e000) na (Item with explicit length #=7) # 164, 1 Item
(0008,0060) CS [MR] # 2, 1 Modality
(0040,0001) AE [NmrEsaote] # 10, 1 ScheduledStationAETitle
(0040,0002) DA [20210430] # 8, 1 ScheduledProcedureStepStartDate
(0040,0003) TM [080000] # 6, 1 ScheduledProcedureStepStartTime
(0040,0007) LO [Daily QC] # 8, 1 ScheduledProcedureStepDescription
(0040,0008) SQ (Sequence with explicit length #=1) # 66, 1 ScheduledProtocolCodeSequence
(fffe,e000) na (Item with explicit length #=3) # 58, 1 Item
(0008,0100) SH [CodeValue] # 10, 1 CodeValue
(0008,0102) SH [SCT] # 12, 1 CodingSchemeDesignator
(0008,0104) LO [CodeMeaning] # 12, 1 CodeMeaning
(fffe,e00d) na (ItemDelimitationItem for re-encoding) # 0, 0 ItemDelimitationItem
(fffe,e0dd) na (SequenceDelimitationItem for re-encod.) # 0, 0 SequenceDelimitationItem
(0040,0009) SH [0041] # 4, 1 ScheduledProcedureStepID
(fffe,e00d) na (ItemDelimitationItem for re-encoding) # 0, 0 ItemDelimitationItem
(fffe,e0dd) na (SequenceDelimitationItem for re-encod.) # 0, 0 SequenceDelimitationItem
(0040,1001) SH [0041]
The Dicom Trace in Orthanc for the request from the scanner is like:
From Markus Sabin@21:1/5 to All on Mon May 10 08:17:57 2021
Hi Stephen,
Freitag, 30. April 2021 um 20:16:58 UTC+2:
First question I have is regarding the StudyInstanceID. The scanner has an option to use the machine generated StudyInstanceID, or it can use one provided in the MWL file. I was examining the tags when using a StudyInstanceID from the MWL and noticed
that the StudyInstanceID is ours, whereas the SeriesUID's and other UID's are using the scanner's root, or so it seems, e.g. Their root looks like: 1.3.76.2.1.1.4.1.3.5388.
Just wondering if that is "normal" behavior, or if the scanner has to be somehow configured to use our root if it is provided as the StudyInstanceUID in the MWL. I have various algorithms to guarantee the uniqueness of our StudyInstanceUID.
Yes, that is the normal behavior. A Study may span different series created by different equipment. Still the user wants to see all these series in a study context. To achieve that, patient- and study attributes are obtained from the worklist and from
the series level onwards, the attributes are equipment-generated. This includes the Series- and SOP Instance UID. Maybe this nice diagram from the standard makes it more clear: http://dicom.nema.org/dicom/2013/output/chtml/part03/chapter_7.html
Also read somewhere that the StudyInstanceUID should be padded with a NULL byte in some instances ?
Yes, this is true and comes from the requirement that each DICOM attribute is required to have an even length. So if your uniquely generated UID is of odd length, it must be padded with a NULL character. See here (section 9.1): http://dicom.nema.org/dicom/2013/output/chtml/part05/chapter_9.html
I have quite a few other questions about appropriately setting up the MWL template so that it does what is needed. Still playing around with that, so I'll follow up with another post regarding that after further investigation. The scanner is an Esaote
G-scan, and I have looked through the Dicom Conformance statement for some guidance.
Below is a partially 'working' version of the MWL .wl file that Orthanc is serving. That is generated from and HL7 message as a .txt template and then a .wl file is created using dump2dcm. I have a lot of flexibility when it comes to configuring that.
There are some placeholders for some of the values:
# Dicom-Data-Set
# Used TransferSyntax: Little Endian Explicit
(0008,0005) CS [ISO_IR 192] # 10, 1 SpecificCharacterSet
[...]
If this is supposed to be a question, I do not fully get what you are asking for. If there is a problem with your query, I would have a first look at the Specific Character Set. In your sample, it says "UTF-8" (ISO_IR 192), and the Esaote system queries
for "nothing" which means "US-ASCII". Since your worklist match does not seem to include any character that cannot be encoded in ASCII, you may try just removing (0008,0005) from your worklist record and see if it works.
From Stephen Douglas Scotti@21:1/5 to All on Mon May 10 10:22:05 2021
Hey Markus, thank you for the response.
For a StudyInstanceID, Orthanc is apparently going to support using a ROOT ID specified as a config item in a future release, in which case I think it would be the ROOT ID followed by the internal uuid that orthanc generates on demand. Still exploring
how to create one in PHP from a ROOT, but looking at something like this:
where DEFAULT_DICOM_ROOT is the user's root with trailing '.', RIS_ID is a unique software application ID with '.', $id is a unique device id for the RIS app with '.', $insert is a unique ID for the MWL order and time() is UTC time stamp. With Orthanc
allowing for a Root ID, that would be much easier.
There does not seem to be a problem with the MWL query itself, just with getting some tags for the Study populated, mostly the StudyDescription. The logs on Orthanc for the C-FIND request and the response are shown below. I actually added a Lua script
to add some tags to the incoming query because the scanner does ask for those by default. The issue I have been having is that the StudyDescription tag is not getting populated on the instances sent to PACS by the MRI unit, and StudyDescription does not
show up on the MRI console prepopulated. The operator has to enter that manually for some reason. That may just be the way the system is setup.
On Orthanc MPPS is not setup either, so that might be a way to get around populating the tags for a study from the RIS once a MPPS message is sent, or on ingress of instances into PACS using a Lua script. The simple solution is to figure out how to
setup the MWL or the scanner to use the StudyDescription from the MWL file. I could add the (0032,1064) to the MWL. Have not tried that yet.
function IncomingWorklistRequestFilter(query, origin)
# Dicom-Data-Set
# Used TransferSyntax: Little Endian Explicit
(0008,0005) CS [ISO_IR 192] # 10, 1 SpecificCharacterSet
(0008,0050) SH [DEVACC00000053] # 14, 1 AccessionNumber
(0008,0090) PN [ReferringPhysicianName] # 30, 1 ReferringPhysicianName (0008,1030) LO [Daily QC] # 8, 1 StudyDescription
(0008,1080) LO [AdmittingDiagnosesDescription] # 22, 1 AdmittingDiagnosesDescription
(0010,0010) PN [QC^Esaote G-scan^] # 18, 1 PatientName (0010,0020) LO [PatientID] # 14, 1 PatientID (0010,0030) DA [20210415] # 8, 1 PatientBirthDate
(0010,0040) CS [M] # 2, 1 PatientSex (0010,1020) DS (no value available) # 0, 0 PatientSize (0010,1030) DS (no value available) # 0, 0 PatientWeight (0010,2180) SH (no value available) # 0, 0 Occupation (0010,21b0) LT [Type the Title for Study into the Console (Study Description)] # 62, 1 AdditionalPatientHistory
(0010,4000) LT (no value available) # 0, 0 PatientComments
(0020,000d) UI [1.3.6.1.4.1.56016.0.1.1.131.1620648192] # 38, 1 StudyInstanceUID
(0032,1060) LO [Daily QC] # 8, 1 RequestedProcedureDescription
(0040,0100) SQ (Sequence with explicit length #=1) # 0, 1 ScheduledProcedureStepSequence
(fffe,e000) na (Item with undefined length #=9) # u/l, 1 Item
(0008,0050) SH [DEVACC00000053] # 14, 1 AccessionNumber
(0008,0060) CS [MR] # 2, 1 Modality
(0008,1030) LO [Daily QC] # 8, 1 StudyDescription
(0040,0001) AE [NmrEsaote] # 10, 1 ScheduledStationAETitle
(0040,0002) DA [20210510] # 8, 1 ScheduledProcedureStepStartDate
(0040,0003) TM [080000] # 6, 1 ScheduledProcedureStepStartTime
(0040,0007) LO [Daily QC] # 8, 1 ScheduledProcedureStepDescription
(0040,0008) SQ (Sequence with explicit length #=1) # 0, 1 ScheduledProtocolCodeSequence
(fffe,e000) na (Item with explicit length #=3) # 54, 1 Item
(0008,0100) SH [0040,0008] # 10, 1 CodeValue
(0008,0102) SH [0040,0008] # 10, 1 CodingSchemeDesignator
(0008,0104) LO [0040,0008] # 10, 1 CodeMeaning
(fffe,e00d) na (ItemDelimitationItem for re-encoding) # 0, 0 ItemDelimitationItem
(fffe,e0dd) na (SequenceDelimitationItem for re-encod.) # 0, 0 SequenceDelimitationItem
(0040,0009) SH [0041] # 4, 1 ScheduledProcedureStepID
(fffe,e00d) na (ItemDelimitationItem) # 0, 0 ItemDelimitationItem
(fffe,e0dd) na (SequenceDelimitationItem for re-encod.) # 0, 0 SequenceDelimitationItem
(0040,1001) SH [0041] # 4, 1 RequestedProcedureID
Followed by:
T0510 15:46:21.700881 CommandDispatcher.cpp:291] (dicom) Received Association Parameters:
====================== BEGIN A-ASSOCIATE-RQ =====================
....
======================= END A-ASSOCIATE-RQ ======================
====================== BEGIN A-ASSOCIATE-AC =====================
...
======================= END A-ASSOCIATE-AC ======================
===================== INCOMING DIMSE MESSAGE ====================
Message Type : C-STORE RQ
Presentation Context ID : 209
Message ID : 5
Affected SOP Class UID : MRImageStorage
Affected SOP Instance UID : 1.3.76.2.1.1.4.1.3.5388.671276871.0
Data Set : present
Priority : medium
======================= END DIMSE MESSAGE =======================
. . . . .
From Markus Sabin@21:1/5 to All on Tue May 11 05:20:36 2021
As for the Study Description, there is unfortunately no standard-way (that I am aware of) to safely transfer this to the modality. The worklist has a Requested Procedure Description; Study Description is not an attribute that is part of a worklist
response according to PS3.4, Table K.6-1. DICOM does not put any requirements on how the Study Description is generated on the modality, and IHE recommends (i.e. no hard requirement) to set it to a value equal to Performed Procedure Step Description (
0040,0254). This attribute is "equipment generated" however, i.e. assigned on the modality.
You may want to look into the DICOM Conformance Statement of the modality in question to see where the attribute's value is obtained from. But whatever solution you will find, it is far from being guaranteed to work with other equipment as well.
BTW: The code sequence item for the Scheduled Protocol Code Sequence in your response does not look healthy ;-)
From Stephen Douglas Scotti@21:1/5 to All on Tue May 11 19:12:15 2021
Thank you again.
I actually have: (0032,1060) LO [Daily QC] # 8, 1 RequestedProcedureDescription in the MWL file, and that tag is also in the C-FIND request, so presumably the modality is getting that in the response.
I was playing around with some Lua scripts to: 1. Modify the C-FIND query so that tags not requested by the modality might be returned also (bad idea I think) and 2. Modifying instances after they are stored to update / add the missing tags. A Lua
script could do that, but it is resource intensive I think, and it is possible to do that sort of thing at the Study Level after the exam is marked as complete by the technologist, or even programmatically after the study becomes "Stable". The latter
would require a little checking to verify that a MWL file still exist and that the ingest is from an AET that you want to modify tags for, but that would work actually also as long as what is in the MWL file matches what was actually done. Still, to get
the technologist, that would have to sent by the scanner itself or by the RIS after manually marking the study as complete.
I do have some sample tags from an instance that was generated by the scanner after using an MWL file, some tags deleted or somewhat anonymized even though it is a test study. Note the note to the technologist, which did not happen: (0010,21b0) LT [
Type the Title for Study into the Console (Study Description)] # 62, 1 AdditionalPatientHistory. The tags of primary interest are probably the ones below. I am pretty sure that when / if the technologist manually enters a StudyDescription that is
shows up in a Performed Procedure Step Description (0040,0254) tag, which is missing below, although the preceding tags are there. You are correct about ScheduledProtocolCodeSequence. That is sort of a placeholder. I may not need that actually.
I have not looked too deeply into using MPPS because that requires some development as far as use with Orthanc is concerned.
Orthanc does however have a method to add / update tags at the study level. That might actually be the easiest and most modality independent since there is also apparently a regulatory requirement to have the Technicians / Operator Tag populated as well
?? (0070,0084), although various viewers appear to be a little inconsistent about what annotations are shown on images. I would want the AccessionNumber and Operator to show up on the annotations, or at least be configurable.
One thing that would be easy to try is to have the technologist mark the exam as "Complete" in the RIS once QA is done and the study approved. Already do that. Kind of hard these days to get a human to push a button consistently sometimes since it
seems like the desire is to have everything work by AI. The RIS can then: 1. Delete the MWL File (does that). 2. Capture any additional Tags the need to be added to the Study at the time of completion (i.e. The Actual Study Performed & the
Technologist who performed the Study, or the signed in user in our case). 3. Via a REST API, Orthanc can then update the tags and indexing at the Study Level and everyone might be happy. That is probably sort of what the MPPS does, but I'd have to
build that. This method would be easy to test, and in a low volume environment not too resource intensive.
BTW, kind or hard to do some of the MWL testing in a development environment without a scanner. I've tried using FINDSCU to simulate a worklist C-FIND request and that only partially works, and I've started to look around for something to emulate MPPS.
It is a little bit tricky with a live scanner, even if it isn't fully operational yet because the tech has
From Herman Oosterwijk@21:1/5 to All on Thu May 13 11:16:03 2021
BTW, kind or hard to do some of the MWL testing in a development environment without a scanner. I've tried using FINDSCU to simulate a worklist C-FIND request and that only partially works, and I've started to look around for something to emulate MPPS.
It is a little bit tricky with a live scanner, even if it isn't fully operational yet because the tech has
You can use DVTK as a modality worklist SCU simulator. Conquest also provides a simple MWL SCU. I do have a modality simulator but that is not free, you can contact me through linked in and I can get you more info.