Rocksolid Light

Welcome to RetroBBS

mail  files  register  newsreader  groups  login

Message-ID:  

To the systems programmer, users and applications serve only to provide a test load.


devel / comp.protocols.dicom / Re: Question about MWL's and MPPS

SubjectAuthor
* Question about MWL's and MPPSStephen Douglas Scotti
`* Re: Question about MWL's and MPPSMarco Eichelberg
 `* Re: Question about MWL's and MPPSStephen Douglas Scotti
  `* Re: Question about MWL's and MPPSStephen Douglas Scotti
   `- Re: Question about MWL's and MPPSMarco Eichelberg

1
Question about MWL's and MPPS

<0dc0b1d6-7208-4e20-b1eb-f50c54f75f8dn@googlegroups.com>

  copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=399&group=comp.protocols.dicom#399

  copy link   Newsgroups: comp.protocols.dicom
X-Received: by 2002:a37:2f04:0:b0:663:397d:7051 with SMTP id v4-20020a372f04000000b00663397d7051mr8010714qkh.333.1649301938589;
Wed, 06 Apr 2022 20:25:38 -0700 (PDT)
X-Received: by 2002:a05:620a:1448:b0:67d:4057:ec80 with SMTP id
i8-20020a05620a144800b0067d4057ec80mr7800068qkl.563.1649301938374; Wed, 06
Apr 2022 20:25:38 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.protocols.dicom
Date: Wed, 6 Apr 2022 20:25:38 -0700 (PDT)
Injection-Info: google-groups.googlegroups.com; posting-host=66.253.168.220; posting-account=YFi_UAoAAACTPXmZqt1QuJHF4fLwCPfF
NNTP-Posting-Host: 66.253.168.220
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <0dc0b1d6-7208-4e20-b1eb-f50c54f75f8dn@googlegroups.com>
Subject: Question about MWL's and MPPS
From: stephen.d.scotti@gmail.com (Stephen Douglas Scotti)
Injection-Date: Thu, 07 Apr 2022 03:25:38 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 32
 by: Stephen Douglas Scot - Thu, 7 Apr 2022 03:25 UTC

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.

Re: Question about MWL's and MPPS

<06ee7757-671b-4024-a622-2c6c567feff6n@googlegroups.com>

  copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=401&group=comp.protocols.dicom#401

  copy link   Newsgroups: comp.protocols.dicom
X-Received: by 2002:a05:622a:148e:b0:2e2:2ebd:63d9 with SMTP id t14-20020a05622a148e00b002e22ebd63d9mr15066173qtx.601.1649397072602;
Thu, 07 Apr 2022 22:51:12 -0700 (PDT)
X-Received: by 2002:a05:620a:1081:b0:680:9e18:1d12 with SMTP id
g1-20020a05620a108100b006809e181d12mr11717463qkk.606.1649397072479; Thu, 07
Apr 2022 22:51:12 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.protocols.dicom
Date: Thu, 7 Apr 2022 22:51:12 -0700 (PDT)
In-Reply-To: <0dc0b1d6-7208-4e20-b1eb-f50c54f75f8dn@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=91.96.91.4; posting-account=3DmVbgoAAABFUuSdYzST0SJs6tjfL1mL
NNTP-Posting-Host: 91.96.91.4
References: <0dc0b1d6-7208-4e20-b1eb-f50c54f75f8dn@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <06ee7757-671b-4024-a622-2c6c567feff6n@googlegroups.com>
Subject: Re: Question about MWL's and MPPS
From: marco.eichelberg@googlemail.com (Marco Eichelberg)
Injection-Date: Fri, 08 Apr 2022 05:51:12 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 18
 by: Marco Eichelberg - Fri, 8 Apr 2022 05:51 UTC

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.

Re: Question about MWL's and MPPS

<53d149ad-401a-41c4-a813-8ac3d65dd1b3n@googlegroups.com>

  copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=402&group=comp.protocols.dicom#402

  copy link   Newsgroups: comp.protocols.dicom
X-Received: by 2002:a05:620a:993:b0:67b:1385:242a with SMTP id x19-20020a05620a099300b0067b1385242amr16621796qkx.14.1649517311839;
Sat, 09 Apr 2022 08:15:11 -0700 (PDT)
X-Received: by 2002:ac8:7dca:0:b0:2e1:db1b:7ba1 with SMTP id
c10-20020ac87dca000000b002e1db1b7ba1mr19777239qte.614.1649517311676; Sat, 09
Apr 2022 08:15:11 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.protocols.dicom
Date: Sat, 9 Apr 2022 08:15:11 -0700 (PDT)
In-Reply-To: <06ee7757-671b-4024-a622-2c6c567feff6n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=66.253.168.220; posting-account=YFi_UAoAAACTPXmZqt1QuJHF4fLwCPfF
NNTP-Posting-Host: 66.253.168.220
References: <0dc0b1d6-7208-4e20-b1eb-f50c54f75f8dn@googlegroups.com> <06ee7757-671b-4024-a622-2c6c567feff6n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <53d149ad-401a-41c4-a813-8ac3d65dd1b3n@googlegroups.com>
Subject: Re: Question about MWL's and MPPS
From: stephen.d.scotti@gmail.com (Stephen Douglas Scotti)
Injection-Date: Sat, 09 Apr 2022 15:15:11 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: Stephen Douglas Scot - Sat, 9 Apr 2022 15:15 UTC

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

Re: Question about MWL's and MPPS

<0ea26426-3abe-4d68-9bc3-6ce3d269c1a9n@googlegroups.com>

  copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=404&group=comp.protocols.dicom#404

  copy link   Newsgroups: comp.protocols.dicom
X-Received: by 2002:a37:308:0:b0:69b:37b8:6381 with SMTP id 8-20020a370308000000b0069b37b86381mr2723156qkd.367.1649764152720;
Tue, 12 Apr 2022 04:49:12 -0700 (PDT)
X-Received: by 2002:a9d:20e2:0:b0:5c9:2edb:af8e with SMTP id
x89-20020a9d20e2000000b005c92edbaf8emr13168658ota.325.1649764152442; Tue, 12
Apr 2022 04:49:12 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.protocols.dicom
Date: Tue, 12 Apr 2022 04:49:12 -0700 (PDT)
In-Reply-To: <53d149ad-401a-41c4-a813-8ac3d65dd1b3n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=66.253.168.220; posting-account=YFi_UAoAAACTPXmZqt1QuJHF4fLwCPfF
NNTP-Posting-Host: 66.253.168.220
References: <0dc0b1d6-7208-4e20-b1eb-f50c54f75f8dn@googlegroups.com>
<06ee7757-671b-4024-a622-2c6c567feff6n@googlegroups.com> <53d149ad-401a-41c4-a813-8ac3d65dd1b3n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <0ea26426-3abe-4d68-9bc3-6ce3d269c1a9n@googlegroups.com>
Subject: Re: Question about MWL's and MPPS
From: stephen.d.scotti@gmail.com (Stephen Douglas Scotti)
Injection-Date: Tue, 12 Apr 2022 11:49:12 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 198
 by: Stephen Douglas Scot - Tue, 12 Apr 2022 11:49 UTC

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:

# 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

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
(fffe,e0dd) na (SequenceDelimitationItem for re-encod.) # 0, 0 SequenceDelimitationItem

Re: Question about MWL's and MPPS

<52e78a54-c965-4168-9ec7-1e3f35f69142n@googlegroups.com>

  copy mid

https://www.rocksolidbbs.com/devel/article-flat.php?id=413&group=comp.protocols.dicom#413

  copy link   Newsgroups: comp.protocols.dicom
X-Received: by 2002:ad4:5642:0:b0:444:47e1:b244 with SMTP id bl2-20020ad45642000000b0044447e1b244mr10754832qvb.4.1650359055504;
Tue, 19 Apr 2022 02:04:15 -0700 (PDT)
X-Received: by 2002:ae9:e71a:0:b0:69e:a5f4:e5f2 with SMTP id
m26-20020ae9e71a000000b0069ea5f4e5f2mr4102351qka.662.1650359055294; Tue, 19
Apr 2022 02:04:15 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.protocols.dicom
Date: Tue, 19 Apr 2022 02:04:15 -0700 (PDT)
In-Reply-To: <0ea26426-3abe-4d68-9bc3-6ce3d269c1a9n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=91.96.94.160; posting-account=3DmVbgoAAABFUuSdYzST0SJs6tjfL1mL
NNTP-Posting-Host: 91.96.94.160
References: <0dc0b1d6-7208-4e20-b1eb-f50c54f75f8dn@googlegroups.com>
<06ee7757-671b-4024-a622-2c6c567feff6n@googlegroups.com> <53d149ad-401a-41c4-a813-8ac3d65dd1b3n@googlegroups.com>
<0ea26426-3abe-4d68-9bc3-6ce3d269c1a9n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <52e78a54-c965-4168-9ec7-1e3f35f69142n@googlegroups.com>
Subject: Re: Question about MWL's and MPPS
From: marco.eichelberg@googlemail.com (Marco Eichelberg)
Injection-Date: Tue, 19 Apr 2022 09:04:15 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 12
 by: Marco Eichelberg - Tue, 19 Apr 2022 09:04 UTC

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.

1
server_pubkey.txt

rocksolid light 0.9.8
clearnet tor