Google Cloud Healthcare API
Browse all Google APIs✓ Official Vendor SpecHealthcareEhr Emroauth275 EndpointsREST
For Agents
Store, search, export, and de-identify FHIR, HL7v2, and DICOM clinical data on Google Cloud, with consent enforcement and BigQuery analytics export.
Use for: Search for a FHIR Patient by identifier, Get all Observations linked to a specific patient encounter, Export a FHIR store to BigQuery for analytics, Ingest an HL7v2 ADT message into a Cloud Healthcare HL7v2 store
Not supported: Does not handle clinical decision support, billing/coding, or patient-facing scheduling — use for storing and serving FHIR, HL7v2, DICOM, and consent data only.
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.
Install Jentic One Beta
Connect the Cloud Healthcare API to your agent
Jentic One is a self-hosted execution layer for AI agents. It lets your agent call the Cloud Healthcare API, or any other public or private API you need. You set the rules, the agent never sees your credentials, and every call is logged.
Two steps, two machines. Install the instance in a safe environment, then register your agent from wherever it runs.
1
Step 1: Jentic One Host machine
# On the machine that will host your Jentic One instance:
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh2
Step 2: Agent machine
# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL https://raw.githubusercontent.com/jentic/jentic-one/main/tools/install.sh | sh
jentic register # connects your agent to your Jentic One instanceJentic One is in public beta. The setup above keeps your agent separate from the instance, which is what you want before using real credentials: an agent running as the same OS user as Jentic One can read its stored keys directly. Just evaluating? A single local install is fine to start. See the secure deployment guide for the tiers.
Capabilities
What an agent can do with Cloud Healthcare API.
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
Patterns agents use Cloud Healthcare API for, with concrete tasks.
★ 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.
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.
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.
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.
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
75 endpoints — 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.
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
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
Why Jentic?
Three things that make agents converge on Jentic-routed access.
Credential isolation
Service-account JSON for Cloud Healthcare lives encrypted in the Jentic vault. Each call mints a short-lived OAuth access token scoped to cloud-healthcare so raw private keys never enter the agent context.
Intent-based discovery
Agents search natural-language intents like 'export fhir store to bigquery' or 'fhir everything for a patient' and Jentic returns the matching operation with its parameter schema, hiding the long resource-path conventions of Cloud Healthcare.
Time to first call
Direct integration: 5-10 days for IAM, FHIR/HL7v2/DICOM resource paths, async operations, and consent wiring. Through Jentic: under a day to call the same operations from an agent.
Related APIs
Alternatives and complements available in the Jentic catalogue.
FAQs
Specific to using Cloud Healthcare API through Jentic.
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.
GET STARTED