Dataverse Healthcare APIs: pipelinesjabloon voor gezondsheidsgegevens gebruiken om Azure Logic Apps te implementeren.
Dit artikel biedt een stapsgewijze handleiding voor het gebruik van een sjabloon om een groep Azure Logic Apps te implementeren waarmee FHIR-gegevens in Dataverse Healthcare APIs, Azure Health Data Services of beide worden opgenomen. Deze oplossing werkt als een bedrijfsklare Logic App-stroom die dient als een relais tussen Azure Health Data Services en Dataverse API's voor gezondheidszorg. De stroom beheert ook de logica voor opnieuw proberen en de afhandeling van uitzonderingen. Het vertrouwt op een Azure Blob Storage-trigger in plaats van de HTTP-trigger die wordt gebruikt in de handmatige configuratie.
Deze workflow is beschikbaar voor implementatie als een Azure Resource Manager (ARM)-sjabloon met de titel Pipelinesjabloon voor gezondsheidsgegevens. U kunt de sjabloon implementeren via het Microsoft Cloud-oplossingencentrum. Dit aanbod is een meer robuuste en ondersteunde oplossing verschaft door Microsoft Cloud for Healthcare. Nadat u de sjabloon hebt geïmplementeerd, moet u een aantal basisconfiguraties handmatig uitvoeren.
Notitie
De Logic App-stroom wordt verschaft als toegangspunt voor inkomende elektronische gezondheidsdossiergegevens (EPD), zodat FHIR-gegevens naar de juiste services worden gepost. Het is in de huidige staat nog geen definitieve oplossing en is bedoeld om te worden bijgewerkt op basis van uw zakelijke behoeften.
Deze services voor logische apps zijn niet verplicht om FHIR-gegevens te posten naar de eindpunten van Dataverse Healthcare API′s. U kunt ervoor kiezen uw eigen oplossing te bouwen om gegevens van uw EPD door te geven aan de API's en de reacties af te handelen.
De logische app-services zijn afhankelijk van een asynchrone Azure Blob Storage trigger-naar-trigger-verwerking van de bundels die naar een configureerbare opslaglocatie zijn gepost. Deze optie verwerkt zwaardere belastingen voor zakelijke toepassingen en omvat extra stappen voor uitzonderingsafhandeling. U moet echter grondig testen met uw verwachte dagelijkse belasting.
Na de implementatie kunt u Logic Apps uitbreiden om aan de specifieke behoeften van uw systeem te voldoen.
Belangrijk
Deze ARM-sjabloon is alleen compatibel met Releasewave 2 Microsoft Cloud for Healthcare voor 2022 en latere versies. Voor oudere versies verwijdert u de actie requestBody voor FHIR-respons instellen bij succes voordat een run wordt geactiveerd.
De configuratie omvat de volgende stappen:
- Vereisten
- Ontwerpen
- Stappen na implementatie
- Afhandeling van fouten
- Nieuwe pogingen instellen
- Logic Apps beveiligen
Vereisten
Zorg ervoor dat uw omgeving aan de volgende vereisten voldoet voordat u de sjabloon implementeert:
- Een Azure-account en -abonnement. Als u geen abonnement hebt, meld u dan aan voor een gratis Azure-account voordat u begint.
- Een Azure-resourcegroep geconfigureerd met de juiste machtigingen om nieuwe resources te maken, of een Inzenderrol om nieuwe resourcegroepen te maken.
- Toegang binnen de resourcegroep om resources te maken en Azure-rollen toe te wijzen.
- Naleving van de beveiligingsrichtlijnen die zijn beschreven door Azure-beheerders en het organisatiebeleid.
Ontwerpen
Het onderstaande diagram illustreert het ontwerp van de pijplijn die via de sjabloon wordt geïmplementeerd:
Met de ARM-sjabloon worden verschillende modulair ingedeelde Logic Apps geïmplementeerd. Het omvat de volgende drie logische app-services:
Logic App | Omschrijving |
---|---|
FHIR-bundel verwerken | Het eerste logische app-exemplaar dat wordt geactiveerd wanneer een bundel naar de blob-opslag wordt geüpload. Deze logische app bepaalt of de bundel naar FHIR of rechtstreeks naar Dataverse moet worden gepost. |
Bundel naar FHIR verzenden | De tweede logische app wordt geactiveerd vanuit de logische app FHIR-bundel verwerken , wanneer u ervoor kiest om de bundel naar FHIR te posten. Met deze logische app wordt de aanvraagbundel verwerkt en naar de FHIR-server gepost. Nadat deze logische app de bundel naar de FHIR-server heeft verzonden, wordt de bundel doorgestuurd naar de volgende logische app Bunch verzenden naar Dataverse voor verdere verwerking. |
Bundel verzenden naar Dataverse | De laatste logische app die wordt geactiveerd via de logische app FHIR-bundel verwerken of Bundel naar FHIR verzenden. Hiermee wordt de aanvraagbundel verwerkt en gepost naar Dataverse. Het verwerkt ook het opruimen van de bundelcontainer door de aanvraagbundel naar de bundleserror of de bundlesarchive -container te verplaatsen. |
Sjabloonparameters
Parameter | Omschrijving |
---|---|
Resourcelocatie | De Azure-regio voor het maken van resources. Deze parameterwaarde is standaard ingesteld op de regio die is gebruikt om de resourcegroep te maken. |
URL voor Dataverse | De URL van uw Microsoft Cloud for Healthcare Dataverse-omgeving. Bijvoorbeeld https://*orgname*.crm.dynamics.com |
Naar FHIR-server posten | Een booleaanse waarde. Als deze optie op waar is ingesteld, wordt de bundel naar de FHIR-server gepost. |
URL van FHIR-server | De URL van us FHIR-server. https://*fhirserver*.azurewebsites.net U hebt deze parameter bijvoorbeeld alleen nodig als u naar de FHIR-server wilt posten voordat u naar het Dataverse upsert API-eindpunt post. |
Unieke waarde | De unieke tekenreeks die wordt gebruikt om resourcenamen te genereren. Deze waarde is standaard ingesteld op de functie uniqueString. U kunt deze waarde indien nodig overschrijven. |
Geïmplementeerde resources
Met de sjabloon worden de volgende resources in uw omgeving geïmplementeerd:
Bron | Omschrijving |
---|---|
Beheerde identiteit | De naam van de beheerde identiteit heeft de indeling mi_UniqueValue. Deze beheerde identiteit wordt toegewezen aan de logische app en krijgt toegang tot het opslagaccount, de FHIR-server en de Dataverse-omgeving. |
Azure-storageaccount | De naam van het opslagaccount heeft de indeling sa_UniqueValue. Samen met het opslagaccount implementeert de sjabloon ook de volgende drie containers: bundles , bundlesarchive en bundleserror . |
Roltoewijzing | Wijst de rol Bijdrager van Storage Blob-gegevens voor het opslagaccount toe aan de beheerde identiteit. |
Azure Event Grid | De naam van Event Grid heeft de indeling eg_UniqueValue. Alle blob-gebeurtenissen worden gepost in dit Event Grid. |
Azure Service Bus | De naam van Service Bus heeft de indeling sb_UniqueValue. Het Event Grid plaatst evenementen op deze Service Bus. De naam van de wachtrij is bundleCreated . |
Autorisatieregel | Creëert een autorisatieregel Luisteren op de Service Bus met de naam bundleauthlisten . |
Azure Logic-apps | Een set gerelateerde logische app-werkstromen van het type Verbruik. De werkstroom wordt geactiveerd door de Service Bus-gebeurtenissen. Met deze logische apps wordt de inkomende FHIR-bundel verwerkt en naar de geconfigureerde eindpunten gepost. Elke logische app krijgt een naam met de unieke waarde die wordt opgegeven tijdens de implementatie: 1. laprocessfhirbundle_UniqueValue 2. lasendbundletodataverse_UniqueValue 3. lasendbundletofhir_UniqueValue |
API-verbinding | Er zijn verschillende API-verbindingen vereist voor de logische apps. |
Uitvoer
Op basis van het feit of de uitvoering goed of met een fout wordt beëindigd, wordt een blob met de naam orginalblobname_response.json gemaakt in de map bundlesarchive
of bundleserror
met het volgende 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.>"
}
Afhankelijk van welke logische app de fout heeft geactiveerd, bevat de JSON-fout het knooppunt dataverseResponse
of fhirServerResponse
. Als u bijvoorbeeld een fout tegenkomt met de logische app lasendbundletofhir_UniqueValue, bevat de JSON-respons alleen het fhirServerResponse
-knooppunt en de waarde.
Stappen na implementatie
In het volgende gedeelte staan de stappen die u moet uitvoeren volgen nadat u de sjabloon hebt geïmplementeerd.
Verleen toegang tot de FHIR-server.
Voor toegang tot de FHIR-server vanuit de logische app is het volgende vereist: roltoewijzing voor Inzender van FHIR-gegevens, waarmee nieuwe gegevens naar de service kunnen worden gepost. Voeg de roltoewijzing Azure toe aan de beheerde identiteit die door de logische app wordt gebruikt.
Ga naar de FHIR-serverinstantie, selecteer Toegangsbeheer (IAM) en selecteer vervolgens Roltoewijzing toevoegen.
Selecteer op het tabblad Rol de rol Inzender van FHIR-gegevens.
Selecteer Leden, selecteer Beheerde identiteit en selecteer vervolgens + Leden selecteren.
Voeg de beheerde identiteit toe die is gemaakt met de ARM-sjabloonimplementatie. De nieuw geïmplementeerde beheerde identiteit moet de naam mi_UniqueValue hebben.
Het kan enkele minuten duren voordat de toewijzing de beheerde identiteit weerspiegelt. Selecteer Azure-roltoewijzingen om de roltoewijzing voor de beheerde identiteit te bekijken.
Toegang verlenen tot Dataverse Healthcare APIs
Dezelfde beheerde identiteit wordt gebruikt in de logische app om toegang te krijgen tot de Dataverse Healthcare APIs door deze te verbinden met een gebruiker van de toepassings in het doelvoorbeeld in Dataverse. Ga voor meer informatie over toepassingsgebruikers naar Toepassingsgebruikers beheren in het Power Platform-beheercentrum.
U hebt de client-id voor Azure voor de beheerde identiteit nodig om de toepassingsgebruiker te configureren. Om de client-id op te halen, opent u de beheerde identiteit die is gemaakt met de ARM-sjabloonimplementatie en kopieert u de waarde van de Client-id uit het gedeelte Overzicht .
Open in het Power Platform-beheercentrum de Microsoft Cloud for Healthcare-doelomgeving. Selecteer in de sectie Toegang de optie S2S-apps en selecteer vervolgens Nieuwe app-gebruiker.
Selecteer in het deelvenster Een nieuwe app-gebruiker maken de juiste Business unit en selecteer vervolgens Een app toevoegen.
Zoek in het deelvenster Een app uit Microsoft Entra ID toevoegen naar de client-id die u van de beheerde identiteit hebt gekopieerd.
Selecteer de beheerde identiteit in de lijst, selecteer Toevoegen en bewerk vervolgens de beveiligingsrollen.
Selecteer de rol Reg User voor Synchronisatiebeheer voor FHIR-app en selecteer vervolgens Opslaan.
Selecteer Maken om de nieuwe toepassingsgebruiker te maken.
Nadat u de configuratie hebt voltooid, kunt u de werkstroom van de logische app testen door een voorbeeldbundel naar de sa_UniqueValue-container te posten voor verwerking. Afhankelijk van uw oplossingsvereisten kunt u ook een van deze logische apps aanpassen voor verdere verwerking.
Afhandeling van fouten
Als de uitvoering van een logische app tot een fout leidt, wordt een bestand met de naam originalblobname_response.json gemaakt in de container bundleserror
in het opslagaccount. U kunt door dit bestand parseren om de hoofdoorzaak van de fout te identificeren, deze op te lossen en de bundel opnieuw in te dienen met de mislukte bronnen.
Bundeltype: batch
De FHIR-server en de Dataverse Healthcare APIs verwerken een bundel van het type batch als een groep onafhankelijke acties. Als gevolg hiervan geven de antwoorden het succes en de fout van elke resource onafhankelijk aan.
Volgens de FHIR-specificatie resulteert elke resource die faalt in een OperationOutcome waarvan de urgentiewaarde is ingesteld op fout, terwijl de Dataverse Healthcare API de msind_requeststatus
instelt op 935000002. Ga voor meer informatie over de verschillende aanvraagstatustypes naar Typen aanvraagstatus.
De werkstroom van de logische app verwerkt zowel de reacties van de FHIR-server als de Dataverse API's voor gezondheidszorg. De stroom wordt beëindigd met de melding Mislukt als er een resource is die tot een fout heeft geleid.
Notitie
Dataverse Healthcare APIs ondersteunen momenteel alleen FHIR-bundels van het type batch en batch-respons.
Nieuwe pogingen instellen
Nadat u de fout hebt geïdentificeerd en verholpen, kunt u de bundel terugplaatsen in de container bundles
voor verwerking.
Opnieuw met vertraging: FHIR-server
De HTTP-actie in de logische app-werkstroom die naar de FHIR-server wordt gepost, maakt gebruik van het ingebouwde beleid voor opnieuw proberen van HTTP-acties. De standaardwaarde is een exponentieel intervalbeleid dat is ingesteld om vier keer opnieuw te proberen. U kunt het beleid voor opnieuw proberen bewerken.
Selecteer het beletselteken in de rechterbovenhoek van de actiekaart en selecteer vervolgens Instellingen.
Wijzig onder Beleid voor opnieuw proberen de waarde van het veld Type.
Opnieuw proberen met vertraging: Dataverse Healthcare APIs
De API-limieten voor servicebeveiliging beïnvloeden de Dataverse Healthcare APIs. Als een aanvraag bij Dataverse Healthcare APIs wordt vertraagd, probeert de werkstroom van de logische app (standaard) drie keer opnieuw met het interval Retry-After
dat is opgegeven door de API in de koptekst van de respons. U kunt zowel het aantal nieuwe pogingen als het interval bewerken.
Om het aantal nieuwe pogingen te wijzigen, bewerkt u de waarde Aantal in de actie Herhalen tot.
Om het interval te wijzigen, bewerkt u de waarde Aantal in de actie Vertraging.
Logic Apps beveiligen
Nadat u klaar bent met het instellen en testen van de logische app, kunt u de tracering vergrendelen door de invoer- en uitvoeracties te beveiligen. Ga voor meer informatie naar Logic Apps beveiligen.