Open-source PACS servers compared: which archive fits your hospital
Orthanc and dcm4chee are both open-source DICOM archives you can run in your own data center or cloud account, so the choice turns on scale, team skills and the license terms your legal team will accept. Orthanc suits a team that wants a lightweight server it can stand up quickly and extend through plugins. dcm4chee-arc-light suits a team that expects a full enterprise archive with a multi-service stack and has staff to operate it. On licensing, the Orthanc core is GPLv3 or later, but its scalability and cloud plugins, including the PostgreSQL and web viewer plugins, are AGPLv3 or later, which can matter if you modify those plugins and offer them over a network. dcm4chee-arc-light is licensed under the Mozilla Public License 1.1. Confirm with counsel how these terms apply to your deployment model before you commit.
Architecture and operating effort diverge most. Orthanc uses a built-in SQLite index, and its scalability FAQ says to move to an enterprise database once the archive holds several hundred thousand DICOM instances. The PostgreSQL plugin is the recommended route for large datasets, and since Orthanc 1.9.2 with PostgreSQL or MySQL plugins 4.0, several Orthanc instances can share one database for horizontally scaled setups. dcm4chee-arc-light runs in WildFly on Java 17 or newer, keeps its central configuration in LDAP under the DICOM configuration management profile, and builds against DB2, Firebird, H2, MySQL, Oracle, PostgreSQL and SQL Server. Its Docker reference stack adds OpenLDAP, PostgreSQL, Keycloak and an Elastic Stack for logs, so plan for more components to patch, back up and monitor. Ask your team which database and identity provider it already operates before choosing.
Security defaults also determine what you configure first. Orthanc accepts HTTP connections only from localhost by default. If you enable RemoteAccessAllowed, the Orthanc Book says AuthenticationEnabled should be true, users should be defined in RegisteredUsers, and HTTPS and a reverse proxy are recommended for any Internet exposure. Its advanced authorization plugin adds finer control. For dcm4chee, the reference Docker setup includes a secured variant built around Keycloak, but confirm with your integrator how identity, TLS and audit logging are set in your build. Before you decide, pilot one modality workflow end to end, request a written quote from Orthanc Team for any deployment or support work (it sells services, not a paid edition), and run a restore test.
Which PACS archive fits which scenario
This table maps common deployment scenarios to the archive that fits best and the facts behind each choice. Read each row as a starting point, then confirm the conditions against your own environment, since the right answer depends on volume, staffing and the systems around the archive.
| Scenario | Best fit | Reason and what to confirm |
|---|---|---|
| Small clinic or research group with modest study volume | Orthanc | Runs as a lightweight server on Windows, macOS, Linux or Docker, and its built-in SQLite index is a reasonable start at small scale. Confirm that your instance count stays well below the point where the docs recommend moving to PostgreSQL. |
| Large single-site archive expected to grow into the hundreds of thousands of instances | Orthanc with PostgreSQL plugin | The docs advise replacing SQLite with an enterprise database once several hundred thousand instances are stored, and recommend the PostgreSQL plugin for large datasets. Confirm the PostgreSQL plugin license terms (AGPLv3) with your legal team. |
| Multi-site hospital needing high availability | dcm4chee-arc-light | Its Docker wiki documents setups from one host up to secured services distributed across several hosts. Orthanc also supports multiple instances on one database since 1.9.2 with PostgreSQL or MySQL plugins 4.0, so compare the operational design you need for failover and load balancing. |
| Bahmni deployment | dcm4chee-arc-light | Bahmni Standard's Docker Compose stack runs dcm4chee as its PACS with a pacs-integration service, so it is the imaging archive in those hospital deployments. Confirm the Bahmni version and its integration service before choosing a different archive. |
| Existing OHIF or DICOMweb viewer stack | Either, depending on the archive already in use | The OHIF Viewer documentation lists both DCM4CHEE Archive 5.x and Orthanc as DICOMweb archives, with Orthanc as its main example. Confirm the DICOMweb endpoints and version your viewer configuration expects. |
| Environment that centrally manages DICOM configuration through LDAP | dcm4chee-arc-light | It uses LDAP as its central configuration store, aligned with the DICOM Application Configuration Management Profile. Confirm that your directory team can operate an LDAP service, since Orthanc does not use this model. |
| Team with no DICOM specialist and limited staff time | Orthanc, with a support plan if needed | A simpler configuration surface and single-binary deployment reduce early effort. Orthanc Team SRL sells deployment, configuration and support hours on request, so ask for a written scope before committing. |
| Team that already runs a Java EE or WildFly stack and a Keycloak identity service | dcm4chee-arc-light | Its Docker deployment already bundles WildFly, Keycloak and the Elastic Stack for logging, and it requires Java 17 or newer. Confirm that your platform team can maintain this stack and its version upgrades. |
How Orthanc and dcm4chee store images and metadata
Orthanc runs as a single server process that stores DICOM instances and keeps an index of their metadata. By default that index is a built-in SQLite database, which is simple to deploy and suits small or single-site archives. The docs advise replacing SQLite with an enterprise database engine once the archive holds several hundred thousand DICOM instances, and they recommend the PostgreSQL plugin for large datasets. The PostgreSQL and MySQL/MariaDB plugins, along with an ODBC back end, move the index out of the process. Since Orthanc 1.9.2 with PostgreSQL/MySQL plugins 4.0, several Orthanc instances can read and write the same database, which is the basis for horizontally scaled and highly available setups.
- Default index: SQLite runs inside the server with no separate database service to operate.
- Database plugins: PostgreSQL, MySQL/MariaDB and ODBC back ends externalize the index.
- Multi-instance access: Since 1.9.2 with plugins 4.0, multiple instances can share one database.
- Object storage plugins: S3, Azure and Google Cloud storage plugins hold the DICOM files outside local disk.
- Production reference: The Orthanc Book cites hospital deployments above 65 TB, so scale depends on the design you choose.
Confirm the plugin versions, database engine and storage class you will run together, and test failover against your own network before you rely on a shared-database layout.
dcm4chee-arc-light is the DICOM Archive application from the dcm4che project. It is a Java EE application deployed in WildFly and was written as a complete rewrite of DCM4CHEE Archive 2.x. Its configuration does not live in local files alone. It uses LDAP as the central configuration store, which follows the DICOM Application Configuration Management Profile (DICOM PS3.15 Annex H). That design lets several archive nodes share one configuration tree, but it also means your team must operate an LDAP directory as a dependency. The build supports DB2, Firebird, H2, MySQL, Oracle, PostgreSQL and SQL Server for the archive database, and it requires Java 17 or newer.
- Application server: The archive runs inside WildFly, so application server patching is part of the job.
- Central configuration: LDAP stores archive settings in a directory that follows PS3.15 Annex H.
- Database choice: The archive supports DB2, Firebird, H2, MySQL, Oracle, PostgreSQL and SQL Server.
- Runtime requirement: Java 17 or newer is required for the build.
- Docker layout: The Docker deployment separates OpenLDAP, PostgreSQL, the archive, Keycloak and logging services into separate images.
Confirm which database engine and LDAP product your security standards accept, and which versions the archive release you choose has been tested against.
Both archives separate image data from the metadata index, but they differ in which object storage services are available as supported options. Orthanc documents S3, Azure and Google Cloud storage plugins as official, so you can keep DICOM files in cloud object storage while the index stays in a database. For dcm4chee, the supplied material documents the database engines and LDAP configuration but does not list the object storage backends for the release you would deploy. Storage placement affects backup design, retention, egress costs and where patient data physically sits, so this is a point to settle early.
- Orthanc object storage: S3, Azure and Google Cloud plugins are official options.
- Orthanc index separation: Metadata can sit in PostgreSQL while files sit in object storage.
- dcm4chee storage: Confirm with the dcm4chee project which object storage backends the target version supports.
- Backup scope: Object storage, database and LDAP each need their own backup and restore test.
- Data location: Cloud storage regions and key management determine where patient images are held.
Ask the dcm4chee maintainers or your DeployOpen contact to confirm the object storage options for your target release, and check the restore time for a full archive in your own environment.
The number of services each archive needs to run determines how much operational work accumulates over time. A minimal Orthanc deployment can be one process with SQLite and local disk, which means few moving parts. A production Orthanc deployment on PostgreSQL with object storage adds a database service and cloud access management. A dcm4chee deployment typically includes the archive on WildFly, a relational database, an LDAP configuration server, and an identity layer if you use the Docker setup, which documents Keycloak and an OAuth2 proxy for log access. The dcm4chee Docker wiki describes setups from a minimum set of archive services on one host to a secured, distributed Elastic Stack deployment, so the footprint can range widely.
- Orthanc footprint: One server process with optional database and storage plugins.
- dcm4chee footprint: Archive, WildFly, relational database and LDAP run as separate components.
- Identity services: The dcm4chee Docker layout includes Keycloak 26.0.6 for authentication.
- Logging stack: The Docker wiki covers Elastic Stack and Logstash for log management.
- Upgrade surface: Each additional service adds its own patch and compatibility cycle.
Ask each vendor for a reference architecture that matches your site size, and confirm which components your security team must approve before you commit to a design.
Capability comparison across both archives
This table compares Orthanc and dcm4chee-arc-light on the capabilities that drive a self-hosted PACS decision: licensing, release line, runtime, storage, DICOMweb, worklists, viewers, authentication and support. Where the researched facts do not cover a cell, the cell tells you what to confirm with the vendor or your own environment before you commit.
| Capability | Orthanc | dcm4chee-arc-light |
|---|---|---|
| License | Core is GPLv3 or later; scalability and cloud plugins such as PostgreSQL and the web viewer plugin are AGPLv3 or later | Mozilla Public License 1.1 |
| Current release line | 1.13.0, released 2026-08-15 | 5.35.2, published 15 October 2026 |
| Runtime requirement | Native binaries for Windows, macOS and Linux, plus Docker images | Java EE application on WildFly; build requires Java 17 or newer |
| Database back ends | Built-in SQLite index; PostgreSQL, MySQL/MariaDB and ODBC plugins; docs recommend PostgreSQL for large datasets | DB2, Firebird, H2, MySQL, Oracle, PostgreSQL and SQL Server supported by the build |
| Object storage | Official S3, Azure and Google Cloud storage plugins; confirm your target configuration with Orthanc Team | Confirm storage back ends and cloud object options against the current dcm4chee-arc-light documentation |
| DICOMweb | Official DICOMweb plugin; OHIF Viewer lists Orthanc as its main example archive | DICOMweb supported; OHIF Viewer lists DCM4CHEE Archive 5.x as a compatible archive |
| Modality worklist | Official modality worklist plugin | Confirm worklist configuration and SCP scope with the dcm4chee documentation for your release |
| Viewers paired | Orthanc Explorer 2, Stone Web and OHIF viewers through official plugins | OHIF Viewer is documented as compatible; confirm other viewers against your workflow |
| Authentication model | Off by default for remote access; AuthenticationEnabled with RegisteredUsers, plus an advanced authorization plugin | LDAP central configuration; Keycloak 26.0.6 in the Docker reference deployment; confirm identity options for your release |
| Docker support | Official Docker images | Separate images for OpenLDAP, PostgreSQL 12 to 18, WildFly-based archive, Keycloak and logging |
| Paid support path | No paid edition; Orthanc Team sells services and pre-paid dedicated support hours valid for 12 months, quoted on request | Confirm commercial support options directly with the dcm4che project and its vendors |
Orthanc and dcm4chee-arc-light in brief
Orthanc and dcm4chee-arc-light are both open-source DICOM archives, but their license terms, commercial support routes and runtime components differ. The cards below set out the points that shape a PACS decision, from license scope and contributor constraints to the services you would run and patch yourself. Read them before the architecture and effort comparison that follows.
Orthanc core and plugin licenses
The Orthanc core is licensed GPLv3 or later, so an archive that runs only the core carries that license. The scalability and cloud plugins, including the PostgreSQL and web viewer plugins, are licensed AGPLv3 or later, which adds network-use obligations. If your design depends on PostgreSQL, S3 or the web viewer, have counsel review the AGPLv3 terms against how the service will be exposed and distributed before you commit to the architecture.
UCLouvain contributions cannot be dual licensed
Orthanc's copyright is shared by the University Hospital of Liege, Osimis S.A. (now defunct), Orthanc Team SRL and UCLouvain. Contributions from UCLouvain made since September 1, 2021 cannot be dual licensed, so a commercial license cannot replace the open terms for those parts. Ask any vendor offering Orthanc-based products how this restriction applies to the components they deliver and which of them it affects.
No paid Orthanc edition
Orthanc has no paid edition, so the software itself carries no license fee. Orthanc Team SRL sells deployment, configuration and development services, including pre-paid dedicated support hours. Those hours are valid for the period shown here and are quoted on request, so ask what the hours cover, how requests are handled and what is excluded before comparing against a commercial PACS. Staff time for patching and upgrades remains yours in either case.
dcm4chee-arc-light under MPL 1.1
dcm4chee-arc-light is the DICOM Archive Java EE application of the dcm4che project. It runs in WildFly and is licensed under the Mozilla Public License 1.1. Its README describes it as a complete rewrite of DCM4CHEE Archive 2.x, so existing 2.x deployments call for a planned migration. The build supports DB2, Firebird, H2, MySQL, Oracle, PostgreSQL and SQL Server and needs a current Java runtime, so check your JVM and database standards before sizing the team.
dcm4chee Docker stack components
The Docker deployment separates several services you must patch, back up and monitor: an OpenLDAP configuration server, PostgreSQL (versions 12 to 18), the archive on WildFly in plain, secure and secure-ui variants, Keycloak, an OAuth2 proxy for Kibana log access and Logstash. The wiki documents setups from a minimum set of archive services on one host up to the Elastic Stack distributed over several hosts, with or without Docker Swarm. Confirm which variant and topology your security team will accept.
What the Orthanc license split means for your deployment
The Orthanc core and its add-ons do not carry the same license, so your legal review has to cover each component you deploy. The Orthanc core is licensed GPLv3 or later. The scalability and cloud plugins, including the PostgreSQL and web viewer plugins, are licensed AGPLv3 or later. A hospital that runs only the core under GPL terms faces a different set of obligations from one that runs the PostgreSQL plugin and a web viewer as network-facing services. Before go-live, list every Orthanc binary and plugin in the planned build, record its license, and have counsel confirm the obligations that follow from each.
Copyright in Orthanc is held by several parties: the University Hospital of Liege (2012 to 2016), Osimis S.A. (2017 to 2024, now defunct), Orthanc Team SRL (2024 to present) and UCLouvain (2021 to present). UCLouvain contributions since September 1, 2021 cannot be dual licensed, so a commercial license from one rights holder does not change the terms on that code. Ask your counsel to read the project's licensing FAQ and confirm which terms apply to the exact versions you intend to deploy.
AGPL network-use terms are the point most likely to need specific legal advice. Counsel should determine whether a hospital's internal modifications to an AGPL plugin, or a web viewer built on it and offered to clinicians or partner sites, trigger source-offer obligations, and whether those obligations change if the service is reached only on an internal network. Also confirm whether dcm4chee-arc-light, which is licensed under the Mozilla Public License 1.1, raises different questions for your modifications. Have counsel confirm the Open Source Initiative status of each named license for your own records, since this page does not assert it.
How to choose and pilot a PACS archive
This sequence takes a team from sizing its imaging workload to a tested archive that viewers can reach securely and that can be restored. Each step ends with a check you can record before moving on.
Define modalities, volume and access patterns
The clinical imaging lead and the radiology IT owner list every modality that will send images, the expected study and instance volume per year, and who will retrieve images and from where. Include any teleradiology or external reading access, since it changes the network and authentication requirements. The step is done when this inventory is written down and the team agrees on an expected instance count for the first three years. Orthanc's scalability guidance ties the storage choice to instance count, so this number drives the next step.
Choose the database and storage target
The archive owner and the platform engineer decide between the default embedded index and an enterprise database, and between local disk and object storage. Orthanc's scalability FAQ says the built-in SQLite index should be replaced by an enterprise engine once several hundred thousand instances are stored, and it names the PostgreSQL plugin for large datasets. For dcm4chee, confirm the supported database engine and version in its README and Docker setup before you commit. Record the chosen database, storage backend and backup target in the design note, and confirm with the vendor or community how each one is licensed and supported.
Test DICOMweb with your viewer
The integration engineer connects the chosen viewer, such as OHIF or the Stone Web viewer for Orthanc, to the archive over DICOMweb using a test dataset. Confirm that studies list, series load and the viewer can query, retrieve and store through the expected endpoints. The OHIF documentation lists both Orthanc and DCM4CHEE 5.x as configurable DICOMweb archives, but you should still verify the exact configuration against your deployed versions. The step is done when a clinician-style test session opens a full multi-series study from each modality path you inventoried.
Verify authentication, HTTPS and the reverse proxy
The security owner checks the configuration keys that control access. For Orthanc, confirm that remote access is disabled unless needed, that AuthenticationEnabled is true when RemoteAccessAllowed is on, and that users are defined in RegisteredUsers. Place the service behind a reverse proxy with HTTPS for any exposure beyond the local network, as the Orthanc security FAQ recommends. Run a scan or manual check from outside the allowed network to confirm that unauthenticated requests are refused. Record the results and any open findings in the security assessment file.
Run a restore test from backup
The operations lead restores the database and the object or file store into a separate environment and confirms that the restored archive returns the same studies and that the viewer can open them. Test a full restore, not only a backup job's success status. Note the time taken and any manual steps, because that record is what you will use to judge recovery expectations with your own stakeholders. The step is done when a restored copy passes a study-level comparison against the source and the procedure is written as a runbook.
Confirm support paths and upgrade ownership
The procurement lead and the platform owner confirm who answers for each layer: the community, a commercial support contract, or an implementation partner. For Orthanc, the Orthanc Team website describes pre-paid dedicated support hours valid for 12 months, quoted on request, while the software itself has no paid edition. For dcm4chee, identify the support route for the Docker or WildFly build you run. Ask each provider for written response expectations and for their upgrade path. Record the named owner for each layer and the escalation contact before go-live.
Operating effort for Orthanc and dcm4chee in production
The recurring work on a self-hosted archive is what decides long-term cost, and it differs between the two servers. For Orthanc, the main routine is keeping pace with releases. The NEWS file records 1.12.10 on 2025-11-26, 1.12.11 on 2026-04-14 and 1.13.0 on 2026-08-15, and 1.13.0 rewrote storage-area access and DICOM parsing and transcoding. Plan a test cycle for each upgrade that exercises your storage plugin (S3, Azure, Google Cloud or filesystem), your database plugin and any DICOMweb or viewer integrations, because those are the parts most likely to change behavior. For dcm4chee-arc-light, the routine adds a Java 17 or newer runtime, WildFly maintenance, and LDAP configuration, since the LDAP store holds the archive's central configuration. Confirm with the dcm4che project which WildFly and image versions your chosen release expects before you schedule upgrades.
Database operations and the log stack add their own load. Orthanc's scalability FAQ says the built-in SQLite index should be replaced by an enterprise engine once several hundred thousand instances are stored, and it cites production deployments above 65 TB, about 340,000 studies and around 150 million instances. Use those figures as a reference point only and size against your own modality volumes, growth rate and retention rules. The dcm4chee Docker setup runs PostgreSQL, OpenLDAP, Keycloak and an Elastic Stack for logs, so backup, restore testing and patching apply to each of those components, not just the archive. Ask your team who owns each one and how a restore of the whole set is rehearsed.
Security patching and backups should be written as runbooks before go-live. For Orthanc, confirm that RemoteAccessAllowed stays off unless you have set AuthenticationEnabled, RegisteredUsers, HTTPS and a reverse proxy, as the security FAQ describes, and that every plugin version is patched alongside the core. For dcm4chee, confirm the Keycloak realm, the OAuth2 proxy and the LDAP admin credentials are rotated on a schedule. Quotes from Orthanc Team SRL cover deployment, configuration and development, and its dedicated support hours are pre-paid and valid for 12 months. Ask any vendor or partner to show the recurring tasks, named owners and expected hours per month in writing, since those hours are the real operating cost of either choice.
Questions buyers ask before choosing a PACS server
What drives the cost of running Orthanc or dcm4chee?
Neither platform charges a license fee for its core software, so most spending goes to infrastructure and people. Orthanc has no paid edition, and dcm4chee-arc-light is licensed under MPL 1.1. The main cost drivers are storage volume, the database engine you choose, compute for transcoding and the number of instances, and staff time for operations, backups and upgrades. The Orthanc Book scalability FAQ cites production hospital deployments holding more than 65 TB, so storage growth often dominates recurring cost. One-time costs include the initial build and integration with modalities and worklists. Any outside work, such as deployment or support hours, is priced on request. Ask for a written quote that separates setup, recurring support and storage assumptions.
Can a team self-host Orthanc or dcm4chee without outside help?
Yes, if the team already has Linux, container, database and DICOM skills in house. Orthanc runs on Windows, macOS and Linux and is available as Docker images, which makes a small pilot straightforward to stand up. dcm4chee is heavier: it runs in WildFly, requires Java 17 or newer, stores central configuration in LDAP under DICOM PS3.15 Annex H, and supports several database back ends. The dcm4chee Docker wiki covers setups from one host to distributed Elastic Stack deployments. Outside help is optional but commonly used for hardening, integration with your RIS and EMR, and upgrades. Assess the skills gap honestly before you commit to either platform.
How long does a PACS pilot take, and what does it depend on?
No researched figure gives a standard pilot duration, so treat any number you hear as a claim to verify with the provider. Duration depends on how many modalities and worklist integrations are in scope, the volume of studies, identity integration, the security review you require, and whether clinicians must validate the viewing and reporting workflow. Orthanc is usually quicker to stand up for a bounded pilot because its initial configuration is smaller. dcm4chee's LDAP-based configuration model takes longer to learn, but it can pay off in larger, multi-site estates. Ask for a written scope with milestones before work starts, and confirm which acceptance tests end the pilot.
Does Orthanc need PostgreSQL for production use?
Not for a small archive, but you should plan on an enterprise database once volume grows. The Orthanc Book says the built-in SQLite index should be replaced once Orthanc stores several hundred thousand DICOM instances, and it recommends the PostgreSQL plugin for large datasets. Since Orthanc 1.9.2 with PostgreSQL or MySQL plugins 4.0, multiple instances can read and write the same database, which enables horizontally scaled and highly available setups. Check licensing before you deploy: the core is GPLv3 or later, while the PostgreSQL plugin is AGPLv3 or later. Operating PostgreSQL adds recurring work for backups, upgrades, monitoring and connection management, so budget for those tasks as well.
Does dcm4chee need Keycloak for authentication?
The reference Docker deployment in the dcm4chee wiki includes Keycloak 26.0.6 as a separate image alongside OpenLDAP, PostgreSQL and the archive, so the stack is built to expect it. Confirm in the wiki and release notes whether your chosen install path requires Keycloak, and whether your existing identity provider can be used in its place. Orthanc handles access differently. By default it accepts HTTP connections only from localhost. If RemoteAccessAllowed is enabled, AuthenticationEnabled should be true with users defined in RegisteredUsers, and the Orthanc security FAQ recommends HTTPS and a reverse proxy for Internet exposure. Map identity and access requirements before choosing the authentication layer.
How do DICOMweb and OHIF connect to Orthanc or dcm4chee?
The OHIF Viewer connects through a DICOMweb data source. Its DICOMweb documentation lists DCM4CHEE Archive 5.x and Orthanc among the archives it can be configured against, using Orthanc as the main example. Orthanc offers DICOMweb as an official plugin, so the archive exposes the endpoints the viewer requests. Most of the work is in configuration: base URLs, authentication, cross-origin settings and TLS. Confirm the DICOMweb version and endpoints your archive exposes, then test with representative study sets, including large multi-series studies, before clinicians rely on the viewer. Treat the viewer and archive as one tested pair during acceptance.
What does a support engagement from DeployOpen cover?
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, including cloud accounts, data centers and air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers. DeployOpen does not publish a price list, so a quote follows from the written scope. DeployOpen prepares systems and evidence for compliance assessments but does not issue audit reports or certifications. If you want vendor-direct help for Orthanc, Orthanc Team sells deployment, configuration and development services, including pre-paid dedicated support hours valid for 12 months, quoted on request. Compare both scopes line by line.
Where to read next in the healthcare platforms hub
If you are choosing an imaging archive, the next question is usually how images get in front of clinicians. The open-source DICOM viewers compared page covers The OHIF Viewer and Weasis, and notes Orthanc's Stone Web viewer as a plugin option. Use it to check which viewers can be configured against your archive, since the OHIF Viewer documentation lists both DCM4CHEE Archive 5.x and Orthanc as DICOMweb archives it can connect to. Confirm the DICOMweb endpoints and authentication setup for your chosen archive with the viewer vendor or project before you commit to a pairing.
An imaging archive rarely runs alone. Read the open-source hospital information systems compared page to see how Bahmni, GNU Health and OpenMRS assemble inpatient care, lab, pharmacy, billing and imaging. Bahmni's Standard Docker Compose stack runs dcm4chee as its PACS alongside a pacs-integration service, so if Bahmni is on your shortlist, the dcm4chee side of this comparison applies directly. Ask the Bahmni community or the pacs-integration documentation how orders and study references move between the EHR and the archive in the version you plan to run, because that wiring is set by the distribution rather than by the archive alone.
How DeployOpen scopes PACS selection and implementation
DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure, so an archive decision starts with where images will live and who will run them. Engagements are typically fixed-scope, with scope, deliverables and timelines agreed in writing before work begins.
How we scope
- Confirm modality list, study volumes and expected growth before choosing between Orthanc and dcm4chee.
- Record the target database, object storage and identity provider the archive must work with.
- Agree in writing which viewers, DICOMweb clients and integrations are in and out of scope.
How we build
- Deploy the chosen archive in the client's cloud account, data center or air-gapped network.
- Configure remote access, authentication, HTTPS and a reverse proxy before any clinical traffic arrives.
- Connect the viewer and integration services agreed in scope, then test storage and retrieval paths.
How we hand over
- Provide written configuration, network and access documentation tied to the agreed scope.
- Run security testing against the deployed archive and its APIs, with findings documented for remediation.
- Walk operations staff through backup, upgrade and restore procedures in their own environment.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover.
- Plan version upgrades and document their impact on plugins, databases and viewers.
- Prepare systems and evidence for compliance assessments, while independent auditors issue any formal reports.
