TL;DR - Resumen Ejecutivo
HL7 es la familia de estándares más utilizada para intercambio de información clínica desde 1987. FHIR (Fast Healthcare Interoperability Resources) es su evolución moderna, basada en APIs REST y JSON, lanzada en 2014 y adoptada masivamente desde 2019. En trazabilidad de dispositivos médicos, FHIR provee recursos específicos (Device, DeviceUseStatement, DeviceDefinition) que permiten consultar por API qué dispositivos se usaron en qué paciente, con qué lote y por qué profesional. Para un hospital chileno moderno, adoptar FHIR en nuevos desarrollos mientras se mantienen integraciones HL7 v2 legacy es la estrategia recomendada. Los costos varían entre 15 y 200+ millones CLP según alcance; herramientas open source como HAPI FHIR y Mirth Connect reducen significativamente la inversión.
Definiciones Oficiales
HL7 (Health Level Seven): organización internacional sin fines de lucro que desarrolla estándares para intercambio electrónico de información clínica, administrativa y logística entre aplicaciones de salud. El "7" refiere a la capa de aplicación del modelo OSI.
FHIR (Fast Healthcare Interoperability Resources): estándar de interoperabilidad desarrollado por HL7 International que define "recursos" clínicos accesibles mediante APIs RESTful con formatos JSON y XML, diseñado para ser fácil de implementar con herramientas web modernas.
La historia: del papel a las APIs
Antes de HL7, cada hospital desarrollaba integraciones punto-a-punto entre sus sistemas. Un hospital con HIS + laboratorio + radiología + farmacia podía terminar con 12 interfaces personalizadas, cada una rota con cada actualización. En 1987, un grupo de profesionales de sistemas de salud fundó HL7 con un objetivo simple: crear un lenguaje común para el intercambio clínico.
La evolución ha pasado por tres grandes generaciones:
HL7 v2 (1987-presente)
Mensajes planos delimitados por pipes (|) y acentos circunflejos (^). Extremadamente extendido: según HL7.org, más del 95% de hospitales de EE.UU. usan HL7 v2 para al menos una integración. Ejemplo: PID|1||12345||GONZÁLEZ^FELIPE||19800615|M|||...
HL7 v3 / CDA (2005)
Basado en un modelo formal (RIM - Reference Information Model) y XML. Potente pero complejo, con baja adopción fuera de CDA (Clinical Document Architecture) que sí se usa ampliamente para historia clínica estructurada.
FHIR (2014, DSTU2)
Revolución de diseño: APIs REST, JSON/XML, modelo de recursos discretos y reutilizables. La comunidad lo adopta masivamente por su compatibilidad con tecnologías web modernas.
FHIR R4 (2019)
Versión "normative" estable para los recursos principales (Patient, Observation, etc.). Base para los mandatos regulatorios en EE.UU. (ONC Cures Act) y la adopción masiva en Europa y LATAM.
FHIR R5 (2023) y más allá
Refinamientos, nuevos recursos, subscription API para datos en tiempo real, mejor soporte para investigación clínica y genómica. Los hospitales implementan R4 como base, con ojo en R5 para casos específicos.
HL7 v2: el workhorse silencioso
A pesar de tener 35+ años, HL7 v2 sigue siendo el estándar de facto en integraciones hospitalarias. Es probable que hoy mismo, en cualquier hospital mediano de Chile, estén viajando miles de mensajes HL7 v2 entre HIS, laboratorio y radiología sin que nadie los vea.
Anatomía de un mensaje HL7 v2
Un mensaje HL7 v2 se compone de segmentos (líneas), cada uno con un código de 3 letras y múltiples campos delimitados:
Ejemplo: admisión de paciente (mensaje ADT^A01)
MSH|^~\&|HIS|HOSPITAL|LAB|CENTRAL|202506120830||ADT^A01|MSG00001|P|2.5 EVN|A01|202506120830 PID|1||12345^^^HOSPITAL^MR||GONZÁLEZ^FELIPE||19800615|M|||AV. APOQUINDO 1234^^SANTIAGO^^7550000||+56912345678 PV1|1|I|CARDIO^301^A||||DR.SILVA||||||||||||
Interpretación: el HIS envía al laboratorio una admisión (A01) del paciente Felipe González (RUT 12345), hombre, nacido el 15-jun-1980, admitido en Cardiología cama 301-A bajo el Dr. Silva.
Tipos de mensajes HL7 v2 más usados
| Tipo | Uso | Ejemplo de Evento |
|---|---|---|
| ADT | Admisión, alta, traslado | A01 (admisión), A08 (actualización), A03 (alta) |
| ORM / OMG | Órdenes clínicas | Solicitud de examen de laboratorio o imagen |
| ORU | Resultados de observaciones | Resultados de laboratorio, informes radiológicos |
| SIU | Agendamiento | Cita médica, programación quirúrgica |
| DFT | Transacciones financieras | Cargos, pagos, facturación |
| MDM | Documentos clínicos | Epicrisis, informes, consentimientos |
FHIR: la nueva generación
FHIR fue diseñado desde cero para la web moderna. En lugar de mensajes transaccionales, expone recursos clínicos como endpoints REST. Un desarrollador familiar con APIs web (Stripe, Twilio, GitHub) puede aprender FHIR en semanas, lo que contrasta con meses o años para HL7 v2/v3.
Principios de diseño de FHIR
- Recursos discretos: cada entidad (paciente, observación, medicamento) tiene un modelo formal reutilizable.
- RESTful: operaciones CRUD estándar (GET, POST, PUT, DELETE) y búsqueda parametrizada.
- Formatos múltiples: mismo contenido en JSON, XML, Turtle (RDF).
- Extensibilidad: mecanismo formal de extensiones para casos específicos sin romper interoperabilidad.
- Perfiles y guías de implementación: organizaciones/países publican "perfiles" que restringen o extienden FHIR para su contexto.
- Human-readable: cada recurso incluye una sección narrativa HTML para que no-técnicos entiendan el contenido.
Ejemplo: recurso Patient en FHIR
GET /Patient/12345 (respuesta JSON)
{
"resourceType": "Patient",
"id": "12345",
"identifier": [{
"system": "http://hospital.cl/mrn",
"value": "12345"
}],
"name": [{
"family": "González",
"given": ["Felipe"]
}],
"gender": "male",
"birthDate": "1980-06-15",
"address": [{
"line": ["Av. Apoquindo 1234"],
"city": "Santiago",
"postalCode": "7550000"
}],
"telecom": [{
"system": "phone",
"value": "+56912345678"
}]
}
HL7 v2 vs FHIR: tabla comparativa
| Característica | HL7 v2 | FHIR |
|---|---|---|
| Año de lanzamiento | 1987 | 2014 (R4 estable 2019) |
| Formato de datos | Texto plano delimitado (pipes) | JSON, XML, RDF |
| Paradigma | Mensajería transaccional | APIs RESTful (recursos) |
| Transporte | MLLP sobre TCP (típico) | HTTPS (REST estándar) |
| Curva de aprendizaje | Alta (3-6 meses) | Moderada (2-4 semanas dev web) |
| Herramientas web modernas | Escasas | Amplias (Postman, Swagger, SDK) |
| Seguridad | VPN, IPsec (fuera del protocolo) | OAuth 2.0, SMART on FHIR, TLS |
| Casos de uso fuertes | Integraciones intra-hospitalarias | Apps móviles, portales, APIs públicas |
| Adopción global | 95%+ hospitales EE.UU. | Creciente rápidamente |
| Mejor para | Sistemas legacy y eventos transaccionales | Nuevos desarrollos y ecosistema de apps |
FHIR aplicado a trazabilidad de dispositivos médicos
La trazabilidad en salud es uno de los casos de uso donde FHIR brilla especialmente. Los recursos relevantes son:
1 Device
Representa un dispositivo médico específico: identificador UDI, fabricante, modelo, número de serie, lote, fecha de expiración, estado (activo, inactivo, implantado). Es la piedra angular.
2 DeviceUseStatement
Documenta el uso del dispositivo en un paciente: cuándo se implantó/aplicó, quién lo hizo, dónde (anatómicamente), por qué (indicación). Vincula Device con Patient.
3 DeviceDefinition
Define el tipo genérico del dispositivo (ejemplo: "Stent coronario liberador de zotarolimus 3.0x18mm"), independiente de unidades específicas. Útil para catálogos.
4 SupplyDelivery / SupplyRequest
Gestiona solicitudes y entregas de insumos desde bodega a servicios clínicos. Clave en automatización del supply chain.
Ejemplo práctico: Device con UDI
POST /Device
{
"resourceType": "Device",
"udiCarrier": [{
"deviceIdentifier": "00614141999996",
"issuer": "http://hl7.org/fhir/NamingSystem/gs1",
"carrierHRF": "(01)00614141999996(11)230101(21)SN123456"
}],
"status": "active",
"manufacturer": "MedDevices Inc.",
"manufactureDate": "2023-01-01",
"expirationDate": "2028-01-01",
"lotNumber": "LOT-2023-789",
"serialNumber": "SN123456",
"modelNumber": "CX-300",
"type": {
"coding": [{
"system": "http://snomed.info/sct",
"code": "448596008",
"display": "Coronary artery stent"
}]
}
}
Con este modelo, una consulta como GET /Device?lot-number=LOT-2023-789 devuelve todos los dispositivos de ese lote, y GET /DeviceUseStatement?device.lot-number=LOT-2023-789 devuelve todos los pacientes que los recibieron — en segundos. Esta capacidad es crítica para respuesta rápida ante recalls.
Arquitectura de integración: patrones comunes
Motor de integración (Integration Engine)
La pieza central en la mayoría de hospitales. Recibe mensajes HL7 v2 de un sistema, los transforma (si es necesario) y los reenvía a los destinos. Herramientas líderes:
- Mirth Connect (NextGen): open source, comunidad amplia, el más usado en LATAM.
- Rhapsody (Lyniate): comercial enterprise, potente.
- Cloverleaf (InterSystems): motor histórico, robusto.
- IRIS for Health (InterSystems): evolución moderna con FHIR nativo.
- Apache Camel + HAPI: opción open source para equipos con capacidad de desarrollo.
Servidor FHIR
Expone APIs REST con los recursos FHIR. Puede ser el corazón de un nuevo sistema o un gateway frente a un sistema legacy. Opciones principales:
- HAPI FHIR (Java): open source líder, mantenido por Smile CDR.
- Medplum (TypeScript): moderno, cloud-first, ideal para startups.
- Microsoft Azure API for FHIR: PaaS gestionado, ideal para hospitales con Azure.
- Google Cloud Healthcare API: PaaS similar en GCP.
- Aidbox (Firely): comercial con opciones flexibles.
- Blaze FHIR Server (Samply): open source, enfocado en investigación.
Gateway HL7 v2 ↔ FHIR
Traduce entre ambos mundos: recibe un ORU^R01 (resultado de laboratorio en HL7 v2) y lo convierte en un recurso Observation FHIR, disponible vía API para apps modernas. Permite modernizar progresivamente sin reemplazar integraciones existentes.
Fase 1 — Mantener HL7 v2 funcionando
Inventariar todas las integraciones HL7 v2 existentes, documentarlas y monitorear su estabilidad. No romper lo que funciona.
Fase 2 — Introducir servidor FHIR
Desplegar HAPI FHIR o equivalente. Poblar inicialmente con recursos Patient y Encounter mediante pipelines desde el HIS.
Fase 3 — Integrar gateway
Mirth Connect o similar escucha mensajes HL7 v2 y los transforma a recursos FHIR en tiempo real, manteniendo sincronización.
Fase 4 — Exponer APIs a apps
Portal del paciente, apps de médicos, sistemas de investigación consumen datos vía FHIR con SMART on FHIR para seguridad.
Fase 5 — Nuevos desarrollos FHIR-first
Todo sistema nuevo se construye contra el servidor FHIR como fuente de verdad, reduciendo progresivamente la dependencia de HL7 v2.
Seguridad: SMART on FHIR y OAuth 2.0
Una API FHIR pública sin autenticación es un desastre de seguridad (y legal) esperando ocurrir. El framework estándar es SMART on FHIR, que combina:
- OAuth 2.0: autorización delegada, el usuario no comparte contraseña con la app.
- OpenID Connect: autenticación de identidad.
- Scopes granulares FHIR: la app solicita permisos específicos (ejemplo:
patient/Observation.readpero nouser/*.write). - Contexto de lanzamiento: la app recibe el paciente y encuentro actual del EHR.
Consideraciones de seguridad chilenas
Los datos clínicos son datos sensibles bajo la Ley 19.628 (Protección de Datos Personales). La nueva Ley de Protección de Datos (aprobada 2024, en implementación) y la Ley 21.663 Marco de Ciberseguridad elevan los requisitos. Toda API FHIR debe: usar HTTPS obligatoriamente, cifrar datos en reposo, auditar accesos con retención de al menos 5 años, implementar MFA para usuarios privilegiados, aplicar anonimización o pseudonimización en usos secundarios (investigación). Ver también requisitos de acreditación hospitalaria.
IHE: integración lista para producción
IHE (Integrating the Healthcare Enterprise) no compite con HL7 o FHIR: los combina en "perfiles" específicos para casos reales. Un perfil IHE dice: "para resolver el caso X, usen estas operaciones de estos estándares de esta forma". Perfiles relevantes para trazabilidad:
| Perfil IHE | Función |
|---|---|
| PIX / PDQ | Identificación cruzada y demografía de pacientes entre sistemas |
| XDS / XDS.b | Compartir documentos clínicos entre instituciones (CDA) |
| XDS-I | Compartir estudios de imagen — ver nuestro artículo RIS PACS |
| MHD | Mobile Health Documents — XDS adaptado a FHIR |
| mACM | Mobile Alert Communication Management — alertas clínicas |
| PCC | Patient Care Coordination — continuidad asistencial |
FHIR en el ecosistema de salud chileno
Chile está adoptando FHIR progresivamente. Iniciativas relevantes:
- Registro Nacional de Prestadores (RNPI): servicios gubernamentales explorando FHIR para Practitioner y Organization.
- Ficha Clínica Electrónica (FCE): recomendaciones Minsal incluyen estándares HL7 v2, CDA y creciente adopción FHIR.
- HL7 Chile: capítulo nacional que promueve adopción y publica guías de implementación localizadas.
- Proyectos privados: varias clínicas privadas (Clínica Las Condes, Alemana, Santa María, Indisa) han implementado servidores FHIR internos.
- Interoperabilidad transfronteriza: iniciativas con Argentina y Perú para intercambio FHIR en casos de urgencia de turistas.
FHIR es al sector salud lo que REST fue al desarrollo web hace 15 años: no una mejora incremental, sino un cambio de paradigma que habilita casos de uso imposibles con el modelo anterior.
Grahame Grieve, creador de FHIR, HL7 International
Casos de uso concretos por área
Farmacia hospitalaria
Prescripción electrónica completa basada en FHIR: MedicationRequest del médico, MedicationDispense del químico, MedicationAdministration de la enfermera. Cada acción queda trazada, auditada y disponible para análisis. Integración con catálogos ATC y códigos ISP.
Laboratorio clínico
ServiceRequest desde el HIS, Specimen al recibir la muestra, DiagnosticReport con Observations al emitir resultado. Compatibilidad total con LOINC para codificación de exámenes.
Imagenología
Integración con RIS y PACS mediante el perfil IHE XDS-I, o directamente con ImagingStudy en FHIR. El recurso contiene referencias a las imágenes DICOM en el PACS.
Investigación clínica
Plataformas de investigación multicéntrica extraen datos anonimizados vía FHIR para entrenar algoritmos de IA o estudios clínicos. El recurso ResearchStudy modela el estudio y ResearchSubject los participantes.
Trazabilidad e implantes
Todos los implantes (stents, marcapasos, prótesis, válvulas) quedan registrados como Device con UDI. Ante un recall, una query FHIR identifica en segundos a todos los pacientes afectados. Para detalle ver artículos sobre stents coronarios y vasculares.
Checklist para implementar HL7 FHIR
- Diagnóstico inicial: inventario de sistemas y sus integraciones actuales, identificar brechas y casos de uso prioritarios.
- Gobernanza: sponsor ejecutivo (CIO o Dirección Médica), comité multidisciplinario (IT, informática biomédica, calidad, servicios clínicos).
- Estrategia: coexistencia HL7 v2 + FHIR, no reemplazo big-bang. Definir roadmap 2-3 años.
- Selección tecnológica: servidor FHIR (HAPI, Medplum, cloud), motor de integración (Mirth Connect), herramientas de monitoreo.
- Perfiles y guías: definir perfiles FHIR propios para el hospital (ejemplo: Patient con campos obligatorios locales como RUT).
- Mapeos de datos: ejercicio crítico — mapear campos del HIS legacy a recursos FHIR; documentar formalmente.
- Seguridad: implementar OAuth 2.0 / SMART on FHIR, cifrado en tránsito y reposo, auditoría de accesos.
- Testing: usar FHIR Validator, Touchstone, Postman collections; simular escenarios reales antes de producción.
- Capacitación: desarrolladores (tutoriales FHIR), analistas (mapeos), usuarios (impacto funcional).
- Piloto controlado: iniciar con un caso de uso acotado (ejemplo: API de Patient para portal del paciente), medir y ajustar.
- Documentación: publicar capability statement, guías de integración, SDK/ejemplos para desarrolladores internos y partners.
- Mejora continua: monitoreo de performance, latencia, errores; evolución según FHIR R5 y regulaciones locales.
Errores comunes al implementar HL7/FHIR
7 errores que hacen fracasar proyectos
- Intentar FHIR-first sin plan para legacy: ignorar las integraciones HL7 v2 existentes lleva a parálisis. Coexistir, no reemplazar.
- No modelar perfiles locales: usar FHIR "vainilla" sin adaptar a RUT, Fonasa, códigos Minsal genera datos inconsistentes.
- Subestimar los mapeos: los campos del HIS legacy rara vez mapean limpiamente a FHIR. Presupuestar tiempo real (semanas/recurso).
- Ignorar la seguridad: exponer FHIR con autenticación básica o sin OAuth 2.0 es grave violación regulatoria.
- No validar con FHIR Validator: recursos que "parecen correctos" pueden fallar en producción con otras implementaciones.
- Centralizar demasiado: un solo servidor FHIR para todo el hospital puede volverse cuello de botella; considerar federación.
- Obviar el monitoreo: APIs sin observabilidad (logs, métricas, alertas) fracasan en operación real.
Glosario de términos clave
Vocabulario esencial de interoperabilidad en salud
Health Level Seven. Familia de estándares y la organización que los desarrolla para intercambio de información clínica y administrativa.
Fast Healthcare Interoperability Resources. Estándar moderno de HL7 basado en APIs REST y recursos JSON/XML.
Unidad básica de información en FHIR, autodescriptiva y con identidad propia (Patient, Observation, Device, etc.).
Personalización de un recurso base para un contexto específico (país, institución, caso de uso), restringiendo o extendiendo campos.
Documento FHIR que declara qué recursos y operaciones soporta un servidor. Permite a clientes descubrir capacidades dinámicamente.
Framework que combina FHIR con OAuth 2.0 y OpenID Connect para autorización segura de aplicaciones clínicas.
Integrating the Healthcare Enterprise. Organización que publica perfiles de integración combinando HL7, DICOM y otros estándares.
Minimal Lower Layer Protocol. Protocolo de transporte sobre TCP tradicionalmente usado para HL7 v2.
Logical Observation Identifiers Names and Codes. Estándar para codificar observaciones clínicas y de laboratorio. Usado masivamente en FHIR.
Systematized Nomenclature of Medicine — Clinical Terms. Terminología clínica más completa a nivel mundial. Chile cuenta con licencia nacional.
Clinical Document Architecture. Estándar HL7 v3 para documentos clínicos estructurados (epicrisis, informes). Aún ampliamente usado.
Software que recibe, transforma y enruta mensajes entre sistemas. Ejemplos: Mirth Connect, Rhapsody, Cloverleaf.
Preguntas Frecuentes sobre HL7 y FHIR
¿Qué es HL7 y para qué sirve?
HL7 (Health Level Seven) es un conjunto de estándares internacionales para intercambio electrónico de información clínica y administrativa entre sistemas de salud. Fue creado en 1987 y resuelve el problema de que cada sistema hospitalario hable "su propio idioma". HL7 define tanto la estructura de los mensajes como los flujos de eventos para que los sistemas puedan intercambiar datos sin desarrollos personalizados.
¿Qué es FHIR y en qué se diferencia de HL7?
FHIR (Fast Healthcare Interoperability Resources) es la evolución moderna de HL7, basada en APIs REST y formatos web estándar (JSON, XML). Mientras HL7 v2 usa mensajes de texto plano con pipes y HL7 v3 usa XML complejo, FHIR estandariza la información en recursos accesibles vía HTTP con verbos CRUD. FHIR es más fácil de implementar y compatible con arquitecturas modernas.
¿Cuál es la diferencia entre HL7 v2, HL7 v3 y FHIR?
HL7 v2 (1987): mensajes planos delimitados por pipes, muy extendido. HL7 v3 (2005): basado en XML y RIM complejo, adopción limitada. CDA (parte de v3): documentos clínicos estructurados, usado en historia clínica. FHIR (2014, estable 2019): basado en recursos REST y JSON/XML, adopción creciente globalmente. En Chile conviven los tres; la tendencia es FHIR para nuevos desarrollos.
¿Qué son los recursos FHIR?
Los recursos (Resources) son las unidades básicas de información en FHIR, cada uno representando una entidad clínica o administrativa. Ejemplos: Patient, Practitioner, Encounter, Observation, Medication, MedicationRequest, Device, DiagnosticReport. Son auto-contenidos, tienen identificadores únicos, versionado y referencias cruzadas. Existen alrededor de 150 recursos en la especificación actual.
¿Cómo se usa FHIR para trazabilidad de dispositivos médicos?
FHIR provee recursos específicos: Device representa el dispositivo con UDI, fabricante, modelo, lote, vencimiento. DeviceUseStatement documenta el uso del dispositivo en un paciente. DeviceDefinition define el tipo genérico. Supply maneja insumos. Combinando estos recursos mediante una API FHIR, un hospital puede consultar qué pacientes tienen dispositivos del lote X implantados con consultas HTTP estándar.
¿HL7 FHIR es obligatorio en Chile?
No es obligatorio por ley específica, pero las tendencias regulatorias empujan hacia su adopción: la normativa de ficha clínica electrónica del Minsal recomienda estándares interoperables, los proyectos de historia clínica única se basan en FHIR, y la acreditación hospitalaria valora la interoperabilidad. La recomendación es adoptarlo en nuevos desarrollos aunque no sea aún obligatorio.
¿Cómo se implementa una API FHIR en un hospital?
Proceso típico: (1) Elegir servidor FHIR (HAPI FHIR, Medplum, Firely, Aidbox o cloud). (2) Modelar los recursos FHIR necesarios. (3) Mapear datos del sistema legacy hacia recursos FHIR. (4) Implementar autenticación SMART on FHIR u OAuth 2.0. (5) Desplegar APIs con HTTPS y publicar capability statement. (6) Probar con herramientas como Postman o FHIR Validator. Adopción incremental por recursos.
¿Qué es SMART on FHIR?
SMART (Substitutable Medical Applications, Reusable Technologies) on FHIR es un framework que combina FHIR con OAuth 2.0 y OpenID Connect para permitir que aplicaciones de terceros accedan de forma segura a datos clínicos. Una aplicación SMART puede integrarse a distintos HIS que soporten el framework sin desarrollo específico. Es la base de los marketplaces de apps clínicas.
¿Cuánto cuesta implementar interoperabilidad HL7/FHIR?
Varía según alcance: motor de integración básico HL7 v2 entre 2 sistemas desde 5 millones CLP; servidor FHIR on-premise con HAPI FHIR más integración con HIS: 15-50 millones; solución empresarial completa con cloud FHIR, mapeos múltiples y auditoría: 80-200+ millones. Open source reduce costos pero incrementa esfuerzo interno.
¿Qué herramientas open source existen para HL7 FHIR?
Las principales: HAPI FHIR (Java, el más popular), Medplum (TypeScript, cloud-first), LinuxForHealth FHIR (IBM), Firely Server, Aidbox, Blaze FHIR Server. Para HL7 v2: Mirth Connect (motor de integración open source líder), NextGen Connect, HL7apy (Python). Para FHIR clients: SDK oficial de HL7 en varios lenguajes.
¿Qué es el IHE y cómo se relaciona con HL7?
IHE (Integrating the Healthcare Enterprise) no crea estándares; publica perfiles de integración que combinan HL7, DICOM y otros estándares para resolver casos de uso específicos. Ejemplos: PIX, PDQ, XDS-I, SWF. Implementar un perfil IHE garantiza compatibilidad con otros vendedores certificados. IHE publica guías técnicas detalladas que referencian HL7 y FHIR.
¿FHIR puede reemplazar totalmente a HL7 v2?
En teoría sí, en la práctica convivirán por muchos años. HL7 v2 tiene 35+ años de implementaciones legacy. La estrategia práctica es: mantener HL7 v2 para integraciones existentes; usar FHIR para nuevos desarrollos, acceso web/móvil, APIs públicas, integración con aplicaciones SaaS. Varias organizaciones operan gateways que traducen HL7 v2 ↔ FHIR.
Conclusión
HL7 y FHIR no son tecnologías opcionales en salud moderna: son los cimientos sobre los que se construye cualquier sistema clínico interoperable. La estrategia ganadora no es "FHIR o nada", sino coexistencia inteligente: mantener HL7 v2 para integraciones legacy estables, adoptar FHIR para nuevos desarrollos, apps móviles y APIs públicas, y unir ambos mundos con gateways de traducción. Las herramientas open source (HAPI FHIR, Mirth Connect) hacen accesible la implementación incluso para hospitales con presupuesto acotado. En Hemodynamics implementamos sistemas de trazabilidad de dispositivos médicos y investigación multicéntrica integrados vía HL7 y FHIR con el stack tecnológico del hospital.