The short answer
There are exactly two open-source projects you can honestly call a PACS archive: Orthanc and dcm4chee. The other names that appear on open source PACS lists are real and useful but they are not archives: Dicoogle is a research and indexing platform, OHIF is a viewer, and Horos and Weasis are desktop viewers. All of them are genuinely good at what they do. None of them is a working clinic system out of the box, because a working PACS is the archive plus a viewer, a worklist, access control, backups and someone to call. Open source hands you excellent parts; the assembly is yours.
One thing to state before the profiles, so nobody reads this page under a false impression: MiniPACS is not open source. It is a commercial, self-hosted PACS built on the same philosophy, your hardware, your data, no cloud dependency, that ships already assembled. Where that fits, and where it honestly does not, is covered after the projects themselves.
The real open-source players
Orthanc: the lightweight DICOM server
Orthanc is the default answer for a reason. It is a lightweight, standalone DICOM server with a REST API, Lua scripting, and a plugin ecosystem that covers most of what a small archive needs: PostgreSQL storage, DICOMweb, the Stone Web viewer. It installs in minutes, runs on modest hardware, and is maintained by people who care about DICOM correctness. It is not a toy: production imaging stacks run on it, including MiniPACS's own engine. What Orthanc deliberately does not include is the clinic layer: a front-desk worklist, staff roles, an audit trail, automated tested backups, a support line. The Orthanc alternative page walks that gap in detail.
dcm4chee: the enterprise archive
dcm4chee is the heavyweight of open-source imaging: a Java-based archive from the dcm4che project, built for hospital scale and IHE workflow profiles. Where Orthanc is a compact server you script around, dcm4chee is closer to a commercial VNA in scope. The trade is operational weight: a Java application server, LDAP, a database, and configuration that assumes an administrator who has run enterprise Java before. For a hospital IT department that has that person, dcm4chee is a serious, proven option. For a three-person clinic it is usually the wrong amount of machine. The dcm4chee alternative page covers the day-two reality.
Dicoogle: research and indexing
Dicoogle is an open-source platform from the research world, and that is its honest home. Its strength is indexing: plugin-based full indexing of DICOM metadata so you can query large collections in ways a standard archive query cannot. For dataset curation, academic projects and imaging research it is genuinely useful. It was never designed to be a clinic's daily archive, and using it as one means building even more around it than you would around Orthanc.
OHIF: a viewer, not a PACS
OHIF is the open-source web viewer, zero-footprint, browser-based, and good enough that commercial products ship it. But it stores nothing. OHIF speaks DICOMweb to an archive behind it, most commonly Orthanc or dcm4chee, and without one it is a screen with no film. It belongs in an open source PACS conversation as a component, not a candidate. For what separates viewers from archives in general, see DICOM viewer.
Horos and Weasis: desktop viewers, not archives
Horos is a free macOS viewer descended from OsiriX: a capable radiologist workstation whose maintenance has visibly slowed in recent years. Weasis is a free cross-platform desktop viewer, usually launched from an archive to display a study. Both are viewers that live on one workstation; neither receives from your modalities, indexes patients or serves other users. Clinics sometimes use a desktop viewer plus a shared folder as an accidental PACS, and that arrangement fails exactly where you would expect: no archive, no backups, no concurrent access. The Horos and Weasis pages take each on its own terms.
What you assemble yourself
Pick Orthanc or dcm4chee and you have solved the archive, which is the best-solved part of the problem. What remains is the difference between a DICOM server and a system a clinic runs on:
- The viewer wiring. Deploying OHIF or Stone against the archive, keeping versions compatible, and making studies open reliably from every machine that needs them.
- A worklist. The screen a front desk and a reader actually live in. Neither archive ships one; this is a build.
- Access control. Accounts, roles and an audit trail, so a tech, a radiologist and an admin see different things and a compliance review has something to read.
- Transport security. TLS on the DICOM and web layers, and a safe answer for reading from outside the building that is not port-forwarding the archive to the internet.
- Backups you test. Encrypted, automated, restored from at least once. Scripts you write, drills you schedule.
- Upgrades and support. Patches land monthly, forever, and when ingest stops the escalation path is a mailing list. Both are fine if it is someone's actual job.
None of this is a criticism of the projects; it is their stated scope. If you want to walk the DIY route with open eyes, the how to self-host a DICOM server guide is the honest step-by-step, and self-hosted PACS covers the deployment model itself.
Where MiniPACS fits, stated honestly
MiniPACS is not an open-source project and does not pretend to be one. It is a commercial self-hosted PACS: closed source, paid, and built for clinics that want the self-hosted outcome, data on their own hardware, no per-study cloud bill, without an engineering project. Full disclosure, because it matters in this conversation: MiniPACS runs Orthanc as its DICOM engine internally. The product is the assembled layer around that engine, the part this page just listed as yours to build.
Assembled means: C-STORE ingest from any modality and C-STORE send with C-ECHO for network checks, DICOM TLS, a DICOMweb layer that is gated to the LAN and serves both Stone and OHIF viewers in the browser, a worklist, reports as encapsulated PDFs that travel inside the study, share links, remote reading over an outbound-only tunnel rather than an open port, and a gateway agent for the modality side. It installs with Docker on Linux, runs on a mini PC for a single site, and holds millions of images in production. Pricing is a flat $300 per location per month; if the subscription lapses the system goes read-only and your archive stays yours, in standard DICOM, on your disk. Details on the pricing page, and the landing page has a live demo.
Who should not buy it: if your requirement is source code you can audit and fork, zero license cost, or deep customization of the archive itself, MiniPACS is the wrong product and Orthanc is the right starting point. That is not false modesty; it is the actual boundary.
Open source or assembled: how to choose
Choose open source when you have real engineering capacity, in-house or contracted, and the archive is worth that capacity to you: you want maximum control over every component, the freedom to modify and integrate without a vendor, and a license cost of zero. Hospital IT departments, imaging research groups and technically-staffed teleradiology outfits fit this profile, and for them the open-source stack is not a compromise, it is the better system.
Choose an assembled self-hosted PACS when the clinic has no one whose job is to build and maintain imaging infrastructure. The archive still sits in your building and the data is still yours; what you are paying for is the assembly, the upgrades and the phone number. The failure mode this avoids is specific and common: a DIY install that worked on day one and stopped being maintained the month its builder got busy.
| Open-source stack, DIY | MiniPACS, assembled | |
|---|---|---|
| Archive | Orthanc or dcm4chee, you deploy and tune | Included, C-STORE ingest from any modality |
| Viewer | OHIF or Stone, you wire to the archive | Stone and OHIF in the browser, included |
| Worklist | You build it | Included |
| Reports | You build it | Encapsulated PDFs that travel with the study |
| Backups | You script and test them | Included |
| Remote reading | VPN you configure | Outbound-only tunnel, no open ports |
| Support | Forums and mailing lists | A person who answers |
| Cost | $0 license, ongoing engineering time | $300 per location per month, flat; read-only on lapse, never locked out |
FAQ
Is MiniPACS open source?
No. MiniPACS is a commercial, closed-source product. It is self-hosted, so the archive runs on your hardware and the imaging data stays in your building, and it uses the open-source Orthanc server as its DICOM engine internally, but the product around that engine, the worklist, the reports, the backups and the support, is proprietary and paid: a flat $300 per location per month. If open source is a requirement for you, Orthanc and dcm4chee are the real options, and this page describes them fairly.
What is the best open source PACS?
For most small and mid-sized deployments, Orthanc: it is lightweight, well documented, actively maintained, and its plugin ecosystem covers DICOMweb, PostgreSQL storage and the Stone Web viewer. For hospital-scale archives with IHE workflow requirements and a team that runs Java enterprise software, dcm4chee is the more complete archive. There is no single best; there is a best fit for the engineering capacity you actually have.
Is Orthanc a complete PACS?
It is a complete DICOM server and archive, and a genuinely good one, but not a complete clinic system. Out of the box it has no worklist built for a front desk, no staff roles, no automated tested backups and no support line. Those are deliberate non-goals: Orthanc is the engine, and its maintainers expect you to build or bolt on the rest. Plenty of teams do exactly that; the honest question is whether yours is one of them.
Is OHIF a PACS?
No. OHIF is a web-based DICOM viewer, and a very good one, but it stores nothing. It needs an archive behind it that speaks DICOMweb, most commonly Orthanc or dcm4chee. If you see OHIF listed as an open source PACS, that listing is wrong: it is one component of a PACS, the screen, not the storage.
What does a free open source PACS actually cost to run?
The license is zero and stays zero. The cost is engineering time: the initial assembly of viewer, worklist, access control, TLS and backups, and then the permanent tail of upgrades, security patches, restore drills and being the person who answers when it breaks at 8am. For a team that already has that capacity, the total cost can genuinely beat any commercial option. For a clinic without it, the free license is the cheapest line item in an expensive project.
Can I run an open source PACS in a HIPAA-covered clinic?
Yes, there is no rule against open source software in a covered entity. Compliance is about how the system is run, not who wrote it: access controls, audit trail, encryption, tested backups and the written policies around them. Open source gives you full control to implement all of that, and full responsibility for actually doing so. A commercial self-hosted product does not make you compliant either; it just ships more of those controls pre-built.