Toda interfaz HL7 acaba necesitando pruebas — contra un parser, un motor de integración, un sistema destino o un harness de tests unitarios. Y cada prueba necesita un mensaje. Escribirlo a mano es engañosamente doloroso: olvidar los caracteres de codificación en MSH-2, mal contar pipes, confundir MSH-5 con MSH-3 o dejar fuera un segmento obligatorio causa rechazos silenciosos en el extremo receptor. Esta guía recorre la anatomía de un mensaje HL7 v2.x válido, los trigger events más habituales que necesitarás probar y cómo generar datos sintéticos seguros sin riesgo de PHI.
Anatomía de un Mensaje HL7 Válido
Un mensaje HL7 v2.x es un documento de texto delimitado por pipes. El primer segmento siempre es MSH (Message Header), y sus dos primeros campos son peculiares: MSH-1 es el propio separador de campo (|) y MSH-2 declara el resto de caracteres de codificación — componente (^), repetición (~), escape (\) y subcomponente (&). Todo mensaje estándar empieza exactamente por MSH|^~\&|. Sin esto, ningún parser downstream podrá entender el resto.
Tras MSH, segmentos específicos del trigger event llevan la carga. ADT^A01 (ingreso) necesita EVN, PID y PV1 como mínimo. ORU^R01 (resultado de laboratorio) necesita PID, OBR y OBX. Cada segmento tiene un orden rígido de campos definido por la especificación HL7, y cada campo un tipo de dato y cardinalidad (obligatorio, opcional, repetible). El parser receptor los valida y rechaza mensajes que se desvían estructuralmente.
El Problema de los Datos de Prueba
Los mensajes reales contienen Información de Salud Protegida: nombres de pacientes, números de historia, fechas de nacimiento, identificadores de médico y direcciones institucionales. HIPAA (en EEUU) y regímenes equivalentes de protección de datos en Europa y otros lugares prohíben compartir PHI fuera del entorno cubierto. Esto significa que el atajo obvio para pruebas — "coge un mensaje de producción" — no está disponible. Los ingenieros de integración o bien escriben mensajes a mano desde la especificación, copian plantillas de documentación del proveedor, o usan un generador que emite mensajes sintéticos estructuralmente válidos.
Estrategias de Datos Sintéticos
Los buenos datos sintéticos siguen tres principios: (1) son obviamente ficticios, (2) ejercen estructura realista y (3) son deterministas cuando necesitas reproducibilidad. "Obviamente ficticios" significa un nombre como TEST^PATIENT^A, una FN 19000101, un centro llamado SENDING_APP. Cualquiera que mire un mensaje con esos valores sabe de un vistazo que son datos de prueba, sin riesgo de confusión con producción.
"Estructura realista" significa que longitudes de campo, cardinalidad y tipos de dato casan con lo que llevaría un mensaje real. Un PID-3 debe tener formato de MRN real — TEST000001^^^TESTFAC^MR, no abc. Un valor OBX-5 debe ser un número plausible con unidades plausibles. Los validadores del sistema receptor son estrictos con los tipos aunque los valores sean claramente ficticios.
"Determinista" importa para tests de regresión. Si el generador produce valores diferentes en cada ejecución, las aserciones sobre campos específicos se rompen. El generador de este sitio usa valores de muestra fijos para que puedas commitear un mensaje generado a un fixture y coincida la semana siguiente.
Los Trigger Events Más Habituales a Probar
ADT (Admisión, Alta, Traslado)
La familia ADT es la razón más común de que exista una interfaz. Prácticamente todos los sistemas clínicos y administrativos dependen de feeds ADT para mantener sincronizado su propio registro de pacientes. Prueba como mínimo:
- ADT^A01 — Ingreso. Nueva visita de ingresado. Garantiza que los flujos de registro de nuevo paciente y creación de visita funcionan de extremo a extremo.
- ADT^A03 — Alta. Garantiza que la limpieza del alta, handoff a facturación y actualizaciones de gestión de camas se disparan correctamente.
- ADT^A04 — Registro ambulatorio. Valida el camino de registro ambulatorio, que suele tener enrutado downstream algo distinto al de ingresado.
- ADT^A08 — Actualización de datos. El evento "caballo de batalla". Cualquier corrección demográfica, cambio de seguro o actualización de detalle de visita viaja como A08. También es la fuente más probable de bugs downstream porque los sistemas receptores deben reconciliar actualizaciones con el estado existente.
- ADT^A11 — Cancelar ingreso. Garantiza que las cancelaciones de ingreso previo se propagan; fuente habitual de discrepancias en camas y facturación cuando se maneja mal.
Peticiones y Resultados (ORM, ORU)
ORM^O01 transporta nuevas peticiones — labs, imagen, farmacia — al sistema ejecutor, y ORU^R01 devuelve resultados. Las pruebas deben ejercer:
- Una observación con un solo OBX (resultado numérico único).
- Una observación multi-OBX (un panel de laboratorio con 5–15 medidas individuales).
- Flags de anormal (OBX-8) y estados de resultado (OBX-11: P, F, C para preliminar, final, corregido).
- Resultados de texto (OBX-2 = 'TX') para informes de radiología y patología.
Agenda, Documentos, Finanzas, Vacunas
SIU^S12 prueba la creación de cita — fuente habitual de bugs de sincronización de calendarios. MDM^T02 prueba la transmisión de documento clínico; BAR^P01 y DFT^P03 ejercen el pipeline financiero; VXU^V04 cubre el reporte de inmunización, ya obligatorio en varios países como feed de salud pública. Un generador que soporta todos en una sola interfaz acelera el QA para equipos que tocan varios dominios.
Configurar Processing ID Correctamente
MSH-11, el Processing ID, dice a los sistemas downstream si el mensaje es producción, training o debug. Los valores válidos son P (producción), T (training) y D (debug). Al inyectar mensajes sintéticos en un entorno de pruebas compartido, pon siempre T o D. Casi todos los sistemas downstream tienen filtros de ruta que ignoran el tráfico no-P para facturación, prescripción y reporte — es el mecanismo que evita que un resultado de lab de prueba aparezca en la historia de un paciente real.
El generador de este sitio usa P por defecto porque el mensaje pretende ser una referencia estructural. Cámbialo a T antes de enviarlo a un motor de integración real.
Round-Trip a Través de Parser y ACK
Un mensaje generado que parece correcto en pantalla puede aún fallar en un parser downstream. La validación más barata es hacer round-trip del mensaje por un parser propio — idealmente la misma librería que usa tu sistema de producción. En este sitio, el Visor HL7 parsea y resalta mensajes segmento a segmento, detectando problemas estructurales como campos obligatorios ausentes o codificaciones de tipo erróneas. El Generador de ACK simula la respuesta del sistema receptor, ejercitando el camino de confirmación que a menudo se olvida en los tests.
Errores Habituales
- Separadores de campo en los datos. Un nombre con apóstrofe o ampersand se rompe si no lo escapas con
\F\,\S\, etc. Casi todos los generadores escapan por ti; prueba siempre con al menos un nombre con un carácter escapable. - Zonas horarias en MSH-7. La especificación permite offsets horarios; algunos sistemas los aceptan, otros no. Prefiere UTC sin offset (
20260420120000) para máxima compatibilidad. - Componentes ausentes en PID-5. Un nombre sin al menos los componentes de apellido y nombre (
SMITH^JOHN) falla en algunos receptores aunque la especificación permita un nombre de un solo componente. - Z-segments. Los segmentos propietarios (prefijo Z) los permite la especificación pero no están estandarizados. No supongas que un sistema downstream los manejará — si tu integración depende de uno, pruébalo explícitamente.
- Codificación de caracteres. HL7 v2 usa ASCII por defecto; UTF-8 es cada vez más común pero debe declararse en MSH-18. Los acentos en PID-5 se ven bien en tu pantalla y llegan corruptos si no se negocia la codificación.
Usando el Generador
Abre el Generador de Mensajes HL7, elige un tipo de mensaje, pulsa 'Rellenar con datos de ejemplo' para poblar los obligatorios con valores obviamente ficticios y personaliza lo que tu prueba necesite. El mensaje generado se actualiza en vivo según escribes. Usa Copiar o Descargar para llevarlo a tu test harness, o pulsa 'Abrir en Visor HL7' para inspeccionarlo segmento a segmento antes de enviarlo.
Cada mensaje generado parsea limpio por nuestro parser HL7 — lo verificamos en el test suite — así que el mensaje que copias está garantizado como estructuralmente válido. Combínalo con el Visor y el Generador de ACK y tendrás un bucle completo para probar cualquier lado de una interfaz sin tocar datos reales de paciente.
Escalar: Generación Automatizada de Datos de Prueba
Para la mayoría de los flujos QA de interfaces, un puñado de mensajes sintéticos curados a mano es suficiente. Pero al construir suites de regresión automatizadas para un motor de integración grande o al certificar un conector EHR nuevo, puedes necesitar cientos o miles de mensajes con perfiles de paciente variados, valores de campo en el límite y tipos de mensaje mezclados. El patrón que funciona bien: usa este generador como fuente de plantillas, luego envuélvelo en un script pequeño (10–20 líneas de Python o Node) que sustituya valores de campo desde un CSV o JSON de fixtures. Esto te da datos de prueba deterministas y versionados que conservan la corrección estructural del generador sin editar cientos de archivos a mano. Parametrizaciones habituales: pools de nombres de paciente (TEST^SMITH, TEST^JONES, TEST^GARCIA), rangos de fechas realistas pero sintéticos y patrones MRN rotatorios que ejerciten los formatos que esperaría tu integración de distintos sistemas origen.
Contexto de Cumplimiento: HIPAA Safe Harbor y Datos Sintéticos
La regla Safe Harbor de HIPAA identifica 18 elementos específicos que deben eliminarse o generalizarse para que un dataset se considere desidentificado. Los datos de prueba sintéticos esquivan toda esa conversación porque nunca fueron reales — no hay que eliminar nada, no hace falta aprobación IRB para pruebas internas y no se requieren acuerdos BAA con los entornos de prueba downstream. Por eso los equipos de integración prefieren cada vez más generadores sintéticos a extractos de producción desidentificados: la carga legal y procedimental es casi nula y la cobertura de pruebas suele ser mejor porque puedes inyectar casos límite (nombres largos, direcciones unicode, fechas de nacimiento futuras para pacientes pediátricos) que quizá no existan en tu corpus de producción. Para pruebas de certificación contra suites de validación HL7, los datos sintéticos son la única opción — los organismos certificadores exigen explícitamente mensajes sin PHI.
Trucos de Depuración cuando un Mensaje Generado Falla Downstream
Ocasionalmente un mensaje generado pasa nuestro parser pero falla en un motor o sistema de un proveedor. Las causas más habituales, por frecuencia: (1) el receptor espera un Processing ID específico (MSH-11) — cambia P a T o D, (2) el receptor espera un formato concreto de Sending Facility (MSH-4) — sustituye SENDING_FAC por un ID que reconozca su configuración, (3) el receptor espera valores de tabla concretos (por ejemplo Patient Class en PV1-2 debe ser I, O, E, P, R o B según la tabla HL7 0004, no tu string propio), (4) el receptor exige compatibilidad específica de versión vía MSH-12, (5) falta un Z-segment específico del proveedor. Para el caso (5) el único arreglo es consultar la especificación del proveedor y añadir a mano el Z-segment al mensaje generado antes de enviarlo.