Orthanc alternative

What Orthanc actually is

Orthanc is a lightweight, open-source DICOM server built for hospitals and researchers who need a real DICOM engine without a commercial PACS license. It speaks C-STORE, DICOMweb and Stone rendering, ships a plugin system, and has a large community behind it. As a piece of DICOM infrastructure it is excellent, and it is not a toy: production imaging stacks run on it, including MiniPACS's own. Orthanc and the MiniPACS application share one Postgres database underneath, in disjoint tables, so this is not a marketing analogy. The engine really is Orthanc.

What Orthanc does not try to be is a finished clinic application. It has no worklist built for a front desk, no concept of staff roles, no audit log a compliance officer can hand to an auditor, and no support line. That is by design, not a shortcoming: Orthanc's maintainers built a DICOM server for people who already know how to build the rest. Orthanc is the engine, not the car, and it was never meant to be both.

Where DIY Orthanc stalls in a real clinic

Standing up Orthanc yourself gets a clinic a working DICOM receiver in an afternoon: point a modality at it, watch a C-STORE land, open the study in Orthanc Explorer or a Stone viewer. That part is genuinely fast, and it is why so many clinics start there. It rarely survives contact with the next six items, which are the parts that show up weeks later, not on day one.

• Users and roles. A tech, a radiologist and a front-desk admin need different screens and different permissions. Orthanc's own interface is not built for that split.
• Audit log. HIPAA's audit-controls requirement wants a way to record and examine who touched what study, when and from where. An append-only, exportable log that satisfies it is something to build, not something Orthanc ships.
• Backups. Encrypted, automated, tested backups are a project of their own: a passphrase-gated AES-256 job, a restore drill, an off-site copy.
• HIPAA paperwork. Business associate agreements, a written risk assessment, annual staff training, a contingency plan with a yearly restore test. None of it is code, all of it is required, and Orthanc's docs do not cover it.
• Upgrades. Security patches and version bumps land on someone's plate every month, forever, on top of their actual job.
• Support. When the worklist stalls at 8am and a radiologist is waiting, "post on the forum and wait" is not a support plan.

None of that is a knock on Orthanc. A hospital IT department with a DICOM engineer on staff can build all of it and often does. A radiology clinic with a front desk and a handful of readers usually cannot, and that gap is where DIY installs quietly stop being maintained.

An alternative that keeps the engine

MiniPACS does not replace Orthanc. It runs Orthanc as the DICOM engine underneath a clinic-facing product: a worklist that opens studies in any browser, with a 0.6 second measured viewer cold-open, reports attached to the study as DICOM so they travel with it on export, users and roles, an append-only audit log with CSV export, automatic encrypted backups, session controls (15-minute auto-logoff, instant revocation), and Vendo, a referral portal that lands referrals straight onto the same worklist. The disk, the backups and the audit log stay on the clinic's own server, the same self-hosted posture DIY Orthanc starts from.

The difference is who is responsible for the parts around the engine. With DIY Orthanc, the clinic is. With MiniPACS, updates and patches are installed remotely, priority support is a phone call with one dedicated person, and the read-only fallback keeps studies viewable even if a payment lapses. See the full product for the complete picture. If the clinic's pain is moving images to referrers, patients or other facilities, see medical image sharing for the portal and DICOM-transfer side.

Migrating an existing Orthanc install

Because the engine underneath MiniPACS is Orthanc itself, moving an existing Orthanc archive over is a same-engine migration: studies port natively, without a transcoding gamble on years of DICOM. That is the structural difference between this move and a normal PACS switch, where the old vendor's export format decides how painful the project gets. Here nothing has to be converted; it has to be transferred.

The bulk importer is built for archives that are bigger than the machine doing the work. It watches the host while it runs, and below 15 GB of free disk or 2 GB of free RAM it pauses new intake and waits instead of crashing mid-archive. It keeps per-study state after every completion, so a stopped run resumes exactly where it left off, and a power cut or an operator Ctrl-C ends in a clean shutdown, not a corrupted transfer. How long the whole move takes depends on archive size and disk speed, not on staff attention: the importer is designed to run unattended for days if the archive needs it. For the vendor-independent walkthrough of what any PACS migration involves, see PACS migration.

How to migrate off Orthanc to MiniPACS

Moving off a running Orthanc archive is a defined sequence, not a leap of faith, and because the destination runs the same engine none of it involves converting your DICOM. These are the steps the move actually follows.

1. Inventory the source Orthanc. List the modalities defined in its configuration - the DicomModalities block records the AE title, host and port of every sender - and note the study and instance counts you expect to move.
2. Stand up MiniPACS as the destination. Because MiniPACS runs Orthanc inside, migrated studies land natively with no transcoding; nothing about the source format has to be converted on the way in.
3. Verify connectivity with a C-ECHO. Send a C-ECHO from the source to the destination before moving anything, confirming the AE title, host and port resolve and the link is up.
4. Forward the studies by C-STORE. Push studies from the source Orthanc to MiniPACS over C-STORE, or run a bulk export from the old archive and import it into the new one.
5. Let the resumable importer handle interruptions. If a transfer stops (a power cut, an operator halt, or the host running low on disk or RAM) MiniPACS's resumable chunked importer keeps per-study state and picks up exactly where it left off, so you restart the run, not the whole archive.
6. Verify the counts match. Confirm the study and instance counts line up between source and destination before you decommission the old server.

For MSPs and integrators who maintain client Orthanc servers

A large share of real-world Orthanc installs are not run by the clinic at all. They were stood up by an MSP or an integrator years ago, and that partner now owns the upgrades, the storage questions and the 8am calls, usually without a software line on the invoice to show for it. If that is you, there is a specific track for it: you resell MiniPACS and Vendo under your own contract at a 25% recurring margin, you keep first-line support (the work you are already doing, now billable), and we carry the product and second line. Registered deals are protected for 90 days, and on a deal that takes both products we run the archive migration free.

The full terms, including white label from 5 committed locations, are public on the partners page. Nothing about your client's posture changes: the archive stays on the server you already manage, self-hosted, which is usually why Orthanc was chosen in the first place.

Orthanc vs dcm4chee

Orthanc and dcm4chee are the two open-source DICOM archives clinics actually compare, and the honest read is that they solve the same problem at different weights. Orthanc is the lighter, newer engine: a single binary with a plugin system and a fast path from zero to a working DICOM receiver, which is why it shows up so often in smaller deployments and research setups. dcm4chee is the older, heavier, more enterprise-shaped archive, built on the dcm4che Java toolkit, with years of hospital and regional-network deployments behind it and a deeper footprint for large-scale integration work. Neither ships vendor support, a worklist built for a front desk, or HIPAA paperwork, because neither one is trying to be a finished clinic product. Whichever engine a team picks, the category and the questions that follow it are the same: who builds the viewer and the worklist on top, who owns backups and upgrades, and who a clinic calls when something breaks at 8am. See the dcm4chee alternative comparison for the same walkthrough applied to that engine specifically.

Who should still run raw Orthanc

Being honest about fit matters more than winning every comparison. A hospital or research group with a DICOM engineer on staff, a custom pipeline to build, or a need to modify Orthanc's plugin internals directly is better served running Orthanc itself and building exactly what they need on top. Orthanc's plugin system exists for that kind of work, and no packaged product will beat a purpose-built integration for a team that has the engineering time to build one. Sending a bug report or a plugin fix upstream to Orthanc is also a better use of that team's time than switching engines, and MiniPACS benefits from that same upstream project every time it does.

MiniPACS is for the other case: a clinic that needs the worklist, the users, the audit log and the backups solved on day one, without hiring for it. If DIY Orthanc got a clinic as far as "the server accepts studies" and then stalled on everything after that, that is the exact gap MiniPACS closes. For the deployment choice itself, see self-hosted PACS; for the other well-known open-source archive, see the dcm4chee alternative comparison. For the wider question of where the images live, see cloud PACS vs onsite; for PACS basics, see what is PACS.

FAQ