#dicom #pydicom #pynetdicom
Вопрос:
Я работаю над SCP MPPS, как описано здесь: MPPS SCP как базовая структура.
Я смог немного протестировать его с помощью DVTk, с некоторыми инструментами, которые доступны здесь: DVTk
Большая часть из них, похоже, работает правильно, но проблема, с которой я, похоже, сталкиваюсь, заключается в том, что в ответе предполагается, что теги с группой 0000 возвращаются в «Наборе команд», а не в самом возвращаемом наборе данных: я действительно установил их в наборе данных, просто чтобы убедиться, что получаю правильные значения, например:
python_mpps_1 | (0000, 0000) Command Group Length ????
python_mpps_1 | (0000, 0002) Affected SOP Class UID UI: Modality Performed Procedure Step SOP Class
python_mpps_1 | (0000, 0100) Command Field US: 33088
python_mpps_1 | (0000, 0120) Message ID Being Responded To US: 2
python_mpps_1 | (0000, 0800) Command Data Set Type US: 0
python_mpps_1 | (0000, 0900) Status US: 0
python_mpps_1 | (0008, 0016) SOP Class UID UI: Modality Performed Procedure Step SOP Class
Я не совсем уверен, какой должна быть Длина группы команд, Поле команд и Тип набора данных команд, но, что более важно, я не знаю, как их правильно настроить. Я не думаю, что они должны быть установлены в наборе данных, но являются частью объекта набора команд для ответа N_CREATE:
# 'N-CREATE-RSP': (
# 'CommandGroupLength', 'AffectedSOPClassUID', 'CommandField',
# 'MessageIDBeingRespondedTo', 'CommandDataSetType', 'Status',
# 'AffectedSOPInstanceUID',
# 'ErrorID', 'ErrorComment'
# ),
Использование DVTk в качестве инструмента тестирования, MPPS.Сценарий SCU в их примерах сценариев, похоже, все работает, за исключением значений набора команд, которые не отправляются в ответе. Немного покопавшись, я думаю, что их нужно установить по-другому, но я не уверен, как это сделать.
В документации pynetdicom может быть дополнительная информация об этом (первая ссылка), но я не смог ее найти.
Комментарии:
1. Не могли бы вы опубликовать какой — нибудь код, воспроизводящий вашу проблему? pynetdicom должен автоматически устанавливать необходимые элементы набора команд
Ответ №1:
Это Command Group Length (0000,0000) общее количество байтов вашего двоичного кодированного сообщения. Обычно это должно быть установлено используемым вами инструментарием (см. Комментарий от Scaramillion).
Ваш тип команды-это N-CREATE ответ, и обычно он приходит без какого-либо набора данных. Не зная сценария DVT, я предполагаю, что ваш сценарий не ожидает, что набор данных будет присоединен к набору команд.
Т. е. SOP Class UID (0008, 0016) не должно присутствовать (оно уже является частью набора команд as Affected SOP Class UID (0000,0002) ), и Command Data Set Type (0000, 0800) должно быть установлено 0x0101 значение, указывающее, что набор данных не следует за набором команд.
По крайней мере, это имеет значение для успешной N-CREATE операции.
Комментарии:
1. Спасибо. Я думаю, что pynetdicom позаботится о наборе команд, как сказал скарамаллион. Мне придется проверить дальше, но я посмотрю. Что касается ответа, я на самом деле хочу немного изменить список attr_list, чтобы добавить некоторые элементы, которые отсутствуют в определенных ситуациях. Это связано с тем, что модальность не поддерживает заполнение всех желаемых тегов DICOM из MWL, но я могу сделать это из ответа MPPS. Я вижу, как это сделать, но это один из способов, которым можно использовать N_CREATE, чтобы слегка изменить список attr_list ?
2. Я отредактирую свой код дальше, снова протестирую и посмотрю, какой журнал снова создается в DVTk. Мне нужно будет посмотреть, сможет ли он захватить и зарегистрировать набор команд. Это хороший пакет, DVTk, даже несмотря на то, что он работает в Windows. По крайней мере, это бесплатно.
3. На самом деле, N-CREATE предназначен для SCU (Модальности), чтобы «объявить» атрибуты, которые будут установлены в сообщении N-SET. Поэтому я не вижу особой пользы в добавлении/изменении атрибутов в ответе N-CREATE. От ООП не ожидается какой-либо реакции на это в любом случае. Существует что-то вроде «принуждения атрибутов», применимого к MPPS-SCP, но это не включает отправку принудительных атрибутов обратно в SCU. То есть: для дальнейшей внутренней обработки вы можете делать все, что хотите (DICOM это не регулирует), но для связи я бы рекомендовал не отправлять дополнительные атрибуты обратно в SCU
4. Спасибо. Это полезно. Похоже, что основная цель MPPS тогда состоит в том, чтобы управлять рабочим списком, зная, когда исследование начато и когда оно завершено, а затем я могу внести изменения в исследование после отправки сообщения N_SET и выполнить некоторые базовые действия с точки зрения управления рабочими списками ? На самом деле я уже делаю что-то подобное на бэкэнде, изменяя экземпляры, когда это необходимо.
5. «принуждение атрибутов» — это на самом деле то, что меня интересует, потому что в некоторых случаях некоторые атрибуты либо будут отсутствовать (т. Е. сервер RIS или MWL был отключен), и техник может просто ввести идентификатор присоединения или базовый идентификатор, а затем исследование должно быть «исправлено», или, как в одном случае, модальность не заполняет исследование тегами, которые на самом деле находятся в файле MWL. Я так понимаю, как я «исправляю» теги, я должен обрабатывать в обработчике N_SET ?