ERP sanitario de código abierto: qué significa de verdad la soberanía del dato en tu clínica

1. El problema real del vendor lock-in

Durante la última década, muchos administradores de clínicas se han visto atrapados en plataformas SaaS cerradas que prometían simplicidad a cambio de algo caro: subidas de cuota sin negociación posible, comisiones opacas por volumen de citas, y un bloqueo de facto que dificulta migrar los historiales el día que se quiere cambiar de proveedor.

1.1. Cómo se nota el bloqueo, en la práctica

No suele ser un contrato que lo prohíba explícitamente. Es más sutil: el volcado de datos que se entrega en un formato propietario difícil de interpretar, la exportación que solo cubre parte de los campos, o un proceso de salida que tarda semanas de gestiones. El resultado práctico es el mismo que un bloqueo formal, aunque nadie lo haya escrito en ningún sitio.

1.2. Qué cambia con un núcleo de código abierto

obeliOmed está construido sobre un núcleo ERP de código abierto en su capa contable y relacional, con una capa de especialización clínica encima: historia clínica por especialidad, agenda, consentimientos, quirófano. Esa base no es una promesa de marketing, es una elección de arquitectura: una base de datos MySQL estándar, sin formatos propietarios que solo el proveedor sepa leer.

La diferencia no se nota el primer mes de uso, cuando todo software parece razonable. Se nota el día que hace falta un informe que nadie previó, una integración con un servicio externo que no estaba en el catálogo del proveedor, o simplemente la decisión de cambiar de sistema. Con un esquema legible y estándar, esas tres situaciones se resuelven con trabajo de consulta sobre datos que se entienden; con un formato propietario opaco, la primera pregunta siempre es «¿esto se puede hacer, o depende de que el proveedor lo permita?».

2. Qué significa que la base de datos sea tuya

«Tus datos son tuyos» es una frase que dicen casi todos los proveedores. Lo que distingue una promesa real de una vacía es lo que pasa el día que pides el volcado completo.

2.1. Exportación completa, no un PDF plano

Cada centro puede descargar en cualquier momento una copia completa de sus propios datos: pacientes, historiales, imágenes en formato estándar, registros administrativos. No es un informe resumido ni una exportación parcial pensada para dificultar el uso posterior: es la base de datos, estructurada, tal y como está.

2.2. Un esquema legible, no una caja negra

La base de datos es MySQL estándar, con un esquema relacional convencional: no hay campos cifrados de forma opaca para que solo el proveedor original pueda leerlos, ni una capa propietaria intermedia que haga falta descifrar para entender qué hay guardado. Esto es lo que de verdad separa un ecosistema abierto de uno cerrado: no que puedas alojarlo tú mismo, sino que lo que se guarda ahí se entiende y se puede volver a usar en otro sitio si algún día hace falta.

Es una diferencia técnica concreta, no una cuestión de confianza en la palabra del proveedor: cualquier persona con conocimientos de bases de datos puede conectarse a un volcado MySQL estándar y entender la estructura sin documentación adicional, algo que no ocurre con un formato binario propietario diseñado para leerse solo con el software original.

3. Construido sobre un núcleo de código abierto

Un error habitual al digitalizar un centro médico es implantar un software clínico que resuelve bien la parte asistencial pero se queda corto en la contable, y obliga a duplicar el trabajo en herramientas externas para facturar o gestionar el IVA.

3.1. El motor contable del núcleo

obeliOmed integra de forma nativa el motor contable de un núcleo ERP de código abierto ya maduro en España en materia de contabilidad, conciliación bancaria y gestión de proveedores. Sobre esa base contable se construye la capa médica: historias clínicas por especialidad, consentimientos informados con firma digital y control de flujos de sala de espera, todo dentro del mismo sistema.

3.2. Qué aporta esto en el día a día

Facturación, remesas bancarias e IVA se gestionan directamente desde el acto médico, sin exportar a una pasarela externa ni volver a teclear el mismo dato dos veces. La gestión clínica con ERP integrado es justo esto: contabilidad y clínica en el mismo sistema, no dos programas cosidos con exportaciones manuales.

El caso donde más se nota es la administración que hoy exporta la agenda del día a una hoja de cálculo para cuadrar cobros con el banco a mano. Con el motor contable integrado, cada cobro queda ya vinculado al acto médico que lo generó, así que conciliar una remesa es revisar coincidencias, no reconstruir a mano qué cita corresponde a qué ingreso.

4. Cifrado y dónde viven tus datos

La soberanía del dato no depende solo de dónde vive la base de datos, sino de qué protección real tiene mientras está ahí.

4.1. Qué está cifrado, y con qué

Los datos se alojan en servidores situados en España. Los documentos clínicos y los campos sensibles del expediente van cifrados con AES-256-GCM —cada tipo de dato con una clave derivada distinta— y la conexión viaja bajo TLS 1.3. No se promete «todo el expediente cifrado» como bloque opaco: se cifran los documentos y los campos marcados como sensibles, que es lo que de verdad importa proteger.

4.2. Trazabilidad, que es lo que de verdad hay

Ningún cambio se pierde: cuando alguien corrige una prueba o un dato del expediente, queda registrado quién lo hizo, cuándo y qué valor había antes. Es trazabilidad verificable, la misma que exige la Ley 41/2002, y es un compromiso más sostenible que prometer un almacenamiento que nadie puede modificar nunca. El detalle del marco de protección de datos completo está en la checklist de auditoría RGPD.

Lo que está protegido también es lo que se puede sacar cuando hace falta.

5. Frente a un SaaS cerrado: la comparación honesta

La diferencia no está en que uno sea «mejor software» que otro en abstracto. Está en tres puntos concretos que sí se pueden comparar con hechos.

5.1. Propiedad y salida de los datos

En muchas plataformas cerradas, el acceso a tus propios datos está limitado por lo que la API del proveedor decide exponer, y la exportación completa no siempre está disponible sin negociar. En obeliOmed la base de datos es MySQL estándar y exportable al completo en cualquier momento, sin depender de que el proveedor habilite un endpoint concreto.

5.2. Estructura de costes y evolución

Las suscripciones por usuario con comisiones adicionales por cita o por almacenamiento son habituales en el sector; el desglose de qué se paga y por qué conviene mirarlo con cuidado en cualquier proveedor, obeliOmed incluido. Quien ya usa otro sistema y se plantea el cambio puede ver la comparativa entre obeliOmed y Doctoralia con criterios concretos en vez de adjetivos.

La pregunta que de verdad separa un modelo de otro no es cuánto cuesta el primer mes, sino qué pasa cuando la clínica crece: si cada especialista adicional o cada módulo nuevo dispara una renegociación con el proveedor, o si el precio sigue las mismas reglas transparentes que el primer día. Eso se comprueba pidiendo el desglose completo antes de firmar, no leyendo la página de precios en diagonal.

6. Contabilidad y clínica en el mismo sistema

La capa médica que se construye sobre el núcleo contable no es un añadido superficial: son módulos pensados para el flujo real de una consulta.

6.1. Historia clínica modular por especialidad

Los campos de la historia clínica electrónica se adaptan a la especialidad del centro —oftalmología, psicología, medicina estética, medicina general— sobre el mismo núcleo de gestión, así que un centro multidisciplinar no necesita un sistema distinto por cada especialidad que atiende.

6.2. Facturación y remesas desde el acto médico

Los libros de facturación, las remesas bancarias y el IVA se generan automatizados directamente desde el acto médico registrado, sin que nadie tenga que volver a introducir el mismo dato en una herramienta de contabilidad aparte. Es la pieza que más horas administrativas ahorra cuando el volumen de actos facturables crece.

7. VeriFactu y cumplimiento normativo

El nuevo reglamento de facturación antifraude español —conocido como VeriFactu— afecta a cualquier centro que emita facturas, clínicas incluidas.

7.1. Qué exige la normativa

VeriFactu exige que los sistemas de facturación generen registros de facturación inalterables y trazables, con posibilidad de remisión a la Agencia Tributaria. El detalle completo de qué obliga y a quién está desarrollado en la guía de facturación médica, donde VeriFactu tiene su propio apartado.

7.2. Qué hace el sistema al respecto

El motor de facturación de obeliOmed está pensado para adaptarse a estos requisitos según se van concretando en su desarrollo reglamentario, dentro del mismo flujo de facturación que ya usa la clínica para sus actos médicos, sin una herramienta añadida aparte solo para este fin.

8. Cómo es una migración real

Migrar de un sistema propietario cerrado a uno construido sobre una base abierta es la parte que más frena la decisión, y suele dar más miedo del que merece si se planifica bien.

8.1. Qué se extrae y cómo se valida

El proceso típico parte de la extracción de los datos del sistema de origen, su depuración —duplicados, campos mal mapeados, formatos inconsistentes— y su validación contra el histórico antes de dar por buena la migración. El detalle metodológico completo está en la guía sobre migración de historiales médicos sin pérdidas.

8.2. La actividad no se detiene mientras tanto

La operativa diaria de la clínica sigue en el sistema actual mientras la migración se prepara y se valida en paralelo, y el cambio operativo se planifica para un momento de baja actividad. No es una migración que obligue a parar la consulta ni a trabajar con dos sistemas a la vez durante semanas enteras: el objetivo del proceso es justo evitar ese escenario.

La migración real convive con la actividad diaria; no la sustituye de golpe.

9. Precio y cómo empezar

El modelo de precio no cambia por estar construido sobre un núcleo abierto: sigue siendo transparente y por plan, sin letra pequeña.

9.1. Cómo se compone el precio

El plan 29 € al mes cubre a un profesional que trabaja solo; el plan 49 € añade un administrativo y agenda compartida; y el plan 79 € está pensado para un equipo con varias sedes. Sin coste de alta ni permanencia en la contratación mensual. Puedes calcular tu configuración exacta en la calculadora de precios.

9.2. El primer paso, si estás evaluando el cambio

La forma más honesta de comprobar el ajuste a tu clínica es verlo funcionando con tus propios datos en una demo, no con un recorrido genérico de funciones. Antes de la demo conviene tener claro qué información quieres poder exportar y con qué frecuencia, para comprobarlo en la propia sesión, en lugar de darlo por hecho y descubrir la respuesta meses después de haber migrado.