Vanliga frågor och svar om Azure API för FHIR

FHIR (Fast Healthcare Interoperability Resources, uttalas ”fire”) är en samverkansstandard för att utbyta hälso- och sjukvårdsdata mellan olika hälso- och sjukvårdssystem. Denna standard utvecklades av HL7-organisationen och antas av vårdorganisationer runt om i världen. Den senaste versionen av FHIR är R4 (version 4). Azure API för FHIR stöder R4 och den tidigare versionen STU3 (Standard for Trial Use 3). Mer information om FHIR finns i HL7.org.

Ja, data lagras i hanterade databaser i Azure. Azure API för FHIR ger inte direkt åtkomst till det underliggande datalagret.

I den hanterade tjänsten kan du inte komma åt underliggande data. Detta för att säkerställa att Azure API för FHIR erbjuder de sekretess- och efterlevnadscertifieringar som behövs för hälso- och sjukvårdsdata. Om du behöver åtkomst till underliggande data kan du använda FHIR-servern med öppen källkod.

Vi stöder Microsoft Azure Active Directory som identitetsprovider.

Nej, vi stöder inte B2C i Azure API för FHIR. Om du behöver mer detaljerade åtkomstkontroller rekommenderar vi att du tittar på FHIR-proxyn med öppen källkod.

Data för den hanterade tjänsten säkerhetskopieras automatiskt var fjärde timme och två säkerhetskopior underhålls. Kvarhållningstiden är alltså 8 timmar. Dataåterställning görs av supportteamet och mål för återställningspunkt (RPO) är mindre än 240 minuter.

Kunder kan göra en begäran om att återställa data eller ändra standardprincipen för säkerhetskopiering av data via en supportbegäran.

Vi stöder versionerna 4.0.0 och 3.0.1. Mer information finns i FHIR-funktioner som stöds. Du kan också läsa om vad som har ändrats mellan FHIR-versioner (STU3 till R4) i versionshistoriken för HL7 FHIR.

Azure IoT Connector för FHIR (förhandsversion) stöder för närvarande endast FHIR-version R4 och visas på R4-instanser av Azure API för FHIR.

Azure API för FHIR är en allmänt tillgänglig hanterad FHIR-tjänst. Med Azure Health Data Services kan du distribuera en FHIR-tjänst och en DICOM-tjänst på samma arbetsyta. Översikten över Azure Health Data Services innehåller mer information.

Azure API för FHIR är en värdbaserad och hanterad version av Microsoft FHIR Server med öppen källkod för Azure. I den hanterade tjänsten tillhandahåller Microsoft allt underhåll och alla uppdateringar.

När du kör FHIR-servern för Azure har du direkt åtkomst till de underliggande tjänsterna, men vi ansvarar för att underhålla och uppdatera servern och allt nödvändigt efterlevnadsarbete om du lagrar PHI-data.

Vi har allmän tillgänglighet för både offentliga myndigheter och myndigheter i flera geo-regioner. Information om myndighetsmolntjänster på Microsoft finns i Azure-tjänster från FedRAMP.

På sidan viktig information får du en översikt över allt som har levererats till den hanterade tjänsten under föregående månad.

Mer information om vad som släpps i Azure API för FHIR finns i versioner av FHIR-servern med öppen källkod. Vi har arbetat med att tagga objekt med Azure-API-for-FHIR om de släpps till den hanterade tjänsten och vanligtvis är tillgängliga två veckor efter att de finns på versionssidan med öppen källkod. Vi har också tagit med instruktioner om hur du testar versionen om du vill testa i din egen miljö.

Om du vill se vilket versionspaket som för närvarande finns i den hanterade tjänsten kan du visa funktionsuttryck för Azure API för FHIR under software.version egenskapen . Du ser vilket paket som distribueras.

Du hittar den exakta FHIR-versionen som exponeras i funktionsutdraget fhirVersion under egenskapen .

Nej. Vi kan inte ändra versionen av en befintlig databas. Du måste skapa ett nytt Azure API för FHIR och läsa in data igen. Du kan använda JSON till FHIR-konverteraren som en plats att börja med att konvertera STU3-data till R4.

Nej. Du kan inte ändra URL:en för Azure API för FHIR.

SMART (Substitutable Medical Applications and Reusable Technology) på FHIR är en uppsättning öppna specifikationer för att integrera partnerprogram med FHIR-servrar och andra hälso-IT-system, till exempel elektroniska hälsojournaler och utbyte av hälsoinformation. Genom att skapa ett SMART på FHIR-program kan du se till att ditt program kan nås och utnyttjas av en mängd olika system. Mer information om SMART finns på IT-webbplatsen för SMART Health .

Ja, smart på FHIR-funktionen stöds med hjälp av AHDS-exempel. Detta kallas SMART på FHIR(Enhanced). SMART on FHIR(Enhanced) kan anses uppfylla kraven med SMART on FHIR Implementation Guide (v 1.0.0) och §170.315(g)(10) Standardized API for patient and population services criterion. Mer information finns i DOKUMENTATIONen om SMART på FHIR(Enhanced).

Vi tillåter inte anpassade FHIR-resurser. Om du behöver en anpassad FHIR-resurs kan du skapa en anpassad resurs ovanpå Basic-resursen med tillägg.

Vi låter dig läsa in alla giltiga FHIR JSON-data till servern. Om du vill lagra strukturdefinitionen som definierar tillägget kan du spara det som en strukturdefinitionsresurs. Om du vill söka efter tillägg måste du definiera dina egna sökparametrar.

Resursen måste vara strax under 2 MB. Det här är en begränsning från det underliggande dataarkivet och vi kan inte öka det här värdet.

I den hanterade tjänsten stöder vi bara JSON. FHIR-servern med öppen källkod stöder JSON och XML. Om du vill visa XML-versionen med öppen källkod använder du _format= application/fhir+xml.

Den aktuella gränsen för _count är 1 000. Om du anger _count till mer än 1 000 får du en varning i paketet om att endast 1 000 poster visas.

För Gruppexport exporterar vi endast de inkluderade referenserna från gruppen och inte alla egenskaper för gruppresursen.

Vi stöder för närvarande publicering av batchpaket, men vi stöder inte publicering av transaktionspaket i Azure API för FHIR. Du kan använda FHIR-tjänsten i Azure Health Data Services om du behöver stöd för transaktionspaket.

Du kan använda åtgärden Patient-$everything eller använda en facksökning i Azure API för FHIR. På så sätt kan du hämta alla resurser som är relaterade till en specifik patient. Observera att patientutrymmet innehåller alla resurser som är relaterade till patienten men inte själva patienten, så du måste också söka för att få patienten om du behöver patientresursen i dina resultat.

Vi stöder sortering efter det datum som senast uppdaterades: _sort=_lastUpdated. Vi stöder också _sort för elementen FirstName, LastName, BirthDate och ClinicalDate. Mer information om andra sökparametrar som stöds finns i Översikt över FHIR-sökning.

Ja, vi har stöd för patient-$everything. Mer information finns i instruktioner för Patient-$Everything.

Nej, Azure API för FHIR stöder inte terminologiåtgärder i dag.

$export ingår i FHIR-specifikationen. Om FHIR-tjänsten har konfigurerats med en hanterad identitet och ett lagringskonto, och om den hanterade identiteten har åtkomst till det lagringskontot, kan du anropa $export på FHIR-API:et så exporteras alla FHIR-resurser till lagringskontot. Mer information finns i artikeln $export.

Vi har ett verktyg med öppen källkod för att av-identifiera FHIR-data. Samma teknik är också integrerad i Azure API för FHIR i form av avidentifierad export.

Anonymiserad export stöds för närvarande endast vid fullständig systemexport (/$export) och inte för patientexport (/patient/$export). Vi arbetar på att göra det tillgängligt på patientnivå också.

Det finns två grundläggande borttagningstyper som stöds i Azure API för FHIR. Dessa är Ta bort och Villkorlig borttagning.

• Med Ta bort kan du välja att göra en mjuk borttagning (den vanligaste typen) och fortfarande kunna återställa historiska versioner av din post.
• Med villkorsstyrd borttagning kan du skicka ett sökvillkor för att ta bort en resurs ett objekt i taget eller flera åt gången.
• Om du har skickat parametern hardDelete med antingen Ta bort eller Villkorsstyrd borttagning tas alla poster och historiken bort och kan inte återställas.

Du kan återställa borttagna filer om du inte använder parametern hardDelete . Posterna i Azure API för FHIR bör fortfarande finnas. Posterna kan hittas genom att göra en historiksökning på resursen och genom att söka efter den senaste versionen med data.

Mer information om hur du aktiverar granskningsloggar och exempelfrågor finns i Aktivera diagnostikloggning i Azure API för FHIR. Om du vill inkludera ytterligare information i loggarna kan du läsa använda anpassade HTTP-huvuden.

För att lösa detta kan du öka dataflödet eller växla över till autoskalning för att säkerställa att du har tillräckligt med beräkning för att bearbeta begärandena. Om du fortfarande har problem kan du öppna ett supportärende.

Det minsta RU-värdet måste vara minst 40 RU per GB. När du läser in data ökar RU:erna i databasen om du är under det här minimivärdet.

Vi har en samling referensarkitekturer på GitHub-sidan Hälsoarkitektur.

Om du vill utföra hälsokontroll på FHIR-tjänsten anger du {{fhirurl}}/health/check i GET-begäran. Du bör kunna se status för FHIR-tjänsten. HTTP-statuskodsvar med 200 och OverallStatus som "Felfri" som svar innebär att hälsokontrollen lyckas. Om det uppstår fel får du ett felmeddelande med HTTP-statuskod 404 (hittades inte) eller statuskod 500 (internt serverfel) och detaljerad information i svarstexten i vissa scenarier.

Ja, Med Azure API för FHIR kan du konfigurera kundhanterade nycklar med hjälp av stöd från Azure Cosmos DB. Mer information om hur du krypterar dina data med en personlig nyckel finns i Konfigurera kundhanterade nycklar i REST.