En este artículo se explica cómo crear un sistema de teleasistencia sanitaria usando la plataforma de nube de Azure.
Architecture
Descargue un archivo Visio de esta arquitectura.
Flujo de trabajo
La solución se basa en cuatro pilares, entre los que se incluyen:
- Clientes
- Componentes de comunicación
- API y lógica de negocios
- Servicios de infraestructura y almacenamiento
Del lado izquierdo del diagrama arquitectónico, hay clientes en dos grupos: el profesional sanitario y el paciente. El profesional sanitario usa el software de ajuste y los clientes del portal web para comunicarse con sus pacientes. Por otro lado, los pacientes usan una aplicación móvil que está vinculada al dispositivo médico a través de una conexión Bluetooth. Esta comunicación en ambas direcciones se logra mediante servicios back-end:
- API de acceso público
- Microservicios internos que son responsables de los flujos de trabajo, como las videollamadas a través de RTC web o la comunicación de cliente a cliente mediante Signal. Signal es una biblioteca de software para Microsoft ASP.NET que permite que el código del servidor envíe notificaciones asincrónicas a las aplicaciones web del lado cliente.
El estado de estos servicios se conserva en varios servicios de Azure (en el lado derecho del diagrama), como Azure Database for PostgreSQL. Los archivos multimedia se guardan en cuentas de almacenamiento de Azure. Todos los registros de todos los servicios se recopilan en una solución de registro centralizada que usa Azure Application Insights. Por último, se puede lograr la comunicación asincrónica entre los clientes a través de notificaciones push mediante la ayuda del Centro de notificaciones de Azure.
La solución se configuró de esta manera para:
Beneficiarse de la escalabilidad de los servicios en la nube que se ejecutan en el servidor back-end.
Aumentar la autonomía de los equipos que compilan la solución. Cada equipo supervisa los dominios funcionales e impulsa la evolución de sus componentes. Puesto que los dominios funcionales no se superponen, cada equipo puede innovar a su ritmo. Además, dado que los códigos base de los servicios son independientes, se simplifica la canalización de CI/CD para toda la solución.
Crear el mecanismo de coordinación y comunicación entre servicios que requiere la distribución de funcionalidades entre los microservicios. La solución que se describe en este documento utiliza Azure Cache for Redis para realizar esta tarea.
Logre la supervisión central y mejore la capacidad de solucionar problemas de la solución.
Administración simplificada de secretos, credenciales, certificados y claves que aprovechan las identidades administradas para proteger la comunicación entre servicios.
Componentes
- Azure Database for PostgreSQL almacena usuarios (pacientes y profesionales sanitarios) y datos relacionados con los dispositivos. Se eligió el servicio porque es estable, ligero y no tiene ningún bloqueo de proveedor.
- Azure Kubernetes Service hospeda la lógica de negocios de la aplicación y proporciona facilidad de implementación y flexibilidad para la personalización. El servicio también abstrae la solución del hardware real que se usa debajo.
- Azure Cache for Redis hospeda los datos temporales utilizados para datos de servicio (datos compartidos). El servicio se puede volver a crear desde la base de datos en caso de que los datos expiren en la memoria caché.
- Centro de notificaciones de Azure notifica a los pacientes de contenido entrante: chat, videollamadas, opciones de configuración de dispositivos.
- Azure Functions programa tareas. Por ejemplo, las comunicaciones amplias con grandes conjuntos de usuarios, la coordinación del trabajo de análisis en el servidor back-end (agregaciones...).
- Azure Application Insights centraliza las señales y los eventos del sistema (registros, telemetría de los registros de microservicios, front-end y dispositivos) para solucionar problemas.
- Azure Content Delivery Network (CDN) se utiliza para el mantenimiento y las actualizaciones (entrega de archivos de scripts de Java) en el portal web y para entregar archivos multimedia (vídeos, imágenes) a través del portal. Todo este contenido se almacena en las cuentas de almacenamiento de Azure en segundo plano.
- Azure Traffic Manager equilibra la carga entre las ubicaciones geográficas.
- Azure Signalr permite que el código del servidor envíe notificaciones asincrónicas a las aplicaciones web del lado cliente. Los dispositivos de usuario final se pueden configurar en el modo Estándar o Avanzado.
Alternativas
En el lado de la base de datos, se podría usar cualquier otro servicio de base de datos PaaS. Al hospedar la lógica de la aplicación, en lugar de usar Azure Kubernetes Service, puede considerar el uso de Azure App Service.
Detalles del escenario
Los detalles especificados están basados en una implementación de cliente real que conecta una organización sanitaria profesional con sus pacientes de forma remota. Aunque hay otras maneras de compilar este tipo de sistema, la solución descrita ha facilitado una comunicación correcta entre pacientes y el proveedor sanitario remoto, así como el ajuste remoto de los dispositivos médicos que llevan los pacientes.
Hay aproximadamente 700 millones de personas que sufren discapacidades auditivas. Sin embargo, solo el 10 % de ellas usan aparatos auditivos para mejorar su vida. En algunas situaciones o zonas geográficas, no es posible que un paciente obtenga asistencia directa cuando la necesita. Por ejemplo, en el caso de pacientes que:
- Necesitan ayuda en una situación auditiva específica (por ejemplo, al caminar en el parque, asistir a una fiesta o estar en casa), que no se puede reproducir en la oficina del profesional en audición.
- Tengan problemas de movilidad o residan a grandes distancias de su profesional en audición.
- Vivan en un país o una región emergente con un número limitado de profesionales en audición.
Para superar estas dificultades, es importante tener la capacidad de proporcionar servicios de atención auditiva de forma remota. En este caso, el profesional sanitario usa la comunicación por chat o vídeo para interactuar con sus pacientes remotos. Las personas con dificultades auditivas usan un smartphone para permitir el acceso al aparato auditivo durante la sesión remota. El paciente tiene de inmediato una mejor experiencia auditiva, ya que el profesional en audición implementa en tiempo real cambios en la configuración del aparato auditivo.
Posibles casos de uso
Esta solución es idónea para el sector sanitario. Los siguientes casos de uso adicionales tienen modelos de diseño similares:
- Se puede acceder a cualquier dispositivo habilitado para Bluetooth, el cual puede ajustarse de forma remota usando una solución de este tipo.
- Comunicación (texto, voz, vídeo) o intercambio de conocimiento (educación, encuestas de satisfacción) en un contexto o escenario remoto.
- Administración de contenido web distribuido globalmente.
- Internet de las cosas (IoT)
Modos
Modo estándar
En el modo estándar, el software de ajuste prepara una notificación que incluye contenido o algún archivo JSON de configuración para el dispositivo. La notificación se pasa al Centro de notificaciones de Azure, que la envía al teléfono del usuario.
Modo avanzado
En el modo avanzado, el profesional en audición utiliza el software de ajuste para insertar información detallada de la configuración en el dispositivo. Esto requiere una conexión estable y de confianza entre el servidor back-end y el dispositivo, que Signalr logra mediante WebSockets. El teléfono del usuario final está en el extremo receptor de este canal. Desde el teléfono, la conexión Bluetooth establece el vínculo de comunicación final con el dispositivo.
Consideraciones
Estas consideraciones implementan los pilares del marco de buena arquitectura de Azure, que es un conjunto de principios guía que se pueden usar para mejorar la calidad de una carga de trabajo. Para más información, consulte Marco de buena arquitectura de Microsoft Azure.
Se recomienda usar Traffic Manager frente a los distintos clústeres para optimizar la latencia entre regiones y como mecanismo de reserva en caso de que los clústeres dejen de estar disponibles. En el caso de las bases de datos, se recomienda usar réplicas de solo lectura para las consultas que requieren cargar y agregar una gran cantidad de datos. Se recomienda entregar archivos web estáticos (.html, .js, imágenes, etc.) globalmente mediante una red de entrega de contenido (CDN) para mejorar la velocidad a través del almacenamiento en caché.
Implementación
El aspecto más importante que hay que tener en cuenta al implementar este escenario es la coordinación de las implementaciones en el servidor back-end basado en la nube y el front-end (teléfonos/dispositivos). Considere la posibilidad de usar el concepto de una marca de característica para lograrlo.
Administración
Para alinearse mejor con la idea de que cada dominio funcional trató con un microservicio específico, a largo plazo, existe la posibilidad de dividir la base de datos en varias bases de datos más pequeñas. Al hacerlo, se habilitará el aislamiento de principio y la autonomía del flujo relacionado con cada microservicio, en lugar de concentrar los datos relacionados con todos los servicios en una sola base de datos. Para lograr este objetivo, es necesario automatizar el aprovisionamiento y la administración de esas bases de datos, que es una de las principales capacidades de un servicio de base de datos PaaS en la nube. La capa de administración de bases de datos se debe integrar en la solución, así como en la solución de supervisión unificada.
Supervisión
Es importante supervisar cada uno de los niveles, y cada faceta de supervisión se debe federar en un único cubo en la nube. Es importante habilitar la correlación de todos estos registros y puntos de datos de telemetría para garantizar información integral en los componentes y las capas.
Actualmente, entre las capas supervisadas se incluye:
- Aplicación Windows (software de ajuste en el escritorio de un profesional en audición)
- Lógica de aplicación hospedada
- Servicios en la nube
Dimensionamiento y escalado
Asegúrese de optimizar la configuración de los clústeres de Azure Kubernetes para que coincidan con los requisitos de escala que fluctúan con la hora del día o los patrones regionales. Considere la posibilidad de descargar cargas de trabajo de lectura (como la agregación de consultas) mediante el uso de réplicas de lectura en Azure Database for PostgreSQL.
El uso de la extensión TimescaleDB de PostgreSQL permitirá un control más eficaz de los datos relacionados con el tiempo procedentes de los dispositivos médicos. Considere la posibilidad de usar una solución de escalabilidad horizontal como Azure Database for PostgreSQL, Hiperescala (Citus), para alcanzar el escalado global mediante el aprovisionamiento de varios nodos de base de datos.
Seguridad y cumplimiento normativo
La seguridad proporciona garantías contra ataques deliberados y el abuso de datos y sistemas valiosos. Para más información, consulte Introducción al pilar de seguridad.
Esta solución controla la PHI y los datos personales. Por lo tanto, es importante usar servicios que estén certificados para aplicaciones médicas (certificaciones HIPAA, no solo para los datos que permanecen en la base de datos sino también los registros y los datos de telemetría). Para obtener más información, consulte la sección HIPAA del Centro de confianza de Microsoft.
La identidad administrada debe usarse en todos los servicios de Azure que admiten este tipo de autenticación sin contraseña para simplificar la administración de contraseñas: AKS, PostgreSQL, Redis Cache, Notification Hub, Azure Key Vault y Azure Functions. Consulte todos los servicios que admiten identidades administradas para recursos de Azure.
Optimización de costos
La optimización de costos trata de buscar formas de reducir los gastos innecesarios y mejorar las eficiencias operativas. Para más información, vea Información general del pilar de optimización de costos.
Para una implementación en una sola región, encontrará información de precios de ejemplo en la calculadora de precios.
Colaboradores
Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.
Creadores de entidad de seguridad:
- Jean-Yves Devant | Administrador de productos principal
Pasos siguientes
Para empezar a implementar una arquitectura comparable para su negocio, considere la posibilidad de desarrollar aptitudes en torno a servicios web, bases de datos como Azure Database for PostgreSQL y técnicas y tecnologías de desarrollo de aplicaciones móviles como .NET MAUI.
Documentación del producto:
- ¿Qué es Azure Database for PostgreSQL?
- Azure Kubernetes Service
- Cuentas de almacenamiento de Azure
- Acerca de Azure Cache for Redis
- Introducción a Azure Functions
- Azure Application Insights
- ¿Qué es Azure Notification Hubs?
Comunicaciones en tiempo real:
Encontrará más información sobre la forma en que WebRTC proporciona capacidades de comunicación en tiempo real a las aplicaciones móviles en el sitio del proyecto de WebRTC.
Servidores Turn:
Use una biblioteca cliente, como IceLink (cargada por la aplicación en el teléfono y el software de ajuste del escritorio del profesional en audición) para administrar los servidores TURN* y los tipos de conexión (TCP, UDP, P2P) entre los dos clientes (software de ajuste y aplicación en el teléfono). La biblioteca cliente:
- Crea el canal de streaming.
- Establece las conexiones.
- Administra la conexión en caso de que se produzcan errores o falten paquetes. Además, ajusta automáticamente el streaming a las variaciones del ancho de banda.
- Codifica y descodifica las llamadas (audio o vídeo) cuando se están realizando.
*Los servidores TURN son entidades de red a cargo de la retransmisión de medios en protocolos relacionados con VoIP. En esta solución, se hospedan mediante https://xirsys.com/ en varios centros de datos de todo el mundo. Establecen una conexión directa entre dos clientes de una misma sesión.