Con qué se integra obeliOmed: equipos, datos y salida

1. El mapa: cuatro vías de conexión

1.1. Las cuatro vías, de un vistazo

«Interoperabilidad» es una de esas palabras que en una demo puede significar casi cualquier cosa, igual que media docena de siglas que la acompañan y que conviene tener definidas de antemano. Para evitar equívocos, este es el mapa completo de por dónde entra y sale información de obeliOmed, con su alcance real:

1.2. Por qué no conviene mezclarlas

Las cuatro son cosas distintas y conviene no mezclarlas, porque el sector las mezcla constantemente. Que un software «se integre con equipos» no dice nada sobre si puedes sacar tus datos, ni sobre si hace lo que de verdad define a un PACS. Y que exporte datos no dice nada sobre si el biómetro le manda las medidas.

Lo que sigue explica cada vía con su límite, incluido el que a veces no gusta contar.

2. Equipos de consulta y de quirófano

2.1. Qué cambia cuando el equipo está integrado

Esta es la integración que más tiempo ahorra a diario, y también la menos vistosa. No consiste en mover imágenes, sino en que los datos que genera un equipo lleguen al expediente sin que nadie los teclee.

Piensa en lo que ocurre hoy en una consulta cualquiera: el equipo mide, alguien lee la pantalla y copia los valores en la ficha del paciente. Ese trayecto de ojo a teclado es donde se cuelan los errores de transcripción, y es un trabajo que no aporta nada salvo el riesgo de equivocarse. Cuando el equipo está integrado, los valores entran solos y el profesional los revisa en lugar de escribirlos.

El mismo principio se aplica en quirófano, donde además hay un componente de trazabilidad: lo que se ha usado en cada intervención tiene que quedar registrado, y hacerlo a mano al final de la jornada es la receta para que falten cosas.

2.2. El alcance depende del equipo

El alcance real depende del equipo. No hay un «se integra con todo», porque cada fabricante expone sus datos de una manera y algunos no los exponen en absoluto. Lo honesto es decir que hay un catálogo de equipos integrados, que crece, y que la pregunta correcta no es «¿os integráis con equipos?» sino «¿os integráis con el mío?».

3. Imagen diagnóstica: qué sí y qué no

Aquí es donde más confusión hay en todo el sector, así que va sin adornos.

3.1. Qué sí: el visor DICOM

Sí: puedes subir al expediente del paciente los archivos DICOM que exportas de tus equipos y trabajarlos ahí —navegar entre las imágenes de un estudio, medir, anotar, comparar dos estudios y descargarlos o compartirlos—. Todo dentro del navegador, sin instalar el visor del fabricante en cada puesto. Es un módulo opcional y está explicado en detalle en la página del visor DICOM.

3.2. Qué no: por qué no es un PACS

No, sin más: obeliOmed no promete que las máquinas envíen un estudio sin que nadie intervenga. Lo que sí hay, según el equipo y el fabricante, son tres vías: carpeta vigilada (el equipo exporta el estudio y obeliOmed lo recoge), worklist (el equipo lee la agenda de obeliOmed para saber qué paciente toca) y acceso a la base de datos del equipo, por API o directamente, para traer los datos específicos. Cuando ninguna de las tres es viable, el archivo lo sube una persona.

Esa distinción no es un tecnicismo: separa dos categorías de producto con un orden de magnitud de diferencia en precio. Si necesitas que las máquinas envíen las pruebas sin intervención humana, necesitas un PACS, y conviene saberlo antes de comparar presupuestos. Tenemos una guía entera sobre cuándo hace falta un PACS de verdad y cuándo no, escrita precisamente porque muchas consultas compran uno sin necesitarlo.

3.3. La asimetría entre datos e imágenes

Merece la pena notar la asimetría: los datos de medida de muchos equipos sí pueden entrar solos, mientras que las imágenes hay que subirlas, salvo que el equipo tenga carpeta vigilada o worklist. Son caminos técnicos distintos, y por eso el alcance es distinto.

4. Si tu equipo no está integrado

4.1. Se estudia, y así ha crecido el catálogo

Se estudia. Y esto no es una fórmula de cortesía comercial, es cómo funciona el producto: obeliOmed acepta peticiones de integración y de funcionalidad nueva, y el catálogo ha crecido así.

Es una diferencia de fondo con el modelo habitual del sector, donde el catálogo de integraciones es una lista cerrada que decide el proveedor y con la que te apañas. Si tu equipo no está en esa lista, la respuesta suele ser que cambies de equipo o que sigas tecleando.

4.2. Qué determina que sea viable

Lo que conviene entender es qué determina que una integración sea viable, porque no depende de nosotros sino del equipo:

• Qué expone el fabricante: hay equipos que ofrecen una salida documentada de sus datos y otros que los guardan en un formato propio sin manera prevista de sacarlos.
• Por dónde salen: algunos escriben un fichero, otros hablan por red, otros exigen su propio software de por medio.
• Qué modelo y qué versión: dos equipos de la misma gama pueden comportarse distinto según el firmware.

Por eso la conversación útil empieza con el modelo concreto encima de la mesa, no con la categoría. «Un biómetro» no es una respuesta; el modelo y la versión, sí.

Y si la integración no es viable, lo decimos. Es preferible a venderla y descubrirlo en la implantación, que es cuando el problema ya te ha costado dinero.

5. La API y la salida de datos

5.1. Cuándo usar la API

Para lo que no cubre una integración de equipo, hay una API con la que otro sistema puede leer o escribir en obeliOmed. Es la vía cuando la conexión que necesitas es con software y no con hardware: un CRM, una herramienta de facturación externa, un cuadro de mando propio, una plataforma con la que ya trabajas.

Como cualquier integración a medida, lo que decide la viabilidad es qué expone el otro extremo. Si el sistema con el que quieres conectar tiene su propia API documentada, la conversación es corta. Si es una aplicación cerrada sin salida prevista, no hay API que valga: el problema no está en este lado.

5.2. Qué garantiza y qué no

Conviene también decir qué no es la API: no es un botón de configuración. Cualquier integración a medida requiere análisis y desarrollo, y por tanto tiempo y presupuesto. Lo que sí garantiza es que la puerta existe, que es justo lo que no ocurre con el software sanitario cerrado.

6. Portabilidad: tus datos son tuyos

6.1. Puedes exportar cuando quieras

Esta es la parte que casi nadie pregunta en la demo y la que más duele años después. Puedes exportar tus datos en formato abierto, cuando quieras y sin coste. Incluida la marcha: si un día decides irte, te llevas tu información.

6.2. El bloqueo de proveedor es técnico, no contractual

Parece obvio y no lo es. El bloqueo de proveedor en software sanitario rara vez es contractual; es técnico. Se manifiesta cuando pides tus datos y te ofrecen un PDF por paciente, o un volcado en un formato que solo entiende su propio sistema, o directamente un presupuesto por la exportación. Llegado ese punto, cambiar de software deja de ser una decisión de producto y pasa a ser una decisión de coste de salida. Es el mismo argumento que desarrollamos en la guía de soberanía del dato clínico.

La puerta abierta del todo, no entornada: puedes llevarte tus datos en formato abierto cuando quieras.

6.3. La lectura legal y la prueba práctica

Hay además una lectura legal. Los datos de la historia clínica son responsabilidad del centro sanitario, que es el responsable del tratamiento (art. 4.7 y 28 RGPD), no del proveedor de software, que actúa solo como encargado del tratamiento. Un proveedor que dificulta la salida de esos datos está complicándole al responsable el cumplimiento de sus propias obligaciones. Es un punto que conviene revisar con el mismo rigor que el resto: el checklist de auditoría RGPD lo incluye.

La prueba práctica es sencilla y se puede hacer en cualquier demo: pide ver la exportación funcionando. No la cláusula del contrato que dice que es posible: la pantalla desde la que se lanza.

7. El núcleo contable y fiscal

obeliOmed no está construido desde cero: se apoya en un núcleo de gestión contable y fiscal consolidado, y eso tiene consecuencias prácticas que conviene conocer.

7.1. Cumplimiento normativo sin reimplementar cada vez

La primera es de cumplimiento. La normativa de facturación cambia —y en España ha cambiado bastante— y mantenerse al día es un trabajo continuo que no tiene nada que ver con la medicina. Al apoyarse en un núcleo que se dedica a eso, los cambios normativos llegan por esa vía en lugar de tener que reimplementarse cada vez.

7.2. Alcance de ERP y datos en el mismo sistema

La segunda es de alcance. La parte contable y fiscal es la de un ERP de gestión, no un módulo de facturación simplificado pensado solo para emitir tickets. Para una clínica con aseguradoras, presupuestos, liquidaciones a colaboradores y varias formas de cobro, esa diferencia se nota —el detalle de copagos y baremos está en la guía de facturación médica y baremos de mutuas.

Y la tercera, la que menos se ve: la información clínica y la económica viven en el mismo sitio. No hay que cuadrar dos sistemas ni exportar de uno para importar en otro, que es donde aparecen los descuadres y donde se pierden horas cada cierre de mes.

8. Qué preguntarle a cualquier proveedor

8.1. Las cinco preguntas técnicas

Sirven para nosotros y para cualquier otro. Si una respuesta es vaga, la vaguedad es la respuesta:

• «¿Os integráis con este modelo concreto?» Con el modelo y la versión, no con la categoría. «Nos integramos con biómetros» no compromete a nada.
• «¿El archivo lo sube una persona o llega solo desde la máquina?» Es la pregunta que distingue un visor de un PACS, y casi nadie la hace.
• «¿Puedo ver la exportación de datos funcionando?» No la cláusula: la pantalla.
• «¿Qué pasa si necesito una integración que no tenéis?» Las respuestas posibles son «se estudia», «no» o un silencio incómodo. Las tres informan.
• «¿Qué me cuesta irme?» En dinero y en semanas. Si no hay respuesta clara, ya la tienes.

8.2. La sexta pregunta, la que más pesa

Hay una sexta pregunta que no es técnica pero decide más que las otras cinco: «¿quién hace la integración y en cuánto tiempo?». Una integración posible que tarda ocho meses en llegar es, a efectos de tu clínica, una integración que no existe.

9. El coste que no se ve: teclear

9.1. El coste que no se pone en el presupuesto

Cuando se valora una integración se mira el presupuesto de ponerla en marcha, y casi nunca se pone precio a lo contrario: seguir sin ella. Merece la pena hacer ese cálculo, porque suele ser más grande de lo que parece y se paga todos los días.

Toma un dato cualquiera que hoy se teclea a mano —los valores de un equipo, los consumibles de una intervención— y multiplica: minutos por paciente, pacientes al día, días al año. La cifra que sale no es el problema principal, pero orienta. El problema principal es el otro:

• El error de transcripción no avisa. Un valor mal copiado no da ningún síntoma: se queda en la ficha con la misma apariencia de fiabilidad que el resto, y se arrastra a todas las decisiones posteriores.
• Se corrige tarde o no se corrige. Cuando se detecta —si se detecta— suele ser porque algo no cuadra meses después, y entonces hay que rehacer el camino para saber qué pasó.
• Escala mal. Con un profesional y treinta pacientes se sostiene. Con cuatro profesionales, personal rotando y turno de tarde, la probabilidad de que alguien se equivoque en algún momento del día tiende a uno.

El trayecto de ojo a teclado es donde se cuelan los errores de transcripción, y no aporta nada salvo el riesgo de equivocarse.

9.2. Cuándo sí conviene integrar

Frente a eso, una integración no es una comodidad: es eliminar por diseño una clase entera de error. Y esa es la comparación honesta a la hora de decidir, no la del precio contra cero.

Dicho lo cual, tampoco conviene integrarlo todo. Un equipo que se usa dos veces al mes no justifica ningún desarrollo, y hay datos que se teclean una vez en la vida del paciente. La pregunta que ordena la lista es sencilla: ¿cuántas veces al día pasa esto?. Lo que ocurre muchas veces al día es candidato; lo demás puede esperar.

10. Por dónde empezar si vienes de otro sistema

Cuando una clínica llega desde otro software, la tentación es querer replicar el día uno todo lo que tenía y añadir lo nuevo a la vez. Sale mejor al revés, y por una razón práctica: cada integración cambia un hábito del equipo, y los hábitos no se cambian todos la misma semana.

10.1. El orden que funciona

• Primero, que los datos estén dentro. La migración del histórico y el uso normal del expediente. Sin eso, lo demás no tiene dónde apoyarse.
• Después, el equipo que más se usa. Uno solo, el de mayor frecuencia diaria. Cuando ese circuito esté rodado, el siguiente cuesta la mitad porque el equipo ya sabe qué esperar.
• Luego, lo que quita trabajo administrativo. Facturación, cobros, lo que descarga a recepción.
• Al final, lo que da visibilidad. Cuadros de mando e informes: son lo más vistoso y lo menos urgente, y además necesitan que los datos anteriores lleven un tiempo entrando bien.

10.2. Por qué el último paso se salta y se paga

Ese último punto se salta a menudo y se paga: un cuadro de mando alimentado con datos que aún se están estabilizando da conclusiones falsas y quema la confianza en la herramienta justo cuando más falta hace.