Antecedentes

Los equipos de Servicios Médicos de Emergencia (EMS) a menudo llegan al departamento de urgencias con pacientes cuyos datos demográficos están incompletos o son desconocidos: sin número de historia clínica (MRN), sin nombre confirmado y, en ocasiones, sin fecha de nacimiento. Sin embargo, las notas de traslado de EMS aún deben registrarse en la historia clínica correcta.

Para respaldar una documentación segura y fiable, las agencias de EMS, los servicios de integración de terceros y los equipos de integración hospitalarios construyen interfaces seguras que intercambian identificadores y mensajes clínicos. Cuando esos identificadores no coinciden, los sistemas posteriores no pueden registrar automáticamente las notas de traslado, lo que genera trabajo manual evitable y retrasa la completitud del registro. Este artículo describe cómo puede utilizarse FHIR Patient.Search (R4) para cubrir las lagunas demográficas más comunes y mejorar el registro automático.

El reto

En muchas integraciones de EMS con hospitales, los pacientes se registran inicialmente con identificadores genéricos o temporales. El registro final—y cualquier fusión de registros—puede no ocurrir hasta más tarde, a veces después del alta. Hasta que esas actualizaciones se propaguen, los identificadores de pacientes de EMS y los del Registro Médico Electrónico (EMR) pueden permanecer desincronizados.

Cuando no se puede registrar una nota de traslado debido a una discrepancia, la integración suele generar un error que se envía a una cola de trabajo del EMR para revisión manual. Con los volúmenes de EMS, esa cola puede crecer rápidamente. Una causa raíz común son los mensajes entrantes que carecen de uno o más campos demográficos necesarios para una coincidencia segura del paciente y el registro en la historia clínica—más frecuentemente:

• Número de Historia Clínica (MRN)
• Nombre
• Fecha de Nacimiento
• Género

Cómo funciona hoy

Hoy, los datos demográficos faltantes se complementan consultando una base de datos de Microsoft SQL Server de larga duración (en servicio por más de 20 años) que almacena una vista interpretada de los mensajes HL7 ADT (Demografía). La capa de integración utiliza llamadas JDBC para ejecutar procedimientos almacenados y recuperar los campos necesarios.

Un enfoque basado en FHIR

Una opción más moderna es obtener los datos demográficos faltantes directamente de un repositorio FHIR. Específicamente, FHIR Patient.Search (R4) ofrece una forma basada en estándares de consultar el MRN, el nombre, la fecha de nacimiento y el género utilizando la información parcial disponible en el momento de registrar la nota de traslado.

Para poner esto en funcionamiento, un proceso de negocio dedicado envuelve la llamada a Patient.Search (R4) y devuelve una respuesta normalizada al flujo de trabajo de integración original.

Resumen del flujo de trabajo

La fuente solicitante envía un PatientSearch.Request (clase de mensaje personalizada) al proceso de negocio.

A partir de ahí, el proceso de negocio realiza los siguientes pasos:

• Obtiene un token de acceso OAuth.
• Transforma el PatientSearch.Request (clase de mensaje personalizada) en un HS.FHIRServer.Interop.Request.
• Envía el HS.FHIRServer.Interop.Request a un repositorio FHIR externo.
• Verifica que la respuesta FHIR devuelva HTTP OK (200).
• Convierte la respuesta FHIR del flujo HTTP en un PatientSearch.Response (clase de mensaje personalizada).
• Devuelve el PatientSearch.Response (clase de mensaje personalizada)al proceso de origen.

Consideraciones adicionales del flujo de trabajo incluyen:

• Asegurarse de que el proveedor proporcione al menos uno de los siguientes: MRN, nombre, fecha de nacimiento o género.
• Si se devuelven múltiples respuestas de FHIR Patient, el resultado se envía al EMR tal cual, permitiendo que el sistema genere un error si los campos proporcionados son insuficientes para identificar de manera única a un paciente.