Introduccion: Por Que el Mapeo ADT Merece Su Propia Guia
Los mensajes ADT son el pulso operativo de la mayoria de los entornos de integracion hospitalaria. Cada admision, alta, traslado, actualizacion demografica, fusion o correccion de datos suele producir un evento HL7 v2.x ADT, y los sistemas receptores usan esos eventos para decidir quien es el paciente, si la visita sigue activa, donde se encuentra y que identificadores deben anclar la historia. Por eso el mapeo ADT es una de las partes mas delicadas de cualquier programa de modernizacion que pasa de interfaces HL7 tradicionales a APIs FHIR.
A primera vista la tarea parece simple: tomar los datos del paciente de PID, los datos de la visita de PV1 y construir recursos FHIR. En produccion, sin embargo, los feeds ADT contienen multiples identificadores, nombres repetidos, convenciones locales de ubicacion, semantica variable de eventos y reglas del ciclo de vida de la visita que rara vez encajan en un enfoque simplista. Si quieres inspeccionar la estructura del mensaje antes de escribir la logica de transformacion, usa nuestro Visor HL7. Si quieres probar mapeos de campos directamente, el Mapeador HL7 v2 a FHIR es la forma mas rapida de validar supuestos con muestras sinteticas o desidentificadas.
Esta guia se centra solo en el paso de ADT a FHIR Patient y Encounter. Complementa nuestra guia general de migracion de HL7 v2 a FHIR y encaja con el articulo companero sobre mapeo de mensajes ORU a DiagnosticReport y Observation. El objetivo aqui es la claridad operativa: que campos suelen importar, como afectan los trigger events al estado de Encounter, donde se pierde informacion y que validaciones evitan errores de identidad y de visita en los sistemas de destino.
Empieza con el Modelo Mental Correcto
Un mensaje HL7 ADT no es un registro de base de datos. Es una notificacion de evento que contiene suficiente estado para que un sistema receptor actualice su propia representacion de un paciente y una visita. El mensaje puede ser autoritativo para demografia, parcialmente autoritativo para ubicacion y solo condicionalmente autoritativo para clase, identificadores financieros o medico responsable segun la aplicacion origen. Los recursos FHIR, en cambio, modelan esos conceptos como recursos reutilizables que pueden vivir de forma independiente y referenciarse en distintos flujos.
Eso significa que tu mapeador debe responder tres preguntas de diseno antes de empezar cualquier transformacion campo por campo. Primero, que recurso es dueno de cada dato de negocio: Patient, Encounter, Coverage, Organization, Location, Practitioner o una extension. Segundo, si el evento ADT crea un nuevo estado, actualiza uno existente o solo senala una transicion. Tercero, que identificadores y referencias permiten al receptor correlacionar la informacion entrante con recursos existentes de forma segura. Los equipos que se saltan estas preguntas suelen entregar un mapeador sintacticamente correcto pero semanticamente inestable.
Como Influyen los Trigger Events ADT en el Estado FHIR
No todos los eventos ADT deben tratarse igual. ADT^A01 y ADT^A04 suelen crear o activar un Encounter. ADT^A08 normalmente actualiza demografia sin cambiar el ciclo de vida de la visita. ADT^A02 puede indicar un traslado que afecta a Encounter.location y a veces a la clase del episodio. ADT^A03 suele cerrar el periodo del encounter. ADT^A11 y A13 revierten una admision o un alta previa y por tanto necesitan una estrategia de rollback o actualizacion compensatoria.
FHIR no tiene un estado unico por cada trigger event HL7. En su lugar, se deriva el estado segun el significado de negocio. A01 y A04 suelen mapear a Encounter.status = in-progress. A03 suele mapear a finished con period.end poblado desde PV1-45. A08 puede dejar igual el estado del Encounter mientras actualiza identificadores, nombre, telecom o direccion de Patient. Si tu feed incluye eventos preadmission como A05, puedes usar planned hasta recibir la admision formal.
La regla practica es sencilla: no permitas que el codigo de evento sobrescriba por si solo un estado de destino mas rico sin tener en cuenta el contexto de la visita. Por ejemplo, un A08 que llega tarde despues del alta probablemente deba actualizar la demografia del paciente, pero no reabrir un Encounter finalizado salvo que el centro haya definido expresamente ese comportamiento.
Segmento PID a FHIR Patient
El segmento PID es el nucleo demografico. El campo mas importante suele ser PID-3, la lista de identificadores del paciente. Como PID-3 se repite, cada repeticion debe evaluarse y no aplanarse. Una repeticion puede ser el MRN corporativo, otra el MRN local del centro, otra un identificador nacional y otra un numero historico. En FHIR, cada una se convierte en un elemento de Patient.identifier[] con un system estable, un type opcional y el valor crudo en value.
La mayoria de los proyectos fallidos de ADT a FHIR no se rompen por el parseo del campo, sino por el modelado del sistema de identificadores. Si la assigning authority de CX.4 esta presente, mapearla de forma consistente a una URI canonica. Si la interfaz solo envia texto local como HOSPITAL o REG, construye una tabla de equivalencias mantenida en vez de copiar esas cadenas directamente a identifier.system. La consistencia importa mas que la elegancia porque el matching de pacientes, las fusiones y la busqueda dependen de sistemas estables.
PID-5 se mapea a Patient.name. El tipo XPN puede incluir apellido, nombre, segundos nombres, prefijos, sufijos y codigo de tipo de nombre. Conserva el nombre principal como official cuando proceda. Si el origen envia alias o apellido de soltera en repeticiones, mapealos como entradas adicionales de HumanName en lugar de perderlos. Esto es importante cuando un portal del paciente o un flujo MPI necesita busqueda por nombres alternativos.
PID-7 suele mapearse a Patient.birthDate y PID-8 a Patient.gender. Conviene ser conservador. El sexo administrativo en HL7 v2 no representa por completo sexo o identidad de genero, asi que no debe ampliarse mas alla del significado de origen. PID-11 se convierte en uno o varios Patient.address, PID-13 y PID-14 en Patient.telecom, y campos como PID-16, PID-22 o PID-29 pueden requerir decisiones locales segun el perfil FHIR objetivo.
Segmento PV1 a FHIR Encounter
PV1 es donde vive el estado de la visita, pero rara vez llega perfectamente normalizado. PV1-2 patient class impulsa Encounter.class, aunque muchos hospitales mezclan clase, nivel asistencial y convenciones locales entre sistemas. Construye una tabla de traduccion documentada desde las clases locales hacia la codificacion FHIR que quieres soportar. Un mapeador que simplemente copie texto local sin vocabulario controlado suele ser imposible de consultar despues.
PV1-3 assigned patient location es otro campo de alto riesgo. El tipo PL puede contener unidad, habitacion, cama, centro, estado y detalles de edificio. FHIR Encounter.location puede referenciar un recurso Location, pero muchos pipelines al principio solo rellenan una cadena visible porque el maestro de ubicaciones aun no existe. Eso puede ser aceptable como fase temporal, pero el equipo debe decidir pronto si esta construyendo integridad referencial o solo salida legible. Si quieres interoperabilidad duradera, crea recursos Location resolubles en vez de emitir solo texto opaco.
PV1-7 attending doctor, PV1-8 referring doctor y PV1-9 consulting doctor pueden convertirse en participantes del encounter, pero solo si defines como se mapean los identificadores de profesional a Practitioner o PractitionerRole. Es el mismo problema arquitectonico que con los identificadores del paciente: el parser es facil; el modelo de identidad de negocio no lo es. Cuando los feeds de origen solo envian nombre y no identificadores estables, hay que tener cuidado de no crear profesionales duplicados en el repositorio destino.
PV1-19 visit number suele mapearse a Encounter.identifier y a menudo es la clave principal de correlacion para la visita. PV1-44 y PV1-45 se mapean de forma natural a Encounter.period.start y Encounter.period.end. Si recibes traslados o cambios de servicio durante la misma estancia, actualiza el mismo Encounter salvo que el centro defina encounters financieros o clinicos separados.
Patrones Frecuentes para A01, A03, A04 y A08
Para ADT^A01, crea o actualiza Patient y crea o activa Encounter. Para ADT^A04, crea Patient y Encounter para un flujo ambulatorio o de registro, normalmente con clase ambulatoria. Para ADT^A03, no crees un Encounter nuevo. En su lugar, localiza la visita actual por identificador, rellena la fecha de fin si falta y cambia el estado a finished. Para ADT^A08, actualiza primero Patient y despues actualiza Encounter solo si han cambiado campos relacionados con la visita.
Observa que esto es logica de correlacion, no solo transformacion. Un mapeador FHIR robusto debe buscar o indexar recursos existentes por identificador antes de decidir si aplica semantica de creacion o actualizacion. Si solo emites bundles de coleccion sin estrategia de deduplicacion, el servidor receptor puede aceptar cada evento como recurso nuevo y destruir la integridad longitudinal con el tiempo.
Fusiones, Correcciones y Casos Limite de Identidad
Muchos entornos terminan necesitando soporte para eventos de fusion ADT^A40, transiciones de preadmission a admision, identificadores temporales de recien nacidos y duplicados entre centros. Esos casos no se resuelven con una regla ingenua de PID-3 igual a Patient.identifier. Hace falta una politica para identificadores sustituidos, un flujo de fusion que preserve trazabilidad y una distincion clara entre el registro activo del paciente y los identificadores historicos retenidos para auditoria o busqueda.
Las correcciones tambien importan. Si un feed envia la fecha de nacimiento incorrecta y luego la corrige con A08, el sistema destino debe actualizar el Patient y no crear un segundo recurso. Si cambia el numero de visita por una reconciliacion del sistema origen, decide si el identificador antiguo pasa a ser una entrada secundaria de Encounter.identifier o si el sistema lo trata como reemplazo. Documentar estas reglas forma parte del contrato de la interfaz, no de la limpieza posterior al go-live.
Estrategia de Pruebas para el Mapeo ADT a FHIR
Las pruebas deben empezar con conjuntos representativos de mensajes y no con un unico A01 feliz. Incluye al menos una admision hospitalaria, un registro ambulatorio, un traslado, un alta, una actualizacion demografica y un evento de reversion si tu entorno los recibe. Verifica el manejo de identificadores con repeticiones de PID-3, assigning authority ausente y mezcla de IDs locales y corporativos. Verifica el parseo de ubicacion con valores PL parciales y variantes propias del centro. Verifica tambien que los A08 tardios no reabran encounters cerrados.
Un flujo de prueba practico es inspeccionar mensajes crudos en el Visor HL7, capturar las rutas de campos exactas que importan y despues ejecutar los mismos payloads en el Mapeador HL7 v2 a FHIR para revisar los recursos Patient y Encounter resultantes. Para el contexto mas amplio de modernizacion, compara el comportamiento con nuestra guia de migracion y continua con el articulo companero sobre mapeo ORU para que los flujos de eventos y resultados evolucionen alineados.
Checklist de Implementacion Antes del Go-Live
- Definir sistemas canonicos para identificadores de paciente y visita.
- Documentar reglas de evento a estado para A01, A03, A04, A08 y eventos de reversion.
- Decidir si Encounter.location referenciara recursos Location gestionados o textos temporales.
- Especificar la logica de correlacion para create versus update en Patient y Encounter.
- Probar escenarios de fusion y correccion, no solo primeras admisiones.
- Validar la salida contra el perfil FHIR que realmente espera el consumidor.
Conclusion
El mapeo de ADT a FHIR es el punto donde la arquitectura de interoperabilidad se convierte en realidad operativa. El trabajo tecnico de parseo es manejable; lo dificil es modelar identidad, ciclo de vida de la visita, correlacion y semantica de ubicacion con suficiente consistencia para que los sistemas de destino confien en el resultado. Si tu equipo resuelve bien PID-3, PV1-19, el tratamiento de trigger events y las transiciones de estado de Encounter, el resto de la transformacion se vuelve mucho mas controlable. Si esos cimientos son debiles, todos los workflows posteriores heredan la ambiguedad.
Usa el Visor HL7 para estudiar payloads ADT reales, valida supuestos campo por campo en el Mapeador HL7 v2 a FHIR y mantén este articulo junto con la guia companera sobre ORU a DiagnosticReport y Observation para que los pipelines de eventos y resultados crezcan juntos. Los ejemplos aqui son educativos y deben validarse siempre contra guias locales de implementacion, restricciones de perfiles y reglas de gobernanza clinica antes del uso en produccion.