canonical: https://jentic.com/apis/googleapis.com/cloud-healthcare

# Google Cloud Healthcare API

The Cloud Healthcare API stores and serves clinical data on Google Cloud using the standards healthcare systems already speak: FHIR R4/STU3/DSTU2 for structured records, HL7v2 for messaging, and DICOM for imaging. Datasets and stores act as logical containers, and operations cover read, write, search, bulk export, de-identification, consent management, and conformance to FHIR ImplementationGuides. The API also includes a consent service for tracking patient authorisations and an analytics export path that streams resources to BigQuery for population queries. It is the managed substrate behind many production EHR integrations, AI medical-imaging pipelines, and HIPAA-aligned research workloads on Google Cloud.

## For AI agents

Store, search, export, and de-identify FHIR, HL7v2, and DICOM clinical data on Google Cloud, with consent enforcement and BigQuery analytics export.

## Scope

Does not handle clinical decision support, billing/coding, or patient-facing scheduling - use for storing and serving FHIR, HL7v2, DICOM, and consent data only.

## Capabilities

- Read, search, and update FHIR R4 resources such as Patient, Observation, and Encounter inside a FHIR store
- Run $everything to retrieve a complete patient record across linked FHIR resources
- Export FHIR resources in bulk to Cloud Storage or BigQuery for analytics and reporting
- Ingest, parse, and route HL7v2 messages between source and destination healthcare systems
- Store and serve DICOM imaging studies with WADO and STOW endpoints for viewer integration
- Apply de-identification transformations to remove PHI from datasets before sharing
- Enforce patient consent on data access via the consent store and evaluateUserConsents operation

## Use cases

### FHIR Patient Record API for Clinical Apps

Clinical software teams use the Cloud Healthcare FHIR store as the system of record behind patient-facing apps. Apps read and write Patient, Observation, Encounter, and MedicationRequest resources through standard FHIR R4 verbs and use $everything to assemble a longitudinal patient summary on demand. Cloud Healthcare handles versioning, search indexing, and audit logging, so app teams ship new clinical workflows without operating a FHIR server.

Example prompt: For patient with identifier MRN-12345 in dataset projects/p/locations/us-central1/datasets/d/fhirStores/s, call GET /v1/{+name}/$everything and summarise the most recent Encounter and three latest Observations.

### HL7v2 Integration Bridge

Hospital integration teams replace point-to-point HL7v2 interfaces with a Cloud Healthcare HL7v2 store fronted by Pub/Sub. Source systems POST ADT, ORU, and ORM messages into the store; downstream consumers subscribe to parsed message events and translate into FHIR or warehouse formats. The API preserves the original HL7v2 segment structure and adds parsed JSON for easy routing.

Example prompt: Ingest the supplied ADT^A04 HL7v2 message into hl7V2Stores/admissions, then list the parsed PID and PV1 segments returned by the API.

### DICOM Imaging Backbone

Radiology platforms store imaging studies in a Cloud Healthcare DICOM store and serve them to OHIF and other web viewers via the WADO-RS endpoints. STOW-RS handles ingestion from modality routers and PACS gateways. Combined with de-identification, the same store can power both clinical viewing and AI-imaging research without duplicating data.

Example prompt: List DICOM studies for patientID 99887766 in dicomStores/imaging, retrieve the latest study's instance metadata, and return the StudyInstanceUID.

### AI Agent Clinical Data Retrieval

An AI clinical assistant uses Jentic to query Cloud Healthcare FHIR stores under a service-account credential scoped to read-only access. The agent fetches relevant Observations and MedicationRequests for a given Patient, runs $everything for full context, and respects the consent store before surfacing data. Jentic isolates the OAuth credential so the agent never holds raw service-account JSON.

Example prompt: For patient resource Patient/abc123 in fhirStores/clinical, first call /$consent-enforcement-status, then if access is permitted call /$everything and return a structured summary of recent vitals and active medications.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| GET | /v1/{+name}/$everything | Retrieve all resources linked to a FHIR Patient |
| GET | /v1/{+name}/$export | Bulk export a FHIR store to Cloud Storage or BigQuery |
| POST | /v1/{+consentStore}:checkDataAccess | Check whether a user is consented to access patient data |
| POST | /v1/{+consentStore}:evaluateUserConsents | Evaluate consent decisions for a user across patients |
| POST | /v1/{+consentStore}:queryAccessibleData | Query the data accessible to a user under current consents |
| DELETE | /v1/{+name}/$purge | Purge historical versions of a FHIR resource |
| GET | /v1/{+name}/_history | Read the version history of a FHIR resource |

## Key resources

- **Datasets** — Top-level containers grouping FHIR, HL7v2, DICOM, and consent stores by region
- **FHIR stores** — Read, write, search, and bulk-export FHIR R4/STU3/DSTU2 resources
- **HL7v2 stores** — Ingest and route HL7v2 messages with parsed segments and Pub/Sub notifications
- **DICOM stores** — Store and serve imaging studies via WADO-RS, QIDO-RS, and STOW-RS
- **Consent stores** — Track patient consent, evaluate user access, and enforce policies on data retrieval

## Why Jentic

- **Setup:** Wiring the Cloud Healthcare API by hand means configuring service-account OAuth2, narrowing to the cloud-healthcare scope, refreshing tokens, and learning its long FHIR, HL7v2, DICOM, and consent-store resource paths yourself. Through Jentic you install once, import the Cloud Healthcare API from the API Directory, store the credential once, and your agent calls it.
- **Permission scoping:** Resource ids travel in the URL path (/v1/{name}/$everything, /v1/{consentStore}:checkDataAccess), so a rule can pin your agent to one FHIR or consent store: it serves and evaluates data for that store and nothing else. You choose the operations it may call, so destructive ones like the $purge delete are not included unless you add them.
- **Credential handling:** Your Cloud Healthcare service-account credential is stored once, encrypted, by your own Jentic One instance and injected at execution time as a short-lived cloud-healthcare access token. The private key never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'export fhir store to bigquery' or 'get everything for a patient', and Jentic returns the matching operation with its input schema so the agent calls the right endpoint without browsing the long resource-path conventions.

## Related APIs

- **Identity and Access Management (IAM) API** — IAM grants the role bindings (e.g. healthcareFhirResourceReader) that Cloud Healthcare evaluates on each call.
- **Cloud KMS API** — Provides customer-managed encryption keys (CMEK) used by Cloud Healthcare datasets.
- **Pub/Sub API** — Cloud Healthcare emits notifications about HL7v2 and FHIR changes to Pub/Sub topics.

## FAQ

### What authentication does the Cloud Healthcare API use?

Google OAuth 2.0 with the cloud-healthcare and cloud-platform scopes, typically via a service account with healthcareFhirResourceReader, healthcareFhirResourceEditor, or store-admin IAM roles. Through Jentic the service-account JSON is encrypted in the vault and exchanged for a short-lived access token at execution.

### Can I export a FHIR store to BigQuery for analytics?

Yes. Call GET /v1/{+name}/$export on the FHIR store with a destination configuration pointing to a BigQuery dataset. The operation runs asynchronously and writes one BigQuery table per FHIR resource type.

### What are the rate limits for the Cloud Healthcare API?

Quotas are per project and per region. FHIR read and write operations default to thousands of QPS but vary by store size and resource type; HL7v2 ingest and DICOM STOW have separate quotas. Exact limits are visible in Cloud Console quotas.

### How do I retrieve a complete patient record through Jentic?

Search Jentic with 'fhir everything for a patient', load the GET /v1/{+name}/$everything operation, and execute with name set to projects/{p}/locations/{loc}/datasets/{d}/fhirStores/{s}/fhir/Patient/{patientId}. Jentic handles auth and returns the bundle.

### How does consent enforcement work?

Consent stores track patient authorisations as Consent resources. Use POST /v1/{+consentStore}:checkDataAccess to verify a user can access a specific patient's data, or :evaluateUserConsents to compute access decisions across patients before returning clinical data to a caller.

### Is the Cloud Healthcare API HIPAA-eligible?

Yes. Cloud Healthcare is included in Google Cloud's HIPAA-covered services list and can be used under a Business Associate Agreement (BAA) with Google Cloud.

### Can I limit what my agent is allowed to do with the Cloud Healthcare API?

Yes. Jentic One runs in your own self-hosted instance, so your own rules decide which Cloud Healthcare operations and credentials the agent may use. Because resource ids travel in the URL path, such as /v1/{name}/$everything and /v1/{consentStore}:checkDataAccess, you can pin the agent to a single FHIR, DICOM, or consent store so it only reads and evaluates data for that store. You also choose the exact operations it may call, so destructive ones like the $purge delete are excluded unless you add them.