Kontingente und Limits

Die Cloud Healthcare API legt aus verschiedenen Gründen Grenzen für die Ressourcennutzung fest. Unter anderem schützen solche Kontingente die Nutzer der Google Cloud-Community vor unerwarteten Auslastungsspitzen. Außerdem bietet Google Cloud Kontingente für kostenlose Testversionen die Google Cloud-Nutzern eingeschränkten Zugriff bieten, einschließlich der Cloud Healthcare API.

Kontingente für die Cloud Healthcare API werden pro Projekt entweder pro Region oder über mehrere Regionen hinweg erzwungen. Die Erschöpfung des Kontingents in einer einzelnen Region hat keine Auswirkungen auf Ihre Nutzung der Cloud Healthcare API in anderen Regionen.

Kontingente und Nutzung überprüfen

Kontingente sind Limits für Speicher (auch Limits für eingehenden Traffic genannt) und Vorgänge.

Das verfügbare Kontingent für Ressourcen in Ihrem Projekt können Sie auf der Seite Kontingente in der Google Cloud Console ermitteln.

Wenn Sie nur die Kontingente der Cloud Healthcare API aufrufen möchten, wählen Sie in der Drop-down-Liste Tabelle filtern die Option Dienst und danach Cloud Healthcare API aus.

Es gelten nicht für alle Projekte dieselben Kontingente. Wenn Sie die Cloud Healthcare API mit der Zeit stärker nutzen, können sich Ihre Kontingente entsprechend erhöhen. Wenn Sie eine die Nutzung stark ansteigen wird, können Sie Kontingentanpassungen anfordern von der Seite Kontingente in Google Cloud Console Es fallen keine Gebühren für die Anforderung eines höheren Kontingents an. Ihre Kosten erhöhen sich nur, wenn Sie mehr Ressourcen verwenden.

Ressourcenlimits

Die Cloud Healthcare API begrenzt die Größe des Inhalts einer Anfrage, beispielsweise die Größe eines Röntgenbildes in einer DICOM-Anfrage. Sie können keine Änderung eines Ressourcenlimits anfordern; unter Umständen können Sie jedoch Inhalte, deren Größe das Ressourcenlimit überschreitet, mithilfe eines Importvorgangs importieren.

Die folgenden Ressourcenlimits gelten (Änderungen vorbehalten):

Modalität Maximale Anfragengröße
DICOM
  • Speichertransaktion: Unbeschränkt, alle anderen Methoden 10 MB
  • Speichertransaktion oder Abruftransaktion: Zeitüberschreitung bei Vorgängen über einer Stunde.
  • Suchtransaktionsmethoden haben einen Offset von maximal 1.000.000 sowie ein maximales Limit von 5.000 für Studien/Serien und 50.000 für Instanzen.
  • De-Identifikation: Die De-Identifikation kann keine DICOM-Dateien verarbeiten, die größer als 1 GB sind, wenn das Pixel entfernt wird.
  • Für aufgenommene DICOM-Dateien gilt ein Limit von 2 GB pro Tag. Das Limit schließt in nativem Format codierte PixelData ein.
  • Die maximale Dateigröße bei der Transcodierung von DICOM-Daten beträgt 1 GB und die maximale Framegröße 150 MB.
  • dicomStores.import: Die maximale Dateigröße beträgt 100 GB.
FHIR
HL7v2 10 MB

Wenn Sie versuchen, Inhalte zu verarbeiten, die das entsprechende Ressourcenlimit überschreiten, tritt ein Fehler auf.

Importvorgänge für Inhalte verwenden, die das Ressourcenlimit überschreiten

Mithilfe von Importvorgängen können Sie Inhalte verarbeiten, die das entsprechende Ressourcenlimit überschreiten. Die Inhaltsgröße bei einem Importvorgang ist nur durch die maximale Speichergröße von Google Cloud von 5 TB für Einzelobjekte begrenzt. Importvorgänge unterliegen Speicherkontingenten, die bestimmen, wie lange ein Importvorgang dauert. Sie können beispielsweise einen Importvorgang verwenden, wenn Sie viele DICOM-Instanzen in einem DICOM-Speicher speichern möchten und nicht dem Größenlimit für Anfragen unterliegen wollen. Anstatt die Instanzen mit den verfügbaren Methoden für Speichertransaktionen hochzuladen, können Sie die Instanzen in einen Cloud Storage-Bucket hochladen und dann in den DICOM-Speicher importieren.

Eine ausführliche Anleitung für das Importieren von DICOM-Daten mithilfe eines Importvorgangs finden Sie unter DICOM-Daten importieren und exportieren.

Eine ausführliche Anleitung für das Importieren von FHIR-Ressourcen mithilfe eines Importvorgangs finden Sie unter FHIR-Ressourcen importieren und exportieren.

Detaillierte Schritte zum Importieren von HL7v2-Nachrichten mithilfe eines Importvorgangs finden Sie unter HL7v2-Nachrichten aus Cloud Storage importieren

Änderung des Kontingents anfordern

Sie benötigen die Berechtigung serviceusage.quotas.update, um eine Änderung Ihres Kontingents anzufordern. Diese ist standardmäßig in den vordefinierten Rollen Inhaber, Bearbeiter und Kontingentadministrator enthalten.

  1. Rufen Sie die Seite Kontingente auf.

    Kontingente aufrufen

  2. Wählen Sie auf der Seite Kontingente die Kontingente aus, die Sie ändern möchten. Wenn Sie nur die Kontingente der Cloud Healthcare API aufrufen möchten, wählen Sie in der Drop-down-Liste Tabelle filtern die Option Dienst und danach Cloud Healthcare API aus.

  3. Klicken Sie auf die Kästchen der Kontingente, die Sie bearbeiten möchten.

  4. Klicken Sie oben auf der Seite auf die Schaltfläche Kontingente bearbeiten.

  5. Füllen Sie das Formular aus und klicken Sie dann auf Weiter.

  6. Geben Sie die Limits ein, die Sie anfordern möchten, und klicken Sie dann auf Weiter.

  7. Klicken Sie auf Anfrage senden.

Anfragen zum Verringern des Kontingents werden standardmäßig abgelehnt. Sollten Sie Ihr Kontingent verringern wollen, antworten Sie bitte auf die E-Mail des Supports und erklären Sie Ihre Anforderungen. Ein Supportmitarbeiter wird auf Ihre Anfrage antworten.

Das Team von Cloud Healthcare API antwortet innerhalb von 24 bis 48 Stunden auf Ihre Anfrage.

Fordern Sie zusätzliche Ressourcen mindestens einige Tage im Voraus an, damit genug Zeit bleibt, um Ihrer Anfrage nachzukommen.

Kontingentlimits

In den folgenden Abschnitten werden die mit der Cloud Healthcare API verbundenen Kontingente beschrieben Datenspeichern und -vorgängen.

DICOM-Kontingente

In der folgenden Tabelle werden die Cloud Healthcare API-Kontingente beschrieben, die mit mit DICOM-Speichern und DICOM-Vorgängen.

Messwertname Anzeigename Beschreibung
dicomweb_ops Anzahl der DICOMweb-Vorgänge pro Minute und Region Enthält die folgenden Methoden:
  • Alle projects.locations.datasets.dicomStores.studies-Methoden in v1beta1 und v1
  • Alle projects.locations.datasets.dicomStores.studies.series Methoden in v1beta1 und v1
  • Alle projects.locations.datasets.dicomStores.studies.series.instances Methoden in v1beta1 und v1
  • Alle projects.locations.datasets.dicomStores.studies.series.instances.frames Methoden in v1beta1 und v1
dicom_structured_storage_bytes Strukturierter DICOM-Speicher eingehender Traffic in Byte pro Minute und Region Strukturierte Byte in Form von DICOM-Tags und zugehörigen Metadaten, die während der Verarbeitung von dicomweb_ops-Vorgängen an die Cloud Healthcare API gesendet werden.
dicom_store_ops Anzahl der DICOM-Speichervorgänge pro Minute und Region Vorgänge im DICOM-Speicher, keine DICOM-Daten. Enthält die folgenden Methoden:
dicom_store_lro_ops Anzahl der lang andauernden DICOM-Speichervorgänge pro Minute und Region Vorgänge im DICOM-Speicher, nicht auf DICOM-Daten, die einen lang andauernden Vorgang zurückgeben. Dazu zählen folgende Methoden:
dicom_structured_storage_operations_bytes Eingangsrate für strukturierten DICOM-Speicher bei Vorgängen mit langer Ausführungszeit in Byte pro Minute und Region Strukturierte Byte in Form von DICOM-Tags und zugehörigen Metadaten, die während der Verarbeitung von dicom_store_lro_ops-Vorgängen an die Cloud Healthcare API gesendet werden.

FHIR-Kontingente

In der folgenden Tabelle werden die Cloud Healthcare API-Kontingente beschrieben, die mit mit FHIR-Speichern und FHIR-Vorgängen.

Messwertname Anzeigename Beschreibung
fhir_read_ops Anzahl der FHIR-Lesevorgänge pro Minute und Region Gemessen in Einheiten, wobei eine Einheit eine Leseanfrage für eine einzelne FHIR-Ressource ist.

Umfasst die folgenden Methoden:

v1beta1: Version 1:
fhir_write_ops Anzahl der FHIR-Schreibvorgänge pro Minute und Region Gemessen in Einheiten, wobei eine Einheit eine Anfrage zum Erstellen, Aktualisieren oder Löschen für eine einzelne FHIR-Ressource ist.

Umfasst die folgenden Methoden:

v1beta1: Version 1:
fhir_search_ops Anzahl der FHIR-Suchvorgänge pro Minute und Region Gemessen in Einheiten, wobei eine Einheit eine Suchanfrage für einen FHIR-Ressourcentyp ist, bei der keine Referenzen aufgelöst werden müssen, es sei denn, _include wird verwendet. Eine Observation?subject:Patient.identifier=system|value-Suche verbraucht beispielsweise zwei Kontingenteinheiten vom Typ fhir_search_ops, da sie zwei Suchvorgänge erfordert: eine in der Beobachtungsressource und eine in der Patientenressource, die subject als Referenz verwendet.

Umfasst die folgenden Methoden:

v1beta1: Version 1:
fhir_storage_egress_bytes Ausgehender FHIR-Speichertraffic in Byte pro Minute und Region In Einheiten gemessen, wobei eine Einheit ein Byte ist, das die Cloud Healthcare API bei der Verarbeitung von fhir_read_ops-, fhir_write_ops- und fhir_search_ops-Vorgängen aus dem Speicher liest.
fhir_storage_bytes Eingehender FHIR-Speicher in Byte pro Minute und Region Anzahl der Bytes, die bei der Verarbeitung von fhir_write_ops-Vorgängen an die Cloud Healthcare API gesendet wurden.
fhir_store_ops Anzahl der FHIR-Speichervorgänge pro Minute und Region Vorgänge im FHIR-Speicher, nicht für FHIR-Daten.

Umfasst die folgenden Methoden:
fhir_store_lro_ops Anzahl der lang andauernden FHIR-Speichervorgänge pro Minute und Region Vorgänge im FHIR-Speicher (nicht FHIR-Daten), die einen lang andauernden Vorgang zurückgeben.

Umfasst die folgenden Methoden:
fhir_storage_operations_bytes Eingehender FHIR-Speicher für Vorgänge mit langer Ausführungszeit in Byte pro Minute und Region Bei der Verarbeitung von fhir_store_lro_ops-Vorgängen an die Cloud Healthcare API gesendete Byte.

Eine einzelne Anfrage kann mehrere Kontingenteinheiten verbrauchen. Beispiel: Eine GET-Suche mit Observation?subject:Patient.identifier=system|value als Suchparameter verbraucht zwei fhir_search_ops-Kontingenteinheiten. Zwei Suchanfragen durchgeführt werden, eine in der Beobachtungsressource und eine in der Patientenressource. subject als Referenz.

Wenn eine bedingte Löschanfrage mit Observation?status=canceled als Suche verwendet wird nach den sechs Beobachtungsressourcen sucht und sie löscht: Verbrauchte Quoteneinheiten:

  • Eine fhir_search_ops-Kontingenteinheit, da die GET-Suchanfrage nur für einen FHIR-Ressourcentyp ausgeführt wird, nämlich die Beobachtungsressource. Die Anfrage gibt alle Beobachtungsressourcen zurück, die den Suchkriterien entsprechen.
  • Sechs fhir_write_ops-Kontingenteinheiten, da es insgesamt sechs fhir_write_ops-Vorgänge für die gelöschten Beobachtungsressourcen gibt.

Verbrauch von Bundle-Kontingent ausführen

So senden Sie eine Anfrage zum Ausführen eines Bundles: unabhängig vom Kontingent, das die Anfrage verbraucht, Im Google Cloud-Projekt muss für jedes folgende Kontingente:

  • fhir_read_ops
  • fhir_write_ops
  • fhir_search_ops

Wenn diese Kontingente nicht verfügbar sind, schlägt die Ausführungsanfrage für das Bundle fehl.

Wenn Sie beispielsweise eine fhir.executeBundle-Nachricht senden, mit einem Transaktions-Bundle, das 100 POST-Vorgänge, von denen jeder eine FHIR-Ressource erstellt, die Cloud Healthcare API überprüft zuerst, ob mindestens eine Kontingenteinheit für fhir_read_ops, fhir_write_ops und fhir_search_ops Wenn die Überprüfung erfolgreich ist, führt das Bundle aus und erstellt die FHIR-Ressourcen, die insgesamt 100 fhir_write_ops Quoteneinheiten.

Sehen Sie sich das folgende Transaktions-Bundle an, das eine bedingte Referenz verwendet um eine Beobachtungsressource zu erstellen, wenn reference vorhanden ist:

{
  "resourceType": "Bundle",
  "type": "transaction",
  "entry": [
    {
      "request": {
        "method": "POST",
        "url": "Observation"
      },
      "resource": {
        "resourceType": "Observation",
        "subject": {
          "reference": "Patient?identifier=a1b2c3d4e5"
        }
      }
    }
  ]
}

Wenn Sie das Bundle ausführen, überprüft zuerst, ob mindestens eine Kontingenteinheit für fhir_read_ops, fhir_write_ops und fhir_search_ops Wenn die Überprüfung erfolgreich ist, das Bundle ausführt. Die folgenden Kontingenteinheiten werden verbraucht:

  • Ein fhir_write_ops, um die neue Beobachtungsressource zu erstellen.
  • Ein fhir_search_ops, da nur ein Suchvorgang für die Patient?identifier=a1b2c3d4e5-Referenz ausgeführt wird.