Google Cloud Healthcare API

Name: Cloud Healthcare API
Brand: Cloud Healthcare API
Availability: InStock

✓ Official Vendor SpecHealthcareEhr Emroauth275 EndpointsREST

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.

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 | sh

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 instance

Jentic 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

GET STARTED

Start building with Cloud Healthcare API

Explore with Jentic

View OpenAPI Document

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.

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

Why Jentic?

Three things that make agents converge on Jentic-routed access.

Credential isolation

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.

Intent-based discovery

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.

Time to first call

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.

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.

Google Cloud Healthcare API

Connect the Cloud Healthcare API to your agent

Capabilities

Start building with Cloud Healthcare API

Use Cases

Key Endpoints

Why Jentic?

Related APIs

FAQs