Respuesta corta: los datos de salud se mueven a través de cuatro capas de estándares. Los estándares de intercambio transportan los datos entre sistemas: mensajes HL7 v2, documentos CDA, recursos FHIR y DICOM para imágenes. Los estándares de modelado y almacenamiento indican cómo se estructura un registro dentro de un sistema: openEHR para registros clínicos, OMOP para bases de datos de investigación. Las terminologías dan a cada concepto un código que ambas partes entienden: SNOMED CT, LOINC, ICD, ATC, UCUM, RxNorm. Los estándares de identidad y seguridad deciden quién puede leer qué: OAuth 2.0 y SMART on FHIR, además de perfiles IHE que combinan todo lo anterior en recetas probadas. Nadie usa solo uno; un hospital suele ejecutar las cuatro capas a la vez.
El mapa
Los estándares de interoperabilidad en salud forman cuatro capas. Los estándares de intercambio (HL7 v2, CDA, FHIR, DICOM y DICOMweb) mueven datos entre sistemas, y los perfiles IHE los combinan en "recetas" probadas. openEHR estructura el registro almacenado y OMOP estructura las bases de datos de investigación. Se utilizan terminologías como SNOMED CT y LOINC, y estándares de identidad como SMART on FHIR, dentro de todos ellos.
| Capa | Estándar | Qué es | Dónde lo encuentras en 2026 |
|---|---|---|---|
| Intercambio | HL7 v2 | Mensajes delimitados por tubería (ADT, ORU, ORM, SIU) sobre MLLP | Dentro de los hospitales: admisiones, resultados de laboratorio, pedidos, programación. Sigue siendo la interfaz más común |
| Intercambio | CDA / C-CDA | Documentos clínicos XML con una parte legible por humanos y entradas codificadas | Resúmenes de alta, cartas de derivación, el C-CDA de EE. UU., resúmenes transfronterizos en MyHealth@EU |
| Intercambio | FHIR (R4, R4B, R5) | Recursos web (Patient, Observation, Condition…) sobre REST y JSON | Aplicaciones para pacientes, API nacionales, API de EHR, US Core, el formato de intercambio EHDS |
| Intercambio | DICOM y DICOMweb | Objetos de imagen con metadatos incrustados; DICOMweb es su interfaz REST | Cada escáner, PACS y visor de radiología; los visores web usan DICOMweb |
| Recetas | Perfiles IHE | Combinaciones probadas de lo anterior para un caso de uso (XDS, PIX/PDQ, XCA, SWF) | Intercambio de documentos entre hospitales y regiones, identidad del paciente, flujo de trabajo de radiología |
| Almacenamiento | openEHR | Modelo de datos clínicos basado en arquetipos para el propio registro | Plataformas de EHR hospitalarias y nacionales en partes de Europa, Escandinavia, Brasil |
| Investigación | OMOP CDM | Un modelo relacional común para la investigación observacional | Redes de investigación, evidencia del mundo real, uso secundario de EHDS |
| Terminología | SNOMED CT, LOINC, ICD-10/11, ATC, RxNorm, UCUM | Códigos para hallazgos, pruebas, diagnósticos, medicamentos, unidades | Dentro de cada uno de los estándares anteriores |
| Identidad | OAuth 2.0, OpenID Connect, SMART on FHIR, IHE XUA | Quién es el usuario y a qué puede acceder la aplicación | Cada aplicación orientada al paciente y cada plataforma de aplicaciones de EHR |
Cómo encajan las capas
Las capas de los estándares de interoperabilidad en salud encajan entre sí al realizar cada una una tarea en el mismo flujo de trabajo: un mensaje HL7 v2 transporta una orden de laboratorio, LOINC y UCUM codifican el resultado, una plataforma openEHR lo almacena, una API FHIR lo sirve a una aplicación para pacientes después de un inicio de sesión SMART on FHIR, y un documento CDA lo comparte con otro hospital.
Un análisis de sangre muestra las cuatro capas en una tarde. El pedido sale del pabellón como un mensaje HL7 v2 ORM (intercambio). El resultado del analizador regresa como un HL7 v2 ORU, con la prueba codificada en LOINC y la unidad en UCUM (terminología). El hospital lo almacena en su propia base de datos, quizás una plataforma openEHR (almacenamiento). La aplicación del paciente la lee a través de una API FHIR como una Observation, después de que el paciente inició sesión con SMART on FHIR (identidad). Si el hospital comparte el informe completo con otro hospital, puede hacerlo como un documento CDA a través de un registro IHE XDS. Si el resultado se une más tarde a una cohorte de investigación, se convierte en OMOP.
Los estándares no son competidores. Cada uno fue construido para un trabajo diferente, y reemplazar uno por otro generalmente significa reconstruir algo que ya funciona.
¿Cuál necesitas?
El estándar de interoperabilidad en salud que necesitas depende de la tarea: FHIR R4 con SMART on FHIR para aplicaciones de pacientes o clínicos, HL7 v2 para conectarse a sistemas hospitalarios existentes, DICOM y DICOMweb para imágenes, documentos CDA o FHIR para documentos completos, openEHR para almacenamiento de registros a largo plazo, OMOP para investigación, y perfiles IHE cuando dos sistemas deben comportarse de manera idéntica.
- Estás creando una aplicación para pacientes o médicos: FHIR R4, con los perfiles de tu mercado (guías de implementación), SMART on FHIR para iniciar sesión.
- Te estás conectando a los sistemas existentes de un hospital: espera HL7 v2 primero; FHIR donde el proveedor lo ofrezca. Consulta Mensajes HL7 v2 explicados.
- Manejas imágenes: DICOM para almacenamiento y transferencia, DICOMweb para cualquier cosa en un navegador, FHIR ImagingStudy solo para metadatos. Consulta DICOMweb explicado y ImagingStudy vs DICOMweb.
- Intercambias documentos completos (resúmenes, cartas): CDA donde sea obligatorio, documentos FHIR (un Bundle de tipo
document) donde puedas elegir. Consulta CDA y C-CDA explicados. - Diseñas cómo se almacena un registro durante décadas: openEHR, con FHIR como capa de intercambio. Consulta openEHR vs FHIR.
- Realizas investigaciones sobre muchos registros: OMOP, con FHIR como fuente. Consulta Uso secundario de datos de salud.
- Necesitas que dos sistemas se comporten de la misma manera: elige el perfil IHE para tu caso de uso y pruébalo.
Dónde se sitúa Anpheros
Anpheros Platform se sitúa en la capa de intercambio del mapa de estándares como un servidor FHIR R4 con acceso OAuth 2.0 y webhooks para notificaciones de cambios, recibiendo resultados de laboratorio a través de un conector desde HL7 v2 ORU, CSV o JSON. No almacena imágenes DICOM ni ofrece un servicio CDS Hooks; esos se quedan en los sistemas hospitalarios.
Anpheros Platform es un servidor FHIR R4 con los recursos que necesita un registro centrado en el paciente (Patient, Observation, Condition, MedicationStatement, DocumentReference, DiagnosticReport, Immunization, Consent, Provenance y otros), OAuth 2.0 para el acceso y webhooks para notificaciones de cambios. Los resultados de laboratorio llegan a través del conector de laboratorio desde HL7 v2 ORU, CSV o JSON. No almacena imágenes DICOM y no ofrece un servicio CDS Hooks; estos permanecen en los sistemas del hospital, y el registro apunta a ellos.
Orden de lectura
Un buen orden de lectura para los estándares de interoperabilidad en salud comienza con qué es FHIR y en qué se diferencia de HL7 v2, luego el recurso FHIR Observation, luego las terminologías LOINC y SNOMED CT utilizadas dentro de él, luego DICOMweb para imágenes, CDA para documentos y finalmente openEHR comparado con FHIR sobre cómo se almacenan los registros.
Si eres nuevo en el campo: Qué es FHIR → HL7 vs FHIR → FHIR Observation → LOINC y SNOMED CT → DICOMweb → CDA → openEHR vs FHIR.
Páginas relacionadas
- HL7 vs FHIR
- Mensajes HL7 v2 explicados
- CDA y C-CDA explicados
- DICOMweb explicado
- openEHR vs FHIR
- Guías de implementación FHIR
- FHIR R4 vs R5
- ¿Qué es un código LOINC?
- ¿Qué es SNOMED CT?
- DICOM vs FHIR para desarrolladores
- Perfiles y extensiones FHIR explicados
- Servidores de terminología FHIR explicados
- Mapa de regulación de datos de salud
- Registros electrónicos de salud nacionales en Europa y EE. UU.
- Integración de sistemas hospitalarios explicada
- IA sobre datos médicos
- Uso secundario de datos de salud
- Seguridad e identidad en aplicaciones de salud
Fuentes
- HL7 International: estándares
- Especificación HL7 FHIR R4
- Estándar DICOM, edición actual
- Marcos técnicos IHE
- Especificaciones openEHR
- Modelo de Datos Común OMOP de OHDSI
- SMART App Launch
Preguntas frecuentes
¿Está FHIR reemplazando a todos los demás estándares?
No. FHIR está reemplazando a las API personalizadas y, lentamente, a algunos intercambios de documentos CDA. HL7 v2 sigue siendo el caballo de batalla dentro de los hospitales, DICOM sigue siendo el único estándar para imágenes, y openEHR y OMOP responden preguntas (almacenamiento, investigación) para las que FHIR no fue diseñado.
¿Cuál es la diferencia entre un estándar y un perfil IHE?
Un estándar como FHIR o DICOM define bloques de construcción. Un perfil IHE selecciona bloques específicos, fija sus opciones y dice exactamente cómo los sistemas deben usarlos para una tarea, de modo que dos proveedores que aprueban las pruebas IHE puedan trabajar juntos sin un proyecto.
¿Qué estándar utilizan los sistemas nacionales de salud?
La mayoría de los sistemas europeos comenzaron con documentos CDA y HL7 v2, y están agregando API FHIR; el formato de intercambio EHDS se basa en FHIR y el IPS. EE. UU. exige FHIR US Core para el acceso del paciente y C-CDA para el intercambio de documentos.
¿Dónde encajan SNOMED CT y LOINC?
No son estándares de intercambio; son vocabularios utilizados dentro de todos ellos. Un código LOINC identifica la prueba en un segmento OBX de HL7 v2, una entrada CDA y una Observation de FHIR por igual.
Pruébalo gratis en el sandbox
Tu primera llamada FHIR en 5 minutos. Una API HL7 FHIR R4 con el consentimiento del paciente integrado: pruébala en el sandbox y luego conecta tu propia app o sistema de clínica.
Gratis · 30 pacientes sintéticos · sin tarjeta
Anpheros crea un historial médico que el paciente controla y puede compartir con cualquier clínica, en una plataforma HL7 FHIR R4, con sede en la UE. Estas guías te ayudan a entender y organizar tu salud; no reemplazan a tu médico.
Sobre Anpheros →