[[["易于理解","easyToUnderstand","thumb-up"],["解决了我的问题","solvedMyProblem","thumb-up"],["其他","otherUp","thumb-up"]],[["很难理解","hardToUnderstand","thumb-down"],["信息或示例代码不正确","incorrectInformationOrSampleCode","thumb-down"],["没有我需要的信息/示例","missingTheInformationSamplesINeed","thumb-down"],["翻译问题","translationIssue","thumb-down"],["其他","otherDown","thumb-down"]],["最后更新时间 (UTC)：2025-09-03。"],[[["\u003cp\u003eThe Cloud Healthcare API uses a REST API to access and manage healthcare data, identifying data stores through a Google Cloud project, location, dataset ID, data store type, and data store ID.\u003c/p\u003e\n"],["\u003cp\u003eAdministrative operations for datasets and data stores, such as creating, reading, updating, and deleting, are consistent with most Google Cloud APIs.\u003c/p\u003e\n"],["\u003cp\u003eResource names within the Cloud Healthcare API consist of a project ID and location, and can extend to include a dataset, data store, and child resources.\u003c/p\u003e\n"],["\u003cp\u003eModality-specific operations require a resource name to identify the data store, along with a modality path to specify the data, adhering to standards like FHIR or DICOMweb.\u003c/p\u003e\n"],["\u003cp\u003eThe format of the path to retrieve an HL7v2 store within a project is represented as such: /projects/\u003ccode\u003ePROJECT_ID\u003c/code\u003e/locations/\u003ccode\u003eLOCATION\u003c/code\u003e/datasets/\u003ccode\u003eDATASET_ID\u003c/code\u003e/hl7V2Stores/\u003ccode\u003eDATA_STORE_ID\u003c/code\u003e.\u003c/p\u003e\n"]]],[],null,["# API structure\n\nThis page describes the structure of Cloud Healthcare API paths and operations\nand how they can be used to access and manage data.\n\nOverview\n--------\n\nHealthcare data in datasets and data stores can be accessed and managed using a\nREST API that identifies each data store using:\n\n- A Google Cloud project\n- A Google Cloud location\n- The dataset ID\n- The data store type\n- The data store ID\n\nThe API also implements modality-specific\nstandards for access that are consistent with industry standards for that\nmodality.\n\nAdministrative operations\n-------------------------\n\nAdministrative operations are available for datasets and all data stores. They\nprimarily consist of creating, reading, updating, and deleting (CRUD) datasets\nand data stores. Administrative operations are consistent with most\nGoogle Cloud (Google Cloud) APIs and do not require any adherence\nto specific modality standards.\n\nExamples of administrative operations include:\n\n- Creating, deleting, getting, listing, and patching datasets and data stores\n- Setting, getting, and testing IAM permissions\n\nResource names\n--------------\n\nA resource name consists of, at minimum, a project ID and a location. It can\nextend to include a dataset, data store, and any of a data store's child\nresources.\n\nThe format for a resource name for a data store that resides within a\nCloud Healthcare API dataset looks like this:\n\n`/projects/`\u003cvar translate=\"no\"\u003ePROJECT_ID\u003c/var\u003e`/locations/`\u003cvar translate=\"no\"\u003eLOCATION\u003c/var\u003e`/datasets/`\u003cvar translate=\"no\"\u003eDATASET_ID\u003c/var\u003e`/`\u003cvar translate=\"no\"\u003eDATA_STORE_TYPE\u003c/var\u003e`/`\u003cvar translate=\"no\"\u003eDATA_STORE_ID\u003c/var\u003e\n\nFor example, the resource name for an HL7v2 store called `clinical-store1` looks\nlike this:\n\n`/projects/my-project/locations/us-central1/datasets/my-dataset/hl7V2Stores/clinical-store1`\n\nThis resource name shows a project called `my-project` in the\n`us-central1` region. The project contains a dataset called `my-dataset`, and\nthe dataset contains an HL7v2 store called `clinical-store1`.\n\nOperations on a location, dataset, data store, or any of a data store's child\nresources all require that a resource name is provided either in\nthe REST path or the gRPC request.\n\nModality paths for modality-specific operations\n-----------------------------------------------\n\nOperations that access data in a modality-specific data store use a request path\nthat consists of two pieces: the resource name (for identifying the data store\nto access), and a modality path (for identifying the actual data to retrieve).\n\n### FHIR resource modality paths\n\nFor example, the full request path for reading a specific FHIR Patient\nresource using the patient's ID might look like the following:\n\n\u003cvar translate=\"no\"\u003eRESOURCE_NAME\u003c/var\u003e`/resources/Patient/`\u003cvar translate=\"no\"\u003ePATIENT_ID\u003c/var\u003e\n\nwith `/Patient/`\u003cvar translate=\"no\"\u003ePATIENT_ID\u003c/var\u003e being the modality path\n(structured according to the FHIR standard) for the Patient resource whose\nidentifier is specified by \u003cvar translate=\"no\"\u003ePATIENT_ID\u003c/var\u003e.\n\n### DICOMweb modality paths\n\nDICOMweb requests to retrieve all studies for a given patient would look\nlike this:\n\n\u003cvar translate=\"no\"\u003eRESOURCE_NAME\u003c/var\u003e`/dicomWeb/studies?PatientName=`\u003cvar translate=\"no\"\u003ePATIENT_NAME\u003c/var\u003e\n\nAs another example, a request to retrieve all instances in a given study\nand series would look like this:\n\n\u003cvar translate=\"no\"\u003eRESOURCE_NAME\u003c/var\u003e`/dicomWeb/studies/`\u003cvar translate=\"no\"\u003eSTUDY_UID\u003c/var\u003e`/series/`\u003cvar translate=\"no\"\u003eSERIES_UID\u003c/var\u003e`/instances`\n\nA request to retrieve an instance would look like this:\n\n\u003cvar translate=\"no\"\u003eRESOURCE_NAME\u003c/var\u003e`/dicomWeb/studies/`\u003cvar translate=\"no\"\u003eSTUDY_UID\u003c/var\u003e`/series/`\u003cvar translate=\"no\"\u003eSERIES_UID\u003c/var\u003e`/instances/`\u003cvar translate=\"no\"\u003eINSTANCE_UID\u003c/var\u003e\n\nIn all of these examples, the modality path specification is consistent with\nthe DICOMweb standard path structure."]]
