Flujo de trabajo de envío de alertas a los clientes

El flujo de trabajo de envío de alertas permite que los servicios de infraestructura registren advertencias con un servicio de alertas. El servicio de alertas permite a los consumidores de alertas consultarlas y enviarlas a los clientes (pacientes) en cualquier formato que sea adecuado (SMS, correo electrónico, etc.).

Un alerta está pensada como una comunicación en gran medida unidireccional a un cliente del sistema. Los casos de uso de alertas incluyen:

1. Respuesta a crisis

En respuesta a una crisis o situación de emergencia, como los brotes de ébola de 2014 y 2015 en África occidental, es fundamental comunicarse con los clientes dentro de una red de atención médica particular y verificar, en la medida de lo posible, la recepción del alerta.

2. Recordatorios de atención

Un sujeto que recibe cuidado puede recibir atención de múltiples proveedores a través de diversas redes de atención médica, y la coordinación de la atención entre proveedores y redes es difícil. Si hay una Historia Clínica Electrónica o una Historia Clínica Compartida/Longitudinal, las alertas del recordatorio para la atención pueden activarse a través del examen de registros clínicos sobre el sujeto que recibe cuidado. Las alertas de recordatorio de atención se envían al sujeto que recibe el cuidado.

Aunque la infraestructura del flujo de trabajo de alertas que se indica a continuación permitiría la comunicación de muchos tipos de mensajes, alertas o notificaciones adicionales, no se pretende que estos mensajes excedan los casos de uso anteriores. En particular, estos no incluyen "Hallazgos críticos" u otros tipos de alertas que requieren una acción inmediata.

El estándar Gestión de Comunicación de Alertas Móviles (Mobile Alert Communication Management, mACM) de IHE en el que este flujo de trabajo espera que se desarrollen perfiles IHE adicionales que utilicen mACM para abordar flujos de trabajo de alerta más amplios.

Madurez del flujo de trabajo	Madurez	• El flujo de trabajo está definido y aprobado por la ARB. • El flujo de trabajo admite el estándar emergente mACM de IHE en la implementación de la prueba.
Estándares*		1. Búsqueda del Borrador del estándar para uso de prueba, versión 2 (2nd Draft Standard for Trial Use, DSTU2) de FHIR en la ubicación, proveedor o recursos del paciente/Respuesta de búsqueda de paquete FHIR DSTU2 O Infraestructura de tecnología de información 73 (Information technology infrastructure, ITI-73) Solicitud de búsqueda de servicios coincidentes CSD/ ITl-73 Respuesta de búsqueda de servicios coincidentes 2. Búsqueda FHIR en solicitud de recursos del paciente (Consulta de Datos Demográficos del Paciente para Dispositivos Móviles [Patient Demographics Query for Mobile, PDQm])/respuesta de búsqueda de paquete DSTU2 de FHIR. O Solicitud de Referencias Cruzadas de Identificadores de Pacientes (Patient Identifier Cross Referencing, PIX)/Consulta de Datos Demográficos del Paciente (Patient Demographics Query, PDQ)/ Respuesta de PIX/PDQ.
Supuestos y prerrequisitos		Ninguno
		Informador de alertas. El sistema de punto de servicio que captura los identificadores de pacientes es responsable de enviar los identificadores al HIE. Un informador de alertas debe transmitir alertas (una alarma, ya sea fisiológica o técnica, o un aviso) al agregado de alertas. Este actor puede consultar opcionalmente a un actor agregador de alertas para obtener estadísticas relacionadas con la difusión del alerta a los destinatarios previstos. En el flujo de trabajo a continuación el informe de alerta se presenta como un actor genérico. Ejemplos incluyen: • Un Sistema de información de gestión de la salud (HMIS advierte que un indicador de umbral sobre el número de casos de cólera para un distrito. Un HMIS podría actuar como un reportero de Al (Artificial Intelligence, AI) consultando un registro de un trabajador de la salud
Actores		para determinar una lista de todos los clientes en el distrito y generar un alerta que indique que deben informar sobre el aumento del número de casos de cólera y brindar información sobre la prevención de enfermedades. • Un mediador en la capa de interoperabilidad podría monitorear una Historia Clínica Compartida y notar que un niño no recibió una vacuna de acuerdo con un protocolo de atención establecido. El mediador actuaría como un informe de alerta y enviaría un recordatorio por SMS a la madre u otro tutor designado. • Un Mediador puede monitorear un Sistema de Referencia Electrónico central y una Historia Clínica Compartida para detectar si el paciente ha perdido su referencia verificando si se ha recibido un encuentro en la Historia Clínica Longitudinal dentro del marco de tiempo indicado en la referencia. Si no se ha recibido una cuenta, el mediador actúa como informador de alertas y envía un alerta de la cita perdida al cliente. Agregador de alertas. Un sistema encargado de distribuir un alerta a un cliente. El agregador de alertas administra estas alertas de acuerdo con el contexto comercial definido por la jurisdicción requerida, por ejemplo, enviándolas a una plataforma de comunicaciones para su entrega a un destinatario previsto. El agregador de alertas puede recopilar opcionalmente estadísticas relacionadas con la difusión del alerta, como el estado de entrega o el valor de una respuesta o reconocimiento de SMS.

Descripción de la interacción

N.º	Interacción	Datos/notas	Opciones de transacciones
1	Observe una condición de alerta (definida por las reglas comerciales del informador de alertas).
2	Buscar identificadores de pacientes.		Búsqueda de FHIR en la solicitud de recursos del paciente (PDQm). O Solicitud PIX/PDQ
3	Buscar identificadores de pacientes.
4/5	Identificadores de devolución	Las transacciones FHIR están más alineadas con la transacción de ITl-84 de mACM que tiene referencias a recursos de organización, ubicación (p. ej., instalación) o Proveedor de recursos	Respuesta de búsqueda del paquete FHIR DSTU2 O Respuesta PIX/PDQ
6	Alerta de informe.	Identificadores de destinatarios pasados ya sea por referencia al recurso FHIR apropiado (requiere servidor FHIR para esos recursos) O Identificadores de destinatarios pasados como referencia incrustada a los recursos FHIR apropiados (no requiere servidor FHIR)	Alerta de informe móvil ITI 84 (mACM)
7	Alerta de informe.		Alerta de informe móvil ITI 84 (mACM)
8	Buscar identificadores de pacientes.		Búsqueda de FHIR en la solicitud de recursos del paciente (PDQm). O Solicitud PIX/PDQ
9	Identificadores de devolución	La implementación de referencia actual de registros interconectados (Interlinked Registries, ILR) (OpenlnfoMan) es compatible con ambas transacciones. Las transacciones FHIR están más alineadas con la transacción de ITl-84 de mACM que tiene referencias a recursos de organización, ubicación (p. ej., instalación) o proveedor de recursos	Respuesta de búsqueda del paquete DSTU2 de FHIR O Respuesta PIX/PDQ
10	Difundir alerta		Difundir alertas a través de los mecanismos de comunicación apropiados disponibles en el HIE (SMS, correo electrónico al sistema de prueba de concepto [proof of concept, POC], etc.). Las transacciones dependen del canal de comunicación.
11	Respuesta
12	Actualizar estado de difusión		Las transacciones no están especificadas (actualmente) por el estándar mACM. Nota: RapidPro utiliza el punto final personalizado compatible con FHIR "Comunicación/$respuesta" y "Comunicación/$enviado" para esto.
13	Solicitud para el estado de alertas		Solicitud para consultar el estado de alerta ITl-85 (mACM)
14	Solicitud para el estado de alertas		Solicitud para consultar el estado de alerta ITl-85 (mACM)
15	Solicitud del estado de alertas		Consulta para el estado de alerta (mACM) Respuesta