Dataverse API de atención médica: use la plantilla de canalización de datos de Healthcare para implementar Azure Logic Apps
Este artículo proporciona guías paso a paso para usar una plantilla para implementar un grupo de Azure Logic Apps que ingieren datos FHIR en Dataverse Healthcare APIs, Azure Health Data Services, o ambos. Esta solución funciona como un flujo de aplicación lógica listo para la empresa que sirve como relé entre Azure Health Data Services y la API de atención médica de Dataverse. El flujo también gestiona la lógica de reintento y el manejo de excepciones. Se basa en un desencadenador de Azure Blob Storage en lugar del desencadenador HTTP utilizado en la configuración manual.
Este flujo de trabajo está disponible para su implementación como una plantilla de Azure Resource Manager (ARM) titulada Plantilla de canalización de datos de atención médica. Puede implementar la plantilla desde Centro de soluciones de Microsoft Cloud. Esta oferta es una solución más resistente y compatible proporcionada por Microsoft Cloud for Healthcare. Es necesario configurar algunas configuraciones manuales básicas después de implementar la plantilla.
Nota
Este flujo de aplicación lógica se porporciona como un punto de entrada para los datos de registros sanitarios electrónicos (HME) entrantes, lo que garantiza que los datos de FHIR se publiquen en los servicios correctos. No es una solución final en su estado actual y está pensada para actualizarse en función de las necesidades de su negocio.
No es necesario que estos servicios de aplicaciones lógicas publiquen datos de FHIR en los puntos finales de la Dataverse Healthcare API. Puede elegir crear su propia solución para transmitir datos de su EHR a las API y manejar las respuestas.
Los servicios de la aplicación lógica se basan en un desencadenador de Azure Blob Storage para el procesamiento asincrónico de los paquetes publicados en una ubicación de almacenamiento configurable. Esta opción gestiona cargas más pesadas para casos de uso empresariales e incluye pasos adicionales de manejo de excepciones. Sin embargo, debe realizar pruebas exhaustivas con las cargas diarias previstas.
Después de la implementación, puede ampliar las Logic Apps para adaptarlo a las necesidades particulares de su sistema.
Importante
Esta plantilla ARM solo es compatible con Microsoft Cloud for Healthcare segunda ola de lanzamientos de 2022 y versiones posteriores. Para versiones anteriores, elimine la acción Establezca requestBody en respuesta FHIR en caso de éxito antes de iniciar una ejecución.
La configuración incluye los siguientes pasos:
- Requisitos previos
- Diseño
- Pasos de posimplementación
- Controlar los errores
- Configuración de reintentos
- Asegurar Logic Apps
Requisitos previos
Debe asegurarse de que su entorno cumple los siguientes requisitos antes de implementar la plantilla:
- Una cuenta de Azure y suscripción. Si no dispone de una suscripción, regístrese para una cuenta de Azure gratuita antes de comenzar.
- Un Grupo de recursos Azure configurado con los permisos adecuados para crear nuevos recursos, o un Rol de colaborador para crear nuevos grupos de recursos.
- Acceda dentro del grupo de recursos para crear recursos y asignar roles de Azure.
- Cumplimiento de las pautas de seguridad descritas por los administradores de Azure y la política de la organización.
Diseño
El siguiente diagrama ilustra el diseño de la canalización implementada a través de la plantilla:
La plantilla ARM implementa varias Logic Apps modularizadas. Incluye los siguientes tres servicios de aplicación lógica:
| Aplicación lógica | Descripción |
|---|---|
| Proceso de agrupación de FHIR | La primera instancia de aplicación lógica que se activa cuando se carga un paquete en el almacenamiento de blobs. Esta aplicación lógica determina si se debe publicar el paquete en FHIR o directamente en Dataverse. |
| Enviar agrupación a FHIR | La segunda aplicación lógica se activa desde la aplicación lógica Procesar paquete FHIR, cuando elige publicar el paquete en FHIR. Esta aplicación lógica procesa la agrupación de solicitud y la publica en el servidor FHIR. Después de que esta aplicación lógica publica el paquete en el servidor FHIR, retransmite el paquete a la siguiente aplicación lógica Enviar paquete a Dataverse para su posterior procesamiento. |
| Enviar agrupación a Dataverse | La aplicación lógica final se activó desde la aplicación lógica Procesar agrupación de FHIR o Enviar agrupación a FHIR. Procesa el paquete de solicitudes y lo publica en Dataverse. También maneja la limpieza del contenedor de paquetes moviendo el paquete solicitado al contenedor bundleserror o bundlesarchive. |
Parámetros de plantilla
| Parámetro | Descripción |
|---|---|
| Ubicación del recurso | La región de Azure para la creación del recurso. El valor predeterminado de este parámetro es la región que se usó al crear el grupo de recursos. |
| URL de Dataverse | La URL del entorno de Dataverse de Microsoft Cloud for Healthcare. Por ejemplo, https://*orgname*.crm.dynamics.com |
| Publicar en el servidor FHIR | Un valor booleano. Si se establece como verdadero, el paquete se publica en el servidor FHIR. |
| URL del servidor FHIR | La dirección URL de su servidor FHIR. Por ejemplo, https://*fhirserver*.azurewebsites.netSolo necesita este parámetro si desea publicar en el servidor FHIR antes de publicar en el punto final de la API upsert de Dataverse. |
| Valor único | La cadena única utilizada para generar nombres de recursos. Este valor predeterminado es la función uniqueString. Puede reemplazar este valor si es preciso. |
Recursos implementados
La plantilla implementa los siguientes recursos en su entorno:
| Recurso | Descripción |
|---|---|
| Identidad administrada | El nombre de la identidad administrada tiene el formato mi_UniqueValue. Esta identidad administrada se asigna a la aplicación lógica y se le otorga acceso a la cuenta de almacenamiento, al servidor FHIR y al entorno de Dataverse. |
| Cuenta de Azure Storage | El nombre de la cuenta de almacenamiento tiene el formato sa_UniqueValue. Junto con la cuenta de almacenamiento, la plantilla también implementa los siguientes tres contenedores: bundles, bundlesarchive y bundleserror. |
| Asignación de roles | Asigna el rol Storage Blob Data Contributor en la cuenta de almacenamiento a la identidad administrada. |
| Azure Event Grid | El nombre de Event Grid tiene el formato eg_UniqueValue. Todos los eventos blob se publican en este Event Grid. |
| Azure Service Bus | El nombre de Service Bus tiene el formato sb_UniqueValue. El Event Grid publica eventos en este Service Bus. Nombre de la cola es bundleCreated. |
| Regla de autorización | Crea una regla de autorización Escucha en el Service Bus con el nombre bundleauthlisten. |
| Aplicaciones lógicas de Azure | Un conjunto de flujo de trabajo de aplicación lógica relacionado del tipo Consumo. El flujo de trabajo se activa a partir de los eventos de Service Bus. Estas aplicaciones lógicas procesan la agrupación FHIR entrante y la publica en los puntos de conexión configurados. Cada aplicación lógica recibe un nombre mediante el valor único proporcionado durante la implementación: 1. laprocessfhirbundle_UniqueValue 2. lasendbundletodataverse_UniqueValue 3. lasendbundletofhir_UniqueValue |
| Conexión API | Se requieren varias conexiones API para Logic Apps. |
Salida
En función de si la ejecución finaliza con éxito o error, se crea un blob con el nombre originalblobname_response.json en el bundlesarchive o la carpeta bundleserror con el siguiente esquema:
{
"dataverseResponse": "<The response from the Dataverse healthcare API post the call.>",
"fhirServerResponse": "<The response from the FHIR server call if the "Post to FHIR server" parameter value was set to True.>",
"statusMessage": "<Summary of the responses. In case of a failure, the message provides details about how many resources failed to post to the FHIR server and to Dataverse.>",
"statusCode": "<Code value associated with the issue encountered.>"
}
Según la aplicación lógica que desencadenó el error, el error JSON contiene el nodo dataverseResponse o fhirServerResponse. Por ejemplo, si encuentra un error con la aplicación lógica lasendbundletofhir_UniqueValue, la respuesta de JSON solo contiene el nodo y el valor de nodo fhirServerResponse.
Pasos de posimplementación
La siguiente sección contiene los pasos que debe seguir tras implementar la plantilla.
Conceda acceso al servidor FHIR
Acceder al servidor FHIR desde la aplicación lógica requiere la asignación de roles colaborador de datos de FHIR, que permite publicar nuevos datos en el servicio. Agregue esta asignación de rol Azure a la identidad administrada utilizada por la aplicación lógica.
Vaya a la instancia del servidor FHIR, seleccione Control de acceso (IAM) y luego seleccione Agregar asignación de roles.
En la pestaña Rol, seleccione el rol Colaborador datos FHIR.
Seleccione Miembros, seleccione Identidad administrada y luego seleccione + Seleccionar miembros.
Agregue la identidad administrada creada con la implementación de la plantilla ARM. La identidad administrada recién implementada debe denominarse mi_UniqueValue.
La asignación puede tardar unos minutos en reflejarse en la identidad administrada. Seleccione Asignaciones de roles de Azure para ver la asignación de roles en la identidad administrada.
Otorgar acceso a Dataverse Healthcare APIs
La misma identidad administrada se usa en la aplicación lógica para acceder a las Dataverse Healthcare APIs al conectarlo a un usuario de la aplicación en la instancia de destino de Dataverse. Para obtener más información sobre los usuarios de la aplicación, vaya a ,Administración de usuarios de la aplicación en el centro de administración de Power Platform.
Necesita el identificador de cliente de Azure para la identidad administrada para configurar el usuario de la aplicación. Para recuperar el ID de cliente, abra la identidad administrada creada con la implementación de la plantilla ARM y copie el valor ID de cliente del área Descripción general.
En el Centro de administración de Power Platform, abra el entorno de Microsoft Cloud for Healthcare de destino. En la sección Acceso, seleccione Aplicaciones S2S y luego seleccione Nuevo usuario de la aplicación.
En el panel Crear un nuevo usuario de la aplicación, seleccione la Unidad de negocio adecuada y luego seleccione Agregar una aplicación.
En el panel Agregar una aplicación desde Microsoft Entra ID, busque el id. de cliente que copió de la identidad administrada.
Seleccione la identidad administrada de la lista, seleccione Agregar y, a continuación, edite los roles de seguridad.
Seleccione el rol Usuario de registro de la aplicación Administración de sincronización para FHIR y seleccione Guardar.
Seleccione Crear para crear el nuevo usuario de la aplicación.
Después de completar la configuración, puede probar el flujo de trabajo de la aplicación lógica publicando un paquete de muestra en el contenedor sa_UniqueValue para su procesamiento. Dependiendo de los requisitos de su solución, también puede modificar cualquiera de estas Logic Apps para obtener más procesamiento.
Controlar los errores
Si la ejecución de una aplicación lógica produce un error, se crea un archivo con el nombre originalblobname_response.json en el contenedor bundleserror de la cuenta de almacenamiento. Puede analizar este archivo para identificar la causa raíz del error, solucionarlo y volver a enviar el paquete con los recursos fallidos.
Tipo de agrupación: lote
El servidor FHIR y las Dataverse Healthcare APIs procesan un paquete del tipo lote como un grupo de acciones independientes. Como resultado, las respuestas indican el éxito y el fracaso de cada recurso de forma independiente.
Según la especificación FHIR, cualquier recurso que falla genera un OperationOutcome con un valor de gravedad establecido en error, mientras que la Dataverse healthcare API establece msind_requeststatus a 935000002. Para obtener más información sobre los tipos de estado de solicitud, vaya a Tipos de estado de solicitud.
El flujo de trabajo de la aplicación lógica analiza las respuestas del servidor FHIR y las API de atención médica de Dataverse. Finaliza el flujo como Fallido si hay algún recurso que generó un error.
Nota
Dataverse Healthcare APIs solo admiten paquetes FHIR del tipo lote y respuesta por lotes.
Configuración de reintentos
Después de identificar y corregir el error, puede volver a colocar el paquete en el recipiente para reprocesamiento bundles.
Vuelva a intentar acelerar: servidor FHIR
La acción HTTP en el flujo de trabajo de la aplicación lógica que publica en el servidor FHIR usa las políticas de reintento de acción HTTP integradas. El valor predeterminado es una política de intervalo exponencial establecida para reintentar cuatro veces. Puede editar la directiva de reintento.
Seleccione los puntos suspensivos en la esquina superior derecha de la tarjeta de acción y después Configuración.
Debajo de Política de reintento, cambie el valor del campo Tipo.
Vuelva a intentar con la limitación: Dataverse Healthcare APIs
Los Límites de la API de protección del servicio afectan a las Dataverse Healthcare APIs. Si una solicitud a las Dataverse Healthcare APIs se limita, el flujo de trabajo de la aplicación lógica (de forma predeterminada) vuelve a intentarlo tres veces al mismo tiempo con el intervalo Retry-After especificado por la API en el encabezado de respuesta. Puede editar tanto el recuento de reintentos como el intervalo.
Para cambiar el conteo de reintentos, edite el valor de Recuento en la acción Bucle hasta.
Para cambiar el intervalo, edite el valor de Recuento en la acción Retraso.
Asegurar Logic Apps
Una vez que termine de configurar y probar la aplicación lógica, puede bloquear el seguimiento asegurando las acciones de entrada y salida. Para obtener más información, vaya a Asegurar Logic App.