TRUSTED CARE · GOOGLE CLOUD

Google Cloud Healthcare — a controlled healthcare data plane

separates the Trusted Care control plane from the Google Cloud healthcare data plane. Any production deployment depends on approved tenant, region, contract and configuration.

Planned architecture · Configuration dependent

Role in the Trusted Care architecture

Cloud Healthcare API is presented as a configurable healthcare data plane, not as an AI model and not as an assumed production backend for every deployment.

TRUSTED CARE CONTROL PLANETenant · identity · consent · authorization · evidence

INTEGRATION GATEWAYMapping · validation · correlation · retry · idempotency

GOOGLE CLOUD HEALTHCARE APIDataset · FHIR R4 Store · HL7v2 Store · DICOM Store

EVENT / ANALYTICSPub/Sub · BigQuery export · downstream AI

Data plane and control plane

Data plane and control plane
Layer	Responsibility	status
Trusted Care	Tenant, user, VNeID/RAR, consent, workflow, evidence and audit context.	Product architecture
Integration Gateway	Identity/resource/message mapping, validation, correlation ID, retry, idempotency, dead-letter and replay.	Configuration dependent
Cloud Healthcare API	FHIR, HL7v2 and DICOM/DICOMweb storage and exchange; Pub/Sub notifications; configurable de-identification.	Planned architecture
Google Cloud IAM / Logging	Access control and activity logging for Google Cloud resources according to project configuration.	Customer/Google configuration
Analytics / AI	BigQuery export or event pipelines for analytics and downstream AI; clinical decisions retain a human-review boundary.	Configuration dependent

FHIR · HL7v2 · DICOM flows

FHIR R4

Resource transaction

Patient, Encounter, Observation and DiagnosticReport resources are mapped with identity and consent context, then validated before read/write operations.

HL7v2

Message ingestion

An MLLP adapter remains an integration boundary; messages are received, validated, submitted to an HL7v2 store and handled with ACK/NACK logic.

DICOMWEB

Imaging flow

A DICOM store exposes DICOMweb operations while patient/study mapping, authorization and provenance remain deployment responsibilities.

Events, analytics and downstream AI

Store change
Pub/Sub notification
Subscriber / event processor
Validation + policy
Analytics / AI pipeline
Human review
Decision + evidence

FHIR notifications may contain personal information depending on configuration. Topic/subscription permissions and data minimization must therefore be designed explicitly.

De-identification and sensitive data

Important boundary: Google states that de-identification uses rules and heuristics and is not guaranteed to meet any specific legal, regulatory or compliance requirement by itself. The deployment team must evaluate configuration and output for the intended use.

Deployment responsibility split

Deployment responsibility split
Party	Typical responsibility
Mobile-ID / Trusted Care	Applications, tenant model, workflows, integration, consent context, audit/evidence and agreed mappings.
Healthcare organization	Processing purpose, project/location choice, user access, data policy, acceptance and operations.
Google Cloud	Cloud Healthcare API and related Google Cloud services under the applicable account configuration and terms.
HIS/LIS/PACS partner	Source messages/resources/images, transport adapters, mapping and source-system exception handling.

V19 evidence refresh · 23 Sep 2026

Verified Google Cloud Healthcare boundaries

These points reflect current Google Cloud documentation and refine the planned architecture without claiming a production deployment.

Store and event model

Cloud Healthcare API datasets can contain FHIR, HL7v2 and DICOM stores. Store changes can publish Pub/Sub notifications; subscribers and downstream processing remain deployment-specific.

Status: Planned architecture · Configuration dependent

De-identification boundary

De-identification creates transformed copies for supported FHIR/DICOM flows and is not, by itself, a guarantee of legal or regulatory compliance. Output and configuration require deployment review.

Status: GOOGLE DOCUMENTATION VERIFIED · PRODUCT USE Configuration dependent

Location and sensitive events

Source and destination stores used by de-identification must be in the same Google Cloud location. FHIR Pub/Sub payloads can contain personal information depending on configuration, so minimization and IAM are explicit design responsibilities.

Evidence reviewed · 23 Sep 2026

Official references: Cloud Healthcare API data stores, Pub/Sub notifications and de-identification documentation. External references are informational only; the core site remains fully offline-capable.