Toda interfaz HL7 necesita un set de pruebas contra: un procesador, un motor de integración, un sistema destino o un arnés de tests unitarios. Cada prueba necesita un mensaje. Escribirlo a mano es traicionero y difícil: olvidar los caracteres de codificación en MSH-2, contar mal los caracteres de pipe, 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 eventos disparadores 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 plano delimitado por pipes. El primer segmento siempre es MSH (Message Header), siendo sus dos primeros campos un tanto 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 procesador de mensajes podrá entender el resto.
Tras MSH, segmentos específicos del evento disparador llevan el contenido. 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 estricto de campos definido por la especificación HL7, y cada campo un tipo de dato y cardinalidad (obligatorio, opcional, repetible). El procesador receptor los valida rechazando mensajes que se desvían de la estructura establecida.
El problema de los datos de prueba
Los mensajes clínicos de producción suelen contener Información de Salud Protegida (PHI): nombres de pacientes, números de historia, fechas de nacimiento, identificadores de médicos y direcciones institucionales. HIPAA (en EE. UU.) y los regímenes equivalentes de protección de datos en Europa y otros lugares prohíben compartir PHI fuera del entorno autorizado. Por tanto, el atajo obvio para las pruebas —«coger un mensaje de producción»— no es una opción segura. Los ingenieros de integración pueden escribir mensajes a mano a partir de la especificación, usar un anonimizador asumiendo el riesgo residual, copiar plantillas de la documentación del proveedor o utilizar un generador que produzca mensajes sintéticos estructuralmente válidos.
Estrategias de datos sintéticos
Los buenos datos sintéticos han de cumplir tres principios: (1) son claramente ficticios, (2) ejercen estructura realista y (3) son deterministas cuando necesitas reproducibilidad. "Claramente 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 las longitudes de campo, su cardinalidad y los 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 el tipado aunque los valores sean claramente ficticios.
Que sean "deterministas" es crucial para los tests de regresión. Si el generador produce valores diferentes en cada ejecución, las aserciones (comprobaciones) sobre campos específicos se rompen. El generador de este sitio usa valores de muestra fijos para que puedas subir un mensaje generado a un fixture y coincida la semana siguiente.
Los eventos disparadores 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 canales y mensajes 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, envío 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 un enrutado 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: laboratorio, imagen, farmacia; al sistema ejecutor, y ORU^R01 devuelve resultados. Las pruebas deben probar:
- Observación con un solo OBX (resultado numérico único).
- Observación multi-OBX (un panel de laboratorio con 5–15 medidas individuales).
- Indicadores anormales (OBX-8) y estados de resultado (OBX-11: P, F, C para preliminar, final, corregido).
- Resultados en formato 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 los calendarios. MDM^T02 prueba la transmisión de documento clínico; BAR^P01 y DFT^P03 tratan el pipeline financiero; VXU^V04 cubre el informe 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 proceso de calidad (QA) para aquellos equipos que tocan varios dominios.
Configurar processing ID correctamente
MSH-11, el Processing ID, dice a los sistemas de procesamiento si el mensaje es producción, preproducción/Training o desarrollo/pruebas. 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 de procesamiento 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 laboratorio 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.
Ida y vuelta a través de parser y ACK
Un mensaje generado que parece correcto en pantalla puede aún fallar en un sistema de procesamiento. La validación más barata es hacer un procesado de “ida y vuelta” del mensaje por un procesador propio; idealmente la misma librería que usa tu sistema de producción. En este sitio, el Visor HL7 procesa 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 & se rompe si no lo escapas con
\F\,\S\, etc. Casi todos los generadores escapan estos caracteres automáticamente; prueba siempre con al menos un nombre con un carácter especial (escapable). - Zonas horarias en MSH-7. La especificación permite husos horarios; algunos sistemas los aceptan, otros no. Intenta usar UTC sin huso horario (
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) están permitidos por la especificación pero no están estandarizados. No supongas que un sistema de procesamiento será capaz de entenderlos; 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, finalmente, personaliza lo que tu sistema o prueba necesite. El mensaje generado se actualiza en tiempo real según escribes. Cópialo o descárgalo para llevarlo a tu test e2e, o pulsa 'Abrir en Visor HL7' para inspeccionarlo segmento a segmento antes de enviarlo.
Cada mensaje generado se comprueba con nuestro procesador HL7 dentro del conjunto de pruebas para verificar su estructura. Combínalo con el Visor HL7 y el Generador de ACK para probar ambos extremos de una interfaz sin utilizar datos reales de pacientes.
Escalar: generación automatizada de datos de prueba
Para la mayoría de los flujos de pruebas automáticas de interfaces, un subconjunto de mensajes sintéticos curados a mano es suficiente. Pero al construir pruebas 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. Para esto, hay un patrón que funciona bien: usa este generador como fuente de plantillas, luego automatízalo usando en un script pequeño (10–20 líneas de Python o Node) que sustituya valores de campo desde un CSV o JSON con los datos. 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 conjunto de datos se considere desidentificado. Los datos sintéticos esquivan esta cuestión porque nunca pertenecieron a una persona real: no hay que redactar datos, no hace falta aprobación de un IRB para pruebas internas y no se requieren acuerdos BAA con los entornos de prueba y procesamiento. Por eso los equipos de integración prefieren cada vez más los generadores sintéticos frente a extractos de producción desidentificados: la carga legal y procedimental es menor y la cobertura de las pruebas puede ser mejor porque permite introducir casos límite que quizá no existan en producción.
Trucos de depuración cuando un mensaje generado falla en el procesado
Ocasionalmente, un mensaje generado supera nuestro procesador, pero falla en el motor de integración o en el sistema de un proveedor. Las causas más habituales son:
- El receptor espera un Processing ID específico (MSH-11): cambia P por T o D.
- El receptor espera un formato concreto de Sending Facility (MSH-4): sustituye
SENDING_FACpor un identificador que reconozca su configuración. - 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 una cadena personalizada.
- El receptor exige una versión específica en MSH-12.
- Falta un Z-segment específico del proveedor. Para el caso 5, consulta la especificación de integración del proveedor y añade manualmente el Z-segment antes de enviar el mensaje.