Por qué Validar Antes de Enviar
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.
Las Tres Capas de Validación HL7 v2.x
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.
Errores vs Avisos: Cómo Triaje Este Validador
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.
Por qué los Mismatches en MSH-2 Son Tan Comunes
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.
Reglas de Segmentos Requeridos por Tipo de Mensaje
Este validador exige los segmentos requeridos para los tipos de mensaje más comunes:
- ADT (admisión, alta, traslado): MSH, EVN, PID, PV1
- ORM / OMG / OMI / OML / OMP / OMS / OMD (órdenes): MSH, PID, ORC, OBR
- ORU / ORF / ORG / ORI / ORL / ORN / ORP / ORR / ORS (resultados): MSH, PID, OBR, OBX
- SIU (programación): MSH, SCH, PID, AIS o AIG o AIL o AIP
- MDM (gestión documental médica): MSH, EVN, PID, TXA
- ACK (acuse): MSH, MSA
- QRY / RSP (consultas y respuestas): MSH, QPD o QAK
- RDE (orden farmacéutica codificada): MSH, PID, ORC, RXE
- VXU (actualización de vacunación): MSH, PID, RXA
- DFT (transacción financiera detallada): MSH, EVN, PID, FT1
Validación de Tipos de Dato: DTM, DA, TM, NM
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).
Validación de Tablas de Códigos
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.
Flujo Práctico: Validar, Arreglar, Reenviar
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.
Lo que Este Validador No Hace
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.
De la Validación a la Resolución
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.