Qué es DICOM: el estándar de imagen médica, explicado sin jerga técnica

1. Qué es DICOM, en una frase

DICOM (Digital Imaging and Communications in Medicine) es el estándar internacional que define cómo se formatea, se guarda y se transmite una imagen médica junto con los datos que la identifican. Lo mantiene el comité NEMA desde 1993 y lo implementan, con matices propios, prácticamente todos los fabricantes de equipos de diagnóstico por imagen: ecógrafos, tomógrafos de coherencia óptica, resonancias, TAC, mamógrafos, angiógrafos y topógrafos corneales.

1.1. Un estándar, no un programa

DICOM no se instala ni se compra: es una norma que un fabricante decide implementar en su equipo. Cuando un equipo «habla DICOM» significa que exporta sus imágenes en ese formato y que, en teoría, cualquier otro programa que también entienda DICOM puede abrirlas. En la práctica cada fabricante añade sus propios campos y variantes dentro del estándar, así que «habla DICOM» no garantiza que dos equipos se entiendan sin ajustes.

1.2. Por qué el nombre aparece como extensión de archivo

Un archivo DICOM suele llevar la extensión .dcm, aunque también puede no llevar ninguna extensión y aun así ser un archivo DICOM válido: el formato se identifica por su cabecera interna, no por el nombre del fichero. Esto es precisamente lo que confunde a quien intenta abrir uno con un visor de imágenes normal: un .dcm no se abre con el visor de fotos del sistema operativo porque, además del píxel, lleva una cabecera de metadatos que ese visor no sabe leer.

2. Por qué existe el estándar: el problema que resuelve

Antes de DICOM (y de su antecesor, ACR-NEMA, de 1985), cada fabricante de equipos de imagen médica guardaba sus estudios en un formato propio. Un hospital con un ecógrafo de una marca y un TAC de otra no podía comparar las imágenes en la misma pantalla, y mucho menos enviarlas a un especialista de otro centro. El estándar resuelve tres problemas a la vez, y entenderlos es lo que explica por qué una clínica pequeña también debería preocuparse por él, no solo un hospital grande. Es una pieza más del ecosistema de interoperabilidad sanitaria.

2.1. El problema de la portabilidad

Sin un formato común, una prueba hecha en un equipo solo se puede ver con el software de ese mismo fabricante. Eso ata al profesional a la sala donde está el equipo, y complica cualquier interconsulta o segunda opinión.

2.2. El problema de los metadatos perdidos

Una imagen sin contexto no sirve de mucho: hace falta saber de qué paciente es, qué ojo o qué zona, con qué equipo se hizo y en qué fecha. DICOM obliga a que esos datos viajen pegados al píxel, dentro del mismo archivo, para que no se pierdan al copiar o enviar el estudio.

2.3. El problema de la trazabilidad clínica

Una prueba de imagen forma parte de la historia clínica del paciente. Si el archivo no lleva identificador de paciente y fecha de forma estructurada, vincularlo al expediente correcto depende de que nadie se equivoque al renombrar un fichero a mano — la causa más habitual del error de vincular una prueba a un paciente equivocado.

3. Qué lleva dentro un archivo DICOM

Cada estudio DICOM agrupa varias imágenes bajo la misma cabecera de identificación.

Un archivo DICOM tiene dos partes claramente separadas, aunque viajen juntas en el mismo fichero:

3.1. La cabecera de metadatos

• Identificador del paciente (nombre, fecha de nacimiento, sexo, un ID propio del equipo)
• Identificador del estudio y de la serie a la que pertenece la imagen
• Fecha y hora de la adquisición
• Fabricante y modelo del equipo que generó la imagen
• Parámetros técnicos de la adquisición (relevantes para interpretar la imagen correctamente)

3.2. Los datos de píxel

Es la imagen en sí: una matriz de valores que el visor traduce a una imagen en pantalla, en escala de grises o en color según la modalidad. Un mismo estudio puede tener decenas o cientos de imágenes agrupadas (por ejemplo, los cortes de un OCT), y todas comparten la cabecera del estudio pero llevan además su propia cabecera de imagen individual. Cuando el dato viaja como valor y no como imagen, es un informe estructurado DICOM SR.

3.3. Por qué esto importa para quien no es técnico

Un archivo DICOM mal exportado —con la cabecera incompleta o con el identificador de paciente vacío— es una imagen huérfana: se puede ver, pero no se puede vincular de forma fiable a un expediente sin intervención manual. Preguntar si el software de la consulta comprueba esa cabecera antes de aceptar el archivo es una pregunta legítima, no un detalle técnico menor.

4. Los tres papeles: quién genera, quién guarda, quién muestra

Hablar de «DICOM» sin distinguir estos tres papeles es la fuente más habitual de confusión, incluida la de quien vende o compra software clínico:

4.1. La modalidad: el equipo que genera el estudio

Es el ecógrafo, el OCT, el topógrafo o el equipo que sea. Genera las imágenes en formato DICOM y las exporta, ya sea a una memoria, a una carpeta de red o —si el equipo y el software lo soportan— directamente a un destino configurado. Ampliado en qué es una modalidad DICOM y por qué importa cuando compras software.

4.2. El PACS: el sistema que archiva y distribuye

Un PACS (Picture Archiving and Communication System) es un servidor especializado que recibe estudios DICOM de varias modalidades, los archiva de forma centralizada y los sirve a quien los pida. Es infraestructura pensada para volumen: un hospital con diez salas de imagen. Se desarrolla en la siguiente sección porque merece su propia entrada. Cómo se organiza cada estudio se cuenta en qué es un estudio DICOM y cómo se guarda dentro del expediente. Fuera del mundo de la imagen, la información viaja entre sistemas por HL7.

4.3. El visor: el programa donde el profesional mira, mide y compara

Es la pieza que de verdad usa el clínico en el día a día: abre el estudio, permite navegar entre las imágenes de la serie, medir distancias o áreas, anotar hallazgos y comparar dos estudios del mismo paciente en fechas distintas. Un visor no necesita ser un PACS para ser útil en una consulta pequeña o mediana.

5. DICOM no es PACS, y la diferencia importa

Es habitual que un proveedor de software use «compatible con DICOM» y «con PACS» como si fueran lo mismo, y no lo son. DICOM es el formato del archivo; PACS es un tipo concreto de infraestructura que además sabe recibir estudios automáticamente por red desde las modalidades (una operación llamada C-STORE, en la jerga del estándar) y responder a peticiones de otros sistemas.

5.1. Qué puede hacer un software sin ser un PACS

Puede perfectamente leer, mostrar, medir y guardar archivos DICOM dentro del expediente del paciente. Lo que no hace, si no es un PACS, es actuar como destino de red al que las modalidades envían el estudio en el momento en que se genera: eso exige un servidor dedicado, con su propia gestión de almacenamiento y de red, que es justo la pieza que separa a un visor de un PACS completo.

5.2. Qué preguntar antes de dar por hecho que «tiene PACS»

Conviene preguntar en concreto: ¿el estudio llega solo, sin que nadie intervenga, en el momento en que el equipo termina la adquisición? ¿O hay un paso intermedio —una carpeta que alguien revisa, una exportación manual— entre el equipo y el expediente? Ninguna de las dos respuestas es mala en una consulta pequeña; lo que no es aceptable es que el software diga una cosa y haga la otra.

6. Cómo llega hoy un estudio DICOM a la ficha de un paciente

Entre el equipo de diagnóstico y el expediente del paciente hay siempre un mecanismo de traspaso, automático o manual.

En la práctica, con la infraestructura que tiene hoy una consulta o clínica de tamaño pequeño o mediano, un estudio DICOM llega al software clínico por alguna de estas vías, y todas conviven en el sector:

6.1. Exportación y carga manual

El profesional o el técnico exporta el estudio del equipo a una memoria o carpeta y lo sube después al expediente del paciente correspondiente. Es el método más simple, funciona con cualquier equipo y su único punto débil es que depende de que alguien no se equivoque de paciente al subirlo.

6.2. Carpeta vigilada

El equipo exporta automáticamente a una carpeta de red o local, y el software revisa esa carpeta y recoge lo que encuentra para asociarlo al expediente que corresponda según la cabecera DICOM. Reduce el paso manual de mover el archivo, aunque sigue dependiendo de que el equipo esté bien configurado para exportar solo. Explicada de principio a fin en qué es una carpeta vigilada DICOM y cuándo es la vía correcta.

6.3. Worklist: el equipo lee la agenda

Un worklist DICOM es la lista de pacientes citados que un equipo de imagen puede consultar antes de hacer la prueba, para no tener que teclear a mano el nombre del paciente en el propio equipo. Reduce un punto de error clásico —el nombre mal escrito en el equipo, que después no casa con el del expediente—, y depende de que el equipo y el software del centro lo soporten en ambos lados.

7. Qué debe cumplir tu software si trabaja con DICOM

Con independencia de cuál de los tres mecanismos anteriores use tu clínica, hay un conjunto de criterios verificables que separan un software que trata bien la imagen médica de uno que solo «abre archivos DICOM»:

7.1. Verifica la cabecera antes de vincular

Debe comprobar el identificador de paciente de la cabecera DICOM contra el paciente al que se está subiendo el estudio, y avisar si no coinciden, en lugar de aceptar cualquier archivo sin más.

7.2. Guarda el estudio dentro del expediente, no aparte

El estudio tiene que quedar accesible desde la misma ficha del paciente donde está el resto de su historia, no en un almacén separado que haya que buscar por otro camino.

7.3. Conserva los metadatos originales

No debe recomprimir ni reescribir la cabecera de forma que se pierdan los datos técnicos de la adquisición: son los que permiten, más adelante, comparar un estudio con otro del mismo tipo hecho en otra fecha.

Y un cuarto criterio, que no es técnico sino de honestidad comercial. Si el mecanismo real es «subida manual» o «carpeta vigilada», el software debería decirlo así y no vender «integración automática con tus equipos» sin matices. Y si promete worklist o acceso directo a un equipo concreto, debería decir también que depende del fabricante y del modelo — no todos los equipos ofrecen las mismas vías de conexión.

8. Errores frecuentes al hablar de DICOM

• «Mi software tiene PACS» cuando en realidad tiene un visor. Un visor que abre archivos DICOM no es, por sí solo, un servidor PACS.
• «DICOM es una marca de software». Es un estándar de formato; lo implementan decenas de fabricantes distintos, cada uno con su equipo.
• «Todos los equipos DICOM se conectan igual». El estándar define el formato del archivo y varios protocolos de transmisión, pero cada fabricante decide qué partes implementa y cómo. Dos equipos «compatibles con DICOM» no siempre se conectan de la misma manera entre sí.
• Confundir el nombre del archivo con la cabecera. Renombrar el archivo no cambia lo que dice su cabecera interna: si la cabecera lleva el paciente equivocado, el problema sigue ahí aunque el nombre del fichero sea correcto.

8.1. El error que más caro sale: exportar a JPG «para verlo rápido»

Convertir un estudio a una imagen corriente es cómodo el primer día y caro a los cinco años. Al hacerlo desaparecen los datos de identificación, los parámetros de la adquisición y la escala real de la medida, de modo que lo que queda ya no se puede comparar con nada ni se puede vincular automáticamente a nadie. Si alguien tiene que enviar una imagen suelta, que sea una copia adicional, nunca lo único que se conserva.

8.2. Creer que el formato aporta la seguridad

El estándar describe cómo se guardan y se transmiten los datos, no quién puede verlos. El control de accesos, el registro de quién abrió qué y la protección del almacén los pone el sistema que custodia los archivos, no el formato. Un archivo con datos de salud en una carpeta compartida sin control sigue siendo un problema por mucho que esté perfectamente formado según la norma.

8.3. Suponer que «compatible» quiere decir «ya conectado»

Que un equipo y un software hablen el mismo estándar significa que pueden entenderse, no que se estén entendiendo hoy en tu consulta. Entre lo uno y lo otro hay una configuración, una prueba con un paciente real y, casi siempre, alguna sorpresa concreta de ese modelo. Es la diferencia entre lo que dice una hoja de características y lo que verás funcionando el martes por la mañana.

9. Qué aporta obeliOmed con esto

9.1. El estudio se mira donde está la historia

obeliOmed incluye un visor DICOM integrado en el expediente del paciente: los estudios se abren, se navegan y se comparan desde la misma ficha, sin cambiar de programa ni ir a buscar el archivo a otro sitio. Es lo que permite que quien lee el caso vea la prueba junto al motivo por el que se pidió, y no como un archivo suelto que hay que interpretar por su cuenta.

9.2. Las vías de traspaso, y su letra pequeña

Lo que sí soporta, según el equipo y el fabricante, es carpeta vigilada, worklist —el equipo lee la agenda del centro— y acceso a la base de datos del propio equipo, por su API o de forma directa, para traer los datos concretos de la prueba. Cada caso se presupuesta por equipo, porque el mecanismo real depende de lo que ese fabricante permita, y generalizar en cualquiera de las dos direcciones sería falso.

9.3. Lo que no hace, dicho antes de que lo preguntes

No es un servidor PACS ni promete recepción automática de estudios desde cualquier equipo. Para una consulta o clínica de tamaño pequeño o mediano eso rara vez es un límite real; cuando lo es, lo honesto es decirlo antes de firmar, no explicarlo después. La comparación entre las dos cosas, con los umbrales de cuándo hace falta cada una, está en la entrada sobre qué es un PACS.