配额和限制

出于多种原因，Cloud Healthcare API 会对资源用量施加限制。例如，配额可保护 Google Cloud 用户群体，避免出现意外的使用量激增。Google Cloud 还提供免费试用配额，为刚刚开始使用 Google Cloud（包括 Cloud Healthcare API）的用户提供一定用量。

Cloud Healthcare API 的配额按项目基于单区域或多区域实施。如果一个区域中的配额用尽，并不会影响您在其他区域中使用 Cloud Healthcare API。

查看配额和用量

配额是对存储量的限制（也称为入站流量限制）以及对操作的限制。

如需查看您的项目中资源的可用配额，请进入 Google Cloud 控制台中的配额页面。

如需仅显示 Cloud Healthcare API 配额，请在过滤表下拉列表中选择服务，然后选择 Cloud Healthcare API。

并非所有项目的配额都完全相同。随着您的 Cloud Healthcare API 使用量逐步增加，您的配额可能会相应地增加。如果您预计自己的用量即将显著增加，可以在 Google Cloud 控制台的配额页面中主动申请调整配额。申请增加配额无需付费。只有当您使用了更多的资源时，费用才会增加。

资源限制

Cloud Healthcare API 会限制请求内容的大小，例如 DICOM 请求中 X 光片的大小。您不能申请更改资源限制。但在某些情况下，您可以使用导入操作来导入大小超过资源限制的内容。

以下资源限制适用于 Cloud Healthcare API（可能会更改）。

模态 请求大小限制
DICOM
  • 实体店交易：无限制。所有其他方法 10 MB。
  • 存储事务或检索事务：操作超过一小时时发生超时。
  • 搜索事务方法的偏移上限为 1,000,000，研究/系列的上限为 5,000，实例的上限为 50,000
  • 去标识化：如果涉及像素隐去，去标识化无法处理大于 1 GB 的 DICOM 文件。
  • 提取的 DICOM 文件限制为每个标记 2 GB。此限制包括原生格式编码的 PixelData。
  • 对 DICOM 数据进行转码时，文件大小上限为 1 GB，帧大小上限为 150 MB。
  • dicomStores.import：文件大小上限为 20 GB。
FHIR executeBundle：50 MB，其他所有方法 10 MB
HL7v2 10 MB

如果您尝试处理大小超过关联资源限制的内容，则会引发错误。

对大小超过资源限制的内容使用导入操作

导入操作便于您处理大小超过关联资源限制的内容。导入操作中的内容大小仅受 Google Cloud 的单个对象存储大小上限 (5 TB) 的限制。导入操作受决定此类操作所需时长的存储配额的限制。例如，如果要在 DICOM 存储区中存储许多 DICOM 实例，并且不希望受到请求大小限制，则可以使用导入操作。您可以将实例上传到 Cloud Storage 存储桶中，然后再将其导入 DICOM 存储区，而不是使用可用的存储事务方法上传实例。

如需了解使用导入操作导入 DICOM 数据的详细步骤，请参阅导入和导出 DICOM 数据。

如需了解使用导入操作导入 FHIR 资源的详细步骤，请参阅导入和导出 FHIR 资源。

如需了解使用导入操作导入 HL7v2 消息的详细步骤，请参阅导入 HL7v2 消息。

申请更改配额

如要申请更改配额，您必须具有 serviceusage.quotas.update 权限。默认情况下，以下预定义角色包含此权限：Owner、Editor 和 Quota Administrator。

  1. 转到配额页面。

    转到“配额”

  2. 在配额页面中，选择要更改的配额。如果您希望仅显示 Cloud Healthcare API 配额，请从过滤表下拉列表中选择服务，再选择 Cloud Healthcare API。

  3. 勾选要修改的配额对应的复选框。

  4. 点击页面顶部的修改配额按钮。

  5. 填写表单，然后点击下一步。

  6. 输入您要申请的限额，然后点击下一步。

  7. 点击提交请求。

默认情况下，减少配额的申请会被拒绝。如果您希望减少配额，请回复支持电子邮件并说明您的要求。支持代表将回复您的申请。

您会在提交申请后的 24 至 48 小时内收到 Cloud Healthcare API 团队的回复。

请提前几天安排申请更多资源，以确保我们有足够的时间来处理您的申请。

配额限制

以下部分介绍与 Cloud Healthcare API 数据存储区和操作相关的配额。

DICOM 配额

下表介绍了与 DICOM 存储区和 DICOM 操作相关的 Cloud Healthcare API 配额。

指标名称 显示名称 说明
dicomweb_ops 每个区域每分钟的 DICOMweb 操作数 包括以下方法：
  • v1beta1 和 v1 中的所有 projects.locations.datasets.dicomStores.studies 方法
  • v1beta1 和 v1 中的所有 projects.locations.datasets.dicomStores.studies.series 方法
  • v1beta1 和 v1 中的所有 projects.locations.datasets.dicomStores.studies.series.instances 方法
  • v1beta1 和 v1 中的所有 projects.locations.datasets.dicomStores.studies.series.instances.frames 方法
dicom_structured_storage_bytes 每个区域的结构化 DICOM 存储入站流量（以每分钟字节数计） 在处理 dicomweb_ops 操作时，以 DICOM 标记和相关元数据的形式发送到 Cloud Healthcare API 的结构化字节。
dicom_store_ops 每个区域每分钟的 DICOM 存储操作数 对 DICOM 存储区的操作（而非 DICOM 数据）。包括以下方法：
dicom_store_lro_ops 每个区域每分钟的 DICOM 存储区长时间运行的操作数 针对 DICOM 存储区的操作（非 DICOM 数据），会返回长时间运行的操作。包括以下方法：
dicom_structured_storage_operations_bytes 长时间运行的操作的结构化 DICOM 存储入站流量（每个区域每分钟字节数） 在处理 dicom_store_lro_ops 操作时，以 DICOM 标记和相关元数据的形式发送到 Cloud Healthcare API 的结构化字节。

FHIR 配额

下表介绍了与 FHIR 存储区和 FHIR 操作相关的 Cloud Healthcare API 配额。

指标名称 显示名称 说明
fhir_ops 每个区域每分钟的 FHIR 操作数 以单位为单位，其中每个单位是对 v1beta1 和 v1 中任何 projects.locations.datasets.fhirStores.fhir 方法的一个请求。
fhir_read_ops 每个区域每分钟的 FHIR 读取操作次数 以单位为单位进行衡量，一个单位是指针对单个 FHIR 资源发出的一个读取请求。

包含以下方法：

v1beta1:： v1:：
fhir_write_ops 每个区域每分钟的 FHIR 写入操作次数 以单位为单位，其中一个单位是针对单个 FHIR 资源的一个创建、更新或删除请求。

包含以下方法：

v1beta1:： v1:：
fhir_search_ops 每个区域每分钟的 FHIR 搜索操作次数 以单位为单位，其中 1 个单位是对 FHIR 资源类型的搜索请求，且搜索不需要解析引用，但使用 _include 时除外。例如，Observation?subject:Patient.identifier=system|value 搜索会使用两个 fhir_search_ops 配额单元，因为它需要两次搜索（一次针对观察资源，一次针对患者资源，并以 subject 作为参考）。

包含以下方法：

v1beta1:： v1:：
fhir_storage_egress_bytes FHIR 存储出站流量（每个区域每分钟字节数） 以单位为单位，其中一个单位是在处理 fhir_read_ops、fhir_write_ops 和 fhir_search_ops 操作时从存储 Cloud Healthcare API 读取的 1 个字节。
fhir_storage_bytes FHIR 存储入站流量（每个区域每分钟字节数） 处理 fhir_ops 操作时发送到 Cloud Healthcare API 的字节数。
fhir_store_ops 每个区域每分钟的 FHIR 存储区操作数 对 FHIR 存储区的操作，而不是对 FHIR 数据的操作。

包含以下方法：
fhir_store_lro_ops 每个区域每分钟的 FHIR 存储区长时间运行的操作数 针对 FHIR 存储区（非 FHIR 数据）的操作返回长时间运行的操作。

包含以下方法：
fhir_storage_operations_bytes 长时间运行的操作的 FHIR 存储入站流量（每个区域每分钟字节数） 处理 fhir_store_lro_ops 操作时发送到 Cloud Healthcare API 的字节数。

一个请求可能会消耗多个配额单元。例如，使用 Observation?subject:Patient.identifier=system|value 作为搜索参数的 GET 搜索请求会消耗两个 fhir_search_ops 配额单元。系统会执行两项搜索操作，一项针对观察资源，另一次针对患者资源，并使用 subject 作为引用。

如果使用 Observation?status=canceled 作为搜索条件的条件删除请求会搜索并删除 6 个观察资源，则系统会消耗以下配额单元：

  • 一个 fhir_search_ops 配额单元，因为 GET 搜索请求仅对一种类型的 FHIR 资源（观察资源）执行。该请求会返回与搜索条件匹配的所有观察资源。
  • 六 fhir_write_ops 个配额单元，因为对已删除的观察资源总共执行了六次 DELETE 操作。

执行软件包配额消耗

如需发送执行软件包请求，无论该请求消耗了多少配额，您的 Google Cloud 项目必须至少为以下每项配额提供一个单元：

  • fhir_read_ops
  • fhir_write_ops
  • fhir_search_ops

如果这些配额不可用，执行软件包请求将会失败。

例如，如果您使用包含 100 个 POST 操作的事务包发送 fhir.executeBundle 请求，且每个操作都会创建一个 FHIR 资源，则 Cloud Healthcare API 首先会验证 fhir_read_ops、fhir_write_ops 和 fhir_search_ops 是否至少有一个配额单元可用。如果验证成功，Cloud Healthcare API 将执行捆绑包并创建 FHIR 资源，这些资源共使用 100 个 fhir_write_ops 配额单元。

请考虑以下事务软件包，它将使用条件引用在 reference 存在时创建观察资源：

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

当您执行软件包时，Cloud Healthcare API 首先会验证是否至少有一个配额单元可用于 fhir_read_ops、fhir_write_ops 和 fhir_search_ops。如果验证成功，Cloud Healthcare API 会执行捆绑包。会消耗以下配额单元：

  • 一个 fhir_write_ops，用于创建新的观察资源。
  • 一个 fhir_search_ops，因为对 Patient?identifier=a1b2c3d4e5 引用执行一次搜索操作。