Editar

Compartir vía


Consultas virtuales con Microsoft Cloud for Healthcare

Azure

En este artículo se describe una posible solución para la programación y el seguimiento de las consultas virtuales entre pacientes, proveedores y administradores de atención.

Architecture

Architecture for virtual visit using Microsoft Cloud for Healthcare

Descargue un archivo de Visio que contiene este diagrama de arquitectura.

En este diagrama de arquitectura, los cuadros azules representan los servicios de Microsoft que son los servicios subyacentes o los complementos necesarios para Microsoft Cloud for Healthcare, cada uno de los cuales debe tener una licencia independiente. Juntos, estos componentes ayudan a acelerar el desarrollo de soluciones integradas de atención sanitaria para la participación de pacientes, la colaboración del equipo de atención y la mejora de la información de datos clínicos y operativos.

Los datos fluyen hacia el sistema a través de varios sistemas médicos externos, como consultas programadas entre pacientes y proveedores, historias clínicas, dispositivos ponibles, etc. Estos datos se ingieren mediante Azure. A continuación, se almacenan en Microsoft Dataverse, un almacén de datos de la plataforma Power Apps. Estos datos tienen formato para usar entidades y relaciones entre ellos, creados mediante Common Data Model (CDM), un estándar del sector para representar datos de atención sanitaria. Todas las interacciones entre paciente, proveedor y administrador de atención tienen lugar con estos datos de CDM almacenados en Dataverse.

Un paciente establecido puede iniciar sesión de forma segura en el Portal para pacientes, un sitio web hospedado en los portales de Power Apps. En este portal, el paciente puede comunicarse con un asistente inteligente. Se trata de una instancia del servicio Azure Health Bot, que recopila sus síntomas, ofrece sugerencias y recomienda llamar al profesional, si es necesario. Si el paciente opta por conectar a su proveedor de atención sanitaria, la instancia de bot de atención obtiene los datos de los proveedores disponibles para consultas virtuales y sus horarios, desde Dataverse. Una vez que el paciente selecciona a un proveedor y una hora, el bot presenta la información de contacto, obtenida a partir de los datos de HCE/HSE almacenados en Dataverse. El paciente puede validar o cambiar esta información y guardar los datos con el bot.

Para programar una cita, la instancia del bot de atención sanitaria se conecta a la aplicación Bookings mediante Microsoft Graph API y agenda una cita en el calendario del proveedor. Se envía un correo electrónico con la información de la cita a ambas partes utilizando Microsoft Outlook. El paciente recibe instrucciones para iniciar sesión en el Portal para pacientes para el proceso de admisión. Este proceso implica confirmar o cambiar su información de contacto, pago y seguro y, a continuación, firmar un formulario de consentimiento para la consulta virtual. Una vez que firma el consentimiento, se le proporciona el vínculo Microsoft Teams para la cita.

El proveedor inicia sesión en Teams para comprobar los horarios de las citas y el resumen de cada una. Teams presenta esta información mediante la aplicación Appointment Queue. Después, el proveedor puede iniciar la consulta virtual en Teams para la cita programada. Durante la llamada, el proveedor puede tomar notas y agregarlas a la historia del paciente.

Una nueva nota en la historia clínica del paciente desencadena una notificación de revisión para el administrador de atención asignado al paciente. Cuando el administrador de atención recibe esta notificación, puede iniciar sesión en Teams, donde puede ver los pacientes que tiene asignados y ver las notas. A través de la aplicación Care Management, puede realizar los cambios necesarios en el plan de atención al paciente.

Componentes

La arquitectura consta de los siguientes componentes:

  • SAP. Los sistemas de administración de pacientes (SAP) son sistemas que automatizan el papeleo administrativo en organizaciones de atención sanitaria, como hospitales. Son los componentes principales de la infraestructura de TI de una organización de este tipo. Un SAP registra los datos demográficos del paciente, como el nombre, la dirección particular, la fecha de nacimiento, etc. También registra información detallada de todos los contactos del paciente con el hospital, tanto como paciente ambulatorio como internado. Con la ayuda del SAP, los hospitales modernos pueden informar y programar recursos a lo largo de toda la organización. El SAP es una fuente clave de los datos sobre horarios en esta solución. Dado que estos datos son externos y pueden estar en un formato no estándar, es importante convertirlos a un formato que entiendan todos los componentes de esta solución.

  • HCE/HSE. Las historias clínicas electrónicas (HCE) y las historias sanitarias electrónicas (HSE) proporcionan los registros digitales de la información médica y sanitaria de un paciente, incluidos los diagnósticos, los medicamentos, las vacunas, etc. Pueden estar limitadas a un único consultorio médico, como las HCE, o bien estar diseñadas para un ámbito mucho mayor, y acompañar a los pacientes hasta cualquier centro al que acudan, como las HSE. Estos son orígenes de datos externos importantes en esta solución y pueden tener un formato no estructurado no estándar. Por tanto, estos datos se deben convertir a un formato que los componentes de esta solución puedan usar.

  • Azure API for FHIR. Azure es el primer paso en el proceso de incorporar datos en el ecosistema de Microsoft y Microsoft Cloud for Healthcare. Esta capa proporciona una interfaz segura entre los datos externos y los componentes internos de esta arquitectura. Azure API for FHIR ingiere los datos procedentes de orígenes dispares, como HCE, SAP, dispositivos, ya sean estructurados o no estructurados, los convierte en FHIR y se conservan en Azure. Estos datos se pueden usar a continuación en Microsoft Cloud for Healthcare para distintos servicios. Azure API for FHIR se creó teniendo en cuenta la seguridad y el cumplimiento y está diseñada para los datos de PHI (información médica protegida). Para obtener más información sobre esta capa, consulte Azure para el sector sanitario y la API de Azure para FHIR

  • Common Data Model. Con Common Data Model, Microsoft proporciona un sistema estandarizado de definición de metadatos que es extensible y personalizable para necesidades empresariales específicas. Las entidades CDM están disponibles para áreas temáticas, como, CRM, atención sanitaria, talento, etc. Para obtener más información, lea la información de uso de Common Data Model. Además de estas entidades, los clientes pueden extraer datos de su propiedad definiendo la tabla de entidades y los campos subyacentes en Common Data Model, que luego se pueden usar sin problemas con otras entidades en toda la solución.

  • Microsoft Dataverse. Dataverse, una base de datos relacional que alimenta Microsoft Dynamics 365, es el repositorio de los datos representados en Common Data Model. Contiene las bases de datos con información de los pacientes, incluidos detalles como sus nombres, información familiar, enfermedades, historiales, etc. También contiene la información obtenida de los dispositivos ponibles usados y registrados por los pacientes, así como los datos de agenda y de administración de la organización de atención sanitaria. Estos datos se definen mediante Common Data Model.

  • Portal para pacientes. Este portal de Power Apps permite a los pacientes ver sus historias clínicas, reservar citas, conversar con la instancia de bot de atención sanitaria, etc. Este portal se puede extender para admitir otros datos. Forma parte de Microsoft Cloud for Healthcare y permite poner en marcha fácilmente un portal, que puede conectarse con entidades en Dataverse, extrayendo datos, como información de pacientes, planes de atención, citas, etc.

  • Intelligent Assistance. Se trata de una instancia del servicio Azure Health Bot, a la que pueden acceder los pacientes a través del Portal para pacientes. Esta instancia del bot de atención sanitaria está cargada dentro de un sitio web de Azure App Service. Se puede personalizar y programar con los escenarios necesarios para los clientes.

  • Aplicación Bookings. La aplicación Bookings es un servicio de Microsoft 365, incluido en Microsoft Cloud for Healthcare. Facilita la programación de eventos de calendario y permite crear reuniones de Teams.

  • Microsoft Outlook. Esta solución usa Microsoft Outlook como cliente de correo electrónico. La aplicación Bookings que envía la notificación por correo electrónico está integrada en Outlook. Como alternativa, se puede usar el cliente de correo electrónico preferido por el proveedor de atención sanitaria.

  • Microsoft Teams. Microsoft Teams es un componente de Microsoft Cloud for Healthcare y proporciona el front-end para las interacciones entre pacientes, proveedores y administradores de atención sanitaria. Los usuarios pueden usar una versión instalada localmente o la versión web. Para obtener más información sobre Teams, lea la documentación de Microsoft Teams.

  • Appointment Queue. Esta herramienta genera una página HTML con datos extraídos de Dataverse, mediante la API web de Dynamics 365. Presenta al proveedor información acerca de las citas programadas para el día y el resumen de cada una. También proporciona un vínculo para acceder a la información del paciente a través de la aplicación Care Management. Appointment Queue se desarrolló para admitir este escenario y no forma parte de Microsoft Cloud for Healthcare. Las fuentes de datos para esta herramienta son principalmente los sistemas PAS y los registros EMR/EHR. Si estos sistemas tienen herramientas integradas para presentar estos datos, esas herramientas pueden suponer un reemplazo para este componente en una implementación real.

  • Care Management. La herramienta Care Management es un componente de Microsoft Cloud for Healthcare. Se trata de una aplicación de Power Apps implementada a través de Dynamics 365. Extrae los datos de las HCE/HSE de los pacientes almacenados en Dataverse en formato CDM, y presenta una vista agregada en Teams. La solución de un centro de atención puede optar por usar su propio sistema para su funcionalidad, en función de cómo se quiera presentar esta información.

  • Análisis de Power BI. Se trata de una herramienta de análisis creada para este escenario y no está disponible con Microsoft Cloud for Healthcare. En esta solución, se genera información proveniente de los dispositivos IoMT del paciente. Puede tratarse de datos como la frecuencia cardíaca, el nivel de oxígeno en sangre, etc. La aplicación Care Management usa estos datos para presentar a los proveedores de atención sanitaria información adicional sobre sus pacientes en función de sus actividades diarias.

  • Dispositivos conectados. Se trata de dispositivos de Internet de las cosas médicas (IoMT) , que son dispositivos inteligentes para uso médico o sanitario. Entre los ejemplos de dispositivos IoMT se incluyen ponibles, como Apple Watch o Fitbit, monitores médicos o vitales, etc. Los pacientes pueden aprovisionar sus dispositivos a través de Azure y optar por permitir que su sistema de administración de atención sanitaria recopile los datos de IoMT para su uso por parte de sus proveedores. Los proveedores pueden obtener información adicional de estos dispositivos, casi en tiempo real, y vincular anomalías, como una frecuencia cardíaca elevada durante un período de tiempo, con los síntomas actuales del paciente.

  • Automatización con Power Automate. Se trata de una herramienta personalizada creada para admitir este escenario y no está disponible con Microsoft Cloud for Healthcare. Dado que se trata de un escenario de consulta virtual, el proveedor podría ser un médico de guardia y no el médico habitual del paciente. Esta herramienta permite que las notas del proveedor desencadenen una notificación de Teams para el administrador de atención. Un administrador de atención es el miembro del equipo médico que trabaja como enlace entre el médico de atención primaria y el paciente, y se encarga de la administración de la atención a largo plazo. Una notificación enviada al administrador de atención, que indica que se han agregado nuevas notas para el paciente, le permite revisar y realizar los cambios adecuados en la administración de atención del paciente después de la consulta.

Alternativas

Los servicios de Azure para el sector sanitario, como Azure API for FHIR y Azure Health Bot, la interfaz de Common Data Model, Microsoft Dataverse y Microsoft Teams forman los componentes principales de esta solución. La mayoría de los demás componentes de este sistema pueden reemplazarse por sistemas usados actualmente por el centro de atención sanitaria:

  • Si el sistema de HCE/HSE incluye complementos para la administración de reservas, agendas y atención, estos complementos se pueden usar en esta solución en lugar de los componentes correspondientes.

  • Los sistemas usados por el centro de atención sanitaria podrían usarse en lugar de Bookings y las notificaciones por correo electrónico y la programación de Outlook. Esto puede hacerse a través del sistema HCE o a través de una aplicación de un tercero. La aplicación debe proporcionar una API que la instancia del bot de atención sanitaria pueda usar para crear y programar citas, junto con la capacidad de crear reuniones virtuales.

  • Si el proveedor ya tiene implementado un portal para pacientes a través de su sistema de HCE/HSE, se puede usar en lugar del Portal para pacientes. Es fácil integrar este componente externo en esta solución, ya que estos componentes usaban interfaces estándar, por ejemplo, una interfaz iFrame para comunicarse con la instancia del bot de atención sanitaria. Los componentes que admiten este flujo se pueden crear en el portal de su propiedad, como el formulario de consentimiento que el paciente tiene que firmar antes de unirse a la reunión de Teams.

  • Merece la pena tener en cuenta que una implementación real necesitará herramientas de reemplazo para algunos componentes de esta solución, como Appointment Queue, las notificaciones automatizadas y las herramientas de análisis de Power BI. Estos componentes se deben crear y personalizar según las necesidades empresariales del proveedor de atención sanitaria.

Detalles del escenario

En la actual pandemia de COVID-19 (coronavirus), es posible que un gran número de pacientes prefieran visitar a sus proveedores de atención sanitaria de manera virtual y no en persona, siempre que sea posible. Mejorar la información clínica y operativa en la atención sanitaria es importante en dicho mundo virtual. Esto incluye la conexión de los datos entre sistemas, la creación de información para predecir riesgos y ayudar a mejorar la atención al paciente, el control de calidad y las eficiencias operativas.

La base de esta solución es Microsoft Cloud for Healthcare. Microsoft Cloud for Healthcare reúne las funcionalidades de confianza de Microsoft 365, Azure, Dynamics 365, Power Platform y el amplio ecosistema de asociados de Microsoft para ayudar a las organizaciones de atención sanitaria a crear soluciones sanitaria rápidas, eficientes y seguras.

Posibles casos de uso

Esta solución está destinada a proporcionar atención virtual a los pacientes en el contexto de la actual pandemia. Sin embargo, los proveedores de atención sanitaria pueden aplicarla fácilmente en los siguientes escenarios:

  • Programar seguimientos virtuales para las consultas presenciales.

  • Brindar una guía médica que no sea de emergencia a los pacientes mientras están de viaje.

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.

Seguridad

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.

Dado que el sistema se basa en los datos de los pacientes, al desarrollar esta solución deben aplicarse consideraciones básicas de seguridad para la información privada:

  • Solo los datos necesarios deben fluir a través del sistema en cualquier momento dado. Por ejemplo, extraiga solo los datos de los sistemas de HCE/HSE que sean necesarios para la programación y administración de la consulta virtual. Revise las reglas de cumplimiento de HIPAA establecidas para obtener instrucciones sobre dónde se deben almacenar los datos de los pacientes, qué se puede hacer con ellos y quién debe tener acceso a ellos. Durante el desarrollo de la solución, tenga en cuenta la importancia del cumplimiento en la atención sanitaria. Para obtener más información, lea Cumplimiento en Microsoft Cloud for Healthcare.

  • Solo el personal autorizado debe tener acceso a los datos de los pacientes y solo a los datos necesarios para su rol. En varios puntos del sistema, como Care Management y el análisis que lo alimenta, Appointment Queue o los sistemas de notificación, se debe tener cuidado al autenticar y autorizar al personal, y limite el acceso a la información de los pacientes únicamente necesaria.

  • Los módulos que interactúan con pacientes, como Intelligent Assistance y la aplicación Bookings, toman, almacenan y usan datos de pacientes. El control de acceso y la autenticación adecuados en estos módulos garantizan que se aborden los problemas de privacidad.

Debido a la naturaleza de los datos privados implicados, la seguridad y el cumplimiento son principios básicos de Microsoft Cloud for Healthcare.

Este ejemplo también se basa en las reglas de seguridad establecidas por Dynamics 365 y Teams:

Los servicios individuales incluidos en Microsoft Cloud for Healthcare proporcionan su propia capa de seguridad y cumplimiento:

En el caso de los controles de seguridad personalizados, considere la posibilidad de usar Microsoft Entra ID y el control de acceso basado en roles.

Por último, al implementar esta solución, tenga en cuenta los procedimientos recomendados y la guía para desarrollar soluciones de Azure seguras.

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 obtener información detallada sobre los precios de Microsoft Cloud for Healthcare, consulte Compra de Microsoft Cloud for Healthcare. Los componentes que conforman Microsoft Cloud for Healthcare tienen sus propios requisitos de licencia, como:

Para volver a crear los componentes de esta arquitectura que se han personalizado, tenga en cuenta la información de precios de los servicios subyacentes que decida usar.

Implementación de este escenario

La solución debe implementarse en fases:

  1. Algunos productos o servicios deben instalarse como requisitos previos de Microsoft Cloud for Healthcare. Consulte la lista detallada de este artículo sobre los requisitos de licencia.

  2. Microsoft Cloud for Healthcare se puede implementar mediante las instrucciones incluidas en Implementar soluciones de Microsoft Cloud for Healthcare con tecnología de Dynamics 365.

  3. Microsoft Cloud for Healthcare proporciona componentes básicos para empezar a crear rápidamente una solución de atención sanitaria virtual, como el Portal para pacientes, Teams, Bookings, etc. Los datos que se usarán para potenciar estos bloques de creación deben personalizarse según las necesidades empresariales.

  4. Los componentes disponibles en Microsoft Cloud for Healthcare y sus requisitos previos se deben personalizar para satisfacer las necesidades empresariales:

    1. Se deben crear flujos de Power Automate para admitir las notificaciones del administrador de atención.

    2. Se debe configurar el Portal para pacientes. Es posible que sea necesario crear formularios adicionales para elementos como los formularios de admisión o consentimiento. Lea Definir y configurar un portal de acceso a pacientes para obtener más información.

    3. El servicio Azure Health Bot debe estar conectado a la base de datos de Dataverse y personalizado para su comunicación con los pacientes. Para obtener más información, consulte Configurar chats automáticos con Microsoft Health Bot.

    4. Consulte Configurar la sincronización con datos clínicos con el Agente de sincronización de Azure FHIR e Insertar informes de Power BI para análisis para comprender otras configuraciones que puedan ser necesarias.

  5. Los componentes adicionales que se crearon específicamente para esta solución no están disponibles para el uso en el nivel de producción. Es posible que el centro de atención sanitaria tenga que crear su propia versión de estas aplicaciones:

    1. Appointment Queue

    2. Notificaciones automatizadas mediante Power Automate

    3. Aplicación de informes con Power BI

Colaboradores

Microsoft mantiene este artículo. Originalmente lo escribieron los siguientes colaboradores.

Creadores de entidad de seguridad:

Para ver los perfiles no públicos de LinkedIn, inicie sesión en LinkedIn.

Pasos siguientes