Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card
FHIR frente a HL7 v2: diferencias prácticas
Mensajes HL7 v2 y recursos FHIR comparados para desarrolladores: formato, transporte, el mismo resultado de laboratorio en ambos, trampas de traducción y dónde Anpheros acepta v2.
HL7 v2 es el formato de mensaje que los sistemas hospitalarios han intercambiado desde finales de los 80 — eventos delimitados por tuberías como "paciente admitido" o "resultado de laboratorio listo" enviados entre sistemas a través de una conexión de red — mientras que HL7 FHIR es un estándar de API web donde las aplicaciones leen y escriben recursos como Paciente y Observación sobre HTTPS en JSON. No son alternativas que se eligen una vez: la mayoría de los hospitales todavía funcionan internamente con v2, las nuevas aplicaciones y las API orientadas al paciente usan FHIR, y el trabajo de integración a menudo consiste en traducir uno en el otro. Esta página los compara en los puntos que importan cuando escribes código, muestra los mismos datos en ambos y explica dónde Anpheros acepta v2.
Lado a lado
| HL7 v2 | HL7 FHIR R4 | |
|---|---|---|
| Estilo | Mensajes activados por eventos (admisión, pedido, resultado) | Recursos que usted crea, lee, actualiza, busca |
| Formato | Segmentos de texto separados por saltos de línea, campos por \|, componentes por ^ |
JSON (o XML) |
| Transporte | Generalmente MLLP sobre TCP dentro de la red del hospital | HTTPS REST |
| Consulta | Limitada; los sistemas principalmente envían | Parámetros de búsqueda, _include, historial |
| Seguridad | Nivel de red (VPN, enlaces privados) | OAuth 2.0 / SMART on FHIR, TLS, ámbitos |
| Flexibilidad | Muchos campos opcionales y segmentos Z locales; cada interfaz se negocia | Recursos base más perfiles (US Core, IPS, IGs europeos) |
| Usuarios típicos | Sistemas de EHR, laboratorio, radiología, facturación dentro de un hospital | Aplicaciones, APIs de acceso para pacientes, intercambio interorganizacional, IA |
Los mensajes v2 más comunes:
| Mensaje | Significado | Recursos FHIR más cercanos |
|---|---|---|
| ADT^A01, A03, A08 | Admisión, alta, actualización de paciente | Patient, Encounter |
| ORM / OML | Pedir una prueba | ServiceRequest |
| ORU^R01 | Resultado listo | Observation, DiagnosticReport |
| SIU | Programación | Appointment |
| MDM | Documento | DocumentReference |
El mismo resultado de laboratorio en ambos
Una línea de resultado ORU^R01 (segmento OBX):
OBX|1|NM|2093-3^Cholesterol^LN||212|mg/dL|<200|H|||F|||20261002074500
El mismo resultado como una Observación de HL7 FHIR R4, tal como Anpheros lo almacena después de importar ese mensaje:
{
"resourceType": "Observation",
"status": "final",
"category": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/observation-category", "code": "laboratory"}]}],
"code": {"coding": [{"system": "http://loinc.org", "code": "2093-3", "display": "Cholesterol [Mass/volume] in Serum or Plasma"}], "text": "Cholesterol"},
"effectiveDateTime": "2026-10-02T07:45:00Z",
"valueQuantity": {"value": 212.0, "unit": "mg/dL"},
"interpretation": [{"coding": [{"system": "http://terminology.hl7.org/CodeSystem/v3-ObservationInterpretation", "code": "H"}]}],
"referenceRange": [{"high": {"value": 200.0, "unit": "mg/dL"}}]
}
Campo por campo: OBX-3 se convierte en code, OBX-5 y OBX-6 se convierten en valueQuantity, OBX-7 referenceRange, OBX-8 interpretation, OBX-11 status, OBX-14 effectiveDateTime. HL7 publica una guía de implementación oficial de HL7 Version 2 to FHIR con mapeos para segmentos, tipos de datos y vocabularios.
Dónde fallan las traducciones
- Zonas horarias. Las marcas de tiempo de v2, como
20261002074500, a menudo no llevan desplazamiento; debe conocer la zona del remitente. FHIR requiere una zona siempre que haya una hora presente. (Anpheros lee una hora de v2 sin zona como UTC; envíe el desplazamiento si lo tiene). - Códigos locales. Muchos laboratorios colocan sus propios códigos en OBX-3 en lugar de LOINC. Una buena traducción mantiene el código local y lo mapea a LOINC cuando puede, en lugar de descartarlo.
- Envíos repetidos. Los remitentes de v2 retransmiten ante tiempos de espera. Sin un identificador estable por resultado, un almacén FHIR se llena de duplicados.
- Todo opcional. El mismo campo puede estar vacío, repetido o ser utilizado de manera diferente por dos remitentes. Valide el lado FHIR; el validador FHIR R4 muestra lo que le falta a un recurso traducido.
- Correcciones. El estado del resultado v2
C(corregido) debe actualizar la Observación existente y mantener su historial, no crear una segunda.
Cuándo usar cada uno
- Dentro de un hospital, entre sistemas existentes: v2 es generalmente lo que hablan los sistemas. Un motor de integración enruta y transforma mensajes.
- Creando una aplicación, una API de acceso para pacientes o cualquier cosa que cruce organizaciones: FHIR, con OAuth y consentimiento.
- Alimentando IA o análisis: FHIR, porque es consultable, codificado y versionado.
- Ambos: el patrón común en el mundo real: recibir v2 del laboratorio o EHR, almacenar FHIR, servir FHIR a las aplicaciones.
Dónde encaja Anpheros
Anpheros almacena registros de pacientes como FHIR R4 y acepta un tipo de mensaje HL7 v2: ORU^R01 resultados de laboratorio, enviado a través de HTTPS al conector de laboratorio (POST /v1/patients/{id}/labs/import con Content-Type: x-application/hl7-v2+er7). Cada OBX se convierte en una Observación de laboratorio con código LOINC, rango de referencia e interpretación; el ID del informe se mantiene en la procedencia y los informes reenviados se omiten. Un resultado corregido (OBX-11 = C) con un nuevo valor se almacena como una nueva Observación con estado amended; el original permanece como estaba, por lo que si su fuente envía correcciones, marque la Observación anterior entered-in-error o actualícela a través de la API FHIR. Un ejemplo práctico es API de resultados de laboratorio.
No acepta otros mensajes v2 (ADT, pedidos, programación), no escucha en MLLP y no envía v2. Para esos, un motor de integración delante de Anpheros traduce a FHIR y escribe a través de la API.
Preguntas frecuentes
¿Está FHIR reemplazando a HL7 v2?
No pronto. v2 sigue siendo la columna vertebral dentro de la mayoría de los hospitales porque funciona y está integrado en los sistemas existentes. FHIR está creciendo a su alrededor — en aplicaciones, acceso de pacientes e intercambio entre organizaciones — y ambos coexisten, a menudo con traducción entre ellos.
¿Qué es MLLP?
Minimal Lower Layer Protocol: una forma sencilla de enmarcar mensajes v2 sobre una conexión TCP, con caracteres de inicio y fin alrededor de cada mensaje y un acuse de recibo (ACK) de vuelta. FHIR utiliza HTTPS en su lugar.
¿Puedo convertir mensajes HL7 v2 a FHIR automáticamente?
Mayormente. La guía de implementación v2 a FHIR de HL7 proporciona mapeos estándar, y los motores de integración los implementan. Espere trabajo manual para códigos locales, segmentos Z, zonas horarias y cómo cada remitente utiliza campos opcionales.
¿Anpheros acepta HL7 v2?
Sí, para resultados de laboratorio: los mensajes ORU^R01 publicados a través de HTTPS al conector de laboratorio se convierten en FHIR Observations. Otros tipos de mensajes v2 y conexiones MLLP no son compatibles.
Relacionado
- Mapeo de HL7 v2 a FHIR: mapeo de segmentos y campos, y un conversor
- API de resultados de laboratorio: HL7 v2, FHIR y LOINC
- Cómo importar resultados de laboratorio a un registro FHIR
- Interoperabilidad de datos de salud
- DICOM vs FHIR: datos de imágenes y datos clínicos
- Plataforma FHIR
Try it free in the sandbox · first FHIR call in 5 minutesFree · 30 synthetic patients · no card