Краткий ответ: 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 остаются в архиве больницы. Чтобы получить свои изображения в качестве пациента, см. Как получить свои снимки КТ или МРТ.
Связанные страницы
- FHIR ImagingStudy против DICOMweb
- Объяснение тегов DICOM
- PACS против RIS против VNA
- Как получить свои снимки КТ или МРТ (DICOM)
- Стандарты медицинской совместимости: карта
- DICOM против FHIR для разработчиков
Источники
- DICOM PS3.18: Веб-сервисы
- DICOM PS3.7: Обмен сообщениями
- Обзор DICOMweb (Комитет по стандартам DICOM)
- Документация OHIF Viewer
Частые вопросы
Является ли 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, готовые к показу на следующем приеме.
Как это работает в приложении →
