Google Cloud Healthcare API keeps FHIR, HL7v2, and DICOM as separate stores

A common platform is not a common clinical model

Google Cloud's architecture groups healthcare data into datasets and then uses modality-specific stores. That boundary matters. A FHIR resource, an HL7v2 message, and a DICOM object carry different structures, identifiers, vocabularies, context, update behavior, and workflow expectations. Hosting them under one service can simplify infrastructure and policy administration, but it does not turn them into one interchangeable record.

A buyer should ask which datasets and stores exist, which regions and projects contain them, what creates and updates each object, how identifiers are reconciled, and where transformations occur. The inventory should distinguish a stored source artifact from a derived resource, normalized field, index, analytic view, or application state.

Each format keeps its own interface and evidence

The official overview describes format-specific operations: FHIR APIs for resources, HL7v2 APIs for messages, and DICOMweb-oriented capabilities for imaging data. A successful write or retrieval in one store says nothing about a different store. Even within a format, an HTTP success does not show that required fields, terminology, order, provenance, acknowledgements, or clinical meaning survived an exchange.

Production evidence should retain the source event, transport and authentication result, original payload or immutable reference, transformation version, validation outcome, destination object, exception, acknowledgement, retry, and reconciliation result. Teams should be able to trace a displayed fact back through that chain without treating the managed platform as proof of semantic correctness.

Translation creates a governed responsibility

Moving information between HL7v2, FHIR, DICOM, analytics, and application workflows requires explicit mappings and policy. A mapping can drop repetition, default a value, change units, collapse an identifier, lose message order, or interpret a local code incorrectly. The owning team needs versioned mapping specifications, representative fixtures, negative cases, clinical review where appropriate, and a rollback or correction path.

The enterprise test should include complete, incomplete, duplicated, corrected, out-of-order, unknown-code, unauthorized, and version-mismatched inputs. Reviewers should see whether the platform rejected, quarantined, transformed, or accepted each case and whether the receiving workflow understood the result as intended.

Platform controls do not settle data-use authority

IAM, audit logging, encryption, and de-identification can support a governed deployment. They do not independently determine why a user or system may use a record, whether consent applies, which disclosure is permitted, whether a de-identified output is suitable for a particular purpose, or whether a clinical workflow is safe. Those decisions require the applicable organizational, contractual, privacy, security, clinical, and legal controls.

Google Cloud's product page describes platform capabilities; it does not certify a particular implementation, mapping, partner exchange, security posture, privacy conclusion, or clinical result. Interoperability leaders should preserve the useful common operating layer while keeping format stores, transformations, access decisions, conformance claims, and clinical workflows as separate evidence-bearing states.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Health Interoperability Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.