Todo el procesamiento ocurre localmente en tu navegador. Tus mensajes HL7 y PHI nunca salen de tu dispositivo. Compatible con HIPAA.
Suelta un archivo .hl7 o .txt aquí, o pega abajo
Convirtiendo…
Pega tu mensaje HL7 v2.x en el área de texto, o arrastra y suelta un archivo .hl7 / .txt sobre la zona de arrastre.
Elige el modo de salida: Simplificado (claves de campo como PID.5) o Estilo HAPI (claves de componentes de tipo de datos como PID.5.1).
Activa 'Sangría de 2 espacios' para añadir indentación, o 'Descifrar secuencias de escape HL7' para resolver \F\, \S\ y \T\ en la salida.
Haz clic en 'Convertir a JSON'. Revisa la vista lado a lado — HL7 fuente a la izquierda, JSON a la derecha.
Copia el JSON al portapapeles o descárgalo como archivo .json. Usa 'Nueva Conversión' para procesar otro mensaje.
El modo simplificado produce claves planas legibles (PID.5, OBX.5) ideales para inspección rápida. El modo estilo HAPI emite claves de componentes nominadas que reflejan la serialización JSON de la librería HAPI de Java, útil al comparar con sistemas que generan JSON HAPI.
Maneja todos los tipos de segmentos estándar: MSH, PID, PV1, OBR, OBX, ORC, NTE, NK1, DG1, IN1, GT1, MRG y más. Parsea campos repetidos (delimitador ~), componentes (delimitador ^) y subcomponentes.
Resuelve opcionalmente las secuencias de escape: \F\ → |, \S\ → ^, \T\ → &, \R\ → ~, \E\ → \. Conserva la forma codificada cuando el descifrado está desactivado.
Tras la conversión, visualiza el HL7 fuente original y el JSON resultante en paneles adyacentes de sólo lectura para verificar campo a campo que la conversión es correcta.
Todo el procesamiento se ejecuta en tu navegador. Tus mensajes HL7 y cualquier PHI que contengan nunca salen de tu dispositivo. Compatible con HIPAA.
A diferencia de los conversores en la nube, esta herramienta se ejecuta enteramente en tu navegador. Ningún contenido de mensaje, identificador de paciente o PHI se transmite. Puedes usarla en una estación de trabajo aislada o detrás de un cortafuegos hospitalario sin riesgo.
El modo simplificado es ideal para búsquedas rápidas de campos y construcción de reglas ETL ligeras. El modo HAPI es ideal cuando integras con un sistema Java basado en HAPI y necesitas coincidir con su formato JSON de salida, ahorrando horas de reimplementación.
Los mensajes HL7 v2.x en producción usan retornos de carro inconsistentes, campos finales faltantes y segmentos repetidos. El parser maneja todos estos casos límite para que obtengas JSON válido incluso de entradas no ideales.
Combina con el Visor HL7 para inspección a nivel de segmento, el Navegador de Segmentos para definiciones de campos y el Generador ACK para simular respuestas. Un flujo de trabajo HL7 completo sin salir del sitio.
HL7 v2.x es un formato de texto delimitado por tuberías y posicional diseñado a finales de los años 80. Su estructura es precisa pero opaca para las herramientas modernas: la mayoría de las APIs REST, almacenes NoSQL, pipelines ETL y plataformas de análisis esperan JSON. Convertir mensajes HL7 a JSON los hace accesibles para consultas SQL, procesamiento en JavaScript, análisis en Python y almacenamiento en bases de datos de documentos como MongoDB o Elasticsearch, sin modificar los sistemas de destino.
Un mensaje HL7 v2.x es una secuencia de segmentos delimitados por retornos de carro. Cada segmento comienza con un nombre de tres caracteres (MSH, PID, OBX). Los campos dentro de un segmento están separados por el carácter separador de campos (normalmente |). Los campos pueden contener componentes separados por ^, subcomponentes separados por & y repeticiones separadas por ~. Los dos primeros campos del segmento MSH establecen estos caracteres de codificación, por lo que un parser conforme los lee dinámicamente.
En modo simplificado, el convertidor emite un objeto JSON por ocurrencia de segmento, con valores de campo clave como SEG.N (p.ej., PID.5 para el campo de nombre del paciente). Los campos de un solo valor se convierten en cadenas; los campos con componentes se convierten en arrays. Este formato es fácil de indexar en cualquier almacén de documentos y directo de consultar con jq o el módulo json de Python.
HAPI (HL7 Application Programming Interface) es la librería Java más utilizada para el procesamiento de HL7 v2.x. Cuando HAPI serializa un mensaje a JSON, nombra los componentes con el descriptor del tipo de dato HL7. Los sistemas que emiten o consumen JSON HAPI (Epic Bridges, canales Rhapsody, adaptadores Ensemble) producen o esperan esta forma. Si estás construyendo un sistema que debe coincidir con la salida de HAPI, seleccionar modo estilo HAPI ahorra horas de reimplementación.
Los segmentos HL7 pueden repetirse: un mensaje de resultado ORU^R01 puede tener docenas de segmentos OBX, cada uno con una medición de laboratorio diferente. El convertidor asigna un índice de ocurrencia a los segmentos repetidos para que OBX[1], OBX[2], OBX[3] se mantengan distintos en la salida JSON. Las repeticiones de campo (múltiples valores dentro de un campo, separados por ~) se conservan como arrays.
HL7 v2.x utiliza un mecanismo de escape con barra invertida para representar los cinco caracteres de codificación reservados dentro de los valores de campo: \F\ para el separador de campo (|), \S\ para el separador de componente (^), \R\ para el separador de repetición (~), \T\ para el separador de subcomponente (&) y \E\ para el carácter de escape (\). Cuando la opción de descifrado está activada, el convertidor resuelve estos a sus caracteres literales en la salida JSON.
En HL7 v2.x, un campo vacío (||) significa "no proporcionado" y un campo de comillas dobles (|""|) significa "eliminar explícitamente el valor anterior". El convertidor mapea campos vacíos a null de JSON para distinguirlos de campos ausentes, diferencia que importa cuando se usa el JSON para realizar actualizaciones de base de datos.
Los patrones de integración comunes que se benefician de la conversión HL7 a JSON incluyen: alimentar datos demográficos HL7 (PID, PV1) a un índice maestro de pacientes basado en REST; poblar Elasticsearch con resultados de laboratorio (OBX) para análisis; probar la lógica de conversión FHIR parseando primero el mensaje HL7 fuente a JSON y luego mapeando rutas JSON a campos de recursos FHIR; y registrar mensajes en forma estructurada en CloudWatch o Datadog donde el texto delimitado por tuberías no es buscable.
Para propósitos de integración, JSON es típicamente una forma intermedia que no necesita reconstruir el mensaje HL7 original. Sin embargo, si se requiere fidelidad de ida y vuelta, debes conservar los campos nulos, preservar las repeticiones como arrays ordenados y mantener las secuencias de escape codificadas (desactivar la opción de descifrado). El modo simplificado es menos adecuado para ida y vuelta porque omite nombres de componentes; el modo estilo HAPI preserva suficiente estructura para la reconstrucción.
En programas de integración reales, la conversión de HL7 a JSON suele actuar como puente entre feeds legacy y capas modernas de observabilidad o APIs. Los equipos usan la salida JSON para alimentar bases de datos de staging, comparar payloads antes y después de una transformación en tests automatizados y generar logs estructurados buscables para responder a incidencias. Como la salida se genera localmente, los analistas pueden validar mappings con mensajes realistas antes de copiar el JSON resultante a jobs ETL, especificaciones de transformación o cuadernos de conversión a FHIR.
El convertidor también sirve como herramienta de aclaración contractual cuando varios equipos discrepan sobre el significado de un campo. En lugar de debatir el conteo de pipes por correo, puedes inspeccionar la estructura parseada exacta, confirmar cómo se leen repeticiones y componentes y documentar la ruta JSON acordada que deben usar los consumidores downstream. Eso reduce la ambigüedad en tickets de interfaces y facilita alinear a analistas HL7, ingenieros backend y equipos de datos alrededor del mismo modelo de mensaje.
Un analista que aplana campos repetidos para un panel de laboratorio pega un ORU^R01 sintético con una docena de segmentos OBX en modo simplificado, confirmando que cada resultado obtiene su propia entrada indexada en lugar de sobrescribir el último — el modo de fallo exacto de un parser ingenuo línea a línea que asume un solo OBX por mensaje.
Un ingeniero que iguala la salida de un motor de interfaces basado en Java pega el mismo mensaje sintético en modo estilo HAPI y compara las claves nominadas por componentes resultantes con lo que el motor realmente emite, detectando una suposición de tipo de dato incorrecta antes de escribir una sola línea de código de mapeo.
Un tercer flujo comprueba la seguridad de ida y vuelta antes de construir un pipeline de conversión a FHIR. Convertir un mensaje sintético con la opción de descifrado desactivada, y luego confirmar que cada campo nulo, repetición y secuencia de escape sobrevivió intacta en el JSON, verifica que la salida puede transformarse de nuevo a HL7 más adelante si un sistema downstream necesita el formato de cable original.
Esto es una transformación estructural, no un validador — convierte a JSON los segmentos y campos que encuentra, pero no comprueba que los campos obligatorios estén presentes ni que un mensaje cumpla el esquema de un tipo de mensaje concreto. También convierte un mensaje a la vez; un archivo con varios mensajes concatenados necesita dividirse primero en los límites MSH, ya que la conversión por lotes no está integrada. Y como las claves de tipo de dato del modo estilo HAPI provienen de una tabla fija de tipos comunes (XPN, XAD, CX, CWE y similares), un tipo de dato poco común o personalizado recae en una clave genérica en lugar de una totalmente nombrada — trata eso como una señal para revisar el campo manualmente en lugar de asumir que el nombrado está completo.
| Aspecto | Modo simplificado | Modo estilo HAPI |
|---|---|---|
| Formato de clave | Plano, p. ej. PID.5 | Componentes nominados, p. ej. PID.5.FN.1 |
| Ideal para | Búsquedas rápidas, ETL ligero | Igualar el JSON propio de un sistema Java/HAPI |
| Seguridad de ida y vuelta | Limitada — se pierden los nombres de componentes | Mejor — estructura suficiente para reconstruir HL7 |
Un mensaje HL7 que se convierte para un sistema downstream es exactamente el tipo de dato que HIPAA clasifica como información sanitaria protegida — nombre del paciente, MRN, diagnósticos, valores de laboratorio. Como este convertidor analiza y serializa por completo en el JavaScript propio de tu navegador, un ingeniero de integración puede convertir un mensaje real de producción en una estación de trabajo hospitalaria y saber que el contenido nunca cruzó la red como parte del paso de conversión, algo relevante cuando el JSON resultante va destinado a una base de datos de staging o un banco de pruebas en lugar de un sistema de producción con sus propios controles.
La conversión suele ser una parada más en un camino más largo. Inspecciona primero los segmentos y campos de un mensaje en el Visor HL7, busca la definición de un campo poco familiar en el Navegador de Segmentos HL7, y convierte el mensaje aquí solo cuando tengas claro qué significa cada campo. Ese orden mantiene el JSON resultante honesto sobre lo que realmente contenía el mensaje origen.
No. Todo el procesamiento se ejecuta en tu navegador con JavaScript. Ningún contenido de mensaje, PHI o datos de paciente se transmite. Puedes verificarlo en la pestaña de red de las herramientas de desarrollador de tu navegador.
El modo simplificado clave campos como SEG.N (p.ej., PID.5) y representa componentes como arrays, fácil de leer y consultar. El modo HAPI usa claves de componentes de tipo de datos nominadas (p.ej., PID.5.1) que reflejan la salida JSON de la librería HAPI de Java.
HL7 v2.x (v2.1 a v2.9). El parser lee los caracteres de codificación de MSH-1 y MSH-2, por lo que maneja cualquier versión v2.x sin necesitar un selector de versión.
Todavía no. La herramienta espera un solo mensaje por conversión. Para archivos por lotes, divide por líneas MSH y convierte cada mensaje individualmente.
Resuelve las secuencias de escape de barra invertida de HL7 a sus caracteres literales: \F\ → |, \S\ → ^, \T\ → &, \R\ → ~, \E\ → \. Desactívala si necesitas un JSON de ida y vuelta seguro que pueda recodificarse de vuelta a HL7.
Los segmentos repetidos (p.ej., múltiples OBX en un resultado ORU) se emiten como objetos separados en el array de segmentos con un contador de 'ocurrencia'. El modo simplificado también los agrupa por nombre de segmento con claves indexadas.
Los campos vacíos (||) aparecen como null en JSON, y los componentes vacíos de campos no vacíos aparecen como entradas nulas del array. Esto preserva la distinción semántica entre 'no proporcionado' y 'ausente'.
El diseño de privacidad de la herramienta (procesamiento local, sin transmisión de datos) es consistente con los requisitos de salvaguardas técnicas de HIPAA. Sin embargo, el cumplimiento también depende de la seguridad de tu puesto de trabajo, la configuración del navegador y las políticas organizacionales.
El parser verifica un segmento MSH válido y caracteres de codificación correctos. Si la validación falla, se muestra un mensaje de error explicando qué salió mal. No se emite JSON parcial para evitar salida incorrecta silenciosa.
El modo estilo HAPI preserva suficiente estructura para la reconstrucción con una librería conforme. El modo simplificado pierde nombres de componentes, por lo que la reconstrucción de ida y vuelta no es fiable. Desactiva la opción de descifrado para conservar las secuencias de escape intactas.
Aprende cuándo usar HL7 v2 a JSON antes de un pipeline de ingesta FHIR, qué debe preservar ese JSON y cómo evitar pérdida de datos en la modernización.
Leer más →
Aprende a convertir mensajes HL7 v2.x a JSON con salida simplificada o estilo HAPI: mapeo de campos, secuencias de escape y patrones de integración.
Leer más →
Aprende a mapear HL7 PID y PV1 a JSON sin perder identificadores, contexto de visita, repeticiones ni semantica de nulos en pipelines ADT.
Leer más →