Respuesta corta: DICOMweb es el conjunto de servicios web definidos en la Parte 18 del estándar DICOM. Expone un archivo DICOM a través de HTTPS simple: QIDO-RS (Query based on ID for DICOM Objects) busca estudios, series e instancias; WADO-RS (Web Access to DICOM Objects) los recupera, como archivos DICOM completos, como metadatos en JSON, o como imágenes JPEG/PNG renderizadas; STOW-RS (Store Over the Web) carga nuevos objetos. El antiguo WADO-URI recupera un objeto a través de parámetros de consulta. Los visores basados en navegador utilizan DICOMweb porque no pueden usar la red DICOM clásica.
DICOM clásico vs DICOMweb
La red DICOM clásica (partes 7 y 8 del estándar) utiliza un protocolo binario sobre TCP con servicios como C-FIND, C-MOVE, C-GET y C-STORE entre nodos configurados. DICOMweb (parte 18) mapea las mismas operaciones a HTTP: QIDO-RS para buscar, WADO-RS para recuperar y STOW-RS para almacenar, lo que funciona a través de Internet y desde navegadores.
El DICOM clásico (Parte 7 y 8) utiliza su propio protocolo binario sobre TCP con servicios nombrados: C-FIND para consultar, C-MOVE o C-GET para recuperar, C-STORE para enviar. Necesita una "asociación" configurada entre dos nodos conocidos (títulos AE, direcciones IP, puertos), lo cual funciona bien dentro de un hospital y es difícil a través de Internet. DICOMweb mapea las mismas ideas a HTTP:
| Tarea | DICOM clásico | DICOMweb |
|---|---|---|
| Buscar un estudio | C-FIND | QIDO-RS: GET /studies?PatientID=… |
| Recuperar un estudio | C-MOVE / C-GET | WADO-RS: GET /studies/{StudyInstanceUID} |
| Leer solo metadatos | C-FIND a nivel de instancia | WADO-RS: GET /studies/{uid}/metadata |
| Obtener una imagen visualizable | Recuperar y luego renderizar localmente | WADO-RS renderizado: GET …/instances/{uid}/rendered |
| Enviar imágenes a un archivo | C-STORE | STOW-RS: POST /studies |
| Gestionar listas de trabajo | MWL (C-FIND en una lista de trabajo) | UPS-RS |
La jerarquía de recursos sigue el propio modelo de DICOM: un estudio (una visita al escáner) contiene series (una adquisición cada una), que contienen instancias (imágenes individuales u objetos multiframe), cada una identificada por un UID único globalmente.
QIDO-RS: búsqueda
QIDO-RS es el servicio de búsqueda de DICOMweb. Un cliente envía GET /studies, /series o /instances con parámetros de consulta como PatientID, StudyDate o ModalitiesInStudy y la cabecera Accept application/dicom+json. El archivo devuelve una matriz JSON en la que cada atributo DICOM está identificado por su etiqueta de ocho dígitos junto con su representación de valor y sus valores.
GET /dicomweb/studies?PatientID=12345&StudyDate=20260101-20261231&ModalitiesInStudy=CT
Accept: application/dicom+json
La respuesta es un array JSON de estudios. Cada atributo está indexado por su etiqueta (grupo y elemento como ocho dígitos hexadecimales), con su representación de valor y 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]}
}]
Aquí 00201206 es Número de Series Relacionadas con el Estudio y 00201208 es Número de Instancias Relacionadas con el Estudio. Los números de etiqueta se explican en Etiquetas DICOM explicadas.
WADO-RS: recuperación
WADO-RS es el servicio de recuperación de DICOMweb. GET /studies/{StudyInstanceUID} devuelve un estudio completo como archivos DICOM Parte 10 en una respuesta multipart; el sufijo /metadata devuelve las cabeceras como JSON sin datos de píxeles; /frames/{n} devuelve los píxeles de un fotograma; y /rendered devuelve una imagen JPEG o PNG renderizada por el servidor con parámetros de ventana, vista y calidad.
GET /studies/{study}conAccept: multipart/related; type="application/dicom"devuelve cada instancia como un archivo DICOM Parte 10, una parte cada una.GET /studies/{study}/metadatadevuelve las cabeceras de todas las instancias como JSON, sin datos de píxeles. Los visores llaman a esto primero para construir el diseño, luego obtienen los píxeles cuadro por cuadro.GET /studies/{study}/series/{series}/instances/{instance}/frames/1devuelve los datos de píxeles de un cuadro, opcionalmente transcodificado (parámetrotransfer-syntax).GET …/instances/{instance}/renderedconAccept: image/jpegdevuelve una imagen renderizada por el servidor, con parámetroswindow,viewportyquality. Esto es lo que utiliza un portal de pacientes ligero para mostrar una vista previa.
STOW-RS: almacenamiento
STOW-RS es el servicio de almacenamiento de DICOMweb. Un cliente envía POST /studies con un cuerpo multipart/related en el que cada parte es un archivo DICOM. El archivo responde con una lista de instancias aceptadas y fallidas y el motivo de cada fallo, y comprueba que cualquier Study Instance UID dado en la URL coincida con los archivos cargados.
POST /dicomweb/studies
Content-Type: multipart/related; type="application/dicom"; boundary=abc
Cada parte es un archivo DICOM. La respuesta enumera las instancias aceptadas y fallidas con las razones (clase SOP incorrecta, UID duplicado). Los archivos validan que el Study Instance UID en la URL, si se proporciona, coincide con los archivos.
Seguridad
DICOMweb no tiene inicio de sesión propio; se basa en HTTPS y en lo que el servidor ponga delante: tokens de portador OAuth 2.0 en la mayoría de los archivos modernos, a menudo combinados con ámbitos SMART on FHIR cuando el visor se inicia desde un EHR. Registrar quién recuperó qué estudio es trabajo del archivo, no del protocolo.
Dónde se utiliza
Todos los principales PACS y archivos neutrales de proveedores ahora ofrecen un punto final DICOMweb, y los archivos de código abierto (Orthanc, dcm4chee, Google Cloud Healthcare API, Azure DICOM service) son DICOMweb primero. Los visores web como OHIF se construyen completamente sobre QIDO-RS y WADO-RS. En un mundo FHIR, un recurso ImagingStudy apunta a un punto final DICOMweb; los píxeles nunca pasan por FHIR.
Anpheros no almacena imágenes. El registro de un paciente puede contener el informe de radiología como un DocumentReference o DiagnosticReport y, donde un hospital lo proporciona, un enlace a su visor; los datos DICOM en sí permanecen en el archivo del hospital. Para obtener sus propias imágenes como paciente, consulte Cómo obtener sus imágenes de TC o RM.
Páginas relacionadas
- FHIR ImagingStudy vs DICOMweb
- Etiquetas DICOM explicadas
- PACS vs RIS vs VNA
- Cómo obtener sus imágenes de TC o RM (DICOM)
- Estándares de interoperabilidad sanitaria: el mapa
- DICOM vs FHIR para desarrolladores
Fuentes
- DICOM PS3.18: Servicios Web
- DICOM PS3.7: Intercambio de Mensajes
- Descripción general de DICOMweb (Comité de Estándares DICOM)
- Documentación de OHIF Viewer
Preguntas frecuentes
¿Es DICOMweb un estándar diferente de DICOM?
No. Es la Parte 18 del mismo estándar DICOM. Los objetos, etiquetas y UIDs son idénticos; solo el transporte cambia del protocolo propio de DICOM a HTTP.
¿Cuál es la diferencia entre WADO-URI y WADO-RS?
WADO-URI es el servicio más antiguo: un objeto por solicitud, seleccionado con parámetros de consulta (?requestType=WADO&studyUID=…). WADO-RS es RESTful, puede devolver estudios o series completos, metadatos como JSON y cuadros individuales, y es lo que implementan los nuevos sistemas.
¿Puedo usar DICOMweb sin un PACS?
Necesita algún archivo que lo implemente. Servidores de código abierto como Orthanc y dcm4chee proporcionan DICOMweb de fábrica y se utilizan comúnmente para desarrollo y para clínicas pequeñas.
¿Reemplaza FHIR a DICOMweb?
No. FHIR describe el estudio (ImagingStudy) y el informe (DiagnosticReport); DICOMweb entrega las imágenes. Un visor utiliza ambos: FHIR para saber que existe un estudio, DICOMweb para mostrarlo.
Pruébalo en Anpheros Daily
Guarda tus informes de escáner y pruebas en un solo lugar en Anpheros Daily, listos para mostrar en tu próxima visita.
Cómo funciona en la app →
Anpheros crea un historial médico que el paciente controla y puede compartir con cualquier clínica, en una plataforma HL7 FHIR R4, con sede en la UE. Estas guías te ayudan a entender y organizar tu salud; no reemplazan a tu médico.
Sobre Anpheros →