FHIR-Importoptionen

Auf dieser Seite werden Optionen zum Speichern großer Batches von FHIR-Daten in der Cloud Healthcare API beschrieben.

Tipp: Wenn Sie Daten von einem externen FHIR-Bulk-Server importieren, sollten Sie die Bulk-FHIR-Tools für Open-Source-Ressourcen von Google verwenden, um Daten direkt in die Cloud Healthcare API zu laden.

FHIR-Ressourcen importieren

Verwenden Sie die Methode fhirStores.import, um FHIR-Ressourcen aus Cloud Storage in die Cloud Healthcare API zu laden. Die Methode funktioniert am besten, wenn Daten in einen leeren FHIR-Speicher ohne Störungen durch andere Anwendungen geladen werden.

Informationen zum Aufrufen von fhirStores.import finden Sie unter FHIR-Ressourcen mit Cloud Storage importieren und exportieren.

Berücksichtigen Sie bei der Entscheidung, ob Sie sie verwenden möchten, die folgenden Attribute der Methode fhirStores.import. Wenn fhirStores.import für Ihre Anwendung nicht geeignet ist, können Sie Daten mit der fhir.executeBundle-Methode laden. Informationen zum Aufrufen von fhir.executeBundle finden Sie unter FHIR-Ressourcen mit FHIR-Bundles verwalten.

• Die Methode fhirStores.import akzeptiert Bundles, die größer als das Limit von 50 MB für fhir.executeBundle sind. Allerdings ist die Größe jeder einzelnen Ressource innerhalb des Bundles auf 10 MB begrenzt.

• Mit fhirStores.import entfällt die Komplexität der Ausführung großer FHIR-Bundles wie die folgenden:

  • FHIR-Bundles in kleinere Bundles aufteilen
  • Mehrere Zeitpläne für Sets verwalten
  • Vorübergehende Fehler verwalten, die auf Ressourcen- oder Bundle-Ebene wiederholt werden können

  Häufig überwiegen diese Vorteile die Vorteile von Sets.

• Jede Ressource in der Eingabe muss eine vom Kunden bereitgestellte ID enthalten. Ressourcen werden unabhängig von der enableUpdateCreate-Einstellung des FHIR-Speichers gespeichert.

• Der Importprozess erzwingt keine referenzielle Integrität, egal, was in der disableReferentialIntegrity-Einstellung des FHIR-Speichers angegeben ist. Wird die referenzielle Integrität nicht erzwungen, können Sie Ressourcen mit beliebigen Abhängigkeiten importieren, ohne die Gruppierung oder Sortierung zu berücksichtigen. Falls die Eingabedaten ungültige Referenzen enthalten oder einige Ressourcen nicht importiert werden, kann der Status des FHIR-Speichers die referenzielle Integrität verletzen.

• Ist eine Ressource mit einer bestimmten ID bereits im Speicher vorhanden, so wird die neueste Version der Ressource überschrieben, ohne dass eine neue Verlaufsversion erstellt wird. Das Überschreiben erfolgt unabhängig von der disableResourceVersioning-Einstellung des FHIR-Speichers. Wenn beim Import vorübergehende Fehler auftreten, können erfolgreich importierte Ressourcen mehrmals überschrieben werden.

• Der Importvorgang ist idempotent, es sei denn, die Eingabedaten enthalten mehrere gültige Ressourcen mit derselben ID, aber unterschiedlichen Inhalten. In diesem Fall enthält der Speicher nach Abschluss des Imports genau eine Ressource mit jeder ID, die doppelten Einträge können jedoch eine beliebige Version des Inhalts enthalten. Beispiel: Wenn Sie eine Million Ressourcen mit derselben ID importieren, wird nur eine Ressource in den Speicher geschrieben.

• Die Vorgangsergebniszähler zählen gedoppelte IDs nicht als Fehler. Jede Ressource in der Eingabe zählt als Erfolg. Dies kann zu einer Erfolgsrate führen, die über der Anzahl der Ressourcen im FHIR-Speicher liegt. Dies tritt häufig auf, wenn Daten importiert werden, die in von Patient-everything erstellten Bundles organisiert sind und jedes Bundle eine eigene Kopie einer Ressource wie Practitioner enthält, auf die möglicherweise von vielen Patientenressourcen verwiesen wird.

• Wenn Ressourcen nicht erfolgreich importiert werden, z. B. aufgrund von Parsing-Fehlern, werden importierte Ressourcen nicht zurückgesetzt. Wenn beispielsweise 5 von 100 Ressourcen fehlschlagen, werden die verbleibenden 95 Ressourcen in den FHIR-Speicher importiert.

• Bei Verwendung des Formats BUNDLE lehnt die Importmethode Bundles mit Bundle.type von history ab. Die Importmethode wendet die Semantik für die Bundle-Verarbeitung auf Batch- oder Transaktions-Bundles nicht an. Im Gegensatz zu fhir.executeBundle werden Transaktions-Bundles nicht als einzelne Transaktion ausgeführt. Weiter werden clusterinterne Referenzen nicht neu geschrieben. Das Bundle wird als eine Sammlung von Ressourcen behandelt, die wie in Bundle.entry.resource festgelegt bereitgestellt werden sollen, wobei Bundle.entry.request ignoriert wird. Dies ermöglicht beispielsweise das Importieren von Searchset-Bundles, die von einem FHIR-Such- oder Patient-everything-Vorgang erstellt wurden.

FHIR-Bundles verwenden

Eine Übersicht über FHIR-Bundles finden Sie unter FHIR-Bundles.

Wann sollten FHIR-Bundles verwendet werden?

Beachten Sie die folgenden Eigenschaften und Vorteile der Verwendung der Methode fhir.executeBundle, wenn Sie entscheiden, ob Sie sie zum Speichern von FHIR-Ressourcen verwenden möchten:

• Wenn es zu teuer ist, entweder in Bezug auf die Abrechnungskosten oder die Netzwerkbandbreite, eine Pipeline zu erstellen, die Daten in Cloud Storage speichert und die Daten dann mit fhirStores.import importiert, verwenden Sie fhir.executeBundle.
• Beim Ausführen von Bundles kann die Transaktionsintegrität erzwungen werden.
• Beim Ausführen von Bundles kann die FHIR-Profilvalidierung erzwungen werden.
• Wenn Sie Pub/Sub-Benachrichtigungen senden müssen, wenn FHIR-Erstellungs-, Aktualisierungs- oder Löschvorgänge ausgeführt werden, verwenden Sie fhir.executeBundle. Pub/Sub-Benachrichtigungen werden nicht gesendet, wenn FHIR-Ressourcen mit fhirStores.import importiert werden.
• Wenn die Zeit, zu der eine bestimmte FHIR-Ressource verarbeitet werden muss, in Sekunden oder Minuten liegt, verwenden Sie fhir.executeBundle. Wenn eine bestimmte FHIR-Ressource in Stunden oder Tagen verarbeitet werden muss, verwenden Sie fhirStores.import.
• Wenn in Ihrem Google Cloud-Projekt viele Vorgänge mit langer Ausführungszeit (Long-Running Operations, LRO) für andere Aufgaben vorhanden sind, wird mit fhir.executeBundle im Vergleich zu fhirStores.import möglicherweise eine bessere Leistung erzielt.

• Wenn die Anwendung, die den fhirStores.import-Vorgang verwaltet, keine gute Strategie für Folgendes hat, verwende fhir.executeBundle:

  • Bulk-Fehler verarbeiten
  • Fehler für eine Teilmenge von FHIR-Ressourcen oder ganze Batches beheben

Wann keine FHIR-Bundles verwendet werden sollten

Beachten Sie die folgenden Einschränkungen von fhir.executeBundle, wenn Sie ermitteln, ob Sie damit FHIR-Ressourcen speichern möchten:

• Bei Bundles gelten das entsprechende Kontingent und die entsprechende Abrechnung für die Vorgänge innerhalb des Bundles, als ob die Vorgänge außerhalb des Bundles ausgeführt würden. Wenn ein Bundle beispielsweise 10 POST-Vorgänge, 5 GET-Vorgänge und 1 DELETE-Vorgang enthält, gelten das Kontingent und die Abrechnung für das Bundle genauso, als ob diese Vorgänge unabhängig ausgeführt würden.

  Das Ziel, die Kontingentlimits und die FHIR-Betriebskosten zu senken, sind daher keine Gründe für die Verwendung von Bundles anstelle von fhirStores.import.

• Bei großen Transaktions-Bundles ist die Wahrscheinlichkeit höher, dass es Transaktionskonflikte gibt, was zu Datenkonflikten und fehlgeschlagenen Vorgängen führt. Informationen dazu, wie diese Probleme auftreten können und wie Sie sie beheben können, finden Sie unter 429 Resource Exhausted operation_too_costly-Fehler verhindern.

• Mit Batch-Bundles können Sie einen hohen Datendurchsatz erreichen und aufrechterhalten und so Datenkonflikte vermeiden. Batch-Bundles haben jedoch keine Funktionen für transaktionale Konsistenz, wie z. B. referentielle Integrität.

• Wenn ein Bundle sehr groß ist, kann der Datendurchsatz geringer sein, selbst wenn es sich um ein Batch-Bundle handelt. Weitere Informationen finden Sie unter Große Transaktionssets vermeiden.