This page describes the structure of Cloud Healthcare API paths and operations and how they can be used to access and manage data.
Healthcare data in datasets and data stores can be accessed and managed using a REST API that identifies each data store using a project, location, dataset, data store type, and data store name. The API also implements modality-specific standards for access that are consistent with industry standards for that modality.
Administrative operations are available for datasets and all data stores. They primarily comprise creating, reading, updating, and deleting (CRUD) datasets and data stores. Administrative operations are consistent with the majority of Google Cloud Platform (GCP) APIs and do not require any adherence to specific modality standards.
Examples of administrative operations include:
- Creating, deleting, getting, listing, and patching datasets and data stores
- Setting, getting, and testing IAM permissions
A resource name comprises, at minimum, a project ID and a location. It can extend to include a dataset, data store, and any of a data store's child resources.
The format for a resource name for a data store that resides within a Cloud Healthcare API dataset looks like this:
As a specific example, the resource name for an HL7v2 store called
clinical-store1 looks like this:
This resource name shows a project called
my-project in the
us-central1 region. The project contains a dataset called
the dataset contains an HL7v2 store called
Operations on a location, dataset, data store, or any of a data store's child resources all require that a resource name be provided either in the REST path or the gRPC request.
Modality paths for modality-specific operations
Operations that access data in a modality-specific data store use a request path that comprises two pieces: the resource name (for identifying the data store to be accessed), and a modality path (for identifying the actual data to be retrieved).
FHIR resource modality paths
For example, the full request path for reading a specific FHIR Patient resource using the patient’s ID might look like the following:
/Patient/PATIENT_ID being the modality path
(structured according to the FHIR standard) for the Patient resource whose
identifier is specified by
DICOMweb modality paths
DICOMweb requests to retrieve all studies for a given patient would look like this:
As another example, a request to retrieve all instances in a given study and series would look like this:
A request to retrieve a particular instance would look like this:
In all of these examples, the modality path specification is consistent with the DICOMweb standard path structure.