Ideas clave
- FHIR transporta información estructurada, pero los perfiles y terminologías determinan si conserva significado.
- ICD-11 y las guías clínicas digitales conectan el registro asistencial con reporte, decisión y conocimiento actualizable.
- La OMS se incorporó en julio de 2026 a la Open Health Stack Software Foundation para impulsar infraestructura abierta y reutilizable.
- FHIR R5 es la versión publicada vigente; FHIR R6 continúa en proceso de desarrollo y ballot.
- Una estrategia hospitalaria debe empezar por casos de uso y gobierno, no por conectar todo indiscriminadamente.
Respuesta breve: ¿qué es una infraestructura digital abierta de salud?
Es un conjunto gobernado de estándares, servicios y componentes reutilizables que permite a distintas aplicaciones compartir información y conocimiento sin depender de integraciones irrepetibles. Abierta no significa pública ni sin controles. Significa que los contratos son transparentes, implementables y versionados, mientras identidad, autorización, consentimiento, auditoría y seguridad se aplican conforme al contexto.
En un hospital, esta infraestructura puede conectar expediente, laboratorio, imagen, farmacia, dispositivos, portales, analítica y salud pública. El objetivo no es copiar todos los datos a un solo lugar, sino permitir que cada proceso reciba la información autorizada, con significado y oportunidad suficientes para actuar.
Qué aporta FHIR y qué no resuelve por sí solo
FHIR organiza información sanitaria en recursos como Patient, Encounter, Observation, Condition, MedicationRequest y DiagnosticReport. Define formatos, relaciones, búsqueda e intercambio mediante APIs. Esto facilita aplicaciones web y móviles, integración con nube y componentes modulares. HL7 identifica R5 como la versión publicada vigente, mientras R6 se encuentra todavía en proceso de ballot; una institución debe seleccionar versión y perfiles según su ecosistema real.
FHIR no garantiza interoperabilidad semántica automática. Dos sistemas pueden enviar Observation y utilizar códigos, unidades o interpretaciones diferentes. Por eso se necesitan perfiles de implementación, conjuntos de valores, terminologías, reglas, validación y pruebas. Tampoco sustituye la gobernanza: una API técnicamente correcta puede exponer más información de la necesaria o entregar datos sin contexto clínico suficiente.
- Sintaxis: cómo se estructura y transmite el recurso.
- Semántica: qué significan códigos, unidades y relaciones.
- Proceso: cuándo se envía, quién responde y cómo se corrigen errores.
- Seguridad: quién puede acceder, para qué propósito y con qué evidencia.
- Conformidad: qué perfil y versión deben cumplir emisor y receptor.
ICD-11 como servicio terminológico digital
ICD-11 se distribuye con herramientas digitales y API. Esto permite que un sistema consulte contenidos, versiones y propiedades sin convertir la clasificación en una tabla local olvidada. La edición 2025 destacó integración FHIR API y la edición 2026 reforzó su papel como infraestructura para documentación precisa y reportes comparables.
La integración debe controlar disponibilidad, caché, actualizaciones, licenciamiento y trazabilidad. Cada diagnóstico histórico necesita conservar el sistema y la versión con los que fue registrado. Si una descripción cambia, el hospital no debe alterar retrospectivamente la decisión clínica original. La gestión terminológica es una capacidad institucional, no una función secundaria del formulario.
De la guía en PDF al conocimiento clínico ejecutable
Las guías tradicionales son esenciales, pero su implementación depende de lectura, interpretación y traducción manual a formularios, reglas y recordatorios. Las WHO SMART Guidelines buscan expresar recomendaciones y flujos de trabajo en artefactos digitales reutilizables. Esto puede reducir la distancia entre evidencia normativa y sistemas, siempre que exista adaptación local, validación clínica y gobierno de versiones.
Ejecutable no significa autónomo. Una recomendación computable necesita contexto, exclusiones, datos confiables y supervisión. El sistema debe mostrar la fuente, versión y lógica relevante, registrar excepciones y permitir que el profesional documente por qué una recomendación no aplica. La tecnología hace visible el conocimiento en el momento de decisión; no reemplaza responsabilidad clínica.
La señal estratégica de Open Health Stack en 2026
En julio de 2026, la OMS anunció su incorporación a la Open Health Stack Software Foundation. La iniciativa, alojada por Linux Foundation, busca mantener herramientas abiertas basadas en estándares como FHIR, terminologías internacionales y WHO SMART Guidelines. La noticia es relevante porque conecta estándares normativos con software reutilizable y reduce la necesidad de traducir cada guía desde cero.
Para hospitales y redes de México, la lección no es adoptar automáticamente una pila específica. La lección es diseñar para portabilidad: contratos abiertos, datos exportables, componentes sustituibles y conocimiento versionado. Una arquitectura de este tipo puede disminuir dependencia de proveedor, facilitar innovación y permitir que soluciones especializadas convivan con el HIS.
Arquitectura de referencia para un hospital interoperable
Una arquitectura sostenible separa responsabilidades. Los sistemas de registro conservan la operación; una capa de interoperabilidad gestiona contratos y transformaciones; los servicios terminológicos resuelven códigos; identidad y consentimiento controlan acceso; observabilidad detecta fallas; y una capa analítica recibe datos gobernados. Las guías computables se publican con versión, ámbito y responsables clínicos.
Esta separación evita que cada aplicación resuelva de manera distinta identidad, catálogos y seguridad. También permite evolucionar. Un hospital puede mantener interfaces HL7 v2 para flujos maduros e incorporar FHIR en nuevos casos. La modernización no exige desechar lo que funciona; exige que cada componente tenga propósito, propietario y ruta de evolución.
- Índice maestro de pacientes y reglas de identidad.
- Gateway de APIs y motor de integración con observabilidad.
- Repositorio FHIR o capa de recursos según el caso de uso.
- Servicio de terminologías y catálogos maestros.
- Autorización, consentimiento, auditoría y mínimo privilegio.
- Gestión de conocimiento clínico y versiones de reglas.
- Plataforma analítica con calidad, linaje y definiciones comunes.
Casos de uso que justifican la inversión
La infraestructura debe demostrar valor mediante procesos concretos. Conectar todo sin prioridad multiplica interfaces y riesgo. Un buen caso tiene problema visible, responsables, datos disponibles, receptor definido y una métrica de resultado. Admisión, órdenes y resultados suelen ser puntos de partida, pero cada organización debe analizar su realidad.
- Resultados de laboratorio e imagen disponibles dentro del episodio correcto.
- Conciliación de medicamentos entre servicios y transiciones.
- Resumen clínico longitudinal para continuidad autorizada.
- Protocolos y recordatorios basados en datos estructurados.
- Intercambio con pacientes, médicos tratantes y pagadores.
- Indicadores de calidad alimentados sin recaptura manual.
Seguridad, privacidad y confianza
La modularidad amplía superficies de intercambio. Cada flujo debe aplicar autenticación fuerte, autorización granular, cifrado, auditoría, propósito de uso y minimización. Los tokens no deben convertirse en permisos universales, y la existencia de una API no implica derecho de acceso. El hospital necesita revisar proveedores, dependencias, continuidad y respuesta a incidentes.
La confianza también exige calidad. Un resultado asociado al paciente incorrecto puede viajar perfectamente por FHIR y seguir siendo peligroso. Identidad, procedencia, tiempo, estado y contexto deben viajar con el dato. Las alertas de integración necesitan responsables clínicos y técnicos, tiempos de respuesta y conciliación verificable.
Cómo puede ayudar intraMed ONE
intraMed ONE funciona como plataforma modular capaz de conectar procesos clínicos, operativos, financieros, de calidad y experiencia mediante APIs gobernadas, FHIR y coexistencia con sistemas actuales. Sus componentes comparten identidad, permisos, auditoría, catálogos y analítica, reduciendo la creación de nuevas islas.
La organización puede comenzar con un caso de alto impacto, medir adopción y resultado, y después reutilizar la misma base para nuevos servicios y sedes. Así, la interoperabilidad deja de ser una colección de conectores y se convierte en una capacidad institucional inteligente y ágil, preparada para terminologías digitales, guías computables e innovación responsable.
Preguntas frecuentes
¿FHIR reemplaza a HL7 v2?
No necesariamente. Muchos hospitales mantienen HL7 v2 en flujos operativos maduros y utilizan FHIR para nuevas APIs, aplicaciones y casos de intercambio basados en recursos.
¿Cuál es la versión vigente de FHIR?
HL7 identifica FHIR R5 como la versión publicada vigente. R6 continúa en desarrollo y ballot; no debe describirse como versión final hasta su publicación formal.
¿Open Health Stack es un HIS completo?
Es un ecosistema de herramientas y componentes abiertos para infraestructura digital de salud; no debe confundirse automáticamente con un HIS hospitalario completo.
¿Qué son las WHO SMART Guidelines?
Son un enfoque para representar recomendaciones, flujos y artefactos de salud digital de forma estructurada y reutilizable, facilitando su incorporación en sistemas con adaptación y validación local.
¿Una API abierta expone datos públicamente?
No. Abierta se refiere al estándar o contrato. Los datos clínicos siguen requiriendo autenticación, autorización, privacidad, seguridad y propósito de uso.
Documentos consultados
Referencias oficiales y técnicas relacionadas con este análisis.
