Cloud Healthcare API - Preise

In diesem Dokument werden die Preisangaben für die Cloud Healthcare API und Healthcare Natural Language API

Cloud Healthcare API

In diesem Abschnitt werden die Preisangaben für die Cloud Healthcare API erläutert. Sie können auch die Google Cloud-Preisrechner zum Schätzen der Kosten für die Nutzung der Cloud Healthcare API

Wenn Sie in einer anderen Währung als US-Dollar bezahlen, gelten die Preise, die unter Cloud Platform SKUs für Ihre Währung angegeben sind.

Preisübersicht

Die Preise für die Cloud Healthcare API basieren auf einer Kombination aus:

Preistabellen

Den folgenden Preistabellen können Sie entnehmen, welche Gebühren bei der Nutzung der Cloud Healthcare API anfallen.

Die Preisbeispiele zeigen Szenarien mit Nutzung und Gebühren.

Datenspeicher

Datenspeichergebühren werden entweder als Gebühren für strukturierten Speicher oder Blob-Speicher eingestuft. Die in der folgenden Tabelle aufgeführten Gebühren für Blob-Speicher beziehen sich auf Standard- Speicherklasse, für die keine Mindestspeicherdauer erforderlich ist. Um mehr über andere Gebühren für Blob-Speicherklassen und deren Mindestspeicherdauer finden Sie unter DICOM-Datenspeicher.

Standardmäßig werden alle Speichergebühren in die Kategorie „Strukturierter Speicher” eingeordnet. Das Speichervolumen basiert auf aufgenommenen Datenbyte plus dem Indexierungs-Overhead (gemessen an indexierten Byte) und den Sicherungsbyte. Die Preise basieren auf regelmäßigen Messungen, die während eines Abrechnungszeitraums über alle Datenspeicher hinweg aggregiert wurden.

Anfragevolumen

Eine Anfrage ist ein HTTPS- oder gRPC-Vorgang, der über eine der folgenden Methoden aufgerufen wird:

  • Den healthcare.googleapis.com-Endpunkt
  • Das gcloud-Tool
  • Google Cloud Console

Folgende Arten von Anfragen sind zulässig:

  • Standardanfragen: Standardeinstellung für alle Anfragen
  • Komplexe Anfragen: Erfasst rechenintensive API-Anfragen im Vergleich zu Standardanfragen
  • Anfragen für mehrere Vorgänge: Erfasst Anfragen für mehrere Vorgänge
  • Anfragen für erweiterte Vorgänge: Erfasst Vorgänge wie FHIR zu einem bestimmten Zeitpunkt Erholung

Die ersten 25.000 Anfragen sind kostenlos. Wenn die kostenlose Stufe aufgebraucht ist, werden die Preise der nächsten Stufen pro 100.000 Anfragen pro Monat berechnet.

Kategorie 0–25.000 Anfragen 25.000–1 Mrd. Anfragen Über 1 Mrd. Anfragen
Standardanfragen 0,00 $ 0,39 $ 0,29 $
Komplexe Anfragen 0,00 $ 0,69 $ 0,59 $
Anfragen für mehrere Vorgänge 0,00 $ 0,39 $ 0,29 $

Erweiterte Vorgangsanfragen werden mit 0,99 $pro 100.000 abgerechnet. -Anfragen.

Sofern in der folgenden Tabelle nicht anders angegeben, sind alle Vorgänge Standardanfragen. Scrollen Sie, um den gesamten Inhalt der Tabelle zu sehen.

Komplexe Anfragevorgänge Anfragevorgänge für mehrere Vorgänge Kostenlose Vorgänge Erweiterte Vorgänge
consentStores.evaluateUserConsents
dicomStores.searchForStudies
dicomStores.searchForSeries
dicomStores.searchForInstances.
fhir.search.
fhir.conditionalUpdate
fhir.conditionalPatch
fhir.Observation-lastn
fhir.ConceptMap-search-translate
fhir.Resource-validate
fhir.Resource-incoming-references

Wenn FHIR-Profile verwendet werden:
fhir.create
fhir.update
fhir.patch
dicomStores.studies.storeInstances
dicomStores.studies.series.instances.retrieveInstance
dicomStores.studies.retrieveStudy
dicomStores.studies.series.retrieveSeries
fhir.Patient-everything
fhir.executeBundle
hl7V2Stores.messages.batchGet
fhirStores.delete
fhirStores.import
fhir.delete
fhir.Resource-purge
fhir.conditionalDelete
dicomStores.delete
dicomStores.studies.delete
dicomStores.studies.series.delete
dicomStores.studies.series.instances.delete
hl7V2Stores.delete
hl7V2Stores.messages.delete
datasets.delete
annotationStores.delete
annotationStores.import
annotationStores.annotations.delete
fhirStores.rollback

Beispiel:

  • Die DICOM-Vorgänge, die in der Tabelle unter „Anfragevorgänge für mehrere Vorgänge“ aufgeführt sind, können mehrere DICOM-Instanzen in einer einzelnen Anfrage übertragen (z. B. kann eine einzelne dicomStores.storeInstances-Anfrage zum Hochladen mehrerer Instanzen verwendet werden). Bei diesen Anfragen wird für jede übertragene DICOM-Instanz eine Anfrage für mehrere Vorgänge berechnet.
  • Ein Aufruf der Methode hl7V2Stores.messages.batchGet besteht aus einem Standard und n - 1 Anfragen für mehrere Vorgänge, wobei n die Anzahl der zurückgegebene Nachrichten.
  • Ein Aufruf der Methode fhir.executeBundle besteht aus einer Standardanfrage und n-1 Anfragen mit mehreren Vorgängen, wobei n ist die Anzahl der angeforderten Bundle-Einträge, die keine Löschvorgänge sind (fhir.delete ist kostenlos).
  • Die Validierung für FHIR-Profile wird jeweils als eine komplexe Anfrage berechnet Ressource in einer fhir.create-, fhir.update- und fhir.patch-Anfrage. Anrufe an fhir.executeBundle werden für jede überprüfte Ressource im Bundle in Rechnung gestellt. Ihnen wird nur einmal pro Ressource in Rechnung gestellt, unabhängig von der Anzahl der Profile. für die Ressource.
  • Einzelne FHIR-Ressourcen-ID mithilfe der FHIR-Wiederherstellung zu einem bestimmten Zeitpunkt wiederherstellen der Vorgang (fhirStores.rollback) 0, 0000099 $kostet und die Wiederherstellung 100.000 eindeutige FHIR-Ressourcen-IDs kosten 0,99 $.

Benachrichtigungsvolumen

Benachrichtigungen sind Streaming-Ereignisse, die aus Datenspeichern stammen und an Google Cloud oder externe Endpunkte gesendet werden. Benachrichtigungen enthalten entweder Ressourcennamen, Ressourcenmetadaten oder ganze Ressourcen und werden gemäß einer vom Nutzer bereitgestellten Konfiguration generiert. Die Standardeinstellung für alle Benachrichtigungen ist der Typ „Standardbenachrichtigungen“.

Die folgenden Preise gelten pro 1 Million Benachrichtigungen pro Monat:

Kategorie 0–100.000 Benachrichtigungen (pro 1 Million) Über 100.000 Benachrichtigungen (pro 1 Million)
Standardbenachrichtigungen 0,00 $ 0,29 $

Standardbenachrichtigungen sind beispielsweise Pub/Sub-Benachrichtigungen, die an ein Pub/Sub-Thema gesendet werden, das an einen Datenspeicher angehängt ist.

DICOM-Datenspeicher

Gespeicherte, DICOM-Rohdaten verwenden in allen Regionen Blob-Speicher. Suchbare Metadaten von aufgenommene DICOM-Images (z. B. DICOM-Tags) gespeichert und im Rahmen des Strukturierter Speicher.

Die Preise für Blob Storage basieren auf der Menge an nicht strukturierten Byte bzw. BLOB-Byte, die aufgenommen und gespeichert werden sowie in der verwendeten Speicherklasse. Die folgenden sind die verschiedenen Speicherklassen aufgeführt, die zum Speichern von DICOM-Rohdaten verfügbar sind. Mindestspeicherdauer:

Speicherklasse Mindestspeicherdauer
Standard Keine
Nearline 30 Tage
Coldline 90 Tage
Archivieren 365 Tage

Die folgende Tabelle zeigt die anwendbaren Gebühren für ruhende Daten bei Verwendung von Nearline Storage-, Coldline Storage- und Archive-Speicherklassen zum Speichern von DICOM-Daten Cloud Healthcare API Diese Gebühren gelten für alle Regionen.

Speicherklasse Preis (pro GB/Monat)
Nearline 0,020 $
Coldline 0,010 $
Archivieren 0,003 $

Die Gebühren für die Standardspeicherklasse werden als Blob aufgeführt. Speichergebühren für verschiedene Regionen unter Datenspeicherung .

Vorzeitiges Löschen von DICOM-Daten

Wenn Sie einen DICOM löschen, überschreiben oder neu schreiben, fällt eine Gebühr für vorzeitiges Löschen an. -Objekt enthält. Ein Beispiel für das Umschreiben ist die Änderung der Speicherklasse eines Objekts. Die Gebühr für vorzeitiges Löschen entspricht dem Betrag, der angefallen wären, Das Objekt blieb für die Mindestdauer in seinem ursprünglichen Zustand.

Dazu ein Beispiel:

  • Sie speichern 1.000 GB DICOM-Objekte mit der Coldline Storage-Klasse. Für Coldline Storage beträgt der Preis pro GB und Monat 0, 01 $. Wir haben einen Monat in Betracht gezogen als 30 Tage berechnet, lässt sich der Preis pro GB und Tag so berechnen:

     $0.01/GB/month * 1 day / 30 days 

  • Am Ende von Tag 60 löschen Sie alle Daten im Store. Weil Coldline eine Mindestspeicherdauer von 90 Tagen hat, wird Ihnen Objekt wurde während der gesamten Mindestspeicherdauer von 90 Tagen gespeichert. Hier ist die Aufschlüsselung der Belastung:

    • Die normalen Speicherkosten für ruhende Daten, die mit die 60 Tage, die Ihre Daten im Bucket vorhanden waren:

       $0.01/GB/month * 1,000 GB * 2 months = $20 
    • Einer Gebühr für vorzeitiges Löschen, die für die verbleibenden 30 Tage der Mindestspeicherdauer von 90 Tagen gilt:

       ($0.01/GB/month * 1 day / 30 days) * 1,000 GB * 30 days = $10 
  • Addieren Sie die beiden Komponenten der Gebühr, also die Gesamtspeicherkosten für Ihre DICOM- für 60 statt für 90 Tage, beträgt 30 €. Das sind die gleichen Kosten, die Sie bezahlt, wenn Sie Ihre DICOM-Daten über die gesamten 90 Tage des Mindestspeichers und werden am Ende von Tag 90 gelöscht.

DICOM-Datenabruf

Wenn Sie Objektdaten oder Objekte lesen, kopieren, verschieben oder neu schreiben, fällt eine Abrufgebühr an. Metadaten, die in Nearline Storage, Coldline Storage oder Archivspeicher. Diese Kosten gelten zusätzlich zu den Netzwerkgebühren. die mit dem Lesen der Daten verbunden sind.

Die folgende Tabelle zeigt die Abrufraten für die einzelnen Speicherklassen:

Speicherklasse Preis (pro GB)
Standard 0 $
Nearline 0,01 $
Coldline 0,02 $
Archivieren 0,05 $

Für jeden Abruf in Nearline Storage, Coldline Storage oder Archive Storage fällt zusätzlich eine Gebühr für komplexe Anfragen an.

ETL-Vorgänge

ETL-Vorgänge (Extrahieren, Transformieren, Laden) in der Cloud Healthcare API gehören zu folgenden Kategorien:

  • Batch exportieren
  • Stream exportieren
  • Batch auswerten
  • DICOM transcodieren

Das gesamte Datenvolumen wird während jedes Abrechnungszeitraums über alle Services hinweg aggregiert. In der folgenden Tabelle sind die Kosten pro GB für jeden ETL-Vorgang aufgeführt:

Kategorie 0–1 GB 1–1.024 GB (1 TB) Über 1 TB
Batch exportieren 0,19 $ 0,14 $ 0,09 $
Stream exportieren 0,34 $ 0,29 $ 0,24 $
Batch auswerten 0,05 $ 0,05 $ 0,05 $
DICOM transcodieren 0,00 $ 0,004 $ 0,003 $

Diese Vorgänge werden anhand des Gesamtvolumens der verarbeiteten Daten abgerechnet. Exportvorgänge umfassen alle Ziele, beispielsweise Cloud Storage und BigQuery. Die DICOM-Transcodierung wird nur in Rechnung gestellt, wenn eine DICOM-Instanz in einer anderen transfer-syntax als der, mit der sie hochgeladen wurde, angefordert wird. Dies kann beispielsweise für „Retrieve Transaction“- und Bulk-Export-Anfragen der Fall sein. Weitere Informationen zum Abrufen von Transaktionen finden Sie im Abschnitt „Retrieve Transaction“ der DICOM-Konformitätserklärung.

Bei Batch-Auswertungsvorgängen werden Daten zwischen zwei Annotationsspeichern verglichen: ein Annotationsspeicher „Ground Truth“ und ein „ausgewerteter“ Annotationsspeicher. Der Vorgang iteriert durch die Annotationseinträge im Speicher „Ground Truth“ und sucht im ausgewerteten Annotationsspeicher nach Treffern (etwa Annotationseinträgen, die die gleiche DICOM- oder FHIR-Ressource beschreiben). Zueinander passende Annotationspaare werden verglichen, um die Differenz zwischen den „Ground Truth“- und den ausgewerteten Annotationseinträgen zu berechnen. Die Preise sind proportional zur Gesamtgröße passender Paare plus der Gesamtlänge der Ressourcennamen im Speicher „Ground Truth“.

Exportieren nach Cloud Storage:

  • Das DICOM-Datenvolumen basiert auf der Größe der gespeicherten Dateien.
  • Das FHIR-Datenvolumen basiert auf den im Protokollzwischenspeicher-Format übertragenen Byte.
  • Das HL7v2-Datenvolumen basiert auf der Größe der unbearbeiteten HL7v2-Nachrichtenbyte.
  • Das Datenvolumen der Annotationseinträge basiert auf den im Protokollzwischenspeicher-Format übertragenen Byte.

Exportieren nach BigQuery:

  • Das DICOM-Datenvolumen basiert auf den gespeicherten DICOM-Metadaten.
  • Das FHIR-Datenvolumen basiert auf der gesamten Ressource.
  • Das Datenvolumen der Annotationseinträge basiert auf den im Protokollzwischenspeicher-Format übertragenen Byte.

Sowohl für DICOM als auch für FHIR basiert die verwendete Messung auf der Anzahl der übertragenen Protokollzwischenspeicher-Byte.

Bei der Transcodierung basiert das Datenvolumen auf der Eingabegröße der Daten und nicht auf der Ausgabegröße oder der maximalen Zwischengröße.

In der folgenden Tabelle sind die Vorgänge für jeden ETL-Kategorietyp aufgeführt:

Batch exportieren Stream exportieren Batch auswerten DICOM transcodieren
fhirStores.export
dicomStores.export
annotationStores.export
fhir.conditionalDelete
fhir.conditionalPatch
fhir.conditionalUpdate
fhir.create
fhir.delete
fhir.executeBundle fhir.patch
fhir.update
annotationStores.evaluate dicomStores.export
dicomStores.studies.retrieveStudy
dicomStores.series.retrieveSeries
dicomStores.studies.series.instances.retrieveInstance
dicomStores.studies.series.instances.retrieveRendered
dicomStores.studies.series.instances.frames.retrieveFrames
dicomStores.studies.series.instances.frames.retrieveRendered

De-Identifikationsvorgänge

De-Identifikationsvorgänge werden auf Basis des Datenvolumens in Rechnung gestellt, das in drei Untervorgängen verarbeitet wird:

  • Prüfung: Erfolgt bei freiem Text oder Bildern, um Instanzen sensibler Daten zu erkennen.
  • Transformation: Umfasst das Entfernen, Ersetzen, Hashing oder Ändern sensibler Daten im Rahmen des De-Identifikationsprozesses.
  • Verarbeitung: Deckt die Grundkosten des Vorgangs ab.

Die Datenmenge in jedem Untervorgang hängt davon ab, wie der Hauptvorgang ist. konfiguriert.

Die Kosten werden monatlich beglichen, abhängig davon, wie viele Einheiten verarbeitet wurden und welcher Stufe sie angehören. Es gibt drei Arten von Einheiten, die unterschiedlich berechnet werden:

  • Prüfeinheiten: je nach Anzahl der überprüften Byte multipliziert mit der Anzahl der zur Prüfung verwendeten infoTypes. Wenn Sie z. B. 1 GB Daten mit 10 infoTypes entsprechen einer Prüfung von 10 Giga-Einheiten (GU). Standardmäßig werden für jede Inspektion mindestens 10 infoTypes verwendet. Das bedeutet, gilt eine Mindestgebühr von 10 Kiloeinheiten pro De-Identifikationsvorgang.
  • Transformationseinheiten: je nach Anzahl der transformierten Byte, wobei 1 GB Daten der Transformation von 1 GU entspricht.
  • Verarbeitungseinheiten: je nach Gesamtzahl der Byte im De-Identifikationsvorgang.

Die Einheitenarten werden, wie in den obigen Tabellen erläutert, in verschiedenen Kategorien abgerechnet:

  • Die Kosten für Prüfung und Transformation sind in Bereichen von Giga-Einheiten (Giga-Units, GU) und Tera-Einheiten (Tera-Units, TU) angegeben. Die Preise für die einzelnen Bereiche verstehen sich pro GU.

    Für einen Abrechnungszeitraum gilt beispielsweise:

    • Bis zu 1 GU an Prüfungseinheiten ist kostenlos.
    • Zwischen 1 TU und 10 TU werden die Prüfungseinheiten mit 0,20 $ für die Anzahl der Einheiten abgerechnet.
  • Die Verarbeitungskosten werden in Bereichen von Gigabyte (GB) und Terabyte (TB) angegeben. Die Preise für die einzelnen Bereiche verstehen sich pro GB.

    Für einen Abrechnungszeitraum gilt beispielsweise:

    • Bei bis zu 1 GB strukturiertem Speicher ist die Batchverarbeitung kostenlos.
    • Zwischen 1 TB und 10 TB werden die Batchverarbeitungseinheiten im strukturierten Speicher mit 0,50 $ abgerechnet.
Untervorgang 0–1 GU 1 GU–1 TU 1 TU–10 TU Über 10 TU
Prüfung 0,00 $ 0,30 $ 0,20 $ 0,10 $
Transformation 0,00 $ 3,00 $ 2,00 $ 1,00 $
Untervorgang Kategorie 0–1 GB 1 GB–1 TB 1 TB–10 TB Über 10 TB
Verarbeitung Strukturierter Speicher, Batch 0,00 $ 0,60 $ 0,50 $ 0,40 $
Verarbeitung Blob-Speicher, Batch 0,00 $ 0,08 $ 0,06 $ 0,05 $

Die Gebühren für die Untervorgänge hängen davon ab, ob Sie mit FHIR- oder DICOM-Daten arbeiten:

FHIR:

  • Prüfungs- und Transformationsgebühren gelten für den Teil der Ressource, der auf sensible Daten untersucht und anschließend transformiert wird.
  • Die Verarbeitungsgebühren werden zum Batch-Preis des strukturierten Speichers abgerechnet und gelten für die gesamte Ressource.

DICOM:

  • Die Prüfungsgebühren gelten für den Teil der Ressource (einschließlich Pixeldaten), der auf sensible Daten untersucht wird.
  • Transformationsgebühren gelten für den Teil der Ressource (ohne Pixeldaten), der nach der Prüfung transformiert wird. Wenn ein Bild entfernt wird, fallen nur für die Prüfung Gebühren an, jedoch nicht für die Transformation. Weitere Informationen, wie dies in der Praxis funktioniert, finden Sie im Beispiel zur DICOM-De-Identifikation.
  • Die Verarbeitungsgebühren gelten für die gesamte Ressource und werden anhand der Größe der ursprünglichen DICOM-Instanz berechnet. Die Verarbeitungsgebühren für DICOM-Metadaten verwenden die Kategorie „Structured Storage, Batch“ (Strukturierter Speicher, Batch). Die Verarbeitungsgebühren für Pixeldaten verwenden die Kategorie „Blob Storage, Batch“ (Blob-Speicher, Batch).

Die Nutzung der Consent Management API wird basierend auf der Anzahl der verwalteten Consent-Ressourcen und der Anzahl der UserDataMapping-Ressourcen abgerechnet, die bei Batchvorgängen zur Zugriffsermittlung evaluiert werden.

Im Rahmen der Abrechnung der Anzahl verwalteter Einwilligungen wird die durchschnittliche Menge der Consent-Objekte mit dem Status ACTIVE und DRAFT während des Abrechnungszeitraums in Rechnung gestellt. Einwilligungen mit dem Status REVOKED, REJECTED und ARCHIVED werden nicht abgerechnet.

Bei der Batchmethode projects.locations.datasets.consentStores.queryAccessibleData zur Zugriffsermittlung ist die Anzahl der evaluierten UserDataMapping-Ressourcen die Gesamtzahl der UserDataMapping-Ressourcen im Consent-Speicher zur Zeit der Anfrage.

Die Speicherung und die Vorgänge für die Consent Management API werden wie unter Datenspeicher und Anfragevolumen beschrieben abgerechnet. Der genutzte Consent-Speicherplatz wird als strukturierter Speicher abgerechnet, abgesehen von den nicht strukturierten Byte bzw. BLOB-Byte, die in einem consentArtifact gespeichert werden. Alle Einwilligungsvorgänge sind Standardanfragen, außer EvaluateUserConsent, das als komplexe Anfrage abgerechnet wird, und QueryAccessibleData, das wie im vorherigen Abschnitt beschrieben abgerechnet wird. Während des aktuellen Aktionszeitraums sind die Speichernutzung sowie Standardanfragen und komplexe Anfragen kostenlos.

Einheit Preise
Verwaltete Einwilligungen 0,05 $ pro Einwilligung und Monat
Zugriffsermittlung, Batch 0,016 $ pro 1 Million evaluierte UserDataMapping-Ressourcen

Netzwerkauslastung

Eingehende Datenübertragung

Eingehende Datenübertragungen sind grundsätzlich kostenlos.

Interregionale Datenübertragung

Für die Datenübertragung fallen keine Kosten an, wenn die Übertragungsanfrage von die Cloud Healthcare API und geht zu jedem Dienst in Google Cloud die sich in derselben Region befindet.

Die folgenden Preise gelten für regionenübergreifende Datenübertragungen oder für Datenübertragungen von einer Gruppe mit mehreren Regionen zu einer einzelnen Region auf demselben Kontinent und umgekehrt. Die Preise verstehen sich pro GB und Monat.

Quelle und Ziel des Traffics Über 0 GB
Nordamerika nach Nordamerika 0,01 $
Europa nach Europa 0,02 $
Asiatisch-pazifischer Raum nach asiatisch-pazifischer Raum 0,05 $
Interkontinental (außer Ozeanien) 0,08 $
Interkontinental nach/von Ozeanien 0,15 $
Allgemeine Netzwerknutzung

Die allgemeine Netzwerknutzung gilt für Daten, die Google Cloud verlassen. Die Cloud Healthcare API verwendet Premium Internet Data Transfer, mit Preisangaben unten. Die Preise für die Datenübertragung entsprechen den Preisen des Google Cloud-Netzwerks – Premium-Stufe.

Die Preise verstehen sich pro GB und Monat.

Quelle und Ziel des Traffics 0–10 TB 10 TB–150 TB Über 150 TB
Nordamerika nach Nordamerika 0,105 $ 0,080 $ 0,060 $
Europa nach Europa 0,105 $ 0,080 $ 0,060 $
Asiatisch-pazifischer Raum nach asiatisch-pazifischer Raum 0,120 $ 0,085 $ 0,080 $
Südamerika nach Südamerika 0,120 $ 0,085 $ 0,080 $
Ozeanien nach Ozeanien 0,120 $ 0,085 $ 0,080 $
Interkontinental (außer Ozeanien und China) 0,120 $ 0,085 $ 0,080 $
Interkontinental nach/von Ozeanien 0,190 $ 0,160 $ 0,150 $
Jeglicher Traffic nach China 0,190 $ 0,160 $ 0,150 $

Preisbeispiele

Preisbeispiel für FHIR

Angenommen, eine FHIR-basierte Anwendung wird in Google Cloud in europe-west2 gehostet und erzeugt in einem Monat 25.000.000 Anfragen mit durchschnittlich 4 KB pro Ressource. Fünf Millionen der Anfragen sind FHIR-Suchanfragen und werden daher als komplexe Anfragen in Rechnung gestellt. Der FHIR-Speicher speichert über einen Zeitraum von einem Monat durchschnittlich 1 TB an Daten, einschließlich Sicherungs- und Indexierungs-Overhead.

Die folgende Tabelle zeigt das Nutzungsmuster im angegebenen Monat:

Preiskategorie Art der Datenverwendung Menge
Anfragevolumen Standardanfragen
Komplexe Anfragen
20.000.000
5.000.000
Datenspeicher Strukturierter Speicher in europe-west2 1 TB

Ihre Rechnung für den Monat wird folgendermaßen berechnet:

Preiskategorie Berechnung Preise
Anfragevolumen Insgesamt 25.000.000 Anfragen:
(Anfragestufe 0–25.000) 25.000 Standardanfragen x 0,00 $
(Anfragestufe 25.000–1 Milliarde) 19.975.000 Standardanfragen x 0,39 $
(Anfragestufe 0–25.000) 25.000 komplexe Anfragen x 0,00 $
(Anfragestufe 25.000–1 Milliarde) 4.975.000 komplexe Anfragen x 0,69 $

0,00 $
77,90 $
0,00 $
34,33 $
Datenspeicher 1 TB insgesamt:
(Stufe 0–1 GB) 1 GB x 0,00 $
(Stufe 1 GB–1 TB) 1.023 GB x 0,39 $

0,00 $
398,97 $
Summe 511,20 $

Preisbeispiel für DICOM

Angenommen, ein kleines Bildgebungszentrum generiert in einem DICOM-Speicher in us-central1 pro Monat Folgendes:

  • 1.000 Röntgenuntersuchungen (mit jeweils ca. 10 MB)
  • 300 CT-Untersuchungen (mit jeweils ca. 300 MB)
  • 200 MRT-Untersuchungen (mit jeweils ca. 300 MB)

Das Bildgebungszentrum bewahrt die Bilder ein Jahr lang auf, was zu einem durchschnittlichen monatlichen Speicherbedarf von 160 GB und zusätzlichen 6,4 GB Speicherverbrauch für analysierte Meta-Tags einschließlich zusätzlichen Aufwendungen führt. Zum Schätzen der Anzahl der gestellten Anfragen wird davon ausgegangen, dass jede Röntgenuntersuchung aus einem einzelnen Bild und jede CT- und MRT-Untersuchung aus 300 Bildern besteht.

Außerdem wird Folgendes vorausgesetzt:

  • Für jede Untersuchung werden zwei Metadatensuchanfragen (DICOMweb-Suchtransaktion) gestellt. Insgesamt also 2 x (1.000 + 300 + 200) = 3.000 komplexe Anfragen.
  • Jedes Bild wird zweimal abgerufen, also lautet die Summe: 2*(1.000 + 300 * 300 + 200 * 300) = 302.000 Anfragen für mehrere Vorgänge.
  • Die Bilder müssen bei jeder Anfrage transcodiert werden, sodass insgesamt 2 x 160 GB = 320 GB transcodiert werden.

Die folgende Tabelle zeigt das Nutzungsmuster im angegebenen Monat:

Preiskategorie Art der Datenverwendung Menge
Anfragevolumen Komplexe Anfragen
Anfragen für mehrere Vorgänge
3.000
302.000
Datenspeicher Strukturierter Speicher in us-central1
Blob-Speicher in us-central1
6,4 GB
160 GB
ETL-Vorgänge DICOM transcodieren 320 GB

Ihre Rechnung für den Monat wird folgendermaßen berechnet:

Preiskategorie Berechnung Preise
Anfragevolumen Insgesamt 305.000 Anfragen:
(Stufe 0–25.000 Anfragen) 3.000 Komplexe Anfragen × 0,00 $
(Stufe 0–25.000 Anfragen) 25.000 Anfragen mit mehreren Vorgängen × 0,00 $
(Stufe 25.000–1 Milliarde Anfragen) 277.000 Anfragen für mehrere Vorgänge × 0 $

0,00 $
0,00 $
1,08 $
Datenspeicher Insgesamt 166,4 GB:
(Stufe 0–1 GB) 0,5 GB strukturierter Speicher x 0,00 $
(Stufe 1 GB–1 TB) 5,9 GB strukturierter Speicher x 0,24 $
(Stufe 0–1 GB) 1 GB Blob-Speicher x 0,00 $
(Stufe 1 GB–1 TB) 159 GB Blob-Speicher x 0,02 $

0,00 $
1,42 $
0,00 $
3,18 $
ETL-Vorgänge Insgesamt 320 GB:
(Stufe 0–1 GB) 1 GB x 0,00 $
(Stufe 1 GB–1 TB) 319 GB x 0,004 $

0,00 $
1,28 $
Summe 6,96 $

Preisbeispiel für HL7v2

Angenommen, ein HL7v2-Speicher in us-central1 ist mit einer Pflegeeinrichtung verbunden, die mit einem lokalen MLLP-Adapter 10.000.000 Nachrichten pro Monat erstellt. Es werden also 10.000.000 Datenaufnahmeanfragen an die Cloud Healthcare API gesendet. Als Antwort werden 10.000.000 Bestätigungsnachrichten generiert (die jedoch nicht im HL7v2-Speicher gespeichert werden).

Der HL7v2-Speicher speichert über einen Zeitraum von einem Monat durchschnittlich 80 GB an Daten, einschließlich Sicherungs- und Indexierungs-Overhead.

Die folgende Tabelle zeigt das Nutzungsmuster im angegebenen Monat:

Preiskategorie Art der Datenverwendung Menge
Anfragevolumen Standardanfragen 20.000.000
Datenspeicher Strukturierter Speicher in us-central1 80 GB

Ihre Rechnung für den Monat wird folgendermaßen berechnet:

Preiskategorie Berechnung Preise
Anfragevolumen Insgesamt 20.000.000 Anfragen:
(Anfragestufe 0–25.000) 25.000 Standardanfragen x 0,00 $
(Anfragestufe 25.000–1 Milliarde) 19.975.000 Standardanfragen x 0,39 $

0,00 $
77,90 $
Datenspeicher Insgesamt 80 GB:
(Stufe 0–1 GB) 1 GB x 0,00 $
(Stufe 1 GB–1 TB) 79 GB x 0,24 $

0,00 $
18,96 $
Summe 96,86 $

Beispiel für eine FHIR-De-Identifikation

Angenommen, Sie de-identifizieren 10 GB an FHIR-Daten. Bei der De-Identifikation werden 10 % (1 GB) der Daten geprüft, von denen wiederum 10 % (0,1 GB) transformiert werden. Standardmäßig werden 15 infoTypes verwendet.

Ihre Rechnung für die De-Identifikation würde dann so aussehen:

Untervorgang Berechnung Preise
Prüfung 10 GB x 0,1 geprüfte Daten x 15 infoTypes x 0,30 $/GU 4,50 $
Transformation 10 GB x 0,1 geprüfte Daten x 0,1 transformierte Daten x 3,00 $/GU 0,30 $
Verarbeitung 10 GB x 0,60 $/GB 6,00 $
Summe 10,80 $

Beispiel für eine DICOM-De-Identifikation

Angenommen, Sie de-identifizieren 10 GB an DICOM-Daten. 90 % (9 GB) der Daten bestehen aus DICOM-Bildern. Alle Bilder werden geprüft und 10 % (0,9 GB) werden transformiert. Standardmäßig werden 16 infoTypes verwendet.

Ihre Rechnung für die De-Identifikation würde dann so aussehen:

Untervorgang Berechnung Preise
Prüfung 10 GB x 0,9 Bilder x 16 infoTypes x 0,30 $/GU 43,20 $
Transformation Mit Prüfung gebündelt 0,00 $
Verarbeitung DICOM-Metadaten: 10 GB x 0,1 Text x 0,60 $/GB
Pixel-Daten: 10 GB x 0,9 Bilder x 0,08 $/GB
0,60 $
0,72 $
Summe 44,52 $

Beispiele für Benachrichtigungsvolumen

Nehmen wir an, dass von einer FHIR-basierten Anwendung 1,6 Mio. Pub/Sub-Benachrichtigungen pro Monat erstellt werden. Da Benachrichtigungen pro 1 Mio. berechnet werden, sieht Ihre Abrechnung für Benachrichtigungen so aus:

Benachrichtigungstyp Berechnung Preise
Pub/Sub-Benachrichtigung Insgesamt 1.600.000 Benachrichtigungen:
(Benachrichtigungsstufe 0–100.000) 100.000 Benachrichtigungen x 0,00 $
(Benachrichtigungsstufe 100.000–1,1 Mio.) 0,29 $
(Benachrichtigungsstufe 1,1–1,6 Mio.) 0,29 $ x 0,5

0,00 $
0,29 $
0,145 $
Summe 0,435 $

Healthcare Natural Language API

Die Healthcare Natural Language API bietet eine Reihe von Features zum Extrahieren von Gesundheitsdaten aus medizinischen Texten. Sie zahlen nur für die Funktionen, die Sie nutzen – und Sie müssen im Vorfeld keine Verpflichtungen eingehen. Die API unterstützt dabei die folgenden Funktionen:

Featuretyp Beschreibung
Entitätsanalyse Analyse von Gesundheitsentitäten im Text. Die Antwort enthält die erkannten Entitätserwähnungen und die Beziehungen zwischen ihnen. Jede Entität ist mit einem standardmäßigen medizinischen Vokabular verknüpft.
Wenn Sie in einer anderen Währung als US-Dollar bezahlen, gelten die Preise, die unter Cloud Platform SKUs für Ihre Währung angegeben sind.

Preistextdatensätze

Ihre Nutzung der Healthcare Natural Language API wird folgendermaßen berechnet: Monatliches Volumen von Textdatensätzen. Ein Textdatensatz enthält 1.000 Zeichen. Zeichen sind Unicode-Zeichen (einschließlich Leerzeichen) und Markup-Zeichen wie HTML- oder XML-Tags enthalten.

Die Gebühren für Textdatensätze sind in die folgenden Stufen unterteilt:

  • Kostenlos (1 Texteintrag – 2.500 Textdatensätze)
  • Geringes Volumen (2.500 Textdatensätze – 1.000.000 Textdatensätze)
  • Hohes Volumen (mehr als 1.000.000 Textdatensätze)

Die Kosten für die Healthcare Natural Language API werden monatlich berechnet. Grundlage dafür sind die genutzten Features und die Anzahl der Textdatensätze, die mit diesen Features ausgewertet wurden. Die folgende Tabelle zeigt den Preis pro 1 Textdatensatz während eines Abrechnungsmonats. Die Preise für die Stufe mit geringem Volumen gelten nur für bewertete Textdatensätze. über das kostenlose Kontingent hinaus. Die Preise im oberen Bereich Volumenstufe gelten nur für Textdatensätze, die über die Stufe mit geringem Volumen hinausgehen.

Funktion Kostenlose Stufe (1 Texteintrag – 2.500 Texteinträge) Stufe mit geringem Volumen (2.500 Textdatensätze – 1.000.000 Textdatensätze) Stufe „Hohes Volumen“ (mehr als 1.000.000 Textdatensätze)
Entitätsanalyse 0,00 $ 0,10 $ 0,03 $

Textdatensätze werden in Schritten von 0,1 Texteinheiten abgerechnet. Beispiel: wenn Sie das kostenlose monatliche Kontingent überschritten haben und Sie eine Anfrage mit 800 Zeichen werden Ihnen 0, 8 Textdatensätze berechnet. Die Gesamtkosten belaufen sich auf 0,08 $ und werden so berechnet: 0.8 * $0.10.

Wenn die Anzahl der Zeichen in einer Anfrage kein Vielfaches von 100 ist, wird die Zeichenzahl auf die nächsthöhere 100er-Stufe aufgerundet.

In der folgenden Tabelle sehen Sie ein Beispiel für die Preise für drei Anfragen, die an der Healthcare Natural Language API in der Stufe mit geringem Volumen (dabei wird davon ausgegangen,dass 2.500 Textzeilen Datensätze wurden bereits gesendet und die kostenlose Stufe ist erschöpft). Die Anfragen enthalten 8.000, 15.000 und 6.000 Zeichen.

  Anzahl der Zeichen Textdatensatzeinheiten Preis
Anfrage 1 8.000 8 0,80 $
Anfrage 2 15.000 15 1,50 $
Anfrage 3 6.000 6 0,60 $
Summe 29.000 29 2,90 $

Die folgende Tabelle zeigt ein Beispiel für die Preise für drei Anfragen. an die Healthcare Natural Language API gesendet. Die Anfragen enthalten 150.000.000 (150 Millionen), 800.000.000 (800 Millionen), und 600.000.000 (600 Millionen) Zeichen, also insgesamt 1.550.000.000 (1,55 Milliarden) Zeichen oder 1.550.000 Textdatensätze

  Anzahl der Zeichen Textdatensatzeinheiten Kumulative Textdatensatzeinheiten Preis
Anfrage 1 150.000.000 150.000 150.000 14.750,00 $ (0–2.500 Textdatensätze in der kostenlosen Stufe, 2.501–150.000 Textdatensätze in der Stufe mit geringem Volumen)
Anfrage 2 800.000.000 800.000 950.000 80.000,00 $ (150.000–950.000 Textdatensätze in der Stufe mit geringem Volumen)
Anfrage 3 600.000.000 600.000 1.550.000 21.500,00 $ (950.000–1.000.000 Textdatensätze in der Stufe „Geringes Volumen“, verbleibende 550.000 Textdatensätze in der Stufe „Hohes Volumen“)
Summe 1.550.000.000 1.550.000 1.550.000 $116.250,00

Google Cloud Platform-Kosten

Wenn Sie Text, der analysiert werden soll, in Cloud Storage speichern oder andere Google Cloud-Ressourcen zusammen mit der Healthcare Natural Language API verwenden, wie z. B. die Cloud Healthcare API oder Compute Engine-Instanzen, dann wird Ihnen auch die Nutzung dieser Dienste in Rechnung gestellt. Im Google Cloud-Preisrechner können Sie die weiteren Kosten gemäß der aktuellen Preise ermitteln.

Ihren aktuellen Abrechnungsstatus einschließlich Nutzung und Ihrer aktuellen Rechnung finden Sie in der Cloud Console auf der Abrechnungsseite. Weitere Informationen zur Kontoverwaltung finden Sie in der Dokumentation zu Cloud Billing und unter Cloud Billing Support.

Nächste Schritte

Individuelles Angebot einholen

Mit den „Pay as you go“-Preisen von Google Cloud bezahlen Sie nur für die Dienste, die Sie nutzen. Wenden Sie sich an unser Vertriebsteam, wenn Sie ein individuelles Angebot für Ihr Unternehmen erhalten möchten.
Vertrieb kontaktieren