OHIF Viewer: The Free Web-Based Medical Imaging Viewer Used by Hospitals Worldwide (2026 Guide)

A radiologist at a partner institution needs to review a CT scan from a patient who was just transferred to your facility. The images are in your PACS. Your vendor's client software is not installed on her laptop. Your IT department does not support remote PACS access without a VPN. It is 11 pm.

This exact scenario — repeated thousands of times daily across the US healthcare system — is why web-based medical imaging viewers exist. And it is why the OHIF Viewer, a free, open-source project housed at Massachusetts General Hospital, has become one of the most widely deployed medical imaging platforms in the world.

OHIF (Open Health Imaging Foundation) Viewer is not a startup product or a niche research tool. It is the foundation on which clinical trial imaging platforms at 8 NCI-Designated Cancer Centers run. It manages imaging workflows across 16 cancer centers coordinating 4,200 active clinical trials and 25,000 patient visits per year. Dana-Farber/Harvard Cancer Center's Tumor Imaging Metrics Core uses it as a primary clinical research viewer. The National Cancer Institute found it sufficiently important to award a five-year sustainment grant in 2023 to keep it maintained and developed.

And it is free. Completely, MIT-license free.

What Is the OHIF Viewer and Why Does It Matter

The OHIF Viewer is a zero-footprint, web-based DICOM viewer. Zero-footprint means that nothing is installed on the end user's computer — physicians, radiologists, and specialists access it through a standard web browser, the same way they access email or a scheduling system. There is no plugin, no download, no IT ticket required to grant access.

DICOM (Digital Imaging and Communications in Medicine) is the universal file format and communication protocol for medical imaging. Every CT scan, MRI, X-ray, ultrasound, and PET scan your practice generates is stored as DICOM data. Traditional PACS (Picture Archiving and Communication System) clients are thick applications installed on specific workstations, with specific hardware requirements, managed by your IT department.

OHIF replaces that thick client with a browser application. A physician can review imaging from a tablet at home, a clinic in a different building, or a consultation room in another hospital — with no local software and no images stored on the device being used to view them.

The project is developed as open-source software under an MIT license, meaning any practice, hospital, or software company can use it, modify it, and build commercial products on top of it without paying licensing fees. The codebase is built in TypeScript (78.5%) and JavaScript (19.9%), runs entirely in modern browsers using WebGL for rendering, and follows a modular plugin architecture that allows institutional teams to add custom functionality without modifying the core viewer.

As of June 2026, OHIF is on version v3.12.4, with the v3.13.0 beta actively in testing. The version 3 rewrite, which migrated the architecture to a modern React-based extension system, was a fundamental improvement over v2 — not just a feature update — and is now the stable platform that health systems are standardizing on.

Why Traditional PACS Deployments Are Becoming Untenable

The legacy PACS model made sense in 1995. Imaging volumes were lower, networks were slower, and the idea of rendering volumetric CT data in a web browser was science fiction. Institutions invested heavily in proprietary PACS infrastructure: dedicated servers, high-end workstations, specialized storage area networks, and long-term vendor contracts.

Thirty years later, those contracts have become expensive anchors.

Commercial enterprise PACS viewer licensing from the major vendors — Philips IntelliSpace, Siemens Syngo.via, GE Centricity — typically runs $70,000–$100,000 per license per year, before implementation costs ($5,000–$15,000), hardware refresh cycles, and ongoing support contracts. For a five-year commitment, a single PACS deployment from a major vendor commonly represents $350,000–$410,000 in total cost of ownership — and that figure does not include the inevitable change-order fees when you need to add seats, upgrade to a new module, or integrate with a new imaging modality.

These costs are not abstract — they are decisions that small and mid-sized practices make every few years, typically when a vendor's support contract expires and the renewal quote arrives. Practices that explored their alternatives in 2024–2026 found that the calculus had changed significantly.

The infrastructure for OHIF itself — a cloud-hosted DICOMweb server (cloud storage from AWS, GCP, or Azure with appropriate HIPAA BAAs, plus a lightweight app server) — typically runs $10,000–$30,000 over five years for a small to mid-size practice. That is the total cost gap: $320,000–$400,000 in favor of the open-source path over five years, for a single deployment.

The missing variable is implementation effort. OHIF is free, but it does not configure itself. Practices that have succeeded with it either have an internal developer with healthcare IT experience or work with a specialist integration partner. This is a real cost — but it is a one-time cost, not a recurring annual licensing fee.

How OHIF Works: Zero-Footprint Architecture Explained

Understanding what you are actually deploying when you deploy OHIF removes a lot of the confusion that surrounds it.

The browser does the rendering. Modern browsers support WebGL, a graphics rendering API that can leverage GPU hardware to render medical imaging data. OHIF uses Cornerstone3D — a JavaScript library developed by the same community — as its rendering engine. This is how it achieves performance that competes with installed desktop applications, entirely inside a browser tab.

Images are not downloaded to the device. Traditional PACS clients download DICOM files to local storage before rendering them. OHIF streams image data from the server as needed, using the WADO-RS protocol. This means a radiologist reviewing a large abdominal CT study on their home laptop is not downloading gigabytes of DICOM files to their hard drive — the images stream in real time and leave no trace on the endpoint when the session ends. This is a material security advantage over traditional PACS clients.

The server is a DICOMweb-compatible archive. OHIF connects to a backend image archive that exposes a DICOMweb API. Many modern PACS systems (Orthanc, DCM4CHEE, AWS HealthImaging, Google Cloud Healthcare API) already speak DICOMweb. If your current PACS does not, there are middleware adapters available that translate legacy DICOM network protocols to DICOMweb.

Authentication is pluggable. OHIF supports OpenID Connect for authentication, meaning it can integrate with your existing identity provider (Microsoft Entra ID, Okta, Google Workspace) rather than requiring a separate user management system.

The overall deployment model — browser application, DICOMweb server, identity provider — is the same architecture you use for any modern web application. Practices with existing cloud infrastructure typically find OHIF integration straightforward because it follows patterns their IT teams already understand.

DICOMweb, WADO-RS, and the Standards That Make It All Work

For practice owners and IT staff encountering these acronyms for the first time, here is what they actually mean.

DICOM is the universal standard for medical imaging data. Every imaging device — every CT scanner, MRI machine, digital X-ray system — stores and transmits images in DICOM format. DICOM images contain both the pixel data (what you see) and structured metadata (patient identity, acquisition parameters, study information). When your radiologist says "send me the DICOM," they mean the full data package, not just a JPEG export.

DICOMweb is a set of REST APIs that expose DICOM data over standard HTTP/HTTPS. Before DICOMweb, DICOM data moved between systems using a proprietary network protocol (DIMSE) that required special networking configuration and only worked over trusted internal networks. DICOMweb works exactly like any modern API — send an HTTP request, get data back — which means it works over the internet, through firewalls, and from browsers.

DICOMweb has three core services:

• WADO-RS (Web Access to DICOM Objects — RESTful): retrieve DICOM data by study, series, or instance. This is how OHIF fetches images.
• QIDO-RS (Query based on ID for DICOM Objects — RESTful): search for studies and series. This is how OHIF populates a worklist.
• STOW-RS (Store Over the Web — RESTful): upload DICOM data to a server. This is how devices send images to a DICOMweb archive.

OHIF fully supports all three services. It also supports the legacy WADO-URI protocol for backward compatibility with older PACS systems that have not yet migrated to the full DICOMweb standard.

What this means practically: OHIF is not tied to any specific PACS vendor. It will work with any backend that exposes a standards-compliant DICOMweb API. This is the interoperability architecture that allows a single viewer to connect to imaging archives from multiple institutions, which is why it has become the default choice for multi-site research and clinical trial imaging coordination.

For practices evaluating EHR integration alongside their PACS strategy, our post on OpenEMR — the free EHR for US medical practices covers the FHIR API integration patterns that connect imaging workflows to electronic health records. OHIF and OpenEMR can share patient context via the SMART on FHIR protocol, creating a coherent workflow from order entry to image review.

OHIF and AI: MONAI Label Integration and the Shift to AI-Assisted Imaging

The most significant development in OHIF in the past two years is not a rendering improvement or a new modality support — it is the integration with MONAI Label, NVIDIA's AI-assisted medical annotation framework.

OHIF v3's extension system allows custom tools to be added to the viewer interface. The MONAI Label extension adds a sidebar to OHIF that connects to a remote MONAI Label server, allowing radiologists and annotators to:

• Run AI segmentation models on open studies with a single click
• Use interactive segmentation tools (DeepEdit, DeepGrow) that refine AI output based on a few user-provided seed points
• Collect annotations that feed back into active learning pipelines for model improvement
• Work with both DICOM and NIFTI datasets in a single interface

This matters for clinical practice in two ways.

First, for research-oriented practices and academic medical centers, it creates a complete AI training data pipeline: radiologists review cases in OHIF, annotate using MONAI Label, and those annotations become labeled training data for AI models — all in a browser, all using free open-source tools.

Second, for practices evaluating AI-assisted diagnosis tools, the OHIF+MONAI architecture shows what the infrastructure layer looks like before you add commercial AI applications on top of it. The viewer, the annotation tools, and the model serving infrastructure are all open-source; the commercial differentiation sits in the specific AI models being run, not in the viewer plumbing.

We covered the MONAI toolkit in depth in our post on MONAI: the free NVIDIA medical imaging AI toolkit. The short version: OHIF is the viewer interface, MONAI is the AI processing engine, and together they represent the open-source stack that major research institutions are using to build AI-assisted imaging workflows at zero licensing cost.

Beyond MONAI Label, the community-developed OHIF-AI project (built by researchers at the University of Bonn) extends OHIF with server-side AI integration for tools like SAM2 (Segment Anything Model for 3D medical data), medSAM2, and visual language models for medical image analysis. These are research-stage integrations, not production-ready clinical tools — but they illustrate where the platform is heading.

The Competitor Pulse Check

The FDA clearance row deserves direct attention. OHIF itself is not FDA cleared as a standalone medical device — it is a software platform, not a finished clinical product. If your regulatory environment requires FDA-cleared diagnostic software (typically Class II or III applications for computer-aided detection), you would need either a commercial viewer that carries FDA clearance or a custom deployment that includes FDA clearance as a design requirement. Several commercial products are built on OHIF and carry FDA clearance; the open-source version does not.

For most use cases in practice — viewing images, consultations, research, workflow coordination — this distinction does not create a practical barrier. Radiologists and physicians use uncertified display systems for clinical consultation routinely. The FDA clearance question matters most when software is being used for primary interpretation on regulated diagnostic studies, and for those workflows, purpose-built cleared products (including some built on OHIF) exist.

What OHIF Supports in 2026: A Technical Overview

The feature surface of OHIF v3.12 is broad enough to cover most clinical and research imaging workflows:

Imaging Modalities:

• CT, MRI, PET, PET/CT fusion, ultrasound, digital X-ray, mammography, fluoroscopy
• RT (radiation therapy) dose volumes, RT structure sets, and RT plan visualization
• Digital pathology (whole slide imaging) via dedicated mode
• Slide microscopy support
• 4D imaging (time-series CT and MRI)
• Video playback for endoscopy and fluoroscopy

Clinical Tools:

• Multi-planar reconstruction (MPR) — axial, coronal, sagittal views
• 3D volume rendering
• Measurement tools (length, area, angle, SUV for PET)
• Annotation and markup tools
• Window/level presets with real-time adjustment
• Hanging protocols for multi-study comparisons
• Report integration via SR (Structured Report) rendering

Workflow Features:

• Worklist management via QIDO-RS
• Study routing and tagging
• Multi-monitor support
• Keyboard shortcuts and customizable layouts
• PDF and video rendering within the DICOM viewer
• Print and export capabilities

Integration Standards:

• DICOMweb (WADO-RS, QIDO-RS, STOW-RS) — full compliance
• SMART on FHIR for EHR launch context
• OpenID Connect for enterprise authentication
• IHE workflow profiles (IHE-IW, IHE-DEN)

This is a viewer that competes with commercial solutions on features, not just on price.

Deploying OHIF for Your Practice: What Implementation Actually Looks Like

The gap between "OHIF is free" and "OHIF is running in our practice" is a real implementation gap. Here is what the path typically looks like.

Step 1: Choose your image archive backend. OHIF needs a DICOMweb-compatible backend. The most common options for practices:

• Orthanc — Open-source DICOM server with a DICOMweb plugin. Free, lightweight, can run on a modest cloud VM.
• DCM4CHEE — The most feature-complete open-source PACS server. Supports the full DICOMweb specification and handles large enterprise imaging volumes.
• AWS HealthImaging — Amazon's managed medical imaging service with native DICOMweb APIs, HIPAA-eligible with BAA, and pay-per-storage pricing.
• Google Cloud Healthcare API (DICOM Store) — Google's equivalent. Also HIPAA-eligible with BAA, DICOMweb-native.
• Your existing PACS vendor, if they support DICOMweb — many modern versions do.

Step 2: Handle authentication and access control. OHIF supports OpenID Connect. If your practice uses Microsoft Entra ID (formerly Azure AD), Google Workspace, or Okta, OHIF can delegate authentication to that existing system. This means the same login your staff uses for email works for the imaging viewer.

Step 3: Configure OHIF for your workflows. OHIF ships with default configurations but typically needs practice-specific customization: hanging protocols for your specialties, worklist column configuration, default window presets for your common modalities. This is where having a developer involved saves significant time.

Step 4: Validate HIPAA controls. OHIF does not store images on endpoint devices — that is a native security advantage. But your overall deployment needs HIPAA controls at the infrastructure layer: encrypted storage in the archive backend, encrypted transmission (HTTPS), BAAs with any cloud service providers, and access logging. This is the same HIPAA architecture we cover for any cloud-based healthcare system — the specific implementation is described in our post on private AI for medical practices.

Step 5: Connect to your EHR (optional but high value). Via SMART on FHIR, OHIF can be launched directly from a patient record in Epic, Cerner, or athenahealth. The EHR passes patient context to the viewer, which then opens to that patient's relevant studies automatically. For practices on these platforms, this integration eliminates the need for staff to search manually for imaging.

The full integration path for an independent practice typically takes four to eight weeks with a competent implementation partner. For larger health systems with multiple imaging modalities, multi-site PACS migration, and complex EHR integration requirements, timelines extend to twelve to twenty weeks.

How OHIF Fits Into a Broader Open-Source Healthcare Stack

OHIF does not operate in isolation. The most powerful open-source healthcare deployments combine it with complementary tools:

OHIF + OpenEMR: The OpenEMR free EHR provides the patient record and workflow management layer. OpenEMR's SMART on FHIR support allows it to launch OHIF in context. Together, they represent a complete EHR + imaging solution at near-zero licensing cost.

OHIF + MONAI: The MONAI medical AI toolkit adds AI-assisted segmentation and annotation to the OHIF viewer. This combination is what research institutions use for clinical trial imaging workflows.

OHIF + a custom AI scribe: We have implemented deployments where the imaging viewer, the ambient documentation system, and the practice management platform all share a unified patient context via FHIR APIs. The physician opens an imaging study in OHIF, the ambient AI generates clinical documentation referencing the imaging findings, and the note with imaging references flows back into the EHR automatically.

This is the architecture that separates practices managing AI point solutions from practices that have built a coherent AI infrastructure. The question of whether to use cloud AI or deploy locally for each component is covered in our comparison of cloud AI vs local AI for medical practices — the decision matrix is similar for imaging infrastructure.

ValueStreamAI Approach: Custom OHIF Deployments

For practices and health systems that need OHIF customized beyond the default configuration — specialty-specific hanging protocols, custom AI model integrations, EHR launch workflow automation, multi-site deployment coordination — we provide implementation support at the following tiers:

• Pilot / MVP (4–6 weeks): £4,000–£12,000 / $5,000–$15,000 — single-site OHIF deployment with DICOMweb backend, authentication integration, and basic EHR launch configuration
• Practice-Wide Deployment (8–12 weeks): £12,000–£32,000 / $15,000–$40,000 — multi-modality configuration, custom hanging protocols, full EHR integration, HIPAA compliance architecture, staff training
• Enterprise Infrastructure (12+ weeks): £32,000+ / $40,000+ — multi-site deployment, custom AI model integration (MONAI Label), federated imaging across multiple PACS backends, reporting system integration

The technology stack for our OHIF implementations typically uses FastAPI for the authentication middleware layer, Orthanc or AWS HealthImaging as the DICOMweb backend, and LangChain/LangGraph when building AI-assisted documentation pipelines that consume imaging context. Infrastructure is containerized with Docker and deployed on managed Kubernetes for practices that need high availability.

The architectural patterns we follow are described in our AI system architecture guide — the same design principles that make enterprise AI systems reliable apply to medical imaging infrastructure.

Frequently Asked Questions

Is OHIF Viewer really free to use in a clinical setting?

Yes. OHIF is licensed under the MIT License, which permits commercial and clinical use without restriction or licensing fees. You do not pay anything to use the software. Your costs are hosting infrastructure (cloud compute and storage), implementation work if you need custom configuration, and any support contracts you choose to establish. Several commercial companies offer commercial support for OHIF deployments; this is optional, not required.

Is OHIF FDA cleared for diagnostic imaging?

OHIF itself is not FDA cleared as a medical device. It is an open-source software platform. Organizations that need FDA clearance for diagnostic display can either use a commercial product built on OHIF (several exist and carry Class II clearance) or pursue their own 510(k) clearance for a custom deployment — which some large health systems do. For most consultation, research, and non-primary-read use cases, FDA clearance is not required.

Can OHIF connect to our existing PACS?

It depends on whether your PACS supports DICOMweb. Many modern PACS versions (Sectra, Fujifilm, Intelerad, and others) now expose DICOMweb APIs. If your PACS only supports legacy DICOM network protocols (DIMSE), a middleware adapter (e.g., Orthanc with a DICOMweb plugin acting as a gateway) can bridge the two. We assess this as part of every implementation engagement.

How does OHIF handle HIPAA compliance?

OHIF does not store images on endpoint devices — a native security feature of the zero-footprint architecture. HIPAA compliance at the system level requires: encrypted transmission (HTTPS, mandatory), encrypted storage in the backend archive (your cloud provider's responsibility under a BAA), access logging (available via standard server logs and OHIF audit events), and Business Associate Agreements with any cloud service providers involved. The viewer software itself is a tool; compliance is an architecture decision.

What is the difference between OHIF and a traditional PACS viewer?

Traditional PACS viewers are thick client applications installed on specific workstations. They require IT-managed deployment, hardware that meets minimum specifications, and typically local storage for downloaded DICOM files. OHIF runs in any modern browser — Chrome, Firefox, Safari, Edge — on any device. No installation. No local image storage. Accessible from any location with internet access. Images are streamed in real time and do not persist on the device.

Can we integrate OHIF with Epic or Cerner?

Yes, via SMART on FHIR. OHIF supports the SMART on FHIR launch protocol, which allows an EHR like Epic or Cerner to launch the viewer in the context of a specific patient. The EHR passes a patient identifier; OHIF queries the connected image archive for that patient's studies and opens the relevant imaging automatically. This requires both sides — OHIF and your EHR — to have SMART on FHIR configured, which is a standard feature of Epic's App Orchard and Cerner's App Gallery.

The Bigger Picture: Why This Moment Matters for Medical Imaging

Nearly two-thirds of healthcare organizations are already using or planning to use cloud-based imaging infrastructure within three years, according to KLAS 2024 research. The shift away from on-premises PACS hardware toward DICOMweb-native, cloud-hosted imaging is not a fringe trend — it is the mainstream trajectory of the industry.

OHIF sits at the center of this shift because it was built for exactly this architecture. While commercial vendors are retrofitting their thick client applications to work in browsers, OHIF was designed from the start as a web-native viewer with no legacy constraints.

For practices evaluating their imaging infrastructure — whether you are renewing a PACS contract, building out a telehealth imaging workflow, or adding AI-assisted imaging capabilities — understanding OHIF is understanding where the industry is going. The cost savings are substantial. The technical foundation is proven at institutions whose imaging volumes dwarf any independent practice. And the AI integration path via MONAI and Cornerstone3D is more accessible than anything available on the commercial side.

The practices and health systems investing in open-source imaging infrastructure today are not just saving money on PACS licenses — they are building imaging platforms that they control, that grow with them, and that integrate with the AI tools they will be adopting over the next five years.

To explore how a custom OHIF deployment fits into your practice's technology roadmap, review our AI development services or contact us directly for a free architecture consultation. For the full picture of AI tools available to medical practices in 2026, the AI for Medical Practices hub is the best starting point.