Mientras un centro es pequeño, «integrarse» significa exportar un Excel a final de mes. A partir de cierto tamaño eso se rompe: el laboratorio manda resultados, la contabilidad pide asientos, la nómina necesita las horas y radiología tiene su propio sistema. Si nada de eso viaja solo, el crecimiento se paga en horas de administración.
Este artículo explica, para quien decide y no para quien programa, qué significa interoperabilidad en un centro sanitario, qué son HL7 y FHIR, y qué hay que exigir a cada proveedor para que la integración no acabe en un cajón.
Cuándo deja de valer el fichero manual
Hay tres señales bastante fiables de que ha llegado el momento:
- Alguien teclea dos veces lo mismo. Un dato que se copia de un sistema a otro es un dato que tarde o temprano se copia mal.
- Los informes llegan tarde. Cuando la dirección pide cifras y la respuesta es «te lo preparo para el lunes», el problema no es la persona: son los sistemas.
- Cada sede lo hace distinto. Sin integración, cada centro inventa su apaño y ninguno es auditable.
HL7 v2 y FHIR: qué son y por qué conviven
Los dos son estándares de la misma organización, HL7, para que sistemas sanitarios distintos se entiendan. La diferencia es la época en que nacieron:
- HL7 v2 es mensajería clásica: mensajes de texto muy compactos que viajan entre sistemas para avisar de un ingreso, una petición de prueba o un resultado. Es viejo, poco vistoso y está en todas partes: la mayoría de los sistemas de laboratorio y radiología instalados hablan v2.
- FHIR (se pronuncia «fire») es el estándar moderno: una API web con recursos —paciente, cita, observación, informe— que se consultan como cualquier servicio de internet. Es lo que se pide en los proyectos nuevos.
Conviven porque nadie tira un sistema que funciona solo por cambiar de estándar. Lo normal en un centro grande es FHIR hacia fuera, v2 hacia dentro, con una capa que traduce. Y junto a ellos aparece siempre DICOM, que no es un competidor: es el formato de las imágenes médicas y del PACS donde se guardan.
El estándar no es el objetivo. El objetivo es que un resultado llegue solo a la ficha correcta.
Qué hay que conectar, por capas
Antes de hablar de tecnología conviene dibujar el mapa. En un centro grande casi siempre son cuatro capas:
La capa de abajo no es negociable: la facturación verificable y el control horario son obligaciones legales, y en un grupo con varias sociedades tienen su propia complejidad —lo vemos en TicketBai y VeriFactu en grupos con varias sedes—. La capa de arriba es la que ve el paciente y la que suele estar peor conectada: una reserva de cita online que no escribe en la agenda real no es una integración, es un formulario.
API, conector o fichero: qué pedir en cada caso
No todas las integraciones merecen la misma inversión. Tres niveles, de más a menos:
- API en tiempo real. Lo correcto cuando el dato se necesita al momento: disponibilidad de agenda, resultado que condiciona la consulta, pago. Es lo más caro de construir y lo único que aguanta volumen.
- Conector programado. Sincroniza cada X minutos u horas. Suficiente para contabilidad, nómina o inventario. Barato y muy estable.
- Fichero de intercambio. Un CSV o un XML que alguien deja en una carpeta. Vale como puente temporal; no como arquitectura. Si a los seis meses sigue ahí, se ha convertido en deuda.
- Documentación de la API accesible, no bajo acuerdo de confidencialidad.
- Entorno de pruebas donde equivocarse sin tocar datos reales.
- Qué pasa si falla: reintentos, alertas y a quién se avisa.
- Quién es responsable de los datos en tránsito, por contrato.
- Coste de mantenerla, no solo de construirla.
Señales de que una integración va a salir mal
Después de unas cuantas, los avisos se repiten siempre:
- «Nuestra API está en el roadmap». Una integración que depende de algo que aún no existe no se puede planificar.
- Nadie sabe quién es el dueño del dato. Si el paciente puede cambiar su teléfono en dos sistemas, hay que decidir cuál manda antes de conectar nada.
- No hay identificador estable. Cruzar pacientes por nombre y apellidos garantiza duplicados; hace falta una clave común y una estrategia para los casos dudosos.
- Se prueba en producción. Sin entorno de pruebas, el primer error lo paga un paciente.
- No hay presupuesto de mantenimiento. Toda integración se rompe: cambia una versión, caduca un certificado. Lo que no se mantiene, se cae.
Cómo lo abordamos en byclinics
Nuestro equipo desarrolla sobre .NET y Azure, y las integraciones se hacen proyecto a proyecto: conectamos la app de gestión con laboratorios, dispositivos, pasarelas de pago, contabilidad y los sistemas que ya tenga el centro, con entorno de pruebas y mantenimiento incluido en el acuerdo. Lo puedes ver en desarrollo a medida y en cuándo compensa el software a medida.
Somos honestos con el alcance: byclinics es la plataforma de gestión de un centro o un grupo, no un sistema de información hospitalaria para un hospital público. Cuando hace falta hablar con un RIS, un LIS o una contabilidad concreta, se estudia la integración y se dice claramente qué es viable y qué no. Si estás organizando un grupo, empieza por software para clínicas con varias sedes.
Preguntas frecuentes
HL7 v2 es mensajería entre sistemas, muy extendida en laboratorio y radiología desde hace décadas. FHIR es el estándar moderno de la misma organización: una API web con recursos como paciente, cita u observación. En un centro real conviven: FHIR para lo nuevo, v2 para lo que ya está instalado.
Solo si vas a intercambiar información clínica con otros sistemas: laboratorio, imagen, un hospital de referencia o una aseguradora. Un grupo de clínicas que únicamente conecta contabilidad, nómina y web no lo necesita; le basta con una API o un conector programado.
Sí, y es una de las integraciones que más tiempo ahorra: la petición sale desde la ficha y el resultado vuelve a ella sin que nadie transcriba nada. El detalle depende del sistema del laboratorio y de si expone HL7, FHIR o un servicio propio; se valora antes de comprometer plazos.
Menos de lo que tarda en decidirse quién es el dueño de cada dato. La parte técnica de un conector sencillo son semanas; lo que alarga los proyectos es no tener documentación de la otra parte, no disponer de entorno de pruebas o descubrir a mitad que los pacientes no se pueden cruzar por un identificador fiable.
No. byclinics es la plataforma de gestión de clínicas, centros grandes y grupos multicentro: agenda, historia clínica, facturación e informes, con integraciones a medida cuando hacen falta. Un hospital con quirófanos, urgencias y farmacia hospitalaria necesita otra categoría de producto.
¿Tienes que conectar tu centro con otros sistemas?
Cuéntanos qué hay al otro lado —laboratorio, radiología, contabilidad— y te decimos qué es viable, cómo y con qué esfuerzo.
Hablar con el equipo técnicoNota: este artículo es divulgativo. La viabilidad de cada integración depende de los sistemas concretos que haya en el centro y de lo que expongan sus fabricantes; se valora caso por caso antes de comprometer alcance o plazos.