Orthanc implementation plan and cost

What an Orthanc implementation involves

Orthanc has no paid edition, so the cost of an implementation is the cost of the work around the software: planning the archive, configuring it, connecting modalities and viewers, testing, and keeping it supported. Budget requests should separate these items rather than treat the server as a line item. Ask any partner to price each one on its own, with a clear statement of who performs it and what they hand over.

Most mini-PACS or imaging archive projects start from one of four situations: a new archive for a department or study, a research or teaching imaging store that needs DICOM access without a commercial license, a regional sharing point between sites, or a replacement for an aging system. The trigger matters because it sets the volume of instances, the number of connected modalities and viewers, and how long the data must be kept. Teams with a Linux administrator, a database owner and a clinical or research contact who can test workflows often build the first version in-house. Teams that lack DICOM network experience, or that must meet an internal audit date, often bring in a partner for the design and first cutover, then keep the in-house staff as operators.

The Orthanc core is licensed GPLv3 or later, while several official plugins, including the PostgreSQL and web viewer plugins, are licensed AGPLv3 or later. The obligations differ when you modify, host or distribute code, so licensing review belongs in planning, not after the build. Ask legal or counsel to confirm which components the design uses, whether any custom plugin or viewer change will be distributed or offered over a network, and how those obligations affect vendor agreements. Record the answer in the scope document so that it is not re-decided at each upgrade.

What the work includes

A typical Orthanc engagement covers the workstreams below. Each one ends in a named deliverable that your team keeps and operates after handover.

Architecture and sizing

Defines how many Orthanc instances, databases, storage back ends and network zones the archive needs, and how it sits beside your existing PACS and modalities. Sizing starts from expected instance counts, study growth and peak ingest, which you should provide. Deliverable: an architecture decision record with a sizing worksheet and diagram.

Database and storage choice

Compares the built-in SQLite index with the PostgreSQL, MySQL/MariaDB and ODBC plugins, and local disk against S3, Azure or Google Cloud object storage. The Orthanc docs advise moving off SQLite once the archive holds several hundred thousand instances. Deliverable: a documented database and storage selection with the reasoning and migration path.

Plugin selection

Chooses which official plugins to enable, such as DICOMweb, modality worklists, the database and object storage plugins and the advanced authorization plugin, and checks their license terms. Each plugin adds a version to track during upgrades. Deliverable: a plugin register listing versions, licenses and the reason each is enabled.

Viewer selection

Decides between Orthanc Explorer 2, Stone Web and OHIF for clinical and administrative users, based on the viewing features each group needs and the browsers they use. Viewer choice also affects which authorization approach fits. Deliverable: a viewer decision with a test set of studies and the configuration for the chosen viewers.

DICOM and DICOMweb connections

Configures DICOM association settings for each modality, PACS and remote site, including AE titles, ports and modality worklist queries. Confirm each device's supported transfer syntaxes and whether TLS is required before go-live. Deliverable: a connection inventory and tested store, query and worklist transactions per device.

Access control

Sets who can read, upload, export and administer studies, and how users sign in. The built-in user list is simple but limited, so the choice between it and an external token-checking service depends on your identity model. Deliverable: an access model document and the configured authentication and permission settings.

Backups and restore testing

Designs backups for the metadata database and the object or file storage separately, then tests restoring a sample of studies to confirm both halves match. Backup frequency and retention should come from your clinical and records policies. Deliverable: a backup design and a recorded restore test with its results.

Monitoring and alerting

Defines the health checks, storage capacity thresholds, database status and DICOM connection failures that the archive reports. Alerts should reach the team that answers them at night as well as during business hours. Deliverable: monitoring configuration, alert rules and a list of tested alert paths.

Runbooks and handover

Writes the procedures your team follows for routine tasks, incidents, plugin updates and restores, then runs a handover session to transfer operation. Confirm who owns each runbook after handover and how upgrades will be tracked. Deliverable: a runbook set, an operations guide and a recorded handover.

What drives cost and duration

Each row names one factor that changes the scope of an Orthanc implementation, why it moves cost or schedule, and what the client can do to keep it contained.

Driver	Why it moves cost or effort	How to keep it down
Modalities and PACS or archive sources	Each modality, legacy PACS or archive needs its own DICOM connection, AE title configuration, routing rules and test transfers, and each source adds mapping work for patient and study identifiers.	List every source with its DICOM role (sending, receiving or query) and version before the quote, and phase in sources that are not needed at go-live.
Instance and study volume	Volume sets the sizing of storage, the database and backup windows, and it decides whether the built-in index is enough. The Orthanc Book cites production hospital deployments above 65 TB, 340,000 studies and around 150 million instances, so the range is wide.	Ask for a current count of studies and instances and a yearly growth estimate from the client's own systems, then size the design against that figure rather than an assumed one.
Database engine and timing of the move off SQLite	The Orthanc Book says the built-in SQLite index should be replaced by an enterprise engine once the store holds several hundred thousand instances, and it recommends the PostgreSQL plugin for large datasets. Choosing PostgreSQL early adds installation, backup and migration work, while moving later adds a data migration.	Decide the engine during planning based on expected volume. If the archive starts small, confirm the threshold and the migration path with the vendor and the partner before go-live.
Viewers and their integrations	Each viewer (Orthanc Explorer 2, Stone Web, OHIF or a third-party viewer) needs its own configuration, access testing and, where it is not bundled, plugin deployment. Clinical workflow integrations, such as launch from a worklist or a PACS viewer link, add interface testing.	Limit the first release to the viewers that clinical users actually need and document the launch URLs and supported browsers before the build starts.
DICOMweb and modality worklist needs	DICOMweb and the modality worklist plugin each add endpoints, client configuration and test cases. Worklists also depend on the scheduling system and demand testing with each modality model.	Name the DICOMweb clients and modalities that will use these services, and test them against a fixed list of devices rather than all devices in the department.
Authentication model	The built-in RegisteredUsers list needs little setup but gives limited per-study control. The advanced authorization plugin with an external token service adds a service to build, deploy and secure, plus identity provider integration, and it shifts ongoing ownership to the team that runs that service.	Decide early whether per-study permissions and central identity are required. If they are not, start with RegisteredUsers and plan the authorization plugin as a later phase.
TLS and reverse proxy requirements	Remote access requires HTTPS, usually through a reverse proxy, with certificate management and access rules. DICOM TLS for inter-site exchange, supported from version 1.9.0, needs certificate exchange with each partner site and adds testing per connection.	Agree on the network zones and the certificate authority before the quote, and list which connections truly need DICOM TLS rather than applying it everywhere.
High availability with multiple instances on a shared database	The Orthanc Book says multiple instances can read and write the same database from version 1.9.2 with PostgreSQL or MySQL plugin 4.0 or later. Load balancing, shared object storage, failover tests and monitoring add design and verification effort on top of a single-server build.	Confirm the availability target with the clinical owner first. If a single instance with tested restore meets it, avoid building a cluster in the first phase.
Environments and compliance evidence	Separate development, test and production environments, change control and the records that a compliance assessor expects (access reviews, backup restore tests, configuration baselines) add build and documentation work. DeployOpen prepares evidence for assessments but does not issue audit reports or certifications.	Ask which environments are required and which controls the organization must evidence, then agree on a short list of evidence items in the written scope.

Project phases and outputs

The sequence moves from agreed requirements and sizing to a validated, documented Orthanc archive that your team can operate after handover.

Run discovery and requirements
We interview clinical, imaging IT and security stakeholders, inventory the modalities, PACS or archives and viewers in use, and record data volumes, retention and access rules. The output is a written requirements document that states which Orthanc plugins, viewers and modality connections are in scope. The step closes when you sign off that document.
Design architecture and sizing
We choose the database back end, storage back end and whether one or several Orthanc instances are needed, based on the requirements. We size compute, storage and network from expected instance counts and growth. The output is an architecture decision record and a sizing sheet that you review before any build starts.
Build development, test and production environments
We provision the three environments in your infrastructure, whether cloud accounts, data centers or air-gapped networks, and install Orthanc from the agreed release. Configuration is kept in version control so each environment is built the same way. The step is done when each environment starts, responds to a health check and is documented.
Configure database and storage
We set up the database engine and the storage area, using the PostgreSQL, MySQL or ODBC plugin and file, S3, Azure or Google Cloud storage as decided in design. We confirm backup and restore paths for both the index and the stored files. The output is a tested restore of a sample dataset and the configuration record.
Set up plugins and viewers
We install and configure the selected plugins, such as DICOMweb, worklists, Orthanc Explorer 2 and the chosen viewer, and confirm each version is compatible with the core release. Viewer access is tested with representative studies. The output is a plugin and viewer matrix showing versions and settings.
Test modality and DICOM connections
We register each modality, PACS or remote site and run storage, query and retrieve tests with real or test instances agreed with your imaging team. We check transfer syntaxes, AE titles and any DICOM TLS settings. The step closes with a connection test log for every link in scope.
Configure security and validate
We apply the remote access, authentication, HTTPS and reverse proxy settings from the security design, disable the dangerous REST routes, and set up user or token-based access. We then run the agreed acceptance tests covering data integrity, access control and failover where it applies. The output is a test report and a list of any open findings.
Cut over and hand over
We move production traffic to the new archive according to the agreed cutover plan and monitor the first operating period. We deliver runbooks, configuration records, backup and restore procedures and training for your operators. Handover is complete when you accept the documentation and the support arrangement in writing.

What teams keep in-house and what they outsource

This table compares the Orthanc work that stays with the client's clinical and PACS staff against the technical build that is often outsourced, with the skills each row needs.

Work area	Usually kept in-house	Often outsourced	Skills the work needs
Clinical workflow owners	Define which studies, departments and reading workflows the archive must serve	Document the workflow requirements back into a written scope for the build	Radiology workflow knowledge, clinical sign-off authority
PACS administrator decisions	Decide retention rules, AE titles, who may query or delete studies, and cutover timing	Translate those decisions into Orthanc configuration and a runbook	PACS administration, DICOM conformance statements, change control
Network and modality configuration	Own modality IP addresses, firewall rules and hospital network segmentation	Prepare test C-STORE, C-FIND and C-MOVE scripts and check results against the plan	DICOM networking, TCP and firewall administration, VLAN design
Data governance	Approve data classification, access reviews, de-identification rules and retention schedules	Implement the agreed rules in configuration, logs and backup policies	Data protection law awareness, records management, audit logging
User acceptance	Run acceptance tests with real clinical users and sign off on viewer behavior	Support test cases, defect triage and fixes found during acceptance	Clinical QA, test case design, viewer usage (Orthanc Explorer 2, Stone Web or OHIF)
Architecture	Approve the target design, sizing assumptions and risk acceptance	Design the storage, database, plugin and environment layout as a fixed-scope deliverable	Systems architecture, Linux, container operations, capacity planning
Orthanc and plugin configuration	Review settings that affect patient data, such as remote access and scripting routes	Configure Orthanc core, PostgreSQL or object storage plugins, DICOMweb and viewers	Orthanc configuration, DICOMweb, PostgreSQL administration, Linux
Database and storage build	Provide storage capacity, backup targets and retention periods	Build the PostgreSQL database, object storage bucket and restore procedure	PostgreSQL administration, S3 or Azure object storage, Linux, backup tooling
Authorization integration	Decide which roles and groups may see which studies	Integrate the advanced authorization plugin with the token service and identity provider	Identity integration, OIDC and Keycloak, web service development
Automation, testing and runbooks	Own the operational runbooks and approve their use after handover	Script deployments, automate tests and write the operating and recovery runbooks	Container operations, infrastructure as code, shell scripting, incident response

What usually goes wrong

These are the failure patterns that most often affect Orthanc archives. Each card names a check to ask the partner to include in the scope.

Staying on SQLite too long

The built-in SQLite index suits small trials. The Orthanc docs recommend an enterprise database engine once the archive holds several hundred thousand DICOM instances, and the PostgreSQL plugin for large datasets. Moving later means a second data migration under production load. Ask the partner to size the database against your expected instance count and include the plugin setup in scope.

Modality and AE title gaps

Each modality, workstation and peer archive needs a matching AE title, host and port on both sides before any study flows. Mismatches can be hard to diagnose from the viewer, and conformance and transfer tests are often skipped. Ask the partner to document every device's configuration at both ends and test storage, query and retrieve with each one before go-live.

Remote access without authentication

By default Orthanc accepts HTTP connections only from localhost. Enabling RemoteAccessAllowed without AuthenticationEnabled, defined RegisteredUsers and HTTPS exposes patient images to anyone who can reach the port. The security FAQ recommends HTTPS and a reverse proxy for Internet exposure. Ask the partner to set authentication, users, TLS termination and network limits in scope, then test access from outside the network.

Script and export routes left enabled

The security FAQ warns that the /tools/execute-script route can let a malicious user run any system command, and that the export route can overwrite files. Both are easy to leave enabled from early testing. Ask the partner to disable them in every environment, verify the deployed configuration, and record the review in the hardening checklist.

Plugin versions out of step with core

Plugins load into a specific Orthanc core, so a core upgrade can leave a plugin built for a different version. Releases such as 1.12.10, 1.12.11 and 1.13.0 each need a compatibility check before the upgrade is scheduled. Ask the partner to pin plugin versions in the scope, test the upgrade on a staging copy, and include compatibility checks in the upgrade plan.

Restores that were never tested

A backup that has never been restored is an assumption. The database, storage area and configuration must be restored together, because a backup taken at different times can leave the index out of step with the stored files. Ask the partner to run and document a full restore into a separate environment, measure the result, and repeat it after major changes.

How the work changes by starting point

A new archive with no existing PACS starts from a blank configuration, so the work centers on design decisions rather than data movement.

Scope: server build, storage area and database choice, modality connections, viewers, user access and backups.
Drivers: expected study volume, how many modalities send images, and whether clinicians need a web viewer on day one.
Decisions: whether SQLite is enough for the first phase or PostgreSQL is chosen from the start, and which official plugins are required.
Verification: test C-STORE and C-FIND from each modality, then restore a backup to a clean host.
Confirm with the vendor or your team: the expected study volume and growth rate, since these set the database and storage sizing.

What the client needs to provide

Before any Orthanc work is scheduled, the client needs to name a business owner and a clinical or research sponsor who can make decisions about scope, priorities and trade-offs. The implementation team also needs an inventory of every modality, PACS and archive source that will send or receive studies, with each device's DICOM AE title, IP address, port and role (store, query, retrieve or worklist). Missing or duplicated AE titles are one of the most common causes of delay in a modality connection phase, so this inventory should be reviewed by whoever manages the imaging network.

Network information is the second input. Confirm the network paths between modalities, the Orthanc host and any external sites, and the firewall rules that must be opened in each direction. Ask for expected study volumes per modality, current growth, peak daily load and the retention period the business expects. These figures set the storage sizing, database choice and backup scope in the quote. Access to the hosting environment (cloud account, virtualization platform or data center tooling) and the identity source decision, such as local accounts, LDAP or an existing identity provider, should also be settled in advance.

The client should provide a written backup and retention policy, including how long studies, audit logs and database snapshots are kept and where recovery copies must reside. Supply a test dataset that matches production characteristics: the same modalities, transfer syntaxes, compression types, multi-frame and large-series studies, and a realistic mix of patient and study metadata, de-identified where required. Name the people who will accept each phase, such as imaging informatics, radiology operations and security, and agree how acceptance will be recorded.

Patient data handling and data processing agreements must be settled with the client's legal and privacy team before any real or copied patient data is moved into a test or staging environment. Confirm the lawful basis, the data processor terms, the location of storage and any cross-border transfer limits. Ask the legal and privacy team to confirm whether de-identified test datasets are acceptable and who approves their creation.

Frequently asked questions

If Orthanc is free, why does an implementation still have a cost?

Orthanc has no paid edition, so the cost sits in the work around the software. Ask for a quote that lists each component separately: planning and architecture, database and storage setup, plugin configuration, viewer integration, modality connections, testing with your own studies, builds for test and production environments, documentation, staff training and handover. Each line is either work someone is paid to do or time your staff spends. DeployOpen does not publish a price list. A quote follows from the written scope, so the scope document determines the number.

How long does an Orthanc implementation take to complete?

The timeline comes from the written scope, not from a generic template. The main drivers are the number of modalities and sites to connect, whether you are migrating existing studies, the database choice, how many viewers and plugins you need, and how many environments must be built and tested. Your own change approval and testing windows also set the pace. Ask for the phases that depend on your staff, such as access to modalities, network changes and sign-off, because a timeline without those dependencies is hard to plan against.

Can our in-house team implement Orthanc without a partner?

Yes, a capable team can, if it has the skills and time. Required skills typically include Linux or Windows server administration, Docker, networking, and DICOM concepts such as AE titles, C-STORE and worklists. Database administration is needed if you use PostgreSQL. The Orthanc Book documents configuration options, plugins and the REST API, so much of the configuration is covered there. The documentation does not decide your architecture, the security settings for patient data or your test plan. Assess those gaps honestly before choosing.

Do Orthanc vendor support hours replace an implementation partner?

No, not in general, because they cover different work. Orthanc Team SRL sells deployment, configuration and development services, including pre-paid dedicated support hours valid for 12 months, quoted on request. Those hours suit targeted questions and fixes. An implementation partner owns the scope, the plan, environment builds, testing and handover against your requirements. Compare what each option covers in writing, and check whether the hours would be used during the build or after go-live.

Which database should we choose for Orthanc, SQLite or PostgreSQL?

SQLite is the built-in index. The Orthanc documentation advises replacing it with an enterprise database engine once Orthanc stores several hundred thousand DICOM instances, and it recommends the PostgreSQL plugin for large datasets. Decide early if you expect growth, several Orthanc instances or high availability. Since Orthanc 1.9.2 with PostgreSQL plugin 4.0, multiple instances can read and write the same database. MySQL/MariaDB and ODBC back ends are also available. Switching databases later adds a migration step of its own.

What must our team provide before an Orthanc implementation starts?

Before work starts, the partner needs the inputs the scope depends on. Typical items are a list of modalities and PACS or archives with their AE titles, network paths and firewall rules, a storage location with capacity expectations, identity and access requirements, the viewers your clinicians use, a named technical owner, a sign-off contact, and sample studies approved for use in non-production environments. Confirm each item in the written scope, including who approves changes to the production network.

How DeployOpen scopes and delivers Orthanc work

DeployOpen plans, implements, configures, hardens and documents Orthanc inside infrastructure you control, from database and storage choices through viewers and modality connections. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.

How we scope

The written scope lists the Orthanc version, database back end, storage target and plugins to be delivered.
Modality connections, viewers and expected instance volumes are recorded so the design matches your imaging workflow.
Environments such as development, test and production are defined, with the environments each deliverable covers stated.

How we build

Installation, configuration and plugin setup are carried out on the platforms and networks you specify.
Remote access, authentication and dangerous REST routes are configured and tested against the agreed security settings.
Test results for DICOM transfers and database behavior are recorded and reviewed with your team before sign-off.

How we hand over

Documentation covers the deployed architecture, configuration files, plugin settings, backup procedures and restore steps.
Your team receives runbooks for routine operations, upgrades and troubleshooting of modality connections.
A handover session walks your administrators through the running system, with open items listed in the closing report.

How we support

Ongoing support, upgrades and testing are available as a retainer, scoped in writing separately from the build.
Orthanc upgrades are planned and tested against your plugins and database schema before any production change.
Support scope, response expectations and included hours are confirmed in the written agreement, not assumed in advance.