配额和限制

出于多种原因，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。
  • 存储事务或检索事务：操作超过 30 分钟时发生超时。
  • 搜索事务方法的偏移上限为 1,000,000，研究/系列的上限为 5,000，实例的上限为 50,000
  • 去标识化：如果涉及像素隐去，去标识化无法处理超过 1 GB 的 DICOM 文件。如果像素数据已压缩，其未压缩大小不得超过 2 GB。您可以使用 DICOM 标记按如下方式计算未压缩大小：NumberOfFrames * Rows * Columns * SamplesPerPixel * BitsAllocated / 8。
  • 提取的 DICOM 文件限制为每个标记 2 GB。此限制包括原生格式编码的 PixelData。
  • 对 DICOM 数据进行转码时，文件大小上限为 1 GB，帧大小上限为 150 MB。
  • dicomStores.import：文件大小上限为 100 GB。
FHIR
HL7v2 10 MB

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

FHIR executeBundle 大小限制

您可以使用 fhir.executeBundle 方法在单个 API 请求中执行多项 FHIR 操作。操作数量取决于批处理或事务软件包中的条目数量。与针对每个操作进行单独的 API 调用相比，这种方法更高效。

fhir.executeBundle 请求的处理时间会随着软件包中条目的数量而增加。资源争用（例如，在许多事务软件包中并行更新同一资源）等因素也可能会影响性能。如需了解资源争用可能发生的情况以及如何防止其导致错误的示例，请参阅数据吞吐量最佳实践。较大的软件包（尤其是超过 1,000 个条目的软件包）可能会超时并无法完成。

为确保成功且及时处理，请在发送 fhir.executeBundle 请求时考虑以下限制：

  • 事务软件包：系统会立即拒绝超过 4,500 条条目的软件包，以防止超时。事务软件包要求所有操作都成功。
  • 批量软件包：没有具体的条目数限制，但软件包越大，超时风险就越高。超时可能会导致部分成功，即仅处理了部分条目。

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

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

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

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

如需了解使用导入操作导入 HL7v2 消息的详细步骤，请参阅从 Cloud Storage 导入 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 在特定区域或多区域位置的配额。

如需在单个区域申请增加配额，请在配额增加请求中指定相应区域。

如需在多区域位置申请增加配额，请执行以下操作：

  • 如需在 us 多区域增加配额，请在请求中注明配额适用于“美国元区域”。
  • 如需在 eu 多区域增加配额，请在请求中注明配额适用于“欧盟元区域”。

配额限制

以下部分介绍了与 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 操作时，发送到 Cloud Healthcare API 的结构化字节，采用 DICOM 标记和相关元数据的形式。
dicom_store_ops 每个区域每分钟的 DICOM 存储区操作数 对 DICOM 存储区（而非 DICOM 数据）的操作。包括以下方法：
dicom_store_lro_ops 每个区域每分钟的 DICOM 存储区长时间运行的操作数 对 DICOM 存储区（而非 DICOM 数据）执行的会返回长时间运行操作的操作。包括以下方法：
dicom_structured_storage_operations_bytes 针对长时间运行的操作的结构化 DICOM 存储空间入站流量（以字节为单位，每个区域每分钟） 在处理 dicom_store_lro_ops 操作时，发送到 Cloud Healthcare API 的结构化字节，采用 DICOM 标记和相关元数据的形式。

FHIR 配额

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

指标名称 显示名称 说明
fhir_read_ops 每个区域每分钟的 FHIR 读取操作数 以单位为单位，其中 1 个单位是指对单个 FHIR 资源发出的 1 次读取请求。

包括以下方法：

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

包括以下方法：

v1beta1： v1
fhir_search_ops 每个区域每分钟的 FHIR 搜索操作数 以单位衡量，其中一个单位是针对 FHIR 资源类型的搜索请求，除非使用 _include，否则搜索不需要解析引用。例如，Observation?subject:Patient.identifier=system|value 搜索会消耗两个 fhir_search_ops 配额单元，因为它需要进行两次搜索，一次是对 Observation 资源的搜索，一次是对 Patient 资源的搜索，并使用 subject 作为参考。

包括以下方法：

v1beta1： v1
fhir_storage_egress_bytes 每个区域每分钟的 FHIR 存储出站流量（以字节为单位） 以单位为单位，其中一个单位为 Cloud Healthcare API 在处理 fhir_read_ops、fhir_write_ops 和 fhir_search_ops 操作时从存储空间读取的字节数。
fhir_storage_bytes 每个区域每分钟的 FHIR 存储空间入站流量（以字节为单位） 处理 fhir_write_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 配额单元。系统会执行两项搜索操作，分别对“Observation”资源和“Patient”资源执行一次，并使用 subject 作为参考。

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

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

执行软件包配额消耗

如需发送执行软件包请求，无论请求消耗的配额是多少，您的Google Cloud 项目都必须至少有以下每个配额可用的一个配额单位：

  • fhir_read_ops
  • fhir_write_ops
  • fhir_search_ops

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

例如，如果您发送一个 fhir.executeBundle 请求，其中包含包含 100 个 POST 操作的事务软件包，每个操作都会创建一个 FHIR 资源，Cloud Healthcare API 会先验证 fhir_read_ops、fhir_write_ops 和 fhir_search_ops 至少有 1 个配额单元可用。如果验证成功，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 是否至少有 1 个配额单元可用。如果验证成功，Cloud Healthcare API 会执行软件包。系统会消耗以下配额单元：

  • 一个 fhir_write_ops，用于创建新的 Observation 资源。
  • 一个 fhir_search_ops，因为系统会对 Patient?identifier=a1b2c3d4e5 引用执行单个搜索操作。

最佳做法

如需了解有关管理 Cloud Healthcare API 配额的最佳实践，请参阅配额管理最佳实践。