Google Cloud Healthcare API
Browse all Google APIs38
AI ReadinessNon-Ready (F)38/100
Official vendor OpenAPI document · agent-readyHealthcareEhr 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://jentic.com/install.sh?src=apis&api=%2Fapis%2Fgoogleapis.com%2Fcloud-healthcare" | sh2
Step 2: Agent machine
# On the machine where your agent runs (keep this separate from the instance):
curl -fsSL "https://jentic.com/install.sh?src=apis&api=%2Fapis%2Fgoogleapis.com%2Fcloud-healthcare" | 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
Jentic AI Readiness Score
This API is usable in Jentic One now. Its AI-readiness score against Jentic's framework shows where it stands today and where improvements would make it even easier for agents to use.
C
Cloud Healthcare API
- Non-Ready (F)38/100
36
Foundational Compliance56
Developer Experience & Jentic Compatibility18
AI-Readiness & Agent Experience90
Agent Usability63
Security68
AI DiscoverabilityPowered by JenticScoring Framework 1.0.0 | Scoring Engine 0.4.0
Show dimension breakdown
36
Foundational Compliance
Base layer of spec validity and structural soundness.
Grade: FSignals: 4
44%
Lint Results
Aggregated quality score from linter diagnostics, weighted by severity.
100%
Resolution Completeness
Percentage of `$ref` references that resolve successfully.
0%
Specification Validity
Checks whether the API description parses successfully and conforms to its declared specification (e.g., OpenAPI).
0%
Structural Integrity
Structural correctness score based on schema issues using logarithmic dampening.
56
Developer Experience & Jentic Compatibility
Clarity, completeness, and ingestion readiness for developers and tooling.
Grade: CSignals: 4
0%
Example Density
How richly the API is illustrated with examples.
100%
Example Validity
Percentage of examples that conform to their schemas.
25%
Response Coverage
Percentage of operations with complete response definitions (success, client error, server error).
100%
Tooling Readiness
Health of API ingestion, bundling, and resolution within Jentic pipelines.
18
AI-Readiness & Agent Experience
Semantic breadth, depth, and agent comprehension for AI systems.
Grade: FSignals: 4
73%
Description Coverage
Coverage of descriptions across API elements.
0%
Error Standardization
Coverage of RFC 9457 Problem Details for error responses.
0%
OperationId Quality
Coverage, uniqueness, and casing consistency of operationIds for AI inference.
0%
Summary Coverage
Coverage of summaries across operations/tags/info.
90
Agent Usability
Functional utility, complexity comfort, and AI orchestration readiness.
Grade: A+Signals: 1
90%
Complexity Comfort
Agent comfort level based on API operational and structural complexity.
63
Security
Trust, risk posture, and security compliance.
Grade: B-Signals: 1
62%
Authentication Strength
Average quality of security schemes based on authentication method strength (weakest link for OAuth2).
68
AI Discoverability
Findability, semantic richness, and reasoning readiness.
Grade: B+Signals: 1
68%
Descriptive Richness
Clarity and depth of descriptions across API elements.
Score it yourself
Every API in the directory is allowlisted, so you can re-score it with no key required.
npx @jentic/api-scorecard-cli score <openapi-url>Why Jentic?
What agents get from Jentic-routed access to this vendor.
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 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.
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.
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.
GET STARTED