Construye mensajes HL7 v2.x de prueba válidos desde un formulario. Elige el tipo, rellena campos y copia el resultado listo para enviar. Local en el navegador.
[object Object]
[object Object]
[object Object]
[object Object]
[object Object]
ADT (A01/A03/A04/A08/A11), ORM, ORU, SIU, MDM, BAR, DFT, VXU — los escenarios que los analistas de integración prueban a diario.
Cada campo incluye tipo de dato HL7, marca de requerido/opcional y tooltip EN/ES con su significado y valores habituales.
Los mensajes generados pasan por nuestro parser HL7 en los tests — lo que copias está garantizado como estructuralmente válido.
Un clic abre el mensaje generado en el Visor HL7 para inspección por segmentos sin salir del sitio.
Los identificadores son obviamente ficticios (TEST^PATIENT, FN 1900-01-01, SENDING_APP) — cero riesgo de fugas accidentales en capturas.
Olvida pipes mal contados y campos obligatorios ausentes. Elige tipo, pulsa ejemplo, ajusta y copia — listo en menos de un minuto.
Sin llamadas a servidor. Los valores, el contenido del mensaje y la descarga permanecen en tu dispositivo. Seguro en portátiles hospitalarios.
Los datos parecen un mensaje real pero usan identificadores TEST y fechas 1900-01-01 — sin riesgo de confundir pruebas con producción.
Handoff con un clic al Visor, Navegador de Segmentos y Generador de ACK. Construye, inspecciona y confirma en un solo flujo.
Un mensaje HL7 v2.x es un documento de texto plano delimitado por pipes, dividido en segmentos separados por retorno de carro. La cabecera MSH establece los caracteres de codificación e identifica los sistemas emisor y receptor. Los segmentos siguientes (PID, PV1, OBR, OBX, ORC, EVN, SCH, RXA, TXA, FT1, etc.) llevan la carga clínica y administrativa. Cada segmento tiene un orden rígido de campos, cada campo un tipo de dato concreto y cada trigger event (como ADT^A01) un conjunto definido de segmentos obligatorios.
Los mensajes HL7 reales contienen Información de Salud Protegida (PHI) — nombres de pacientes, números de historia, fechas de nacimiento — y no pueden salir del entorno cubierto por HIPAA donde se originaron. Los ingenieros de integración acaban escribiendo mensajes a mano al construir o depurar interfaces, lo que es propenso a errores: un pipe mal contado, un campo obligatorio ausente, un formato inválido en MSH-9, y el sistema receptor rechaza el mensaje entero.
Un buen generador te da una estructura bien formada con cada segmento y campo obligatorio poblado por datos de muestra válidos. Desde ahí, solo sobrescribes lo que tu caso de prueba necesita — un patrón específico de ID de paciente, un flag de resultado anormal, una ubicación de cama inusual. La salida del generador está garantizada como parseable, así que cualquier fallo que reporte el sistema downstream es del caso de prueba, no de tu escritura.
La familia ADT es la razón más común por la que existe una interfaz. ADT^A01 anuncia un nuevo ingreso; ADT^A03 señala un alta; ADT^A04 registra un ambulatorio. ADT^A08 actualiza demografía o datos de visita — es el evento "caballo de batalla" que los hospitales usan cuando se corrige un nombre, cambia un garante o llega una actualización de seguro. Los sistemas downstream, desde laboratorio a facturación y radiología, se suscriben a feeds ADT para mantener sus propios registros sincronizados.
ORM^O01 transporta una nueva petición — una analítica, un estudio de imagen, un medicamento — desde el sistema peticionario al sistema ejecutor. ORU^R01 devuelve el resultado, típicamente con un segmento OBX por cada medida individual (uno para el recuento leucocitario, otro para la hemoglobina, etc.). El emparejamiento es la columna vertebral de la mensajería clínica.
SIU^S12 anuncia una nueva cita; MDM^T02 transmite un documento clínico (informe de alta, radiología) con o sin contenido adjunto; BAR^P01 crea una cuenta financiera; DFT^P03 registra un cargo o ajuste. VXU^V04 lleva registros de vacunación — críticos para salud poblacional y reporte público. Cada uno tiene segmentos obligatorios distintos que el generador impone.
Los mensajes generados deben marcarse claramente como datos de prueba. Casi todos los motores HL7 permiten poner MSH-11 (Processing ID) a "T" (training) o "D" (debug), que los sistemas downstream usan para enrutar el tráfico de prueba lejos de los flujos de producción. Este generador usa "P" por defecto porque el mensaje es una estructura; considera cambiarlo a "T" antes de enviarlo a un motor real conectado a sistemas reales.
Una vez generado, ábrelo en el Visor HL7 para inspeccionar segmentos con resaltado de color y decodificación de campos, o pásalo por el Generador de ACK para simular la respuesta del receptor. El flujo combinado — generar, ver, confirmar — permite ejercitar ambos lados de una interfaz antes de que circule un solo mensaje real.
FHIR (Fast Healthcare Interoperability Resources) ha acaparado el trabajo greenfield en integración sanitaria en los últimos cinco años, pero HL7 v2.x sigue dominando las interfaces hospitalarias existentes. Un sistema sanitario típico hoy mantiene cientos de feeds HL7 v2.x entre EHR, laboratorio, radiología, farmacia, facturación y auxiliares — y lo seguirá haciendo durante años. Este generador es la herramienta adecuada cuando construyes o depuras contra ese backbone v2.x. Para proyectos greenfield, apps móviles, analítica poblacional o APIs con partners externos, FHIR suele ser mejor objetivo y este generador no te ayudará — usa un builder de recursos FHIR. La prueba práctica: si el receptor espera un mensaje con pipes que empieza por MSH|^~\\&|, necesitas v2.x; si espera recursos JSON o XML con OAuth 2.0, necesitas FHIR.
El orden de segmentos importa. La especificación HL7 define secuencias estrictas por trigger event: ADT^A01 es MSH → EVN → PID → PV1 (con opcionales como AL1, DG1 en posiciones concretas); ORU^R01 es MSH → PID → OBR → OBX (con OBX repitiéndose para paneles multi-resultado). Los receptores imponen este orden — un segmento fuera de sitio rompe el parseo aunque estén todos los obligatorios. Nuestro generador emite los segmentos en el orden canónico definido por la especificación, así que la salida funciona contra parsers estrictos. Si editas a mano un mensaje, preserva la secuencia original; no reordenes segmentos para "que queden más limpios."
Algunos segmentos son condicionales: PV2 aparece solo cuando hay información ampliada de visita; DG1 se repite una vez por diagnóstico; IN1 por cada plan de seguro; AL1 por cada alergia. Los trigger events definen tanto segmentos obligatorios como opcionales, y el orden en que aparecen las repeticiones. Este generador emite los segmentos obligatorios con datos de muestra; extensiones condicionales como varias AL1 de alergias o una secuencia de DG1 se pueden añadir editando el mensaje antes de copiarlo. Si tu caso de prueba depende de repeticiones condicionales, añádelas manualmente tras generar y pasa el resultado por el Visor HL7 para confirmar que el receptor sigue parseando.
HL7 v2.x usa ASCII por defecto, suficiente para sistemas en inglés pero problemático para textos europeos con acentos o cualquier contenido en idiomas asiáticos. Para emitir un mensaje con texto no-ASCII, pon MSH-18 a UTF-8 explícitamente y asegúrate de que todos los sistemas downstream soportan UTF-8 en la interfaz. En la práctica muchos sistemas antiguos no lo hacen — un nombre de paciente con una tilde llega silenciosamente como "bytes basura" en el receptor. Si vas a añadir caracteres internacionales, prueba el round-trip completo con el sistema objetivo antes de comprometerte con UTF-8 en una interfaz v2.3 antigua. Nuestro generador emite datos de muestra ASCII por defecto para que este problema no aparezca en el andamiaje de pruebas.
Los motores de interfaz — Mirth Connect, Rhapsody, Ensemble, Infor Cloverleaf, Corepoint — consumen mensajes HL7 v2.x, los transforman con canales (reglas de enrutado scriptadas) y los reenvían a los sistemas downstream. Los mensajes de prueba son la materia prima del ciclo QA de cualquier motor. Genera un mensaje aquí, pégalo en el diálogo "Send Message" de Mirth contra un canal de prueba e inspecciona la salida transformada. Para canales ADT → HL7-a-FHIR (patrón común de modernización), genera el v2.x origen aquí y verifica el bundle FHIR resultante contra la forma esperada del recurso. Para canales que enriquecen mensajes consultando maestros externos (índices de paciente, tablas de códigos), genera un mensaje con un ID de paciente que intencionalmente no case con ningún registro para comprobar que el motor maneja bien el miss — fuente habitual de incidentes cuando se actualizan sistemas MDM.
Sí — nuestro test suite parsea cada plantilla con el mismo parser HL7 que usa el visor. La cabecera MSH, caracteres de codificación y campos obligatorios son siempre correctos.
v2.5 por defecto (MSH-12). Puedes cambiar el campo versión antes de descargar; casi todos los sistemas downstream aceptan 2.3–2.7 con la misma estructura de segmentos.
Sí, pero pon MSH-11 (Processing ID) a 'T' (training) o 'D' (debug) para que los sistemas downstream enruten el tráfico de prueba fuera de producción.
Curados a mano, obviamente sintéticos y sin identificadores reales. FNs en 1900-01-01, centros SENDING_APP/RECEIVING_APP, pacientes TEST^PATIENT.
No. Cada campo que introduces permanece en tu navegador. El mensaje se construye en JavaScript y la descarga es un Blob cliente. Verifícalo en el inspector de red.
Pulsa 'Abrir en Visor HL7' — la herramienta codifica el mensaje como parámetro de query y abre el visor en una pestaña nueva con el mensaje precargado.
Todavía no. Los tipos soportados incluyen sus segmentos obligatorios estándar; los Z-segments están en el roadmap. De momento descarga el mensaje y añádelos en un editor.
Processing ID: P=Producción, T=Training, D=Debug. Los receptores lo usan para distinguir tráfico real de pruebas — ponlo a 'T' al alimentar un QA compartido.
EVN (Event Type) es obligatorio en todos los trigger events ADT según la especificación HL7. El generador lo impone para garantizar que el mensaje pasa la validación estructural.
Los obligatorios se marcan con asterisco (*). Al pasar el ratón sobre cualquier campo se muestra un tooltip con su significado. Los opcionales quedan vacíos por defecto.
Aprende a convertir mensajes HL7 v2.x a JSON con salida simplificada o estilo HAPI. Guía paso a paso sobre mapeo de campos, secuencias de escape y patrones de integración.
Leer más →Aprende a generar mensajes HL7 v2.x de prueba válidos para ADT, ORU, ORM y otros trigger events — seguro, sin PHI y sin escribir pipes a mano.
Leer más →Complete guide to generating HL7 ADT trigger events (A01, A03, A04, A08, A11) for testing interface engines. Segment structure, validation, and integration patterns.
Leer más →