Visor DICOM en el navegador vs escritorio: qué conviene para CBCT en clínica

Cuando llega un CBCT al consultorio, la pregunta ya no es solo “¿tengo un visor?”, sino dónde lo abres: en el navegador o en un programa instalado en el PC. Ambas opciones pueden ser clínicas. Elegir mal se nota el viernes a las 18:00, con el paciente en el sillón y un ZIP de varios cientos de megabytes.

Este artículo es una matriz de decisión para dentistas y especialistas. No es una guía de compra de PACS, no sustituye la indicación ALARA del CBCT ni inventa funciones de un producto concreto. Las piezas compañeras del cluster cubren qué es un visor CBCT online, cómo abrir un estudio sin el instalador del fabricante y la checklist de criterios al elegir software DICOM. Aquí el ángulo es otro: navegador frente a escritorio para el trabajo diario con volúmenes dentales.

Qué significa “visor en el navegador” y “visor de escritorio”

Un visor DICOM de escritorio es una aplicación nativa (Windows, macOS o Linux) que instalas, actualizas y ejecutas en un puesto concreto. Habla con la GPU y el sistema de archivos del equipo; a menudo acepta DICOMDIR, carpetas sueltas y discos del fabricante.

Un visor DICOM en el navegador corre dentro de Chrome, Edge, Firefox o Safari. El volumen se carga por enlace, subida o red; el procesamiento (decodificación, MPR, mediciones) ocurre cada vez más en el cliente gracias a WebAssembly, WebGL y, en evolución, WebGPU. No sustituye automáticamente un PACS completo: es la capa de lectura clínica del dataset.

DICOM sigue siendo el estándar NEMA para imagen médica. Farman insistió en que la interoperabilidad protege el activo clínico frente a silos de marca: da igual el contenedor (navegador o .exe) si el archivo no es DICOM abierto.

Lo que ya no es un argumento válido

Algunos mitos siguen circulando:

• “El navegador no puede hacer MPR de verdad.” Falso para la mayoría de flujos 2D/MPR de uso diario. Estudios recientes de visualización DICOM/MPR en aplicaciones web progresivas reportan tiempos de carga y reconstrucción competitivos frente a herramientas web previas, con errores de reconstrucción por debajo de 0,05 mm en validación geométrica reportada.
• “El escritorio siempre es más seguro.” La seguridad depende del cifrado, del control de acceso y de la política del proveedor o de tu red, no del hecho de instalar un .msi. Un PC con el visor del fabricante y discos sin inventariar también es riesgo.
• “Si es online, el radiólogo del otro lado ve el mismo sillón.” Compartir un enlace no es lo mismo que teleconsulta sincronizada ni que un informe firmado. Son capas distintas.

Matriz rápida: cuándo gana el navegador

Elige (o prioriza) un visor en navegador cuando:

1. Varios puestos y sistemas operativos. Operatory Windows, box de planificación Mac, tablet del especialista: un único flujo evita “solo abre en el PC del fondo”.
2. Referidos y CDs ajenos. Necesitas abrir el DICOM del centro sin instalar el autoejecutable de esa marca (y sin pelear con drivers).
3. Compartir sin adjuntos de 500 MB. Enlace con acceso controlado (caducidad, PIN o cuenta) frente a WhatsApp con ZIP o correo que rebota.
4. Actualizaciones sin visitar cada PC. Parches de seguridad y mejoras llegan sin “el que sabe instalar”.
5. Consulta rápida y segunda opinión. Abrir, medir en mm, capturar y devolver el criterio en minutos.

La AAOMR recuerda que quien obtiene el CBCT es responsable de interpretar el volumen (o de derivar a radiología oral). Un visor cómodo no reduce esa responsabilidad; sí reduce la excusa de “no pude abrirlo”.

Matriz rápida: cuándo sigue ganando el escritorio

Prioriza (o mantén) un visor nativo cuando:

1. Offline real o red inestable. Quirófano, zona rural, o Wi‑Fi de recepción saturado: si no hay red, el navegador “solo en la nube” no sirve. Algunos escenarios híbridos permiten caché local; no asumas que todos lo hacen.
2. Postproceso avanzado o plugins del ecosistema del fabricante. Planificación de guías, segmentaciones propietarias, módulos de ATM/ortodoncia ligados a la workstation de marca: a menudo viven en el escritorio.
3. Hardware dedicado y monitores calibrados. Estación de radiología oral con GPU potente, dual monitor y periféricos: el software nativo suele aprovechar mejor ese stack.
4. Volúmenes muy grandes + rendering 3D insistente. El scroll MPR en navegador moderno ya es viable clínicamente; el gap que más se menciona en literatura técnica sigue siendo el volume rendering 3D intensivo frente a workstations nativas, aunque WebGL/WebGPU lo estrecha año a año.
5. Política interna “todo en LAN, nada sale”. Si tu cumplimiento exige que el PHI no toque un proveedor externo, un visor local (o un despliegue on‑premise controlado) puede ser el camino —asesoría legal aparte.

Rendimiento: qué medir en tu clínica (no en la demo)

La demora no es solo molestia: corta la consulta. Prueba con tus archivos, no con el demo de 80 MB.

Escenario	Qué mirar
ZIP / carpeta típica de referidos	Tiempo hasta primer corte útil
FOV amplio (orto / ATM)	Fluidez al recorrer cientos de slices
Wi‑Fi de recepción vs cable	Si “solo falla el viernes”
Mac + Windows mezclados	Misma medición en mm en ambos
Serie incompleta o transfer syntax raro	Mensaje claro vs pantalla en blanco

WebAssembly acerca el parseo y la decodificación al rendimiento nativo al ejecutar código compilado (p. ej. desde C++/Rust) dentro del navegador. Eso explica por qué el argumento “JavaScript es lento para CT” quedó desactualizado para gran parte del trabajo 2D/MPR. Aun así: benchmarkea en tu peor caso real.

Privacidad y cumplimiento (capa común)

Imágenes dentales = datos de salud. En EE. UU. aplica el marco HIPAA; en UE/LATAM, GDPR y leyes locales. Exige al proveedor (o a tu TI):

• Cifrado en tránsito (HTTPS/TLS) si hay carga o visualización remota.
• Control de quién abre el estudio y, si aplica, registro de acceso.
• Política de retención y borrado / caducidad de enlaces.
• Contrato o DPA cuando un tercero procesa datos en tu nombre.

El “visor gratis público sin cuenta” puede servir para un caso anonimizado de docencia. No es automáticamente adecuado para producción con identificadores.

Modelo híbrido (lo que hacen muchas clínicas)

No es binario. Un patrón frecuente:

• Navegador para abrir referidos, compartir con el derivador, revisar en sillón o en casa del especialista.
• Escritorio para planificación profunda en un puesto fijo, módulos de marca o trabajo offline programado.

La checklist de selección de software DICOM (pieza compañera) te ayuda a evaluar ambos con los mismos criterios: Conformance Statement, MPR, mediciones en mm, export abierto, TCO.

Checklist de decisión en una página

1. ¿Cuántos puestos y SO distintos necesitan ver el CBCT esta semana?
2. ¿Qué porcentaje de estudios llega de marcas ajenas / CD con instalador?
3. ¿Necesitas offline garantizado en algún box?
4. ¿El cuello de botella es abrir/medir/compartir o es postproceso de marca?
5. ¿Quién mantiene actualizaciones y backups del PC “que sí abre”?
6. ¿Probaste con un ZIP real de 300–500 MB en la red real de la clínica?
7. ¿El export sigue siendo DICOM estándar (Farman / interoperabilidad)?
8. ¿Quién interpreta el volumen completo (AAOMR) y con qué herramienta lo revisa entero?

Si 1–2 y 6 pesan más, el navegador suele ganar adopción. Si 3–4 pesan más, mantén escritorio (o híbrido).

Qué no hace este artículo

No compara marcas por nombre, no sustituye SEDENTEXCT / principios EADMFR sobre indicación y dosis, no es tutorial de instalación ni promesa de features de un producto. Evalúa con evidencia en tu flujo.

Referencias

1. Horner K, Islam M, Flygare L, Tsiklakis K, Whaites E. Basic principles for use of dental cone beam computed tomography: consensus guidelines of the European Academy of Dental and Maxillofacial Radiology. Dentomaxillofac Radiol. 2009;38(4):187-195. doi: 10.1259/dmfr/74941012
2. European Commission. Radiation Protection No 172. Cone Beam CT for Dental and Maxillofacial Radiology: Evidence-Based Guidelines (SEDENTEXCT). Luxembourg: Publications Office of the EU; 2012.
3. Carter L, Farman AG, Geist J, et al. American Academy of Oral and Maxillofacial Radiology executive opinion statement on performing and interpreting diagnostic cone beam computed tomography. Oral Surg Oral Med Oral Pathol Oral Radiol Endod. 2008;106(4):561-562. doi: 10.1016/j.tripleo.2008.07.007
4. Farman AG. Raising standards: Digital interoperability and DICOM. Oral Surg Oral Med Oral Pathol Oral Radiol Endod. 2005;99(5):525-526. doi: 10.1016/j.tripleo.2005.03.001
5. Farman AG. Applying DICOM to dentistry. J Digit Imaging. 2005;18(1):23-27. doi: 10.1007/s10278-004-1029-z
6. National Electrical Manufacturers Association (NEMA). DICOM Standard (current edition). https://dicom.nema.org/medical/dicom/current/
7. AboArab MA, Potsika VT, Theodorou A, et al. Advancing Progressive Web Applications to Leverage Medical Imaging for Visualization of DICOM and Multiplanar Reconstruction: Software Development and Validation Study. JMIR Med Inform. 2024;12:e63834. doi: 10.2196/63834
8. U.S. Department of Health & Human Services. Minimum Necessary Requirement (HIPAA Privacy Rule). https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/minimum-necessary-requirement/index.html