The Google Cloud Healthcare API is Google’s managed product for storing and exchanging clinical data as FHIR, DICOM, and HL7v2 stores. It is not a generic “healthcare API” explainer, and it is not a PYCAD product.
If you meant healthcare APIs in general (FHIR vs REST, why integrate) → API for healthcare. If you meant DICOMweb as a protocol → what is DICOM, not this product page. PACS as a system → PACS and DICOM.
What the product actually is
You enable the API on a Google Cloud project, create a dataset, then create one or more stores inside it. A FHIR store holds FHIR resources. A DICOM store holds DICOM studies (DICOMweb). An HL7v2 store holds v2 messages. Each store is a different contract on the same project — not one blob that magically speaks every standard.
Docs and console: cloud.google.com/healthcare, FHIR how-to, Google Cloud Console.
Standards the API stores
| Standard | Primary use | Key capabilities | Typical applications |
|---|---|---|---|
| FHIR | Exchanging healthcare information | Resource-based REST, search, bundles | EHR integration, patient portals, apps |
| DICOM | Storing and transmitting medical images | Studies / series / instances, DICOMweb | PACS workflows, radiology archives |
| HL7v2 | Messaging between hospital systems | Event-driven ADT / ORU-style segments | HIS, lab, ADT feeds into FHIR later |
FHIR is the clinical chart. DICOM is the pixels and their tags. HL7v2 is the pager that still runs the hospital bus. The product’s job is to hold each of those in a store you can query, export, and lock down — not to replace your EHR.
BigQuery and Vertex AI
Stores are not a warehouse. The usual next hop is BigQuery (export FHIR / DICOM metadata, run SQL on a population) and Vertex AI (train or call a model on that export). HIPAA alignment is a Google Cloud configuration (BAA, CMEK, IAM, audit logs) — the API does not make a project “HIPAA compliant” by existing.
That pipeline is why imaging teams care: a DICOM store can feed de-identified studies into a training job without standing up a second PACS. The protocol itself is still DICOM; this page is the Google store in front of it.
LANES, Los Angeles, July 2023
The Los Angeles Network for Enhanced Services (LANES) announced in July 2023 that it adopted the Google Cloud Healthcare API and BigQuery to move interoperability and analytics for a network that handles on the order of half a billion transactions a year across about 10 million lives. The public note is LANES’ own announcement — FHIR, HL7v2, and DICOM on the same API, aimed at CalAIM-style whole-person care. That is a named deployment, not a market-share table.
First steps: enable the API, create a FHIR store
You need a Google Cloud project and the gcloud CLI. Then: enable the API, create a dataset, create a FHIR store. After that, FHIR CRUD is ordinary REST against the store URL.
# Enable the Healthcare API
gcloud services enable healthcare.googleapis.com --project=PROJECT_ID
# Dataset (container for FHIR / DICOM / HL7v2 stores)
gcloud healthcare datasets create DATASET_ID
--location=LOCATION
--project=PROJECT_ID
# FHIR store (R4)
gcloud healthcare fhir-stores create FHIR_STORE_ID
--dataset=DATASET_ID
--location=LOCATION
--version=R4
Replace PROJECT_ID, LOCATION (for example us-central1), DATASET_ID, and FHIR_STORE_ID. The same dataset can hold a DICOM store later; do not cram images into the FHIR store. Official walkthrough: Create and manage FHIR stores.
What this is not
It is not “Google Healthcare API” as a different product — that shorter name was a title skin of this same API. It is not a generic medical-API list. PYCAD implements imaging pipelines on top of standards and cloud APIs; it is not a FHIR or EHR vendor, and it does not sell this Google product.
If the work is a viewer, a de-id pipeline, or a model on DICOM that happens to live next to a FHIR store, that is the services side. Case studies.