간단 요약: DICOMweb은 DICOM 표준의 Part 18에 정의된 웹 서비스 모음입니다. 일반 HTTPS를 통해 DICOM 아카이브를 제공합니다. 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는 쿼리 매개변수를 통해 단일 객체를 검색합니다. 브라우저 기반 뷰어는 클래식 DICOM 네트워킹을 사용할 수 없기 때문에 DICOMweb을 사용합니다.
클래식 DICOM vs DICOMweb
표준의 7부와 8부에 해당하는 클래식 DICOM 네트워킹은 구성된 노드 간에 C-FIND, C-MOVE, C-GET, C-STORE와 같은 서비스를 TCP를 통해 바이너리 프로토콜로 사용합니다. DICOMweb(18부)은 동일한 작업을 HTTP에 매핑합니다. 즉, 검색을 위해 QIDO-RS, 검색을 위해 WADO-RS, 저장을 위해 STOW-RS를 사용하며, 이는 인터넷 및 브라우저에서 작동합니다.
클래식 DICOM(Part 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 검색 서비스입니다. 클라이언트는 PatientID, StudyDate 또는 ModalitiesInStudy와 같은 쿼리 매개변수 및 Accept 헤더 application/dicom+json을 사용하여 GET /studies, /series 또는 /instances를 보냅니다. 아카이브는 각 DICOM 속성이 8자리 태그와 값 표현 및 값으로 키가 지정된 JSON 배열을 반환합니다.
GET /dicomweb/studies?PatientID=12345&StudyDate=20260101-20261231&ModalitiesInStudy=CT
Accept: application/dicom+json
응답은 연구의 JSON 배열입니다. 각 속성은 태그(그룹 및 요소, 8자리 16진수)를 키로 하고, 값 표현 및 값을 포함합니다.
[{
"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은 Number of Study Related Series이고 00201208은 Number of Study Related Instances입니다. 태그 번호는 DICOM 태그 설명에서 설명합니다.
WADO-RS: 검색
WADO-RS는 DICOMweb 검색 서비스입니다. GET /studies/{StudyInstanceUID}는 멀티파트 응답으로 전체 연구를 DICOM 18부 파일로 반환합니다. /metadata 접미사는 픽셀 데이터 없이 JSON으로 헤더를 반환합니다. /frames/{n}은 프레임 하나를 픽셀로 반환하고, /rendered는 창, 뷰포트 및 품질 매개변수를 사용하여 서버에서 렌더링된 JPEG 또는 PNG를 반환합니다.
Accept: multipart/related; type="application/dicom"과 함께GET /studies/{study}는 각 파트마다 DICOM Part 10 파일로 모든 인스턴스를 반환합니다.GET /studies/{study}/metadata는 픽셀 데이터 없이 모든 인스턴스의 헤더를 JSON으로 반환합니다. 뷰어는 레이아웃을 구축하기 위해 이를 먼저 호출한 다음 프레임별로 픽셀을 가져옵니다.GET /studies/{study}/series/{series}/instances/{instance}/frames/1은 선택적으로 트랜스코딩된(transfer-syntax매개변수) 단일 프레임의 픽셀 데이터를 반환합니다.Accept: image/jpeg와 함께GET …/instances/{instance}/rendered는window,viewport및quality매개변수를 사용하여 서버에서 렌더링된 이미지를 반환합니다. 이는 경량 환자 포털에서 미리보기를 표시하는 데 사용됩니다.
STOW-RS: 저장
STOW-RS는 DICOMweb 저장 서비스입니다. 클라이언트는 각 부분이 하나의 DICOM 파일인 멀티파트/관련 본문을 사용하여 POST /studies를 보냅니다. 아카이브는 수락된 인스턴스와 실패한 인스턴스 목록 및 각 실패 이유를 회신하고 URL에 제공된 Study Instance UID가 업로드된 파일과 일치하는지 확인합니다.
POST /dicomweb/studies
Content-Type: multipart/related; type="application/dicom"; boundary=abc
각 파트는 하나의 DICOM 파일입니다. 응답은 이유(잘못된 SOP 클래스, 중복 UID)와 함께 수락된 인스턴스와 실패한 인스턴스를 나열합니다. 아카이브는 URL의 Study Instance UID가 파일과 일치하는지 확인합니다(제공된 경우).
보안
DICOMweb은 자체 로그인이 없으며 HTTPS와 서버가 앞에 두는 모든 것에 의존합니다. 대부분의 최신 아카이브에서는 OAuth 2.0 베어러 토큰을 사용하며, 뷰어가 EHR에서 시작될 때는 SMART on FHIR 범위와 결합되는 경우가 많습니다. 어떤 사람이 어떤 연구를 검색했는지 기록하는 것은 프로토콜의 작업이 아니라 아카이브의 작업입니다.
사용되는 곳
모든 주요 PACS 및 벤더 중립 아카이브는 이제 DICOMweb 엔드포인트를 제공하며, 오픈 소스 아카이브(Orthanc, dcm4chee, Google Cloud Healthcare API, Azure DICOM 서비스)는 DICOMweb 우선입니다. OHIF와 같은 웹 뷰어는 QIDO-RS 및 WADO-RS를 기반으로 완전히 구축됩니다. FHIR 환경에서는 ImagingStudy 리소스가 DICOMweb 엔드포인트를 가리킵니다. 픽셀은 FHIR을 통해 전달되지 않습니다.
Anpheros는 이미지를 저장하지 않습니다. 환자의 기록에는 DocumentReference 또는 DiagnosticReport로 방사선 보고서가 포함될 수 있으며, 병원에서 제공하는 경우 해당 뷰어에 대한 링크가 포함될 수 있습니다. DICOM 데이터 자체는 병원 아카이브에 남아 있습니다. 환자로서 자신의 이미지를 얻는 방법에 대해서는 CT 또는 MRI 이미지 얻는 방법을 참조하십시오.
관련 페이지
- FHIR ImagingStudy vs DICOMweb
- DICOM 태그 설명
- PACS vs RIS vs VNA
- CT 또는 MRI 이미지 얻는 방법 (DICOM)
- 의료 상호 운용성 표준: 지도
- 개발자를 위한 DICOM vs FHIR
출처
자주 묻는 질문
DICOMweb은 DICOM과 다른 표준인가요?
아니요. 동일한 DICOM 표준의 Part 18입니다. 객체, 태그 및 UID는 동일하며, 전송 방식만 DICOM 자체 프로토콜에서 HTTP로 변경됩니다.
WADO-URI와 WADO-RS의 차이점은 무엇인가요?
WADO-URI는 이전 서비스입니다. 요청당 하나의 객체를 쿼리 매개변수(?requestType=WADO&studyUID=…)로 선택합니다. WADO-RS는 RESTful이며 전체 연구 또는 시리즈, JSON 형식의 메타데이터 및 개별 프레임을 반환할 수 있으며 새로운 시스템에서 구현됩니다.
PACS 없이 DICOMweb을 사용할 수 있나요?
구현하는 아카이브가 필요합니다. Orthanc 및 dcm4chee와 같은 오픈 소스 서버는 즉시 DICOMweb을 제공하며 개발 및 소규모 클리닉에서 일반적으로 사용됩니다.
FHIR이 DICOMweb을 대체하나요?
아니요. FHIR은 연구(ImagingStudy)와 보고서(DiagnosticReport)를 설명하고, DICOMweb은 이미지를 전달합니다. 뷰어는 둘 다 사용합니다. FHIR은 연구가 존재한다는 것을 알기 위해 사용하고, DICOMweb은 연구를 표시하기 위해 사용합니다.
Anpheros Daily에서 사용해 보세요
검사 및 진단 보고서를 Anpheros Daily의 한 곳에 보관하고 다음 진료 시 보여줄 준비를 하세요.
앱에서 작동 방식 →
Anpheros는 환자가 직접 관리하고 어떤 병원과도 공유할 수 있는 의료 기록을 EU 기반의 HL7 FHIR R4 플랫폼에서 구축합니다. 이 가이드들은 건강 정보를 이해하고 정리하는 데 도움을 드리며, 의사의 진료를 대체하지 않습니다.
Anpheros 소개 →