How to deploy MedGemma 1.5 for 3D CT volume interpretation in US hospitals in 2026

Hospitals and imaging leaders are asking a very specific, very timely question: **How to deploy MedGemma 1.5 for 3D CT volume interpretation in US hos...

Kevan Shah · · 12 min read

Hospitals and imaging leaders are asking a very specific, very timely question: How to deploy MedGemma 1.5 for 3D CT volume interpretation in US hospitals in 2026—and whether it’s realistic to do so in a way that’s clinically useful, operationally safe, and compliant. MedGemma 1.5 is genuinely exciting because it technically supports native 3D CT/MRI analysis and modern multimodal reasoning, and Google DeepMind has positioned it as a next-generation foundation model for medical imaging applications (https://research.google/blog/next-generation-medical-image-interpretation-with-medgemma-15-and-medical-speech-to-text-with-medasr/). The catch is that “deploy” means very different things depending on whether you’re talking about research, non-diagnostic clinical assistance, or diagnostic use.

Here’s the bottom line up front, based strictly on the current public landscape: there is no publicly available, approved deployment pathway to use MedGemma 1.5 for clinical diagnostic interpretation of 3D CT volumes in US hospitals in 2026, because MedGemma 1.5 is not FDA-cleared for diagnostic use and is explicitly described as a research prototype for developers and researchers—not a stand-alone diagnostic device (https://research.google/blog/next-generation-medical-image-interpretation-with-medgemma-15-and-medical-speech-to-text-with-medasr/). That doesn’t mean it’s unusable; it means your realistic pathway is a research pilot or a “limited clinical workflow” where outputs are treated as non-diagnostic and non-binding, with a radiologist always making the final clinical decision.

This post explains what you can do in 2026, what you cannot do, and—most importantly—how to design a technically sound architecture that integrates into PACS workflows while aligning with HIPAA, security, and governance expectations. We’ll also share actionable guidance for IT, radiology informatics, and innovation teams, and show how AI consulting and workflow automation (including n8n workflows) can reduce implementation friction.

How to deploy MedGemma 1.5 for 3D CT volume interpretation in US hospitals in 2026 (what “deploy” really means)

When most stakeholders say “deploy,” they often mean one of three things:

  1. Diagnostic deployment (radiology report support that influences patient care decisions).
  2. Non-diagnostic clinical assistant (“second look,” triage cues, QA flags; radiologist remains sole decision-maker).
  3. Research/education (IRB-approved studies, model evaluation, sandboxed innovation).

As of mid-2026, MedGemma 1.5 is viable only for #2 and #3—unless and until there is an FDA-cleared product (either MedGemma itself or an FDA-cleared wrapper built on top of it).

1) The regulatory barrier: FDA clearance is missing

This is the gating factor—and it’s not optional.

  • Research status is explicit. Google’s own announcement frames MedGemma 1.5 as a release for developers and researchers to build applications, not a ready-to-use diagnostic device (https://research.google/blog/next-generation-medical-image-interpretation-with-medgemma-15-and-medical-speech-to-text-with-medasr/).
  • No FDA approval (510(k) or De Novo). There is no public indication that MedGemma 1.5 has FDA clearance for clinical CT interpretation in the US in 2026.
  • Practical implication: You cannot legally use MedGemma 1.5 to generate final diagnostic reports for patient care. If you deploy it in a hospital environment, it must be positioned as research, education, or (with legal/compliance sign-off) a non-binding assistant that does not alter the diagnostic image or replace clinical judgment.

Operational reality: Hospital legal teams and compliance officers will typically require (a) clear labeling of outputs as non-diagnostic, (b) workflow controls proving a human radiologist remains the final authority, and (c) documentation of data handling, de-identification, access controls, and audit logs.

MedGemma 1.5’s 3D capability vs. real-world 3D CT input

MedGemma 1.5 is described as supporting native 3D CT/MRI analysis (https://research.google/blog/next-generation-medical-image-interpretation-with-medgemma-15-and-medical-speech-to-text-with-medasr/), and technical documentation and third-party summaries emphasize its suitability for volumetric reasoning (https://arxiv.org/html/2604.05081v2, https://dr7.ai/medgemma-1-5-4b). However, a key engineering detail matters for implementers:

That means your “3D CT interpretation” system is, in practice, a pipeline that converts a volume into slices (and often into curated “key slices” or multi-window renderings) and then passes those into the model with appropriate prompts and constraints.

Reference architecture: a compliant, non-diagnostic MedGemma 1.5 pipeline for hospitals

If your goal is an IRB-approved pilot or a limited non-diagnostic workflow, the architecture below is the most realistic approach in 2026. It keeps you aligned with HIPAA expectations, reduces integration risk, and creates a foundation for future FDA-cleared deployments.

Step A — Data preprocessing (critical for 3D CT)

Because the model requires 2D sequences rather than raw volumetric DICOM ingestion, preprocessing becomes the “make-or-break” layer.

1) Slice extraction
Convert the 3D volume into a sequence of axial 2D images—commonly resized to something like 896 × 896 pixels (https://arxiv.org/html/2604.05081v2).
Practical guidance:

  • Preserve slice ordering and spacing metadata for downstream reasoning and UI display.
  • Maintain series identifiers so outputs can be associated with the correct study/series.

2) Windowing and intensity normalization
Apply clinically appropriate CT windowing (soft tissue, bone, lung) prior to inference (https://www.youtube.com/watch?v=TsO6wTA31Xk).
Practical guidance:

  • Consider generating multi-channel composites (e.g., three-window stacked images) to approximate how radiologists review.
  • Normalize intensities consistently across scanners to reduce domain shift.

3) De-identification (HIPAA)
Hospitals must strip patient identifiers before data is processed locally or sent to any API (https://www.youtube.com/watch?v=TsO6wTA31Xk).
Practical guidance:

  • De-identify DICOM headers and burn-in annotations.
  • Maintain a secure mapping table inside the hospital network if you need to re-link outputs for research analysis.

Step B — Choose a deployment option that matches risk tolerance

You have four realistic ways to run the model, each with different security, governance, and integration burdens.

Option 1: Local Docker (on-prem GPU)
Run the 4B model locally on GPU servers for maximum data control and privacy (https://dr7.ai/medgemma-1-5-4b, https://dr7.ai/de/medgemma-1-5-4b).

  • Hospital suitability: High for research and non-diagnostic pilots because PHI stays on-prem.
  • Trade-off: You own patching, monitoring, scaling, and MLOps reliability.

Option 2: Hugging Face Transformers (local development)
Use google/medgemma-1.5-4b-it for development and integration work (https://huggingface.co/google/medgemma-1.5-4b-it, https://dr7.ai/medgemma-1-5-4b).

  • Hospital suitability: Medium; great for prototyping but you still need a production wrapper for PACS and governance controls.
  • Trade-off: Additional engineering for DICOM handling, inference service hardening, and observability.

Option 3: Dr7.ai API / Unified Medical API
Integrate via an API or PACS/DICOM integration offered by an external vendor (https://dr7.ai/medgemma-1-5-4b, https://dr7.ai/es/medgemma-1-5-4b).

  • Hospital suitability: Low/Medium; depends on where PHI flows, contract terms, and whether the vendor has FDA clearance for any wrapper product.
  • Trade-off: Faster integration, but higher vendor and compliance dependency.

Option 4: Vertex AI (Google Cloud)
Run via Google Cloud Vertex AI / Model Garden as referenced in Google materials (https://research.google/blog/next-generation-medical-image-interpretation-with-medgemma-15-and-medical-speech-to-text-with-medasr/, https://www.youtube.com/watch?v=TsO6wTA31Xk).

  • Hospital suitability: Medium; feasible only with strong data governance, network controls, and a HIPAA-aligned contractual posture (e.g., BAA).
  • Trade-off: Excellent scalability and managed infrastructure, but governance complexity is non-trivial.

Step C — Integrate with PACS and radiology workflows safely

Most US hospitals don’t want “yet another tool.” They want this to appear in the existing imaging workflow.

1) DICOM interface
Use a DICOM listener/router such as Orthanc or dcm4chee to receive CT scans from PACS (https://dr7.ai/medgemma-1-5-4b).

  • Route only selected studies/series (e.g., chest CT without contrast) to limit scope.
  • Apply rules-based filters (modality, body part, protocol name).

2) Implement the pipeline script
A practical implementation follows this six-step flow (https://www.youtube.com/watch?v=TsO6wTA31Xk):

  1. Load DICOM
  2. Deidentify
  3. Normalize / Window
  4. Select key slices
  5. Pass to model
  6. Generate output

Key slices are not just a performance optimization—they are a governance and UX improvement. They reduce compute cost, reduce accidental overreach (“the model saw everything”), and make it easier to review model reasoning.

3) Output display without altering the diagnostic record
Outputs (e.g., text summaries, bounding boxes) should be displayed in the viewer/EHR context (Epic, Cerner, or dedicated radiology viewers) without modifying the original diagnostic image (https://dr7.ai/medgemma-1-5-4b).

  • Keep overlays and annotations as a separate layer with clear labeling: “Research/Non-diagnostic.”
  • Preserve audit logs of when the AI output was viewed and by whom.

A realistic 2026 timeline: what it takes to reach clinical deployment

If your organization wants eventual diagnostic deployment, you need a pathway that aligns with FDA expectations—and that’s typically a multi-quarter effort.

A commonly cited sequence is:

  1. Q3–Q4 2025: Initiate an FDA 510(k) submission with a clinical partner to validate safety/effectiveness (https://research.google/blog/next-generation-medical-image-interpretation-with-medgemma-15-and-medical-speech-to-text-with-medasr/).
  2. 2026: Conduct clinical validation studies, including anatomical localization performance (e.g., “38% IoU” as referenced in integration-focused summaries) and classification accuracy relative to human readers (https://dr7.ai/medgemma-1-5-4b, https://www.youtube.com/watch?v=TsO6wTA31Xk).
  3. Post-clearance: Deploy either:

The key nuance: FDA clearance typically applies to a specific intended use and a specific product configuration. Even if a base model is capable, the clinically validated system may be a tightly controlled wrapper with locked weights, fixed preprocessing, and validated outputs.

Immediate recommendation for US hospitals (mid-2026)

Given the current lack of clearance, the prudent approach is:

Practical takeaways: what developers, IT, and innovation teams should do now

1) Build the pipeline as a modular, testable system

Even if FDA clearance isn’t here yet, you can invest in the parts that will remain valuable:

  • DICOM routing + study selection
  • De-identification
  • Windowing/normalization
  • Slice/key-frame selection
  • Model invocation
  • Viewer-side visualization and audit logging

This reduces rework later—whether you switch to a cleared model or an FDA-cleared wrapper built on MedGemma-like technology.

2) Treat preprocessing as a controlled, versioned “medical device component”

The largest hidden risk in imaging AI isn’t just the model—it’s inconsistent preprocessing:

  • Different windowing choices can change what the model “sees.”
  • Different resampling and slice thickness handling can create subtle failures.

Version your preprocessing code, log parameters, and store hashes of inputs/outputs for traceability.

3) Add governance guardrails to keep the workflow non-diagnostic

If the hospital is exploring a limited clinical assistant use case:

  • Display “Non-diagnostic / Research use only” prominently
  • Require explicit user acknowledgement
  • Block auto-population of the radiology report
  • Log user interactions for compliance review

4) Automate the operational glue with n8n workflows

This is where automation can make or break adoption. In practice, teams lose months wiring together PACS events, de-identification jobs, GPU inference queues, and notifications.

Using n8n workflows, you can orchestrate:

  • DICOM listener triggers → job creation
  • De-identification pipeline execution → secure storage
  • GPU inference job dispatch → status tracking
  • Results packaging → delivery to a viewer integration endpoint
  • Alerts to radiology informatics when failures occur
  • Audit log export to SIEM / compliance dashboards

In other words: keep your radiologists and IT teams out of “manual babysitting” mode.

5) Plan for evaluation: clinical validation is not a single accuracy number

If you’re running research trials:

  • Compare by protocol and anatomy (not just global averages)
  • Track failure modes (motion artifact, metal artifact, low-dose scans)
  • Measure calibration and uncertainty, not just classification performance
  • Ensure dataset governance and IRB alignment

How our AI consulting team helps hospitals deploy safely (and avoid dead ends)

Our work in AI consulting and workflow automation is designed for exactly this “high-potential, high-regulation” reality:

  • Architecture design: On-prem vs cloud decisioning, HIPAA-aligned data flows, and segmentation of PHI vs de-identified research stores.
  • PACS integration: DICOM routing patterns, Orthanc/dcm4chee integration, study selection rules, and viewer-safe output handling.
  • Automation engineering: Production-grade n8n workflows to orchestrate imaging pipelines, notifications, error handling, and audit logging.
  • MLOps and observability: GPU scheduling, throughput planning, drift monitoring, and reproducible preprocessing.
  • Governance support: Documenting “non-diagnostic” guardrails and helping stakeholders understand what is and is not permissible prior to FDA clearance.

If you’re serious about “2026 readiness,” the goal is not to rush an unsafe deployment—it’s to build the infrastructure that will let you adopt an FDA-cleared solution quickly when it becomes available, with minimal disruption.

Conclusion: you can deploy MedGemma 1.5 technically—but not as a diagnostic tool in US hospitals (yet)

MedGemma 1.5 is a major step forward in medical imaging foundation models, and it has credible technical support for volumetric imaging workflows (https://research.google/blog/next-generation-medical-image-interpretation-with-medgemma-15-and-medical-speech-to-text-with-medasr/, https://arxiv.org/html/2604.05081v2, https://dr7.ai/medgemma-1-5-4b). But in 2026, US hospitals must treat it as what it is publicly positioned to be: a research prototype without an FDA-cleared clinical deployment pathway.

What you can do right now is build a compliant, secure, modular imaging AI pipeline—on-prem via Docker/Hugging Face (https://dr7.ai/medgemma-1-5-4b, https://huggingface.co/google/medgemma-1.5-4b-it), or in controlled cloud environments like Vertex AI where governance permits (https://research.google/blog/next-generation-medical-image-interpretation-with-medgemma-15-and-medical-speech-to-text-with-medasr/)—and run IRB-approved trials or non-diagnostic “second look” workflows with rigorous oversight (https://www.youtube.com/watch?v=TsO6wTA31Xk).

CTA: Want a deployable, non-diagnostic imaging AI workflow in 60–90 days?

If your hospital or imaging group is evaluating MedGemma 1.5—or planning for the next FDA-cleared generation of multimodal radiology AI—contact us to design a secure pilot architecture, integrate with PACS, and automate the entire pipeline with n8n workflows. We’ll help you move fast without creating compliance, security, or operational debt.

Reach out to our AI consulting team to scope a research pilot, governance plan, and production-ready automation blueprint.}