O arrastra un archivo .hl7 aquí
Validando…
| Severidad | Ubicación | Regla | Mensaje |
|---|
Todo el procesamiento ocurre localmente en tu navegador. Tus mensajes HL7 y PHI nunca salen de tu dispositivo. Compatible con HIPAA.
Pega tu mensaje HL7 v2.x en el área de texto, o arrastra y suelta un archivo .hl7 / .txt en la zona de arrastre.
Haz clic en 'Validar'. El validador parsea el mensaje y aplica reglas estructurales y de contenido HL7 v2.x.
Revisa las tarjetas resumen en la parte superior: número de errores, avisos y elementos informativos detectados.
Inspecciona la tabla de incidencias — cada fila muestra severidad, ubicación (segmento, campo, línea), la regla violada y una explicación legible.
Corrige las incidencias en tu sistema de origen, pega el mensaje corregido y vuelve a validar. Repite hasta que el informe no muestre errores.
Valida los caracteres de codificación en MSH-1/MSH-2, la estructura del segmento MSH, presencia de segmentos requeridos por tipo de mensaje (ADT, ORM, ORU, SIU, MDM, ACK, QRY, RSP, RDE, VXU, DFT), campos requeridos por segmento, formato de tipos de dato (DTM, DA, TM, NM) y valores de tablas de códigos (PV1.2, PID.8, MSA.1, ORC.1, OBX.2, MSH.11).
Distingue errores (debe arreglarse), avisos (probable bug) e info (puede ser intencional). Las tarjetas de conteo y los badges con color te permiten triaje rápido — arregla errores primero, atiende avisos antes de desplegar y usa info para detectar patrones sospechosos pero técnicamente válidos.
Cada incidencia apunta a la ocurrencia exacta del segmento, índice de campo y número de línea (1-based) en el texto pegado. Puedes saltar directo al campo problemático en tu editor o motor de interfaces sin contar pipes manualmente.
Maneja las desviaciones HL7 v2.x comunes en tráfico de producción: líneas \r\n en lugar de \r, campos finales faltantes, líneas en blanco extra, mezcla de Latin-1 y UTF-8. El validador inspecciona lo que realmente hay en lugar de rechazar al parsear.
Todo el parseo y la validación ocurren en tu navegador. El mensaje HL7 y cualquier PHI que contenga nunca salen de tu dispositivo. Apto para estaciones de hospital, clínica, laboratorio y aseguradora.
Los validadores en la nube te obligan a enviar datos de paciente a un tercero — algo difícil de aceptar para seguridad hospitalaria y una posible exposición HIPAA. Este validador corre 100% en tu navegador y no hace llamadas de red durante la validación. Puedes usarlo en una estación air-gapped.
La mayoría de validadores HL7 marcan toda desviación como error y te entierran en ruido. Este prioriza las incidencias que realmente rompen interfaces en producción: PID.3 ausente, MSH-7 mal formado, códigos ack inconsistentes. Errores primero, luego avisos, luego info.
Cada incidencia cita la regla HL7 específica que se violó (p.ej., 'MSH structure: encoding-chars-mismatch', 'PID.8 not in HL7 0001'). Puedes copiar el ID de regla a un ticket para que el equipo upstream entienda exactamente qué arreglar.
Combina el validador con el HL7 Viewer para inspeccionar segmentos crudos, el Segment Browser para definiciones de campo, el ACK Generator para simular respuestas downstream y el conversor HL7 a JSON para alimentar mensajes ya validados a pipelines modernos. Resolución HL7 completa sin salir del sitio.
La mayoría de las interfaces HL7 v2.x en producción son técnicamente no-conformes en algún punto: un campo final faltante, un código ack no estándar, una fecha en YYYY-MM-DD en vez de YYYYMMDD. Muchas sobreviven en producción durante años porque el sistema receptor resulta ser tolerante. Pero el día que cambias de proveedor, migras de motor de interfaces o pasas a una plataforma más estricta como un validador basado en HAPI, esos bugs latentes salen a la superficie como mensajes que fallan en procesarse. La validación pre-vuelo te permite encontrarlos y arreglarlos en tu cronograma, no en el de la fecha de go-live de la integración.
Capa 1: Codificación y estructura. El primer carácter después de MSH establece el separador de campo (casi siempre |). Los siguientes cuatro caracteres establecen los caracteres de codificación: componente (^), repetición (~), escape (\) y subcomponente (&). Un validador debe leerlos dinámicamente y rechazar mensajes que declaran un set en MSH-2 pero usan otros distintos en el cuerpo.
Capa 2: Segmentos y campos requeridos. Cada tipo de mensaje (el valor en MSH-9, p.ej. ADT^A01) tiene una estructura definida: qué segmentos deben aparecer, cuáles son opcionales y cuáles pueden repetirse. Un ADT^A01 requiere MSH, EVN, PID y PV1; faltar PV1 es un error. Un ORU^R01 requiere MSH, PID, OBR y al menos un OBX. El validador recorre el mensaje contra la estructura del tipo y marca segmentos requeridos faltantes.
Capa 3: Tipos de dato y tablas de códigos. Aun cuando la estructura es correcta, los campos individuales pueden llevar valores inválidos. PID.8 (sexo administrativo) debe ser uno de M, F, O, U, A, N. PV1.2 (clase de paciente) debe ser uno de E, I, O, P, R, B, C, N, U. MSA.1 (código de confirmación) debe ser uno de AA, AE, AR, CA, CE, CR. Campos datetime como MSH-7 deben cumplir el datatype DTM (YYYYMMDDHHMMSS[.S[S[S[S]]]][+/-ZZZZ]). Un validador que captura estas violaciones de superficie evita que parsers downstream rechacen el mensaje.
Un error significa que el mensaje fallará en la mayoría de receptores — MSH ausente, segmento requerido ausente, codificación mal formada. Un aviso significa que el mensaje es aceptado por receptores tolerantes pero rechazado por estrictos — códigos no estándar, fechas débilmente tipadas, campos opcionales pero comúnmente requeridos. Un hallazgo nivel info marca patrones que cumplen el spec pero son sospechosos en tráfico real — por ejemplo, un PID sin PID.3 (lista de identificadores de paciente), técnicamente opcional en algunos tipos de mensaje pero casi siempre indicativo de un problema upstream del MPI.
MSH-2 declara los caracteres de codificación usados en el resto del mensaje. El valor por defecto es ^~\&. Un patrón común de bug es un emisor que hardcodea el string estándar en MSH-2 pero realmente emite un carácter de escape distinto en los cuerpos de campo (p.ej., usa % en lugar de \). Receptores que leen MSH-2 dinámicamente (el comportamiento correcto) malinterpretan las secuencias de escape o las dejan sin resolver. El validador detecta esto verificando que las secuencias de escape que aparecen en valores de campo usan el carácter declarado en MSH-2.
Este validador exige los segmentos requeridos para los tipos de mensaje más comunes:
HL7 v2.x define varios datatypes primitivos cuyo formato puedes validar sin consultar un registro externo. DTM (fecha/hora): YYYYMMDDHHMMSS con segundos fraccionarios y offset de zona horaria opcionales. DA (fecha): YYYYMMDD. TM (hora): HHMMSS. NM (numérico): signo opcional seguido de dígitos y parte decimal opcional. El validador corre verificaciones de formato sobre estos datatypes cuando el schema dicta un valor tipado (p.ej., MSH-7 es DTM, OBX-5 es variable pero se verifica contra el código de tipo de valor en OBX-2).
El validador incluye las tablas de códigos operacionalmente más importantes: HL7 0001 (sexo), HL7 0004 (clase de paciente), HL7 0008 (código ack), HL7 0103 (processing ID), HL7 0119 (order control) y HL7 0125 (tipo de valor). Cuando un campo cuyo datatype está restringido a una de estas tablas lleva un valor que no está en la lista, el validador marca un aviso en lugar de un error — muchos sistemas extienden intencionalmente estas tablas con valores específicos del sitio, así que la acción más limpia es marcar y dejar que el analista decida.
Un uso típico del validador se ve así. Un analista de interfaces recibe una queja de que un feed ADT está siendo rechazado por el EHR downstream. Pega el mensaje fallido en el validador y de inmediato ve dos errores: PV1 ausente y MSH-7 mal formado (2024-03-15T09:30 en vez de 20240315093000). Marca la aplicación emisora upstream, adjunta el informe de validación al ticket y el equipo upstream sabe exactamente qué arreglar. El ciclo que antes requería sacar logs del motor de interfaces, ojear texto delimitado por pipes y discutir con un soporte de proveedor colapsa a menos de un minuto.
Este validador no realiza conformidad completa contra un perfil externo (p.ej., una especificación personalizada de un proveedor o una guía de implementación nacional). No verifica reglas de lógica de negocio como 'OBR-7 debe ser igual o posterior a OBR-25' o 'PV1.44 debe estar presente cuando PV1.2 = I'. No valida segmentos Z (segmentos personalizados fuera del estándar HL7). Para esas verificaciones necesitas un validador con perfil como NIST MWB o un validador HAPI personalizado. El rol de esta herramienta es atrapar el 80% de incidencias que son independientes del perfil y bloquearían cualquier procesador downstream.
Una vez que el validador surfacea una incidencia, el siguiente paso es arreglar el sistema upstream que produce el mensaje. Para errores de segmento requerido, trabaja con la aplicación emisora para añadir el segmento o, si el segmento es genuinamente opcional en tu versión del spec, documenta la desviación y configura el receptor para aceptarlo. Para errores de datatype, arregla el formateador origen. Para avisos de tabla de códigos, alinea el valor a la tabla estándar o extiende explícitamente los valores permitidos en el receptor. El validador te da la cita exacta de la regla necesaria para conducir esa conversación.
No. Todo el parseo y validación corre en tu navegador con JavaScript. No se transmite contenido del mensaje, PHI ni datos del paciente. Puedes confirmarlo en la pestaña de red de las herramientas de desarrollo del navegador.
HL7 v2.x (v2.1 a v2.9). El validador lee los caracteres de codificación de MSH-1 y MSH-2 dinámicamente, así que funciona en cualquier versión v2.x sin requerir un selector de versión.
Los errores son violaciones que serán rechazadas por la mayoría de receptores — MSH ausente, segmento requerido ausente para el tipo de mensaje, caracteres de codificación mal formados, MSH estructuralmente inválido. Los avisos son problemas que receptores tolerantes aceptan pero los más estrictos rechazan — códigos no estándar, fechas débilmente formadas, campos opcionales pero esperados ausentes. Los items info marcan patrones que cumplen el spec pero son sospechosos en tráfico real.
ADT, familia ORM (OMG/OMI/OML/OMP/OMS/OMD), familia ORU (ORF/ORG/ORI/ORL/ORN/ORP/ORR/ORS), SIU, MDM, ACK, QRY/RSP, RDE, VXU y DFT. Otros tipos de mensaje se parsean pero solo se aplican reglas estructurales generales.
HL7 0001 (sexo administrativo), HL7 0004 (clase de paciente), HL7 0008 (código ack), HL7 0103 (processing ID), HL7 0119 (order control), HL7 0125 (tipo de valor). Los valores fuera de estas tablas se marcan como avisos, no errores, ya que algunos sistemas las extienden intencionalmente.
No. Los segmentos Z se parsean pero no se validan contra reglas. La conformidad específica de perfil (p.ej., una guía de implementación de proveedor) requiere un validador con perfil como NIST MWB. Este validador apunta a reglas HL7 v2.x estándar e independientes de perfil.
Sí — los datatypes DTM (fecha/hora), DA (fecha), TM (hora) y NM (numérico) se verifican por formato. El validador corre la verificación cuando el schema indica un campo tipado, p.ej., MSH-7 (DTM), PID-7 (DTM), OBX-5 contra el tipo de valor declarado en OBX-2.
Cada incidencia cita el nombre del segmento, índice de ocurrencia (p.ej., segundo OBX), índice de campo 1-based y número de línea en el texto pegado. Puedes saltar directo al campo problemático en tu editor sin contar pipes manualmente.
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. El cumplimiento también depende de la seguridad de tu estación, configuración del navegador y políticas organizacionales — consulta con tu oficial de cumplimiento.
El validador lee MSH-1 y MSH-2 para descubrir los caracteres de codificación realmente en uso, así que mensajes con codificaciones no por defecto se validan correctamente. Si MSH-2 declara un set de caracteres pero los cuerpos de campo usan otro carácter de escape, el validador marca la inconsistencia.
El Viewer renderiza el mensaje como árbol estructurado para inspección. El Segment Browser es una referencia de búsqueda para definiciones de segmentos y campos. El Validador corre reglas automatizadas y produce un informe pasa/falla. Son complementarios — úsalos juntos al investigar una interfaz.
Que significan los caracteres de codificacion del segmento MSH en HL7? Guia campo a campo de la barra, circunflejo, tilde, ampersand y escape.
Leer más →
Diagnostica y corrige errores de tramas MLLP en HL7 v2 — bloques 0x0B ausentes, finalizadores 0x1C 0x0D perdidos y fallos de codificación.
Leer más →
Aprende a validar mensajes HL7 v2.x, detectar errores estructurales, resolver problemas de delimitadores y probar la lógica antes de producción.
Leer más →
Aprende a validar mensajes HL7 v2 con segmentos Z personalizados: comprobaciones base, reglas del sitio, gobernanza y flujos prácticos de validación.
Leer más →
Guía práctica de perfiles de conformidad HL7 y validación por sitio: formaliza reglas locales y combina controles base con revisión por perfiles.
Leer más →