Resposta curta: DICOMweb é o conjunto de serviços web definidos na Parte 18 do padrão DICOM. Expõe um arquivo DICOM através de HTTPS simples: QIDO-RS (Query based on ID for DICOM Objects) procura por estudos, séries e instâncias; WADO-RS (Web Access to DICOM Objects) recupera-os, como ficheiros DICOM completos, como metadados em JSON, ou como imagens JPEG/PNG renderizadas; STOW-RS (Store Over the Web) carrega novos objetos. O mais antigo WADO-URI recupera um objeto através de parâmetros de consulta. Visualizadores baseados em navegador usam DICOMweb porque não conseguem falar o protocolo DICOM clássico.
DICOM Clássico vs DICOMweb
A rede DICOM clássica (Partes 7 e 8 do standard) utiliza um protocolo binário sobre TCP com serviços como C-FIND, C-MOVE, C-GET e C-STORE entre nós configurados. O DICOMweb (Parte 18) mapeia as mesmas operações para HTTP: QIDO-RS para pesquisa, WADO-RS para recuperação e STOW-RS para armazenamento, o que funciona através da internet e a partir de navegadores.
O DICOM Clássico (Partes 7 e 8) usa o seu próprio protocolo binário sobre TCP com serviços nomeados: C-FIND para consultar, C-MOVE ou C-GET para recuperar, C-STORE para enviar. Necessita de uma "associação" configurada entre dois nós conhecidos (títulos AE, endereços IP, portas), o que funciona bem dentro de um hospital e é difícil através da internet. O DICOMweb mapeia as mesmas ideias para HTTP:
| Tarefa | DICOM Clássico | DICOMweb |
|---|---|---|
| Encontrar um estudo | C-FIND | QIDO-RS: GET /studies?PatientID=… |
| Recuperar um estudo | C-MOVE / C-GET | WADO-RS: GET /studies/{StudyInstanceUID} |
| Ler apenas metadados | C-FIND a nível de instância | WADO-RS: GET /studies/{uid}/metadata |
| Obter uma imagem visualizável | Recuperar e depois renderizar localmente | WADO-RS renderizado: GET …/instances/{uid}/rendered |
| Enviar imagens para um arquivo | C-STORE | STOW-RS: POST /studies |
| Gerir listas de trabalho | MWL (C-FIND numa lista de trabalho) | UPS-RS |
A hierarquia de recursos segue o próprio modelo do DICOM: um estudo (uma visita ao scanner) contém séries (uma aquisição cada), que contêm instâncias (imagens únicas ou objetos multiframes), cada uma identificada por um UID globalmente único.
QIDO-RS: pesquisa
QIDO-RS é o serviço de pesquisa DICOMweb. Um cliente envia GET /studies, /series ou /instances com parâmetros de consulta como PatientID, StudyDate ou ModalitiesInStudy e o cabeçalho Accept application/dicom+json. O arquivo retorna um array JSON em que cada atributo DICOM é identificado pela sua tag de oito dígitos juntamente com a sua representação de valor e valores.
GET /dicomweb/studies?PatientID=12345&StudyDate=20260101-20261231&ModalitiesInStudy=CT
Accept: application/dicom+json
A resposta é um array JSON de estudos. Cada atributo é indexado pela sua tag (grupo e elemento como oito dígitos hexadecimais), com a sua representação de valor e valores:
[{
"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]}
}]
Aqui 00201206 é Número de Séries Relacionadas com o Estudo e 00201208 é Número de Instâncias Relacionadas com o Estudo. Os números das tags são explicados em Tags DICOM explicadas.
WADO-RS: recuperação
WADO-RS é o serviço de recuperação DICOMweb. GET /studies/{StudyInstanceUID} retorna um estudo completo como ficheiros DICOM Parte 10 numa resposta multipart; o sufixo /metadata retorna cabeçalhos como JSON sem dados de píxeis; /frames/{n} retorna os píxeis de um frame; e /rendered retorna um JPEG ou PNG renderizado pelo servidor com parâmetros de janela, viewport e qualidade.
GET /studies/{study}comAccept: multipart/related; type="application/dicom"retorna cada instância como um ficheiro DICOM Parte 10, uma parte cada.GET /studies/{study}/metadataretorna os cabeçalhos de todas as instâncias como JSON, sem dados de pixel. Os visualizadores chamam isto primeiro para construir o layout, depois buscam os pixels frame a frame.GET /studies/{study}/series/{series}/instances/{instance}/frames/1retorna os dados de pixel de um frame, opcionalmente transcodificado (parâmetrotransfer-syntax).GET …/instances/{instance}/renderedcomAccept: image/jpegretorna uma imagem renderizada pelo servidor, com parâmetroswindow,viewportequality. É isto que um portal leve para pacientes usa para mostrar uma pré-visualização.
STOW-RS: armazenamento
STOW-RS é o serviço de armazenamento DICOMweb. Um cliente envia POST /studies com um corpo multipart/related em que cada parte é um ficheiro DICOM. O arquivo responde com uma lista de instâncias aceites e falhadas e a razão para cada falha, e verifica se qualquer Study Instance UID fornecido no URL corresponde aos ficheiros enviados.
POST /dicomweb/studies
Content-Type: multipart/related; type="application/dicom"; boundary=abc
Cada parte é um ficheiro DICOM. A resposta lista instâncias aceites e falhadas com razões (classe SOP errada, UID duplicado). Os arquivos validam que o Study Instance UID no URL, se fornecido, corresponde aos ficheiros.
Segurança
O DICOMweb não tem login próprio; depende do HTTPS e do que quer que o servidor coloque à frente: tokens de portador OAuth 2.0 na maioria dos arquivos modernos, muitas vezes combinados com escopos SMART on FHIR quando o visualizador é lançado a partir de um EHR. O registo de quem recuperou qual estudo é trabalho do arquivo, não do protocolo.
Onde é usado
Todos os principais PACS e arquivos neutros de fornecedor oferecem agora um endpoint DICOMweb, e arquivos de código aberto (Orthanc, dcm4chee, Google Cloud Healthcare API, Azure DICOM service) são DICOMweb-first. Visualizadores web como o OHIF são construídos inteiramente em QIDO-RS e WADO-RS. Num mundo FHIR, um recurso ImagingStudy aponta para um endpoint DICOMweb; os pixels nunca passam pelo FHIR.
A Anpheros não armazena imagens. O registo de um paciente pode conter o relatório de radiologia como um DocumentReference ou DiagnosticReport e, onde um hospital o fornece, um link para o seu visualizador; os dados DICOM em si permanecem no arquivo do hospital. Para obter as suas próprias imagens como paciente, veja Como obter as suas imagens de TC ou RM.
Páginas relacionadas
- FHIR ImagingStudy vs DICOMweb
- Tags DICOM explicadas
- PACS vs RIS vs VNA
- Como obter as suas imagens de TC ou RM (DICOM)
- Padrões de interoperabilidade em saúde: o mapa
- DICOM vs FHIR para programadores
Fontes
- DICOM PS3.18: Web Services
- DICOM PS3.7: Message Exchange
- Visão geral do DICOMweb (DICOM Standards Committee)
- Documentação do OHIF Viewer
Perguntas frequentes
O DICOMweb é um padrão diferente do DICOM?
Não. É a Parte 18 do mesmo padrão DICOM. Os objetos, tags e UIDs são idênticos; apenas o transporte muda do protocolo próprio do DICOM para HTTP.
Qual é a diferença entre WADO-URI e WADO-RS?
WADO-URI é o serviço mais antigo: um objeto por pedido, selecionado com parâmetros de consulta (?requestType=WADO&studyUID=…). WADO-RS é RESTful, pode retornar estudos ou séries inteiros, metadados como JSON e frames individuais, e é o que os novos sistemas implementam.
Posso usar DICOMweb sem um PACS?
Precisa de algum arquivo que o implemente. Servidores de código aberto como Orthanc e dcm4chee fornecem DICOMweb pronto a usar e são comumente usados para desenvolvimento e para pequenas clínicas.
O FHIR substitui o DICOMweb?
Não. O FHIR descreve o estudo (ImagingStudy) e o relatório (DiagnosticReport); o DICOMweb entrega as imagens. Um visualizador usa ambos: FHIR para saber que um estudo existe, DICOMweb para o mostrar.
Experimente no Anpheros Daily
Guarde os seus relatórios de exames e análises num só local no Anpheros Daily, prontos para mostrar na sua próxima consulta.
Como funciona na app →
A Anpheros desenvolve um registo médico que o doente controla e pode partilhar com qualquer clínica, numa plataforma HL7 FHIR R4, sediada na UE. Estes guias ajudam-no a compreender e organizar a sua saúde; não substituem o seu médico.
Sobre a Anpheros →