Follow up from Previous Post re: MWL files and question about using own Root ID for StudyInstanceUID.

Google Groups archive
1

We have a couple of our own Root ID’s obtained from IANA of the form:

1.3.6.1.4.1.XXXXX, where XXXXX is our ID. We have the option of using our StudyInstanceUID generated by the RIS using that root ID, or the scanner can also apparently generate its own. We would prefer to use our root ID, but I was looking at the instances generated by the scanner when it uses our root ID and it has our root for the StudyInstanceUID and their root for all other UID’s, e.g. Just wondering if that is the normal expected behavior, or if there is some further configuration required if we want to use our root ID. I can reach out to the vendor as well. 1.3.76.2.1.1.4.1.3.5388 looks like their root ID.

(0020,000d) UI [1.3.6.1.4.1.xxxxx.1.xxxxx] # StudyInstanceUID
(0020,000e) UI [1.3.76.2.1.1.4.1.3.5388.670335607] # SeriesInstanceUID

MWL plug-in now seems to be working with .wl files created with a Python Plug-in from .txt template files. If anyone is using Esaote MRI equipment (G-scan for us), the following format seems to work with the C-Find from the Scanner. Everything populates appropriately now in the instances created by the scanner, including the Study Description.

Dicom-Data-Set

Used TransferSyntax: Little Endian Explicit

(0008,0005) CS [ISO_IR 192] # 10, 1 SpecificCharacterSet
(0008,0050) SH [DEVACC00000035] # 14, 1 AccessionNumber
(0008,0090) PN [0001:Last^First^^^] # 24, 1 ReferringPhysicianName
(0008,1030) LO [MRI BRAIN / BRAIN STEM - WITHOUT CONTRAST] # 42, 1 StudyDescription
(0008,1080) LO [BILLER HAS A HEADEACHE] # 22, 1 AdmittingDiagnosesDescription
(0010,0010) PN [QC^Esaote G-scan^] # 18, 1 PatientName
(0010,0020) LO [5388.668940371] # 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 [^^^^] # 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 [test] # 4, 1 AdditionalPatientHistory
(0010,4000) LT [PatientComments] # 16, 1 PatientComments
(0020,000d) UI [1.3.6.1.4.1.xxxxx.1.xxxxx] # 34, 1 StudyInstanceUID
(0032,1060) LO [MRI BRAIN / BRAIN STEM - WITHOUT CONTRAST] # 42, 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) # 206, 1 ScheduledProcedureStepSequence
(fffe,e000) na (Item with explicit length #=7) # 198, 1 Item
(0008,0060) CS [MR] # 2, 1 Modality
(0040,0001) AE [NmrEsaote] # 10, 1 ScheduledStationAETitle
(0040,0002) DA [20210429] # 8, 1 ScheduledProcedureStepStartDate
(0040,0003) TM [120000] # 6, 1 ScheduledProcedureStepStartTime
(0040,0007) LO [MRI BRAIN / BRAIN STEM - WITHOUT CONTRAST] # 42, 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 [0001] # 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 [0001]

2

Did a little more digging. Apparently, the scanner C-FIND request does not include: (0008,1030) LO (no value available) # 0, 0 StudyDescription,

and the “Normal” behavior for a MWL server is to return only the values that were requested in the C-FIND, so solutions would be to configure the acquisition device to query for all of the parameters that we want included in the response, or to configure Orthanc to return values that were not requested in the first place (probably a bad idea since the acquisition device might not like that). I’ll have to check the vendor and see if they can customize the C-FIND reqeusts to the MWL server.

Otherwise, perhaps there is a way to create a Lua script or to modify the MWL plug-in (static OrthancPlugins::FindMatcher* CreateMatcher), so that some configurable set of items is added to the MWL C-FIND requests coming from a particular acquisition device.

Used TransferSyntax: Little Endian Implicit

(0008,0050) SH (no value available) # 0, 0 AccessionNumber
(0008,0090) PN (no value available) # 0, 0 ReferringPhysicianName
(0008,1080) LO (no value available) # 0, 0 AdmittingDiagnosesDescription
(0008,1110) SQ (Sequence with explicit length #=0) # 0, 1 ReferencedStudySequence
(fffe,e0dd) na (SequenceDelimitationItem for re-encod.) # 0, 0 SequenceDelimitationItem
(0010,0010) PN (no value available) # 0, 0 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,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 (no value available) # 0, 0 AdditionalPatientHistory
(0010,4000) LT (no value available) # 0, 0 PatientComments
(0020,000d) UI (no value available) # 0, 0 StudyInstanceUID
(0032,1060) LO (no value available) # 0, 0 RequestedProcedureDescription
(0032,1064) SQ (Sequence with explicit length #=0) # 0, 1 RequestedProcedureCodeSequence
(fffe,e0dd) na (SequenceDelimitationItem for re-encod.) # 0, 0 SequenceDelimitationItem
(0040,0100) SQ (Sequence with undefined length #=1) # u/l, 1 ScheduledProcedureStepSequence
(fffe,e000) na (Item with undefined length #=7) # u/l, 1 Item
(0008,0060) CS [MR] # 2, 1 Modality
(0040,0001) AE [NmrEsaote] # 10, 1 ScheduledStationAETitle
(0040,0002) DA [20210426-20210426] # 18, 1 ScheduledProcedureStepStartDate
(0040,0003) TM (no value available) # 0, 0 ScheduledProcedureStepStartTime
(0040,0007) LO (no value available) # 0, 0 ScheduledProcedureStepDescription
(0040,0008) SQ (Sequence with explicit length #=0) # 0, 1 ScheduledProtocolCodeSequence
(fffe,e0dd) na (SequenceDelimitationItem for re-encod.) # 0, 0 SequenceDelimitationItem
(0040,0009) SH (no value available) # 0, 0 ScheduledProcedureStepID
(fffe,e00d) na (ItemDelimitationItem) # 0, 0 ItemDelimitationItem
(fffe,e0dd) na (SequenceDelimitationItem) # 0, 0 SequenceDelimitationItem
(0040,1001) SH (no value available) # 0, 0 RequestedProcedureID

3

I guess I’ll try this Lua script and modify it somewhat: https://book.orthanc-server.com/users/lua.html#fixing-c-find-requests

function IncomingWorklistRequestFilter(query, origin)
PrintRecursive(query)
PrintRecursive(origin)

– Implements the same behavior as the “FilterIssuerAet”
– option of the sample worklist plugin
query[‘0040,0100’][1][‘0040,0001’] = origin[‘RemoteAet’]

return query
end