Start from the need, not the tool
“Open-source radiology AI” covers six different kinds of software that solve six different problems. Route yourself first:
- Need a viewer? OHIF for zero-footprint web viewing; 3D Slicer for deep interactive analysis on a workstation.
- Need a PACS / DICOM server? Orthanc for a lightweight, scriptable server; dcm4che if your world is Java or you need the dcm4chee archive.
- Need a training framework? MONAI — the de-facto standard for deep learning on medical images.
- Need pre-trained models to study? TorchXRayVision, for research benchmarking on chest X-rays.
- Need orchestration and validation? Orchid — routing studies to AI apps and scoring them against ground truth — with the maturity caveats covered below.
- Need a signed report? No open-source tool produces one. That gap is real, and we cover it honestly at the end.
The tools that matter
Each project below is described neutrally, with licence and maintenance status checked as of August 2026. Open-source projects move fast — verify current releases on the project's own site before committing.
MONAI
Training framework · Apache-2.0 · actively maintained (v1.6, June 2026)
The Medical Open Network for AI: a PyTorch-based framework purpose-built for deep learning on medical images, backed by NVIDIA and a large academic community. It supplies what generic ML frameworks lack — medical-image transforms and augmentation, reference network implementations, losses and metrics for segmentation and classification, and multi-GPU training pipelines. If a paper trains an imaging model in 2026, odds are good MONAI is underneath it. It trains models; deploying them clinically is an entirely separate (and regulated) problem.
OHIF Viewer
Web DICOM viewer · MIT · actively maintained
The Open Health Imaging Foundation's zero-footprint viewer: a progressive web app that connects to any DICOMweb-capable archive and handles 2D and 3D viewing, segmentations and whole-slide microscopy in the browser — nothing to install on the client. Its extension architecture has made it the default front end for imaging research platforms and AI demos alike. Note that the base viewer is a component, not a turnkey clinical workstation: institutions typically pair it with an archive (Orthanc or dcm4chee below) and their own configuration work.
Orthanc
DICOM server · GPLv3 (some plugins AGPL) · actively maintained (1.12.11, April 2026)
A lightweight, standalone DICOM server from the University Hospital of Liège, and the most common answer to “we need a self-hosted mini-PACS.” Its defining feature is the REST API: everything a modality can do over DICOM, a script can do over HTTP, which makes it the connective tissue of countless research and integration projects. C++ core, plugins for DICOMweb, PostgreSQL and viewers. Mind the licence: GPLv3 for the server and AGPL for several plugins is more restrictive than the permissive licences elsewhere on this list — fine to run, but worth legal review before building proprietary products on top.
3D Slicer
Visualisation & analysis platform · BSD-style · actively maintained (stable 5.x line)
A free desktop platform for medical image visualisation, segmentation and analysis with over two decades of research history, a huge extension catalogue, and deep Python scriptability. It is where a great deal of ground-truth annotation, 3D reconstruction and algorithm prototyping actually happens. Slicer's own documentation is explicit that the distributed application is intended for research — it is a laboratory power tool, not a cleared diagnostic workstation.
TorchXRayVision
Pre-trained models & datasets · Apache-2.0 · actively maintained · research only
A Python library that does two useful things: unified loaders for the major public chest X-ray datasets (CheXpert, NIH, PadChest, VinDr-CXR and others), and pre-trained classification models you can run in a few lines of code. It is the fastest way to get a baseline chest X-ray model for benchmarking, domain-shift studies, or as a teaching tool. It is equally the clearest example of the open-source caveat: these are research models trained on public data, with no regulatory clearance — using them to inform patient care would be both unsafe and unlawful in most jurisdictions.
dcm4che
DICOM toolkit (Java) · MPL 1.1 · actively maintained
The long-standing Java toolkit for DICOM: libraries and dozens of command-line utilities for reading, converting, validating and transmitting imaging data, plus the foundation of the dcm4chee enterprise archive. Where Orthanc is the lightweight scriptable server, dcm4che/dcm4chee is the heavier-duty, standards-exhaustive option that large deployments and imaging vendors reach for. Less approachable than Orthanc for a quick project; more complete when interoperability edge cases matter.
Orchid
AI orchestration & validation · MIT · young project, pre-1.0 · not a medical device
The newest entry on this list, and the one addressing the layer the others leave open: orchestration. Orchid receives studies over a real DICOM C-STORE listener, routes them to AI applications through priority-ordered rules (modality, body part, source, description), collects findings back as structured results and DICOM SRs, and — its most distinctive feature — validates any connected model against ground-truth datasets built from your own studies, with AUC, ROC curves and confusion matrices. It is an open, self-hostable take on what commercial platforms like CARPL.ai sell as an enterprise service. Full disclosure: it is a young, pre-1.0 project by 5C Network's founder, explicitly not a medical device, shipping demo models for illustration only, and suited to research, evaluation and integration prototyping — not production. Details and quick start on our Orchid page or straight from GitHub.
What open source does not give you
The honest half of this guide. Three things no licence on this page provides:
- Regulatory clearance. Diagnostic software is a medical device. CDSCO registration in India, FDA clearance in the US, CE marking in Europe — these attach to a specific, quality-managed product, and an open-source repository has none of them. Running an uncleared model on patients is not a grey area.
- Support and accountability. GitHub issues are not an SLA. When the archive corrupts at midnight or an upgrade breaks the viewer, the responsibility is yours — or a consultancy's you pay, at which point “free” deserves scare quotes.
- Signed reports. No open-source tool interprets a study and takes responsibility for the answer. A diagnostic report requires a qualified radiologist who signs it — software of any licence is, at best, their assistant.
None of this is an argument against open source — it runs infrastructure superbly and is the backbone of imaging research. It is an argument for knowing which layer you are buying. If the layer you actually need is interpreted, quality-checked, signed reports with AI in the workflow, that is a service, not a repository — see how 5C approaches radiology AI for that side of the picture.
Frequently asked questions
Is open-source radiology AI safe for clinical use?
It depends entirely on the role the software plays. Infrastructure components — a DICOM server like Orthanc, a viewer like OHIF, a toolkit like dcm4che — are used inside clinical environments worldwide, subject to each institution's IT validation, security review and local regulations. Diagnostic AI models are different: software intended to detect or characterise disease is regulated as a medical device (CDSCO in India, FDA in the US, MDR/CE in Europe), and an open-source licence does not confer clearance. Research models such as those in TorchXRayVision, and young platforms such as Orchid, state explicitly that they are not for clinical use. The honest rule: open source can run your plumbing today; anything that influences a diagnosis needs a cleared pathway and a qualified radiologist.
What does open-source radiology software really cost?
The licence is free; the deployment is not. Realistic costs include servers or cloud hosting, engineering time for integration with modalities and HIS/RIS, security hardening, backups, upgrades, and — the item most budgets miss — someone accountable when it breaks at 2 a.m. There is no vendor SLA, so hospitals either build that capability in-house, hire a consultancy (Orthanc and OHIF both have commercial-support ecosystems around them), or accept the risk. For a well-staffed IT team the total cost can still be far below commercial licences; for a small diagnostic centre with no engineers, a supported commercial product or service is often cheaper in practice.
Can hospitals self-host these tools?
Yes — self-hosting is the point. Every tool in this guide runs on your own hardware or private cloud: Orthanc and dcm4che as DICOM infrastructure, OHIF served as a web app, 3D Slicer on workstations, MONAI and TorchXRayVision in your training environment, and Orchid as a single self-contained process (or Docker Compose) that works on an isolated network. Self-hosting keeps patient data inside your walls, which simplifies compliance with data-protection law such as India's DPDP Act — but it also makes you the security team, so patch management, access control and audit logging become your responsibility.
Which open-source tool should I start with?
Match the tool to the job. Need to view studies in a browser: OHIF. Need a DICOM server or lightweight PACS: Orthanc. Need to train or fine-tune imaging models: MONAI. Need research-grade pre-trained chest X-ray models to benchmark against: TorchXRayVision. Need deep interactive visualisation and segmentation on a workstation: 3D Slicer. Need Java DICOM plumbing or an enterprise archive: dcm4che. Need to prototype how studies route to AI apps and validate models against ground truth: Orchid — with the caveat that it is a young project for research and evaluation, not production.
Exploring the orchestration layer?
Orchid is the open-source, self-hostable way to prototype AI routing and model validation on your own network. And when the question becomes production reporting, we're easy to find.
