obeliOmed frente a un software tradicional: qué cambia de verdad

1. Qué quiere decir «tradicional»

Conviene fijar el término, porque se usa para cosas muy distintas y no todas son un problema.

1.1. No es una cuestión de antigüedad

Un programa puede tener quince años y funcionar perfectamente. Lo que marca la diferencia no es su edad sino cómo guarda lo que le das: si cada valor va a su campo o si todo acaba en un cuadro de texto y un archivo adjunto.

Tampoco es «local contra nube». Hay sistemas instalados en la clínica que estructuran bien el dato y servicios en la nube que lo guardan como texto libre. Son dos ejes independientes y conviene mirarlos por separado.

1.2. Los dos ejes que sí importan

• Dónde vive el sistema — en un servidor de la clínica o en la nube. Determina quién se ocupa de las copias, las actualizaciones y las caídas.
• Cómo guarda el dato — en campos con significado o en documentos. Determina si el histórico sirve para algo más que leerse.

El segundo es el que casi nunca se pregunta en una demo y el que no tiene arreglo después. El primero se puede cambiar; el histórico escrito en texto libre se queda así.

2. Dónde se rompe: el dato de la prueba

En oftalmología, buena parte del trabajo consiste en comparar la visita de hoy con las anteriores. Ahí es donde un sistema generalista se queda corto, y no por falta de potencia.

2.1. El PDF adjunto es un callejón sin salida

Cuando el informe del equipo se guarda como archivo adjunto, el sistema ha cumplido: el documento está en la historia. Pero para el programa ese archivo es opaco. No sabe qué hay dentro, así que no puede ponerlo en serie con el de hace seis meses ni avisar de nada.

El resultado es que la comparación la hace una persona, abriendo documentos, y en el tiempo que dura una consulta. Funciona, pero depende de que ese día haya tiempo.

2.2. Lo que cambia con el dato en campos

Con los valores en campos —la presión, la paquimetría, los índices del campo visual— el sistema puede ponerlos en serie y mostrarlos juntos, que es lo que evita tener que recordar cifras de visitas anteriores. Mostrar la evolución no es interpretarla: la lectura clínica sigue siendo del profesional, y ningún software debería sugerir otra cosa.

2.3. La prueba de fuego

Hay una pregunta que separa los dos modelos en diez segundos: «enséñame la evolución de este valor en los últimos tres años». Si el sistema la pinta, el dato está estructurado. Si hay que abrir informes, no lo está, y no lo va a estar nunca para lo ya registrado.

3. El coste real de un sistema instalado

La comparación de precios suele hacerse mal porque se compara una licencia con una cuota, y ahí no está el grueso del gasto.

3.1. Lo que no aparece en el presupuesto

• El servidor y su renovación cada pocos años.
• Las copias de seguridad, y sobre todo comprobar que se pueden restaurar, que es distinto de que se hagan.
• Las actualizaciones, incluidas las legales y fiscales, que no son opcionales.
• Quien lo mantiene: alguien de la clínica que dedica horas o un externo con cuota.
• El día que falla, que no aparece en ninguna hoja de cálculo hasta que ocurre.

La licencia es la punta. Debajo van el servidor, las copias, las actualizaciones, quien lo mantiene y el día que falla.

3.2. Lo que sí tiene de bueno

No todo son inconvenientes, y conviene decirlo: en un sistema instalado los datos están físicamente en la clínica, no dependes de la conexión a internet para trabajar y el coste, una vez pagado, es previsible durante años. Para un centro pequeño y estable, con un solo puesto, puede salir perfectamente a cuenta.

3.3. Dónde deja de compensar

Cuando aparece el segundo puesto, la segunda sede o la necesidad de consultar desde fuera. Ahí el modelo instalado empieza a pedir infraestructura —accesos remotos, sincronización, más mantenimiento— y el ahorro inicial se evapora.

4. Cuando hay más de un puesto

Es el punto donde más se nota la arquitectura, y el que más rápido se comprueba en una demo.

4.1. Trabajar a la vez sobre el mismo paciente

Consulta, gabinete y recepción tocan el mismo expediente en momentos distintos y a veces a la vez. Un sistema pensado para un puesto lo resuelve bloqueando: el primero que entra edita y el resto espera. Con varias personas eso se convierte en el cuello de botella de la mañana.

Arriba, cada puesto esperando su turno. Abajo, los tres sobre el mismo expediente sin bloquearse.

4.2. El histórico pesado

Un expediente con años de pruebas y de imagen carga distinto que uno recién creado. Por eso la demo hay que pedirla con un paciente con cinco años de historia, no con uno vacío: es donde se ve si el sistema ordena o solo acumula.

4.3. Varias sedes

Si el centro tiene o va a tener más de una sede, hay una decisión que condiciona todo lo demás: si cada una lleva su propio sistema o si comparten uno con los datos segmentados. Compartir es lo único que permite que un paciente sea el mismo en las dos y que la dirección vea cifras agregadas sin consolidar a mano. Con sistemas separados por sede, esa consolidación se convierte en una tarea manual recurrente que alguien tiene que repetir cada mes, y que crece en horas a medida que se abren nuevas sedes.

5. La imagen: lo que ninguno resuelve solo

Este apartado suele venderse mal en los dos bandos, así que va sin adornos.

5.1. Qué hace falta de verdad

Que el estudio esté en el expediente y no solo en el equipo que lo generó. Si para ver la prueba de hace seis meses hay que ir al aparato, esa prueba no está en la historia clínica: está en un archivo paralelo que sobrevive mientras nadie cambie el ordenador del gabinete.

5.2. Lo que obeliOmed hace y lo que no

Hace: el archivo DICOM llega al expediente y lo trabajas ahí —navegas, mides, anotas y comparas dos revisiones— desde el navegador y sin instalar el visor del fabricante en cada puesto. La llegada del archivo tampoco exige subirlo a mano en todos los casos: lo habitual es una carpeta vigilada en la que el propio equipo exporta el estudio y obeliOmed lo recoge, y cuando el aparato lo permite, también puede leer la agenda del día —la worklist— para saber qué paciente toca sin que nadie lo teclee. Lo que no hace: no es el destino directo al que un equipo entrega estudios por sí solo, sin ningún paso intermedio; la subida manual sigue siendo necesaria cuando el equipo no ofrece carpeta vigilada ni worklist. Lo desarrollamos en la página del visor y en cuándo hace falta un PACS.

5.3. Los datos de medida sí son otra cosa

Los valores numéricos que produce un equipo —longitud axial, queratometrías, índices de perimetría— muchas veces sí pueden entrar sin teclearlos, pero depende del modelo y de qué exponga cada fabricante. La pregunta útil lleva delante el modelo y la versión, nunca la marca a secas. Lo que se integra hoy está en la página de integraciones.

6. Qué exige la normativa a cada modelo

Las obligaciones son las mismas en los dos casos. Lo que cambia es quién las cumple.

6.1. Con el sistema instalado, respondes tú

Si el servidor está en la clínica, el control de acceso, el cifrado, las copias y el registro de accesos son responsabilidad del centro. Es perfectamente asumible, pero hay que hacerlo y hay que poder demostrarlo, no basta con que el programa lo permita.

6.2. Con la nube, se reparte

El proveedor actúa como encargado del tratamiento y hace falta un contrato específico entre las partes. Pregunta siempre dónde están alojados los datos y qué subencargados intervienen. Un anexo genérico dentro de las condiciones de servicio no cumple esa función.

6.3. Lo que aplica en los dos

La documentación clínica se conserva un mínimo de cinco años desde el alta de cada proceso asistencial, y varias comunidades autónomas amplían ese plazo. Con la imagen dentro, ese cálculo es el que decide cuánto almacenamiento vas a necesitar, tanto si el servidor está en la clínica como si está en la nube: el plazo de conservación no cambia según dónde vivan los datos, solo cambia quién tiene que garantizarlo día a día. El marco entero está en la checklist de auditoría RGPD.

7. Cómo decidir sin fiarte de nadie

Incluidos nosotros. Cinco comprobaciones que puedes hacer tú y que no se pueden falsear con una respuesta bien ensayada.

7.1. Las cinco preguntas

• «Ejecuta la exportación de mis datos delante de mí», y dime en qué formato sale. Decide el coste de salida.
• «Enséñame la evolución de un valor en tres años». Distingue el dato estructurado del adjunto.
• «Abre un expediente con cinco años de historia», no uno nuevo.
• «¿Qué pasa si mi equipo no está integrado?» Una respuesta honesta incluye un «no» posible.
• «¿Con quién hablo un martes por la mañana cuando algo falle?» Y cuánto tarda en contestar.

7.2. La que decide de verdad

La primera. Lo que recibas al pedir una exportación te dirá más que cualquier demostración: si llega un volcado estructurado, la migración será una conversación técnica normal; si llega un documento por paciente, el coste de salida ya está fijado y no lo has fijado tú. Pídesela a tu proveedor actual antes de comprometerte con nadie.

8. Cómo se cambia sin parar la consulta

El miedo que más frena un cambio no es el precio: es parar la actividad y perder el histórico. Con números reales se entiende mejor.

8.1. Un caso concreto

En Clínica Masera se migraron 70.000 historiales repartidos en tres formatos a la vez —papel, hojas de cálculo y el software anterior— y el proyecto duró cinco semanas: más de lo habitual, precisamente por tener el origen dividido. La clínica no dejó de atender ni un día. El detalle está en el caso completo.

8.2. Lo que marca el plazo

Casi nunca la formación. Lo que manda es en qué formato entrega los datos el sistema de origen, y por eso lo primero que pedimos es una exportación de prueba antes de dar ninguna fecha. Los estudios de imagen, además, migran aparte del texto de la historia y hay que confirmarlos por separado.

8.3. El orden que funciona

Por fases y no todo a la vez: primero que los datos estén dentro y el expediente se use con normalidad; después el equipo que más se usa; luego lo administrativo. Cada paso cambia un hábito, y los hábitos no se cambian todos la misma semana.

9. Qué hace obeliOmed y qué no

Con el marco anterior delante, el alcance concreto es fácil de situar.

9.1. Lo que sí

Expediente con las pruebas de la especialidad en campos y no en texto libre, con la evolución a la vista; visor DICOM dentro de la historia, con carpeta vigilada y worklist cuando el equipo lo permite; agenda por profesional, sala y equipo; y facturación enganchada al acto. Alojado en Europa, con registro de accesos, actualizaciones automáticas y exportación de tus datos en formato abierto cuando quieras. Todo ello en la página de software para clínicas oftalmológicas.

9.2. Lo que no

• No es el destino directo de un envío automático de estudios. La conectividad va por carpeta vigilada, worklist o API, según lo que permita el fabricante.
• No se conecta con cualquier equipo. Depende del modelo y del fabricante, y si no es viable lo decimos en la demo.
• No da criterio clínico. Ordena, compara y avisa de lo que falta; interpretar es del profesional.
• No funciona sin conexión. Es un servicio en la nube, y eso es una desventaja real frente a un sistema instalado.

9.3. Cuándo no somos la opción

Si tu centro es una consulta de un solo profesional, con un sistema instalado que funciona y sin intención de crecer, cambiar puede no compensar. Y si tu volumen exige que los equipos entreguen el estudio directo a un servidor central de imagen, sin ningún paso intermedio, lo que necesitas es un PACS propiamente dicho, no un visor dentro de la historia clínica. Preferimos decirlo aquí que en el tercer mes de implantación.