Dataverse Healthcare API: utilizzare Modello pipeline dati assistenza sanitaria per distribuire app per la logica di Azure
Questo articolo fornisce una guida dettagliata per l'uso di un modello per distribuire un gruppo di app per la logica di Azure che inseriscono dati FHIR nelle Dataverse Healthcare API, nei Servizi per i dati sanitari di Azure o in entrambi. Questa soluzione funziona come un flusso di app per la logica pronto per l'azienda che funge da tramite tra Servizi per i dati sanitari di Azure e Dataverse Healthcare API. Il flusso gestisce anche la logica di ripetizione e la gestione delle eccezioni. Si basa su un trigger di Archiviazione BLOB di Azure piuttosto che sul trigger HTTP utilizzato nella configurazione manuale.
Questo flusso di lavoro è disponibile per la distribuzione come modello Azure Resource Manager (ARM) denominato Modello pipeline dati assistenza sanitaria. Puoi distribuire il modello da Centro soluzioni Microsoft Cloud. Questa offerta è una soluzione supportata e più affidabile fornita da Microsoft Cloud for Healthcare. Dopo aver distribuito il modello, devi impostare alcune configurazioni manuali di base.
Nota
Questo flusso di app per la logica viene fornito come punto di ingresso per i dati delle cartelle cliniche elettroniche in entrata, assicurando che i dati FHIR vengano pubblicati nei servizi appropriati. Allo stato attuale non si tratta di una soluzione definitiva, ma è destinata ad essere aggiornata in base alle esigenze aziendali.
Questi servizi per app per la logica non sono necessari per pubblicare dati FHIR negli endpoint delle Dataverse Healthcare API. Puoi scegliere di creare la tua soluzione per inoltrare dati dal tuo sistema CCE alle API e gestire le risposte.
I servizi di app per la logica si basano su un trigger di Archiviazione BLOB di Azure per attivare l'elaborazione asincrona delle aggregazioni pubblicate in una posizione di archiviazione configurabile. Questa opzione gestisce carichi più pesanti per i casi d'uso aziendali e include ulteriori passaggi di gestione delle eccezioni. Tuttavia, devi condurre test approfonditi con i carichi giornalieri previsti.
Dopo l'implementazione, puoi estendere le app per la logica per adattare le specifiche esigenze del tuo sistema.
Importante
Questo modello di ARM è compatibile solo con il secondo ciclo di rilascio del 2022 di Microsoft Cloud for Healthcare e versioni successive. Per le versioni precedenti, elimina l'azione Imposta requestBody sulla risposta FHIR in caso di esito positivo prima di avviare un'esecuzione.
La configurazione prevede i passaggi seguenti:
- Prerequisiti
- Progettazione
- Passaggi successivi alla distribuzione
- Gestione degli errori
- Configurare i tentativi
- Proteggere le app per la logica
Prerequisiti
Assicurati che il tuo ambiente soddisfi i seguenti requisiti prima di distribuire il modello:
- Account e sottoscrizione di Azure. Se non disponi di una sottoscrizione, registrati per un account di Azure gratuito prima di iniziare.
- Un gruppo di risorse Azure configurato con le autorizzazioni appropriate per creare nuove risorse oppure un ruolo di collaboratore per creare nuovi gruppi di risorse.
- Accesso al gruppo di risorse per creare risorse e assegnare ruoli di Azure.
- Adesione alle linee guida di sicurezza delineate dagli amministratori di Azure e dai criteri dell'organizzazione.
Progettazione
Il diagramma seguente illustra la progettazione della pipeline distribuita tramite il modello:
Il modello di ARM distribuisce diverse app per la logica modularizzate. Include i seguenti tre servizi di app per la logica:
| App per la logica | Descrzione |
|---|---|
| Elaborazione dell'aggregazione FHIR | La prima istanza dell'app per la logica viene attivata quando un'aggregazione viene caricata nell'archiviazione BLOB. Questa app per la logica determina se pubblicare l'aggregazione in FHIR o direttamente in Dataverse. |
| Invio dell'aggregazione a FHIR | La seconda app per la logica attivata dall'app per la logica Elabora aggregazione FHIR, quando scegli di pubblicare l'aggregazione in FHIR. Questa app per la logica elabora l'aggregazione di richiesta e la pubblica nel server FHIR. Dopo che questa app per la logica pubblica l'aggregazione nel server FHIR, lo inoltra alla successiva app per la logica Invia aggregazione a Dataverse per un'ulteriore elaborazione. |
| Invio dell'aggregazione a Dataverse | L'app per la logica finale attivata dall'app per la logica Elaborazione dell'aggregazione FHIR o Invio dell'aggregazione FHIR. Elabora l'aggregazione di richieste e pubblica il pacchetto in Dataverse. Gestisce anche la pulizia del contenitore delle aggregazioni spostando l'aggregazione delle richieste nel contenitore bundleserror o bundlesarchive. |
Parametri del modello
| Parametro | Descrzione |
|---|---|
| Posizione della risorsa | L'area di Azure per la creazione di risorse. Il valore predefinito di questo parametro è l'area utilizzata per creare il gruppo di risorse. |
| URL Dataverse | L'URL dell'ambiente Microsoft Cloud for Healthcare Dataverse. Ad esempio, https://*orgname*.crm.dynamics.com |
| Pubblica nel server FHIR | Un valore booleano. Se impostata su true, l'aggregazione viene pubblicata nel server FHIR. |
| URL del server FHIR | L'URL del server FHIR. Ad esempio, https://*fhirserver*.azurewebsites.netquesto parametro è necessario solo se vuoi pubblicare nel server FHIR prima di pubblicare nell'endpoint Dataverse upsert API. |
| Valore univoco | La stringa univoca utilizzata per generare nomi di risorse. Il valore predefinito è la funzione uniqueString. Se necessario, puoi sostituire tale valore. |
Risorse distribuite
Il modello distribuisce le seguenti risorse nel tuo ambiente:
| Risorsa | Descrizione |
|---|---|
| Identità gestita | Il nome dell'identità gestita è nel formato mi_UniqueValue. Questa identità gestita viene assegnata all'app per la logica e le viene concesso l'accesso all'account di archiviazione, al server FHIR e all'ambiente Dataverse. |
| Account di archiviazione di Azure | Il nome dell'account di archiviazione è nel formato sa_UniqueValue. Insieme all'account di archiviazione, il modello distribuisce anche i tre contenitori seguenti: bundles, bundlesarchive e bundleserror. |
| Assegnazione di ruolo | Assegna il ruolo Collaboratore dati BLOB di archiviazione dell'account di archiviazione all'identità gestita. |
| Griglia di eventi di Azure | Il nome della griglia di eventi è nel formato eg_UniqueValue. Tutti gli eventi blob vengono pubblicati in questa griglia di eventi. |
| Bus di servizio di Azure | Il nome del bus di servizio è nel formato sb_UniqueValue. La griglia di eventi pubblica eventi in questo bus di servizio. Il nome della coda è bundleCreated. |
| Ruolo di autorizzazione | Crea una regola di autorizzazione Ascolta sul bus di servizio con il nome bundleauthlisten. |
| App per la logica di Azure | Un set del flusso di lavoro dell'app per la logica correlato di tipo Consumo. Il flusso di lavoro attiva gli eventi del bus di servizio. Queste app per la logica elaborano l'aggregazione FHIR in entrata e la pubblicano negli endpoint configurati. A ogni app per la logica viene assegnato un nome utilizzando il valore univoco fornito durante la distribuzione: 1. laprocessfhirbundle_UniqueValue 2. lasendbundletodataverse_UniqueValue 3. lasendbundletofhir_UniqueValue |
| Connessione API | Sono necessarie varie connessioni API per le app per la logica. |
Output
A seconda dell'esito positivo o negativo dell'esecuzione, viene creato un BLOB con il nome originalblobname_response.json nella cartella bundlesarchive o bundleserror con il seguente schema:
{
"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.>"
}
A seconda dell'app per la logica che ha attivato l'errore, l'errore JSON contiene il nodo dataverseResponse o fhirServerResponse. Ad esempio, se si verifica un errore con l'app per la logica lasendbundletofhir_UniqueValue , la risposta JSON contiene solo il nodo fhirServerResponse e il valore.
Passaggi successivi alla distribuzione
La sezione seguente contiene i passaggi necessari da seguire dopo aver distribuito il modello.
Concedere l'accesso al server FHIR
L'accesso al server FHIR dall'app per la logica richiede l'assegnazione del ruolo Collaboratore dati FHIR, che consente di pubblicare nuovi dati nel servizio. Aggiungi questa assegnazione di ruolo Azure all'identità gestita utilizzata dall'app per la logica.
Vai all'istanza del server FHIR, seleziona Controllo di accesso (IAM), quindi seleziona Aggiungi assegnazione di ruolo.
Nella scheda Ruolo seleziona il ruolo Collaboratore dati FHIR .
Seleziona Membri, seleziona Identità gestita e quindi + Seleziona membri.
Aggiungi l'identità gestita creata con la distribuzione del modello ARM. L'identità gestita appena distribuita deve essere denominata mi_UniqueValue.
L'integrazione dell'assegnazione nell'identità gestita potrebbe richiedere alcuni minuti. Seleziona Assegnazioni di ruolo Azure per visualizzare l'assegnazione di ruolo nell'identità gestita.
Concedere l'accesso alle Dataverse Healthcare API
La stessa identità gestita viene usata nell'app per la logica per accedere alle Dataverse Healthcare API collegandola a un utente dell'applicazione nell'istanza Dataverse di destinazione. Per ulteriori informazioni sugli utenti dell'applicazione, vai a Gestire gli utenti dell'applicazione nell'interfaccia di amministrazione di Power Platform.
È necessario l'ID client di Azure per l'identità gestita per configurare l'utente dell'applicazione. Per recuperare l'ID client, apri l'identità gestita creata con la distribuzione del modello ARM e copia il valore ID client dall'area Panoramica.
Nell'interfaccia di amministrazione di Power Platform, apri l'ambiente Microsoft Cloud for Healthcare di destinazione. Nella sezione Accesso seleziona App S2S, quindi seleziona Nuovo utente dell'app.
Nel riquadro Crea un nuovo utente dell'app seleziona la Business unit appropriata, quindi seleziona Aggiungi un'app.
Nel riquadro Aggiungi un'app da Microsoft Entra ID, cerca l'ID client copiato dall'identità gestita.
Seleziona l'identità gestita dall'elenco, seleziona Aggiungi e quindi modifica i ruoli di sicurezza.
Seleziona il ruolo Utente registrazione app Amministrazione sincronizzazione per FHIR, quindi seleziona Salva.
Seleziona Crea per creare il nuovo utente dell'applicazione.
Dopo aver completato la configurazione, puoi testare il flusso di lavoro dell'app per la logica pubblicando un'aggregazione di esempio nel contenitore sa_UniqueValue per l'elaborazione. A seconda dei requisiti della soluzione, puoi anche modificare uno qualsiasi di queste app per la logica per un'ulteriore elaborazione.
Gestione degli errori
Se l'esecuzione di un'app per la logica genera un errore, viene creato un file con il nome originalblobname_response.json nel contenitore bundleserror nell'account di archiviazione. È possibile analizzare questo file per identificare la causa principale dell'errore, correggerlo e inviare nuovamente l'aggregazione con le risorse non riuscite.
Tipo di aggregazione: batch
Il server FHIR e le Dataverse Healthcare API elaborano un aggregazione di tipo batch come gruppo di azioni indipendenti. Di conseguenza, le risposte indicano l'esito positivo e negativo di ciascuna risorsa in modo indipendente.
In base alla specifica FHIR, qualsiasi risorsa che non riesce genera un OperationOutcome con il valore della gravità impostato su errore, mentre la Dataverse Healthcare API imposta msind_requeststatus su 935000002. Per ulteriori informazioni sui tipi di stato della richiesta, vai a Tipi di stato della richiesta.
Il flusso di lavoro dell'app per la logica analizza sia le risposte provenienti dal server FHIR sia le Dataverse Healthcare API. Termina il flusso come Non riuscito se c'è una risorsa che ha causato un errore.
Nota
Le Dataverse Healthcare API supportano attualmente solo le aggregazioni FHIR di tipo batch e batch-response.
Configurare i tentativi
Dopo aver identificato e corretto l'errore, puoi riposizionare l'aggregazione nel contenitore bundles per una nuova elaborazione.
Tentativo in base a limitazione: server FHIR
L'azione HTTP nel flusso di lavoro dell'app per la logica che esegue la pubblicazione nel server FHIR usa i criteri di ripetizione dell'azione HTTP incorporati. Il valore predefinito è un criterio di intervallo esponenziale impostato per riprovare quattro volte. È possibile modificare i criteri di ripetizione.
Seleziona i puntini di sospensione nell'angolo in alto a destra della scheda azione, quindi seleziona Impostazioni.
Sotto Criteri di ripetizione, cambia il valore del campo Tipo.
Tentativo in base a limitazione: Dataverse Healthcare API
I limiti API di protezione del servizio influenzano le Dataverse Healthcare API. Se una richiesta alle Dataverse Healthcare API viene limitata, per impostazione predefinita il flusso di lavoro dell'app per la logica effettua tre tentativi secondo l'intervallo Retry-After specificato dall'API nell'intestazione della risposta. Puoi modificare sia il numero di tentativi che l'intervallo.
Per modificare il numero di tentativi, modifica il valore Conteggio nell'azione Ciclo fino a.
Per modificare l'intervallo, modifica il valore Conteggio nell'azione Ritarda.
Proteggere le app per la logica
Dopo aver completato la configurazione e il test dell'app per la logica, puoi bloccare la traccia proteggendo le azioni di input e output. Per saperne di più, vedi Proteggere le app per la logica.