Визуализация

DICOMweb: QIDO-RS, WADO-RS и STOW-RS простыми словами

DICOMweb — это REST-интерфейс стандарта DICOM. QIDO-RS помогает искать исследования, WADO-RS — получать изображения и метаданные, а STOW-RS — сохранять их. Мы расскажем, как формируются URL-адреса, как выглядит JSON, чем это отличается от классических сетевых протоколов DICOM и что на самом деле вызывает веб-просмотрщик.

автор Опубликовано 5 мин чтения

Краткий ответ: DICOMweb — это набор веб-сервисов, определенных в Части 18 стандарта DICOM. Он предоставляет доступ к архиву DICOM через обычный HTTPS: QIDO-RS (Query based on ID for DICOM Objects) ищет исследования, серии и объекты; WADO-RS (Web Access to DICOM Objects) извлекает их в виде полных файлов DICOM, метаданных в формате JSON или в виде отрисованных изображений JPEG/PNG; STOW-RS (Store Over the Web) загружает новые объекты. Более старый WADO-URI извлекает один объект с помощью параметров запроса. Браузерные просмотрщики используют DICOMweb, потому что они не могут работать с классическим сетевым протоколом DICOM.

Классический DICOM против DICOMweb

Классическая DICOM-сеть (части 7 и 8 стандарта) использует бинарный протокол поверх TCP с такими службами, как C-FIND, C-MOVE, C-GET и C-STORE между настроенными узлами. DICOMweb (часть 18) отображает те же операции на HTTP: QIDO-RS для поиска, WADO-RS для извлечения и STOW-RS для сохранения, что работает через интернет и из браузеров.

Классический DICOM (Части 7 и 8) использует собственный бинарный протокол поверх TCP с именованными службами: C-FIND для запросов, C-MOVE или C-GET для извлечения, C-STORE для отправки. Он требует настроенной "ассоциации" между двумя известными узлами (названия AE, IP-адреса, порты), что удобно внутри больницы, но сложно в интернете. DICOMweb отображает те же идеи на HTTP:

Задача Классический DICOM DICOMweb
Поиск исследования C-FIND QIDO-RS: GET /studies?PatientID=…
Извлечение исследования C-MOVE / C-GET WADO-RS: GET /studies/{StudyInstanceUID}
Чтение только метаданных C-FIND на уровне объекта WADO-RS: GET /studies/{uid}/metadata
Получение просматриваемого изображения извлечь, затем отрисовать локально WADO-RS отрисованное: GET …/instances/{uid}/rendered
Отправка изображений в архив C-STORE STOW-RS: POST /studies
Управление рабочими списками MWL (C-FIND по рабочему списку) UPS-RS

Иерархия ресурсов следует собственной модели DICOM: исследование (один визит к сканеру) содержит серии (каждое отдельное получение данных), которые содержат объекты (отдельные изображения или многокадровые объекты), каждый из которых идентифицируется глобально уникальным UID.

QIDO-RS: поиск

QIDO-RS — это служба поиска DICOMweb. Клиент отправляет GET /studies, /series или /instances с такими параметрами запроса, как PatientID, StudyDate или ModalitiesInStudy, и заголовком Accept application/dicom+json. Архив возвращает JSON-массив, в котором каждый DICOM-атрибут имеет ключ, соответствующий его восьмизначному тегу, вместе с его представлением значения и значениями.

GET /dicomweb/studies?PatientID=12345&StudyDate=20260101-20261231&ModalitiesInStudy=CT
Accept: application/dicom+json

Ответом является массив JSON с исследованиями. Каждый атрибут имеет ключ, соответствующий его тегу (группа и элемент в виде восьми шестнадцатеричных цифр), с его представлением значения и значениями:

[{
  "00080020": {"vr": "DA", "Value": ["20260314"]},
  "00080060": {"vr": "CS", "Value": ["CT"]},
  "00100010": {"vr": "PN", "Value": [{"Alphabetic": "DOE^JANE"}]},
  "0020000D": {"vr": "UI", "Value": ["1.2.840.113619.2.55.3.2831164356.781.1710415000.1"]},
  "00201206": {"vr": "IS", "Value": [3]},
  "00201208": {"vr": "IS", "Value": [412]}
}]

Здесь 00201206 — это количество связанных с исследованием серий, а 00201208 — количество связанных с исследованием объектов. Номера тегов объясняются в Объяснение тегов DICOM.

WADO-RS: извлечение

WADO-RS — это служба извлечения DICOMweb. GET /studies/{StudyInstanceUID} возвращает все исследование в виде файлов DICOM Part 10 в многокомпонентном ответе; суффикс /metadata возвращает заголовки в формате JSON без пиксельных данных; /frames/{n} возвращает пиксели одного кадра; а /rendered возвращает отрисованное сервером изображение JPEG или PNG с параметрами окна, области просмотра и качества.

  • GET /studies/{study} с Accept: multipart/related; type="application/dicom" возвращает каждый объект в виде файла DICOM Part 10, по одной части на каждый.
  • GET /studies/{study}/metadata возвращает заголовки всех объектов в виде JSON, без пиксельных данных. Просмотрщики вызывают это сначала, чтобы построить макет, а затем загружают пиксели кадр за кадром.
  • GET /studies/{study}/series/{series}/instances/{instance}/frames/1 возвращает пиксельные данные одного кадра, опционально транскодированные (параметр transfer-syntax).
  • GET …/instances/{instance}/rendered с Accept: image/jpeg возвращает отрисованное сервером изображение с параметрами window, viewport и quality. Это то, что использует легкий пациентский портал для отображения предварительного просмотра.

STOW-RS: сохранение

STOW-RS — это служба хранения DICOMweb. Клиент отправляет POST /studies с телом multipart/related, в котором каждая часть представляет собой один файл DICOM. Архив отвечает списком принятых и отклоненных экземпляров и причиной каждого сбоя, а также проверяет, соответствует ли любой Study Instance UID, указанный в URL, загруженным файлам.

POST /dicomweb/studies
Content-Type: multipart/related; type="application/dicom"; boundary=abc

Каждая часть — это один файл DICOM. Ответ содержит список принятых и отклоненных объектов с причинами (неправильный класс SOP, дубликат UID). Архивы проверяют, соответствует ли Study Instance UID в URL, если он указан, файлам.

Безопасность

DICOMweb не имеет собственного механизма входа; он полагается на HTTPS и все, что сервер ставит перед ним: токены-носители OAuth 2.0 в большинстве современных архивов, часто в сочетании со скоупами SMART on FHIR при запуске просмотрщика из EHR. Регистрация того, кто и какой объект извлек, является задачей архива, а не протокола.

Где это используется

Каждый крупный PACS и нейтральный архив поставщика теперь предлагает конечную точку DICOMweb, а архивы с открытым исходным кодом (Orthanc, dcm4chee, Google Cloud Healthcare API, Azure DICOM service) в первую очередь ориентированы на DICOMweb. Веб-просмотрщики, такие как OHIF, полностью построены на QIDO-RS и WADO-RS. В мире FHIR ресурс ImagingStudy указывает на конечную точку DICOMweb; пиксели никогда не проходят через FHIR.

Anpheros не хранит изображения. Запись пациента может содержать радиологический отчет в виде DocumentReference или DiagnosticReport и, если больница предоставляет ссылку, ссылку на свой просмотрщик; сами данные DICOM остаются в архиве больницы. Чтобы получить свои изображения в качестве пациента, см. Как получить свои снимки КТ или МРТ.

Связанные страницы

Источники

Частые вопросы

Является ли DICOMweb отдельным стандартом от DICOM?

Нет. Это Часть 18 того же стандарта DICOM. Объекты, теги и UID идентичны; меняется только транспорт с собственного протокола DICOM на HTTP.

В чем разница между WADO-URI и WADO-RS?

WADO-URI — это более старый сервис: один объект на запрос, выбираемый с помощью параметров запроса (?requestType=WADO&studyUID=…). WADO-RS является RESTful, может возвращать целые исследования или серии, метаданные в формате JSON и отдельные кадры, и именно его реализуют новые системы.

Могу ли я использовать DICOMweb без PACS?

Вам нужен архив, который его реализует. Серверы с открытым исходным кодом, такие как Orthanc и dcm4chee, предоставляют DICOMweb "из коробки" и часто используются для разработки и в небольших клиниках.

Заменяет ли FHIR DICOMweb?

Нет. FHIR описывает исследование (ImagingStudy) и отчет (DiagnosticReport); DICOMweb доставляет изображения. Просмотрщик использует оба: FHIR, чтобы узнать о существовании исследования, и DICOMweb, чтобы его отобразить.

Anpheros Daily

Попробуйте в Anpheros Daily

Храните результаты своих обследований и тестов в одном месте в Anpheros Daily, готовые к показу на следующем приеме.

Как это работает в приложении →
Это руководство носит информационный характер и не заменяет консультацию врача. Решения о своём здоровье принимайте вместе с врачом. В экстренной ситуации звоните по местному номеру экстренной помощи (112 в Европе).
Автор
Команда Anpheros

Anpheros создает медицинскую карту, которую пациент контролирует и может делиться с любой клиникой, на платформе HL7 FHIR R4, базирующейся в ЕС. Эти руководства помогут вам понять и организовать свое здоровье; они не заменяют вашего врача.

О Anpheros →