Коротка відповідь: 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 у відповіді multipart; суфікс /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, готові показати на наступному прийомі.
Як це працює в додатку →
Anpheros створює медичну карту, яку пацієнт контролює та може ділитися з будь-якою клінікою, на платформі HL7 FHIR R4, розташованій в ЄС. Ці посібники допоможуть вам зрозуміти та організувати своє здоров'я; вони не замінюють вашого лікаря.
Про Anpheros →