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. Google Cloud bietet außerdem kostenlose Testkontingente, die Nutzern einen eingeschränkten Zugriff ermöglichen, um Google Cloud einschließlich der Cloud Healthcare API kennenzulernen.
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 prü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. Falls Sie eine deutlich stärkere Auslastung erwarten, können Sie auf der Seite Kontingente der Google Cloud Console eine Anpassung Ihres Kontingents anfordern. 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 |
|
FHIR |
|
HL7v2 | 10 MB |
Wenn Sie versuchen, Inhalte zu verarbeiten, die das entsprechende Ressourcenlimit überschreiten, tritt ein Fehler auf.
Größenbeschränkungen für FHIR-executeBundle
Mit der Methode fhir.executeBundle
können Sie mehrere FHIR-Vorgänge in einer einzigen API-Anfrage ausführen. Die Anzahl der Vorgänge hängt von der Anzahl der Einträge in einem Batch oder Transaktionspaket ab. Dieser Ansatz ist effizienter als separate API-Aufrufe für jeden Vorgang.
Die Verarbeitungszeiten für fhir.executeBundle
-Anfragen steigen mit der Anzahl der Einträge im Paket. Auch Faktoren wie Ressourcenkonflikte (z. B. die parallele Aktualisierung derselben Ressource im Rahmen vieler Transaktionsbundles) können sich auf die Leistung auswirken. Beispiele dafür, wann Ressourcenkonflikte auftreten können und wie Sie verhindern, dass sie zu Fehlern führen, finden Sie unter Best Practices für den Datendurchsatz.
Bei großen Paketen, insbesondere bei solchen mit mehr als 1.000 Einträgen, kann es zu einem Zeitüberschreitungsfehler kommen und die Verarbeitung wird nicht abgeschlossen.
Beachten Sie beim Senden von fhir.executeBundle
-Anfragen die folgenden Limits, um eine erfolgreiche und zeitnahe Bearbeitung zu ermöglichen:
- Transaktionsbundles: Bundles mit mehr als 4.500 Einträgen werden sofort abgelehnt,um Zeitüberschreitungen zu vermeiden. Bei Transaktionsbündeln müssen alle Vorgänge erfolgreich sein.
- Batch-Bundles: Es gibt kein bestimmtes Eingabelimit, aber bei größeren Bundles steigt das Risiko von Zeitüberschreitungen. Zeitüberschreitungen können zu einem teilweisen Erfolg führen, bei dem nur einige Einträge verarbeitet werden.
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.
Eine ausführliche Anleitung für das 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.
Rufen Sie die Seite Kontingente auf.
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.
Klicken Sie auf die Kästchen der Kontingente, die Sie bearbeiten möchten.
Klicken Sie oben auf der Seite auf die Schaltfläche Kontingente bearbeiten.
Füllen Sie das Formular aus und klicken Sie dann auf Weiter.
Geben Sie die Limits ein, die Sie anfordern möchten, und klicken Sie dann auf Weiter.
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.
Anfragen für Standortkontingente
Sie können eine Kontingenterhöhung für die Cloud Healthcare API in einer bestimmten Region oder an einem multiregionalen Standort beantragen.
So beantragen Sie eine Kontingenterhöhung für eine einzelne Region: Geben Sie in Ihrer Anfrage zur Kontingenterhöhung die Region an.
So beantragen Sie eine Kontingenterhöhung für einen Standort mit mehreren Regionen:
- Wenn Sie eine Kontingenterhöhung für die Multiregion
us
beantragen möchten, geben Sie in Ihrer Anfrage an, dass das Kontingent für die „Metaregion USA“ gilt. - Wenn Sie eine Kontingenterhöhung für die Multiregion
eu
anfordern möchten, geben Sie in Ihrer Anfrage an, dass das Kontingent für die „EU-Metaregion“ gilt.
Kontingentlimits
In den folgenden Abschnitten werden die Kontingente für Datenspeicher und Vorgänge der Cloud Healthcare API beschrieben.
DICOM-Kontingente
In der folgenden Tabelle werden die Cloud Healthcare API-Kontingente für DICOM-Speicher und DICOM-Vorgänge beschrieben.
Messwertname | Anzeigename | Beschreibung |
---|---|---|
dicomweb_ops |
Anzahl der DICOMweb-Vorgänge pro Minute und Region | Enthält die folgenden Methoden:
|
dicom_structured_storage_bytes |
Eingangsdatenverkehr für strukturierten DICOM-Speicher in Byte pro Minute und Region | Strukturierte Bytes in Form von DICOM-Tags und zugehörigen Metadaten, die bei 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 am DICOM-Speicher, nicht an DICOM-Daten. Enthält die folgenden Methoden: |
dicom_store_lro_ops |
Anzahl der Vorgänge mit langer Ausführungszeit pro Minute und Region | Vorgänge am DICOM-Speicher, nicht an DICOM-Daten, die einen langwierigen Vorgang zurückgeben. Enthält die folgenden 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 Bytes in Form von DICOM-Tags und zugehörigen Metadaten, die bei 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 für FHIR-Speicher und FHIR-Vorgänge beschrieben.
Messwertname | Anzeigename | Beschreibung |
---|---|---|
fhir_read_ops |
Anzahl der FHIR-Lesevorgänge pro Minute und Region | Wird in Einheiten gemessen, wobei eine Einheit eine Leseanfrage für eine einzelne FHIR-Ressource ist. Umfasst die folgenden Methoden: v1beta1: v1: |
fhir_write_ops |
Anzahl der FHIR-Schreibvorgänge pro Minute und Region | Wird in Einheiten gemessen, wobei eine Einheit eine Erstellungs-, Aktualisierungs- oder Löschanfrage für eine einzelne FHIR-Ressource ist. Umfasst die folgenden Methoden: v1beta1: v1: |
fhir_search_ops |
Anzahl der FHIR-Suchvorgänge pro Minute und Region | Wird in Einheiten gemessen. Eine Einheit ist eine Suchanfrage für einen FHIR-Ressourcentyp, bei der keine Verweise aufgelöst werden müssen, es sei denn, _include wird verwendet. Eine Observation?subject:Patient.identifier=system|value -Suche verbraucht beispielsweise zwei fhir_search_ops -Kontingenteinheiten, da zwei Suchanfragen erforderlich sind, eine in der Beobachtungsressource und eine in der Patientenressource, wobei subject als Referenz verwendet wird.Umfasst die folgenden Methoden: v1beta1:
|
fhir_storage_egress_bytes |
FHIR-Speicherausgang in Byte pro Minute und Region | Berechnet in Einheiten, wobei eine Einheit ein Byte ist, das die Cloud Healthcare API beim Verarbeiten von fhir_read_ops -, fhir_write_ops - und fhir_search_ops -Vorgängen aus dem Speicher liest. |
fhir_storage_bytes |
FHIR-Speicherzugriff 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 am FHIR-Speicher, nicht an FHIR-Daten. Umfasst die folgenden Methoden: |
fhir_store_lro_ops |
Anzahl der langwierigen Vorgänge im FHIR-Speicher pro Minute und Region | Vorgänge am FHIR-Speicher, nicht an FHIR-Daten, die einen langwierigen Vorgang zurückgeben. Umfasst die folgenden Methoden: |
fhir_storage_operations_bytes |
FHIR-Speicherzugriff für Vorgänge mit langer Ausführungszeit in Byte pro Minute und Region | Anzahl der Bytes, die bei der Verarbeitung von fhir_store_lro_ops -Vorgängen an die Cloud Healthcare API gesendet wurden. |
Suchanfragen mit mehreren Vorgängen
Eine einzelne Anfrage kann mehrere Kontingenteinheiten verbrauchen. Eine GET
-Suchanfrage, bei der Observation?subject:Patient.identifier=system|value
als Suchparameter verwendet wird, belegt beispielsweise zwei fhir_search_ops
-Kontingenteinheiten. Es werden zwei Suchvorgänge ausgeführt, einer auf der Beobachtungsressource und einer auf der Patientenressource, wobei subject
als Referenz verwendet wird.
Wenn bei einer bedingten Löschanfrage mit Observation?status=canceled
als Suchkriterien nach sechs Beobachtungsressourcen gesucht und diese gelöscht werden, werden die folgenden Kontingenteinheiten verbraucht:
- Eine
fhir_search_ops
-Kontingenteinheit, da dieGET
-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 sechsfhir_write_ops
-Vorgänge für die gelöschten Beobachtungsressourcen gibt.DELETE
Kontingentverbrauch für Bundles ausführen
Um eine execute bundle-Anfrage zu senden, muss in Ihrem Google Cloud-Projekt unabhängig vom Kontingent, das die Anfrage in Anspruch nimmt, für jedes der folgenden Kontingente mindestens eine Einheit verfügbar sein:
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
-Anfrage mit einem Transaktionsbundle mit 100 POST
-Vorgängen senden, durch die jeweils eine FHIR-Ressource erstellt wird, prüft die Cloud Healthcare API zuerst, ob mindestens eine Kontingenteinheit für fhir_read_ops
, fhir_write_ops
und fhir_search_ops
verfügbar ist. Wenn die Überprüfung erfolgreich ist, führt die Cloud Healthcare API das Bundle aus und erstellt die FHIR-Ressourcen, die insgesamt 100 fhir_write_ops
-Kontingenteinheiten verbrauchen.
Im folgenden Transaktions-Bundle wird eine bedingte Referenz verwendet, um eine Beobachtungsressource zu erstellen, wenn die 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, prüft die Cloud Healthcare API zuerst, ob für fhir_read_ops
, fhir_write_ops
und fhir_search_ops
mindestens eine Kontingenteinheit verfügbar ist. Wenn die Überprüfung erfolgreich ist, führt die Cloud Healthcare API das Bundle aus. 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 diePatient?identifier=a1b2c3d4e5
-Referenz ausgeführt wird.
Best Practices
Best Practices für die Verwaltung des Cloud Healthcare API-Kontingents finden Sie unter Best Practices für die Kontingentverwaltung.