Häufig gestellte Fragen zu Azure API for FHIR

Fast Healthcare Interoperability Resources (FHIR, ausgesprochen wie das englische Wort „Fire“) ist ein Interoperabilitätsstandard, der den Austausch von Patientendaten zwischen verschiedenen Gesundheitssystemen ermöglicht. Dieser Standard wurde von der HL7-Organisation entwickelt und wird von Gesundheitsorganisationen auf der ganzen Welt übernommen. Die aktuelle Version von FHIR ist R4 (Release 4). Azure API for FHIR unterstützt R4 und die vorherige Version STU3 (Standard for Trial Use 3). Weitere Informationen zu FHIR finden Sie auf HL7.org.

Ja. Die Daten werden in verwalteten Datenbanken in Azure gespeichert. Die Azure-API für FHIR bietet keinen direkten Zugriff auf den zugrunde liegenden Datenspeicher.

Im verwalteten Dienst können Sie nicht auf die zugrunde liegenden Daten zugreifen. Dies dient der Sicherstellung, dass Azure API for FHIR den Datenschutz und die Compliancezertifizierungen bietet, die für Daten im Gesundheitswesen erforderlich sind. Wenn Sie Zugriff auf die zugrunde liegenden Daten benötigen, können Sie den Open-Source-FHIR-Server verwenden.

Wir unterstützen Microsoft Azure Active Directory als Identitätsanbieter.

Nein, wir unterstützen kein B2C in Azure API for FHIR. Wenn Sie genauer abgestimmte Zugriffssteuerung benötigen, empfehlen wir, den Open-Source-FHIR-Proxy zu erwägen.

Daten für den verwalteten Dienst werden alle 4 Stunden automatisch gesichert, wobei zwei Sicherungen aufbewahrt werden. Die Aufbewahrungsdauer beträgt also 8 Stunden. Die Datenwiederherstellung erfolgt durch das Supportteam, und das Wiederherstellungspunktziel (Recovery Point Objective, RPO) beträgt weniger als 240 Minuten.

Kunden können über ein Supportticket eine Anforderung zum Wiederherstellen der Daten stellen oder die Standard-Datensicherungsrichtlinie ändern.

Wir unterstützen die Versionen 4.0.0 und 3.0.1. Weitere Informationen finden Sie unter Unterstützte FHIR-Features. Informationen zu den Änderungen zwischen FHIR-Versionen (zwischen STU3 und R4) finden Sie auch im Versionsverlauf für HL7 FHIR.

Von Azure IoT Connector for FHIR (Vorschau) wird aktuell nur die FHIR-Version R4 unterstützt, und der Connector ist in R4-Instanzen von Azure API for FHIR sichtbar.

Azure API for FHIR ist ein allgemein verfügbarer, verwalteter FHIR-Dienst. Mit Azure Health Data Services können Sie einen FHIR-Dienst und einen DICOM-Dienst im selben Arbeitsbereich bereitstellen. Weitere Details finden Sie in der Übersicht von Azure Health Data Services.

Azure API for FHIR ist eine gehostete und verwaltete Version des Open-Source-FHIR-Servers von Microsoft für Azure. Im verwalteten Dienst stellt Microsoft die gesamte Wartung und alle Updates zur Verfügung.

Bei Verwendung des FHIR-Servers für Azure haben Sie direkten Zugriff auf die zugrunde liegenden Dienste, aber wir sind für die Wartung und Aktualisierung des Servers sowie für alle erforderlichen Complianceaufgaben zuständig, wenn Sie PHI-Daten speichern.

Allgemeine Verfügbarkeit besteht sowohl für den öffentlichen als auch den behördlichen Bereich in mehreren geografischen Regionen. Weitere Informationen zu Government Cloud Services bei Microsoft finden Sie unter Azure-Dienste nach FedRAMP.

Auf der Seite Versionshinweise finden Sie eine Übersicht über alles, was im vorherigen Monat an den verwalteten Dienst geliefert wurde.

Weitere Informationen dazu, was in Azure API for FHIR veröffentlicht wird, finden Sie in den Releases des Open-Source-FHIR-Servers. Wir haben daran gearbeitet, Elemente mit Azure-API-for-FHIR zu markieren, wenn sie für den verwalteten Dienst freigegeben werden und in der Regel zwei Wochen nach ihrer Verwendung auf der Releaseseite in Open Source verfügbar sind. Wir haben außerdem Anweisungen zum Testen des Builds eingeschlossen, wenn Sie Tests in Ihrer eigenen Umgebung durchführen möchten.

Um festzustellen, welches Releasepaket derzeit im verwalteten Dienst enthalten ist, können Sie die Funktionsbestätigung für Azure API for FHIR unter der software.version-Eigenschaft anzeigen. Es wird angezeigt, welches Paket bereitgestellt ist.

Die genaue FHIR-Version finden Sie in der Funktionsbestätigung unter der Eigenschaft fhirVersion.

Nein. Wir haben keine Möglichkeit, die Version einer vorhandenen Datenbank zu ändern. Sie müssen eine neue Azure API for FHIR-Datenbank erstellen und die Daten neu laden. Sie können den JSON-zu-FHIR-Konverter als Ausgangspunkt nutzen, um mit der Konvertierung von STU3-Daten in R4 zu beginnen.

Nein. Sie können die URL für die Azure-API für FHIR nicht ändern.

Bei SMART (Substitutable Medical Applications and Reusable Technology) on FHIR handelt es sich um eine Reihe offener Spezifikationen für die Integration von Partneranwendungen in FHIR-Server und andere IT-Systeme im Gesundheitswesen, wie elektronische Patientenakten und den Austausch von Gesundheitsinformationen. Indem Sie eine SMART on FHIR-Anwendung erstellen, können Sie sicherstellen, dass auf Ihre Anwendung zugegriffen und diese von einer Vielzahl unterschiedlicher Systeme genutzt werden kann. Weitere Informationen zu SMART finden Sie auf der SMART Health IT-Website.

Ja, die SMART on FHIR-Funktion wird mithilfe von AHDS-Beispielen unterstützt. Dies wird als SMART on FHIR(Enhanced) bezeichnet. SMART on FHIR(Enhanced) kann als erfüllt betrachtet werden, um die Anforderungen des SMART on FHIR-Implementierungsleitfadens (v 1.0.0) und des Kriteriums §170.315(g)(10) standardisierter API für Patienten- und Bevölkerungsdienste zu erfüllen. Weitere Informationen finden Sie in der Dokumentation zu SMART on FHIR(Enhanced).

Benutzerdefinierte FHIR-Ressourcen sind nicht zulässig. Wenn Sie eine benutzerdefinierte FHIR-Ressource benötigen, können Sie eine benutzerdefinierte Ressource auf Grundlage der Basisressource mit Erweiterungen erstellen.

Wir erlauben Ihnen, alle gültigen FHIR-JSON-Daten in den Server zu laden. Wenn Sie die Strukturdefinition, die die Erweiterung definiert, speichern möchten, können Sie diese als Strukturdefinitionsressource speichern. Um nach Erweiterungen zu suchen, müssen Sie Ihre eigenen Suchparameter definieren.

Die Größe Ihrer Ressource muss knapp unter 2 MB liegen. Dies ist eine Begrenzung durch den zugrunde liegenden Datenspeicher, und wir können diesen Wert nicht erhöhen.

Im verwalteten Dienst unterstützen wir nur JSON. Der Open-Source-FHIR-Server unterstützt JSON und XML. Verwenden Sie _format= application/fhir+xml, um die XML-Version in Open Source anzuzeigen.

Der aktuelle Grenzwert für „_count“ liegt bei 1000. Wenn Sie „_count“ auf mehr als 1000 festlegen, erhalten Sie im Bündel eine Warnung, dass nur 1000 Datensätze angezeigt werden.

Für „Gruppenexport“ exportieren wir nur die eingeschlossenen Verweise aus der Gruppe, nicht alle Merkmale der Gruppenressource.

Zurzeit unterstützen wir das Bereitstellen von Batchbündeln, aber wir unterstützen nicht das Bereitstellen von Transaktionsbündeln in Azure API for FHIR. Sie können den FHIR-Dienst in Azure Health Data Services verwenden, wenn Sie Unterstützung für Transaktionsbündel benötigen.

Sie können den „Patient-$everything“-Vorgang verwenden oder eine Depotsuche in Azure API for FHIR. Auf diese Weise können Sie alle Ressourcen, die auf einen bestimmten Patienten bezogen sind, abrufen. Beachten Sie, dass das Patientendepot zurzeit alle Ressourcen enthält, die sich auf den Patienten beziehen, aber nicht den Patienten selbst, sodass Sie auch nach dem Patienten suchen müssen, wenn Sie die Patientenressource in Ihren Ergebnissen benötigen.

Als Sortierkriterium wird das Datum der letzten Aktualisierung unterstützt: _sort=_lastUpdated. Wir unterstützen außerdem „_sort“ für FirstName-, LastName-, BirthDate- und ClinicalDate-Elemente. Weitere Informationen zu anderen unterstützten Suchparametern finden Sie in der Übersicht zur FHIR-Suche.

Ja, wir bieten Unterstützung für „patient-$everything“. Weitere Informationen finden Sie in der Schrittanleitung zu „Patient-$everything“.

Nein, Azure API for FHIR unterstützt zurzeit keine Terminologievorgänge.

„$export“ ist Teil der FHIR-Spezifikation. Wenn der FHIR-Dienst mit einer verwalteten Identität und einem Speicherkonto konfiguriert ist und die verwaltete Identität Zugriff auf dieses Speicherkonto hat, können Sie „$export“ über die FHIR-API aufrufen. Daraufhin werden alle FHIR-Ressourcen in das Speicherkonto exportiert. Weitere Informationen finden Sie im Artikel zu $export.

Wir verfügen über ein Open-Source-Tool, um FHIR-Daten zu anonymisieren. Dieselbe Technologie ist auch in Azure API for FHIR in Form von des anonymisierten Exports integriert.

Der anonymisierte Export wird derzeit nur bei einem vollständigen Systemexport (/$export) und nicht für den Patientenexport (/Patient/$export) unterstützt. Wir arbeiten daran, diesen Export auch auf Patientenebene verfügbar zu machen.

Es gibt zwei grundlegende Löschtypen, die in Azure API for FHIR unterstützt werden. Diese sind „Löschen“ und „Bedingtes Löschen“.

• Mit „Löschen“ können Sie auswählen, ob vorläufiges Löschen (der gängigste Typ) ausgeführt wird, wobei Sie noch historische Versionen Ihres Datensatzes wiederherstellen können.
• Beim „Bedingten Löschen“ können Sie ein Suchkriterium übergeben, um eine Ressource elementweise oder auch mehrere gleichzeitig zu löschen.
• Sowohl beim Löschen als auch beim bedingten Löschen werden, wenn Sie den Parameter hardDelete übergeben haben, alle Datensätze und der Verlauf gelöscht und können nicht mehr wiederhergestellt werden.

Sie können gelöschte Dateien wiederherstellen, wenn Sie nicht den Parameter hardDelete verwenden. Die Datensätze in Azure API for FHIR sollten noch vorhanden sein. Sie können die Datensätze finden, indem Sie eine Verlaufssuche in der Ressource ausführen und nach der letzten Version mit Daten suchen.

Ausführliche Informationen zum Aktivieren von Überwachungsprotokollen sowie Beispielabfragen finden Sie unter Aktivieren der Diagnoseprotokollierung in Azure API for FHIR. Wenn Sie zusätzliche Informationen in die Protokolle aufnehmen möchten, lesen Sie Verwenden benutzerdefinierter HTTP-Header.

Um dies zu beheben, können Sie den Durchsatz erhöhen oder auf automatische Skalierung umstellen, um sicherzustellen, dass Sie über genügend Computeressourcen zur Verarbeitung der Anforderungen verfügen. Wenn Sie weiterhin Probleme haben, öffnen Sie ein Supportticket.

Der RU-Mindestwert muss mindestens 40 RU pro GB betragen. Während Sie Daten laden, erhöhen sich die RUs in der Datenbank, wenn Sie unter diesem Mindestwert liegen.

Auf der GitHub-Seite zur Gesundheitsarchitektur (Health Architecture) finden Sie eine Sammlung von Referenzarchitekturen.

Um die Integritätsprüfung für den FHIR-Dienst durchzuführen, geben Sie {{fhirurl}}/health/check in der GET-Anforderung ein. Der Status des FHIR-Diensts sollte angezeigt werden. Die HTTP-Statuscodeantwort mit 200 und OverallStatus als Antwort "Healthy" bedeutet, dass Ihre Integritätsprüfung erfolgreich ist. Bei Fehlern erhalten Sie eine Fehlerantwort mit HTTP-status Code 404 (Nicht gefunden) oder status Code 500 (interner Serverfehler) sowie ausführliche Informationen im Antworttext in einigen Szenarien.

Ja. Azure API for FHIR ermöglicht das Konfigurieren kundenseitig verwalteter Schlüssel (unterstützt durch Azure Cosmos DB). Weitere Informationen zum Verschlüsseln Ihrer Daten mit einem persönlichen Schlüssel finden Sie unter Konfigurieren kundenseitig verwalteter Schlüssel im RUHEZUSTAND.