DICOM Query/Retrieve объединяет поиск сохранённых исследований и получение их объектов. Для врача это часто выглядит как одно действие: найти пациента и открыть снимки. Для инженера здесь несколько отдельных процессов, и каждый может завершиться по-разному. Исследование способно появляться в результатах поиска, но не загружаться на рабочую станцию. Обратная ситуация тоже возможна: данные есть в архиве, однако выбранный запрос не находит их из-за идентификаторов, уровня поиска или фильтров.
Что означает найденное исследование
Поиск возвращает сведения о подходящих объектах, а не автоматически весь набор пиксельных данных. Его результат удобнее рассматривать как каталог архива. Получение — следующий этап, на котором запрашиваются сами экземпляры. Поэтому успешный поиск ещё не подтверждает работоспособность маршрута изображений, поддержку всех форматов или право выбранного пользователя на просмотр.
В классическом DICOM-обмене для поиска используется C-FIND, а для получения могут применяться C-MOVE или C-GET. Наличие этих названий в техническом предложении нужно расшифровать: какие информационные модели поддерживаются, на каких уровнях разрешён запрос, как настроены роли участников и какие типы объектов доступны. Поддержка протокола одной стороной не означает совместимость конкретной пары систем во всех сценариях.
| Этап | Пример вопроса системе | Ожидаемый результат проверки |
|---|---|---|
| Поиск исследования | Какие исследования соответствуют выбранному идентификатору и периоду? | Список с нужными атрибутами и без смешения пациентов |
| Поиск серий | Какие серии входят в выбранное исследование? | Полный ожидаемый состав и корректные идентификаторы |
| Получение объектов | Передать выбранные экземпляры получателю | Подтверждённая передача предусмотренного набора |
| Отображение | Открыть изображения и дополнительные объекты | Рабочая станция корректно интерпретирует содержимое |
| Повторное получение | Получить тот же набор после перезапуска клиента | Сохраняется воспроизводимый маршрут без неуправляемых дублей |
Разница между C-MOVE и C-GET
При C-MOVE инициатор поручает архиву отправить объекты указанному получателю. Данные передаются операциями C-STORE в отдельной ассоциации. Получателем может быть как инициатор запроса, так и другая система. Название MOVE не следует понимать как удаление оригинала из архива: речь идёт о механизме получения через передачу объектов.
При C-GET получателем служит сам инициатор. Подоперации C-STORE выполняются в той же ассоциации, что и запрос получения. Это различие влияет на согласование ролей и сетевой маршрут. Оно не делает один вариант автоматически лучше другого: пригодность определяется поддержкой устройств, архитектурой сети и документированным рабочим процессом.
Практическое следствие для диагностики простое. Если C-MOVE не доставляет изображения, необходимо проверить не только связь рабочей станции с архивом, но и маршрут от архива к получателю. Если система использует C-GET, внимание уделяют согласованным ролям и поддерживаемым классам хранения в общей ассоциации. Проверка доступности одного адреса не заменяет анализ полного обмена.
| Признак | C-MOVE | C-GET |
|---|---|---|
| Куда поступают объекты | На указанное назначение Move Destination | Инициатору запроса |
| Ассоциация передачи | Отдельная от ассоциации запроса | Та же, в которой выполняется запрос |
| Что проверить в конфигурации | Соответствие назначения реальному получателю и обратный маршрут | Согласование ролей и поддерживаемых объектов |
| Типичная ошибка ожидания | Считать успешный запрос доказательством успешной доставки | Считать единственную ассоциацию гарантией любой совместимости |
| Критерий приёмки | Получатель получил и открыл полный тестовый набор | Инициатор получил и открыл полный тестовый набор |
Идентификаторы и уровни поиска
Человеческое имя удобно для оператора, но недостаточно для однозначного машинного сопоставления. Важны идентификатор пациента и контекст его выдачи, а для выбранных исследований и серий — соответствующие UID. В организации с несколькими источниками регистрации одинаковые номера пациентов могут относиться к разным людям. Поэтому сценарий проверки должен включать заранее подготовленные тестовые записи, которые выявляют неоднозначность, а не только одну уникальную фамилию.
Поиск по пациенту, исследованию, серии и экземпляру отвечает на разные вопросы. Ошибка уровня может создать впечатление отсутствия данных: запрос требует один тип ключа, а интерфейс передаёт другой. Дополнительно влияют даты, модальность, локальные фильтры и правила отображения завершённых процедур. Эти условия следует записывать вместе с результатом теста, иначе повторить его после обновления будет трудно.
У веб-служб DICOM есть собственные операции поиска и получения. Например, Search Transaction в PS3.18 описывает поиск исследований, серий и экземпляров с возвращением метаданных. Нельзя переносить настройки DIMSE на веб-интерфейс по аналогии: адреса, авторизация и согласование представления данных отличаются. В спецификации интеграции нужно прямо назвать используемый механизм.
Разбор: список исследований есть, изображения не приходят
В условном тесте рабочая станция успешно находит исследование и отправляет C-MOVE. Архив принимает запрос, но файлы у получателя не появляются. Этот результат показывает, что часть коммуникации работает. Он не доказывает, что исправна отдельная передача от архива к рабочей станции.
Последовательный разбор начинается с сопоставления назначения запроса и реальной станции. Затем проверяют, начал ли архив подоперации передачи, какие статусы они получили и поддержал ли получатель требуемый класс объектов. Если отказ относится к определённому типу данных, общий сетевой ремонт не решит несовместимость. Если передача вообще не начинается, сначала выясняют причину на уровне задания и назначения.
После исправления проверяют не только одну картинку. Тестовый набор должен представлять типичные исследования отделения: несколько серий, многокадровые объекты, отчёты или другие реально используемые данные. Выбор набора — часть инженерного плана. В рабочей клинической среде диагностические действия согласуют так, чтобы испытания не изменяли записи пациентов и не нарушали текущий просмотр.
Разбор: на двух станциях получен разный состав
Во втором условном примере одна станция открывает все серии, а другая только основные изображения. Одинаковый заголовок исследования создаёт ложное ощущение равенства результата. Для проверки составляют перечень ожидаемых экземпляров и сравнивают его с фактическим получением на каждой стороне. Число видимых вкладок недостаточно: разные программы по-разному группируют объекты.
Если переданы все объекты, но часть не отображается, разбирают поддержку просмотра. Если архив не отправил часть данных, исследуют выбор уровня и фильтры запроса. Если передача была отклонена, смотрят согласованные классы и синтаксисы передачи. Разделение этих трёх вариантов позволяет адресовать вопрос нужному специалисту и избежать повторного импорта одного исследования без понимания причины.
Протокол испытаний Query/Retrieve
| Проверка | Что включить в тест | Как фиксировать результат |
|---|---|---|
| Точность поиска | Несколько пациентов, даты и разные идентификаторы | Входные условия и ожидаемый список |
| Полнота получения | Набор разных серий и типов объектов | Сопоставление UID, а не только количества файлов |
| Совместимость просмотра | Изображения, измерения и дополнительные документы | Отдельный результат для каждого поддерживаемого вида |
| Частичная ошибка | Согласованный негативный сценарий на стенде | Статус, причина и поведение повторной операции |
| Производительность | Типичный и крупный тестовый набор при оговорённой нагрузке | Время поиска, начала передачи и полного открытия отдельно |
| Изменение конфигурации | Повтор теста после согласованного обновления | Версии систем и различия с исходным протоколом |
Хороший протокол описывает не абстрактную «поддержку DICOM», а конкретную цепочку: кто ищет, по каким ключам, у кого, что получает и чем проверяется полнота. Время открытия также лучше разделять на ожидание ответа, передачу и обработку на станции. Тогда медленная работа не будет автоматически приписана каналу связи, если задержка возникает при реконструкции или визуализации уже полученных данных.
При эксплуатации полезно сохранять контрольный обезличенный набор с известным составом. Он позволяет повторить проверку после замены станции, обновления PACS или изменения сетевого сегмента. Результат сравнивают с документированным эталонным поведением системы, а обнаруженные отклонения связывают с определённым этапом обмена. Это делает проверку предметной и воспроизводимой.