Черный ящик, тестирующий удаленный сервер DICOM Q / R

Мне интересно, пробовал ли кто-нибудь когда-нибудь работать над следующей проблемой. Мне нужно выполнить серию тестов на удаленном сервере DICOM Q / R. Это позволит легко проверить заявление о соответствии DICOM.

В качестве детали реализации набора тестов я выполняю следующее (команда в стиле DCMTK):

$ findscu --study --cancel 1 --key 0020,0010=* --key 8,52=STUDY --aetitle MINE --call THEIR dicom.example.com 11112

Цель здесь - найти действительный StudyID (позже я буду использовать этот StudyID для выполнения C-FIND нижнего ключевого уровня и некоторых связанных запросов C-MOVE). Конечно, было бы намного проще, если бы я мог загрузить свой собственный набор данных и попытаться получить его обратно, но я не могу сделать это против работающей системы PACS в клинической среде. Мне нужно определить с минимальным количеством запросов, как найти действительный StudyID.

Однако я опасаюсь, что в некоторых реализациях DICOM может быть policies, где запрещено запрашивать всю базу данных.

Поэтому мне было интересно, написал ли кто-нибудь список этих policies и, возможно, описал бы способ получения действительного StudyID с удаленного сервера с минимальным количеством запросов C-FIND.


dcmtk dicom
person malat    schedule 18.05.2014    source источник
comment
Удаленный сервер должен опубликовать собственное заявление о соответствии DICOM. Вы хотите полностью проверить их заявление о соответствии?   -  person Chris O    schedule 19.05.2014
comment
Что касается разрешений на запросы, если вы вообще можете делать запросы, почему тогда удаленный сервер может препятствовать выполнению запросов при определенных условиях? Обычно это просто так: AE TITLE MINE имеет разрешения на запросы или нет.   -  person Chris O    schedule 19.05.2014
comment
Обычно - это слово, мне просто нужно проверить, в этом весь смысл.   -  person malat    schedule 19.05.2014

Ответы (2)


arrow_upward
4
arrow_downward

Я думаю, что могу просто пойти с:

TODAY=`date +"%Y%m%d"`
findscu --study --key 0008,0020="$TODAY-" --key 0020,0010=* --key 8,52=STUDY --aetitle MINE --call THEIR dicom.example.com 11112

Если это не сработает (вернуть пусто), я проверю yesterday результатов.

person malat    schedule 18.05.2014
comment
Я согласен, выполнение запроса Today к базе данных и поиск действительных идентификаторов исследований - это лучший способ. Сервер PACS должен быть оптимизирован для выполнения этого типа запроса, результаты должны быть ограничены, и вы должны быть обязаны получить действительный ответ в результатах. - person Steve Wranovsky; 23.05.2014

arrow_upward
4
arrow_downward

Добро пожаловать в страну чудес DICOM.

Вы правы в том, что вам следует быть очень, очень, очень, очень осторожным, чтобы запускать просто случайные запросы в клинической PACS. Я видел, как коммерческие PAC-пакеты отправляли всю свою (!) Базу данных в результате непонятного запроса. Не очень красивое зрелище. Это (и конфиденциальность) является одной из причин того, что во многих больницах по всему миру администраторы PACS очень боятся предоставлять прямой доступ к своим PACS через DICOM.

В целом, я бы сказал, что стандартизация вам не поможет. Поэтому вам нужно найти что-то, что работает для вас, и что не приведет к отказу PACS. Никаких гарантий здесь нет.

Просто список наблюдений при запросе PACS в больницах:

  • Некоторые из них чувствительны к регистру при сопоставлении, некоторые - нет.
  • Большинство поддерживает какую-то подстановочную карту. Обычно это "*". но я также видел "%" (поскольку это подстановочный знак SQL, а запрос просто передается как строка SQL). Я думаю, это не совсем четкое определение.
  • Список, который вы получите обратно, может быть ограничен до первых 500 записей. Или 1000. Или случайное число от 500 до 1000. Или весь PACS. Вы просто не знаете.
  • DICOM и отмена не работают. Отмена запроса реализована плохо. Обычно PACS воспринимает это как неудачную передачу и повторяет попытку через некоторое время. И очередь повторных попыток ограничена по размеру, поэтому она может игнорировать новые запросы. Поэтому всегда позволяйте серверу STORE-SCP работать, чтобы опустошить эту очередь.
  • Иногда запросы занимают минуты, особенно на получение. В следующий раз его, возможно, извлекут (с ленты?) И какое-то время это будет быстро.
  • Запрос DICOM может занять много ресурсов от PACS, в зависимости от PACS. Не удивляйтесь, если появится администратор PACS, если вы слишком много поэкспериментируете.
  • Поддерживаемые запросы очень сильно различаются. Для всех поддерживаются только базовые запросы: список пациентов, список идентификаторов исследования / экземпляров исследования для пациентов, список серий для каждого исследования, получение исследования или серии. Если только у вас нет фанкового исследовательского отдела, который использует Osirix, который не поддерживает запросы уровня пациента, а только запросы уровня исследования.

Итак, что я бы посоветовал, если вы хотите, чтобы что-то работало на любой случайной PACS:

  • Используйте пустой-возврат-ключ вместо "*". Это способ получения информации DICOM.
  • Не используйте "-cancel". Если вам действительно нужно отменить, просто закройте TCP-соединение (не поддерживается в DCMTK).
  • Используйте запрос по PatientId, PatientName, Birthdate, StudyDate, чтобы получить список StudyID / StudyInstanceUids.

Самый простой - просто использовать фиксированный StudyID, предполагая, что он остается в PACS достаточно долго. Если нет, подумайте об ограничивающем запросе, чтобы не перегружать PACS (предложение «СЕГОДНЯ» о том, что вы соответствуете этому описанию).

Удачи!

person Rutger Nijlunsing    schedule 22.05.2014
comment
По закону StudyID может быть пустым, поэтому для переносимости необходимо использовать StudyInstanceUID. - person malat; 04.06.2014