Orthanc cost of ownership

Orthanc cost of ownership: what the free core still costs to run

Orthanc has no paid edition, so the cost of running it sits in infrastructure, data growth, integration, support and people. A hospital, imaging network or research group comparing a commercial PACS license with a free DICOM server is really comparing one license line with a set of recurring costs that are easy to miss in a first estimate. The license fee drops out of the spreadsheet, but storage, database operations, backups, viewers, monitoring and the hours needed to keep them working all remain. Teams usually ask for an ownership model at one of three moments: when the annual budget cycle requires a multi-year view, when an existing license is due for replacement, or when a new imaging site is about to connect. Each moment raises a different question about what must be paid for and by whom.

Storage is the cost that grows fastest, so model it first. Orthanc stores DICOM instances, and its documentation says the built-in SQLite index should give way to an enterprise database engine once the server holds several hundred thousand instances, with the PostgreSQL plugin recommended for large datasets. The Orthanc Book cites production hospital deployments holding more than 65 TB of data, 340,000 studies and around 150 million instances, so the growth question deserves a number before the budget is set. Ask for the modality mix, average study size, retention period and expected annual growth. If images will sit in S3, Azure or Google Cloud object storage through the official plugins, the storage provider's recurring charges, egress fees and backup copies belong in the model. Confirm each of those rates with the provider, because they change with region and contract.

People and support are the recurring costs most often underestimated. Orthanc Team SRL sells deployment, configuration and development services, including pre-paid dedicated support hours valid for 12 months, quoted on request. Those hours are one option. The other is internal staff who track releases such as 1.12.10, 1.12.11 and 1.13.0, test upgrades, check database schema changes and cover on-call duties every year. The core is licensed GPLv3 or later, while the scalability and cloud plugins are AGPLv3 or later, so ask counsel how those terms apply if you modify a plugin and offer it to users over a network. In any quote, ask which hours are included, what response coverage applies, who owns plugin versions, and whether unused hours expire after 12 months.

Separate the one-time work from the recurring work in the model. One-time items usually include design, migration, modality worklist and viewer setup, security configuration and acceptance testing. Recurring items include infrastructure, storage growth, database and backup operations, support hours, staff time and access management. Cost rises with study volume, retention length, the number of connected sites and any high availability requirement. Since version 1.9.2 with PostgreSQL or MySQL plugin 4.0, several Orthanc instances can read and write the same database, which is useful for resilience but adds a second node, a load balancer and more monitoring to the bill. Reuse of an existing cloud contract or database skills in-house can lower the recurring line. To decide between building the model in-house or with a partner, list the lines your team can staff, then request a quote that prices only the rest.

What an Orthanc cost of ownership model includes

A cost of ownership model turns a free server into a budget your organization can compare with a commercial PACS license. Each deliverable below answers a different question for finance, IT operations and clinical leadership, and all of them depend on figures from your own quotes and environment.

Component inventory

This lists every software and service piece the archive needs: the Orthanc core, a database back end such as PostgreSQL, an object storage plugin such as S3, Azure or Google Cloud, the viewers, DICOMweb, and the authorization plugin. Each line records its license, its version and whether it is installed, hosted or subscribed. Architects use it to confirm nothing is missing, and procurement uses it to see which lines carry a vendor or service charge.

Storage growth projection

This estimates how much imaging data the archive will hold over time, based on your modality mix, study volumes and retention rules. It separates the database footprint from the object storage footprint, because the two grow differently. Infrastructure owners use it to size disks, buckets and backup targets, and to decide when capacity reviews must happen. Ask your radiology and storage teams for their current volumes before accepting any projection.

Recurring cost sheet

This lists the costs that repeat every year: cloud or data center compute, storage, backup retention, network egress, monitoring, certificates and any support hours you buy. It also separates one-time costs such as migration and setup, so the annual total is not inflated or understated. Finance uses it for budget lines, and it should be checked against your cloud price sheets or hardware contracts rather than generic rates.

Staff time estimate

This records the internal hours needed to run the archive: patching, upgrades, backup restore tests, user administration, incident response and vendor coordination. Because the software is free, staff time is often the largest cost that is not written on an invoice. Engineering managers should name the roles involved, the frequency of each task and who covers absences, then check the estimate against the team's existing on-call rota.

Comparison with a commercial license

This sets the open-source totals beside a quoted commercial PACS license, using the same time period and the same scope for storage, users and modalities. The comparison must include the license, support, hosting, integration and exit terms of the commercial offer, not only the headline fee. Leadership uses it for the decision, and the comparison is only as sound as the written quote it draws on.

Risks and unpriced items

This lists costs and dependencies that a simple spreadsheet tends to miss, such as Orthanc Team support hours, which are pre-paid and valid for 12 months, the need to test upgrades across releases, and the effort of moving to a new database or storage back end later. It also flags items that need confirmation from the vendor or your environment rather than assumptions. Risk owners should review this card before the model is signed off.

Which costs grow with studies, instances and users

This table lists the factors that raise the running cost of an Orthanc archive as it grows, why each one matters, and how to keep it under control. Use it to see which parts of a quote will scale with your volume and which stay roughly fixed. The main takeaway is that storage, database choice and high availability decide most of the growth, not the free software itself.

Driver	Why it moves cost	How to keep it down
Number of instances and studies	Orthanc's built-in SQLite index should be replaced by an enterprise database once several hundred thousand instances are stored, so growth forces a database migration and its effort.	Plan the database choice before the first clinical load; ask the vendor to size the index for your expected instance count.
Total data volume	Storage capacity, backup copies and restore time all scale with the bytes held, and these are paid in your own infrastructure.	Set retention rules early, apply tiering to older studies and size backups against restore-time targets you have agreed.
Growth rate	A fast-growing modality fleet means capacity purchases and quota reviews recur every year, not once.	Measure monthly ingestion from each modality and budget capacity as a recurring line item in your quote.
Modalities and transfer volume	More scanners sending studies increase network load, DICOM association handling and monitoring effort, and each new connection needs configuration and testing.	Group modalities by site, verify throughput during commissioning and add modality connections as scheduled change work.
Number of viewers and concurrent users	Peak concurrent viewing drives server load and web viewer resource needs, and each viewer plugin adds configuration and support scope.	Confirm the viewer plugins you need (such as Orthanc Explorer 2, Stone Web or OHIF) and size for peak, not average, use.
Database choice	Built-in SQLite is simplest at small scale, while PostgreSQL or MySQL/MariaDB plugins add database hosting, backup, patching and DBA skills to the run cost.	Ask whether the quote includes database hosting, backups and upgrades, and what the database engine's support model is.
Object storage use	Object storage (S3, Azure or Google Cloud plugins) bills by capacity, requests and egress in cloud accounts, and adds integration testing.	Confirm which storage tier and egress path apply, and model request volume for viewing and retrieval, not only capacity.
High availability with shared database	Several Orthanc instances reading and writing one database (supported from Orthanc 1.9.2 with the PostgreSQL or MySQL/MariaDB plugins 4.0) add load balancers, shared storage, failover testing and more servers to patch.	Introduce a second instance only when uptime requirements justify it, and include failover tests in the scope of work.
Number of environments and compliance evidence	Each extra environment (test, validation, production) repeats installation, upgrades and security testing, and audit evidence must be collected and kept.	Use infrastructure as code to copy environments, and agree evidence requirements with your assessor before the build starts.

How a cost of ownership study runs from inventory to quote

The study moves from an inventory of current and planned imaging volumes to a written cost model, a staff effort estimate and a handover that finance, clinical and technical owners can check. Each phase closes with a document the client keeps, whether or not the work continues.

Inventory current and planned volumes and modalities
We collect the facts the cost model depends on: current study and instance counts, daily ingest by modality, retention rules, growth expectations for the next few years, and the list of modalities, workstations and external sites that send or receive images. The client provides exports, PACS or archive reports and named owners for clinical and radiology requirements. The step closes with a volume inventory that the client signs off as complete, with open gaps listed by name and owner.
Document the current cost baseline
We record what the existing archive and viewing setup costs today, including licenses, maintenance contracts, hardware, storage, backup, support hours and staff time spent on imaging administration. Figures are taken from invoices and internal time records wherever possible. The output is a baseline table that states its source for each line, so finance can trace every number back to a document.
Define architecture options and component lists
We draft two or three architecture options that meet the inventoried requirements. Each option lists its components: the Orthanc core and the plugins it needs (for example database back end, object storage, DICOMweb, viewers, authorization), the database engine, storage tier, backup target, reverse proxy and hosting model inside the client's environment. Options are compared on what they include and what they leave to the client's team. The step closes when the client confirms which options stay in the model.
Build the three to five year cost model
For each option we build a cost model over three to five years, separating one-time lines (design, configuration, migration work, initial hardware or cloud setup, testing) from recurring lines (storage growth, database and object storage, compute, backups, viewer licenses where applicable, support hours, staff time). Each line states its cost driver, such as data growth rate or number of sites, and its assumption. Changing an assumption updates the model without rebuilding it. The closing check is that every recurring line has an owner and a stated driver.
Estimate the staff effort model
We estimate the effort needed to run each option: installation and upgrades, database and storage administration, backup restore testing, user and access administration, incident response and vendor or partner support. Effort is expressed in roles and hours per activity so the client can compare it with the internal team's capacity. The output is an effort table per option and a list of skills the client must hire or train for. The step closes when the client's infrastructure lead confirms the effort assumptions are realistic for their team.
Review the model with finance and clinical owners
We walk finance, radiology and clinical owners through the cost model, the effort model and the risks each option carries, such as a larger storage footprint, a delayed cutover or a dependency on a single administrator. Reviewers challenge assumptions and we record each change with its reason. The step closes when finance and clinical owners sign off the version they will use for decisions, and open questions are assigned to named people with dates the client sets.
Issue the written handover
We deliver a written handover that contains the final cost model in an editable form, the architecture options and component lists, the effort model, the assumptions register, the review decisions and the list of items the client must confirm with vendors or its own environment. The handover states what was in and out of scope. The study is complete when the client's sponsor confirms receipt and the owners can update the model without us.

Orthanc cost of ownership after go-live: recurring line items

This table lists the recurring cost lines an Orthanc archive carries after go-live, showing for each whether it is one-time or recurring, what drives it, and what to request in a quote. Use it to build a like-for-like comparison against a commercial PACS license, where the software fee is quoted by the vendor and the Orthanc core carries no per-seat fee. The main takeaway is that most of the running cost sits in infrastructure, storage growth, upgrades and staff time rather than in the software itself.

Cost line	One-time or recurring	What drives it	What to request in a quote
Software licensing	Recurring (none for core)	The Orthanc core and most official plugins are GPLv3 or AGPLv3, so no per-seat fee applies. Any commercial viewer or PACS module is priced separately by its vendor.	Written confirmation of each component's license, and vendor-quoted fees for any commercial PACS, viewer or add-on
Hosting or data center capacity	Recurring	Number of servers, CPU and memory for the Orthanc instances, and whether they run in the client's cloud, data center or air-gapped network	Compute and network sizing for production, test and disaster recovery environments, and who pays the hosting provider
Object storage and backup storage growth	Recurring, growing	Imaging volume per year, modality mix, compression and transfer syntax, and retention period. Official S3, Azure and Google Cloud plugins change the billing model.	Expected instance and study growth per year, retention rules, and storage tier and egress assumptions for each cloud provider
Database operations	Recurring	Choice between the built-in SQLite index and the PostgreSQL or MySQL/MariaDB plugins, plus the number of instances sharing one database, backup frequency and patching	Database engine version, high availability design, backup and restore testing, and who performs routine maintenance
Viewer licensing	Recurring where a viewer is commercial	Choice of Orthanc Explorer 2, the Stone Web or OHIF viewers, or a third-party viewer, and the number of users or sites using it	Confirmation of each viewer's license terms and any vendor fee, stated per user, per site or per server
Support hours	Recurring if purchased	Orthanc Team sells pre-paid dedicated support hours valid for 12 months. Hours consumed depend on incident rate, change requests and how much the internal team handles itself.	Number of hours in each block, the validity period, the rate and the escalation path, quoted on request by Orthanc Team
Upgrades and testing per release	Recurring	Each core and plugin release, such as 1.12.10, 1.12.11 and 1.13.0, needs regression testing against the local workflows, database schema checks and a planned change window	Estimated effort per upgrade cycle, test environment needs and whether the upgrade is covered by a retainer or billed per change
Monitoring and logging	Recurring	Number of instances, alerting targets, log retention and whether the client's existing monitoring stack can collect Orthanc metrics	Tooling to be licensed or reused, retention period, and who responds to alerts out of hours
Certificates and key management	Recurring	Number of HTTPS endpoints behind the reverse proxy, DICOM TLS links to other sites, and certificate renewal cadence	Certificate authority used, renewal process, and whether the client or a partner owns renewal and rotation
Internal staff time	Recurring	Administration, user access requests, incident response, release reviews and vendor coordination. Often the largest line in the long run.	Expected role split between client staff and partner, and the number of internal hours per month the client should plan for

Why the free core still has license terms to check in the model

The Orthanc core is only one license in the stack. The core is licensed under GPLv3 or later, while the scalability and cloud plugins, including the PostgreSQL and web viewer plugins, are licensed under AGPLv3 or later. A cost model that treats the whole archive as one free product will miss that the database back end and the viewer carry a different license from the server. Each component on the bill of materials should carry its own license entry, its version and its role in the design, because plugins can be added or swapped during the life of the archive. Record the license next to each line item before the software cost is discussed, so finance and counsel can see the review from the start.

The AGPL differs from the GPL in one respect that matters for archives: it contains a network clause. In broad terms, the clause can apply when a modified version of a program is made available for users to interact with over a network, even where no copy of the software is distributed. Whether it is triggered depends on which plugin is modified, what the modification is, and how users reach it, including clinicians, referring sites or external viewers. Running an official plugin without modification is a different position from running a custom build, so the cost model should keep the two apart. Ask the client's counsel to confirm where that line sits for the planned design and write the answer down, because a later custom viewer change could move the deployment across it.

Copyright in Orthanc is shared among several parties. The University Hospital of Liege holds copyright for 2012 to 2016, Osimis S.A. for 2017 to 2024 (the company is now defunct), Orthanc Team SRL for 2024 to present, and UCLouvain for 2021 to present. The practical consequence is that no single company can grant a commercial exception covering the whole code base. UCLouvain contributions made since September 1, 2021 cannot be dual licensed, so a commercial license offer from one party would not cover those contributions. The cost model should therefore not assume that a vendor can sell a relicensed copy that removes the open-source terms. Treat the license position as a property of the code and its history, and confirm it against the specific releases in scope.

Turn these terms into inputs for the model. Add a licensing column to the component list that records the license, the version tested, whether the component is unmodified, and which users reach it over a network. Assign an owner for the inventory and a review point at each upgrade, because a release such as 1.13.0 or a newly added plugin can change the list. Ask Orthanc Team in writing to confirm the license terms of the specific components and versions in scope. In the quote, ask the implementation partner to state whether the license inventory is part of the fixed scope, who keeps it current after go-live, and which changes would trigger a new review. The client's counsel confirms any obligation that follows from these terms. This section describes license terms for planning purposes and is not legal advice.

How the cost changes by starting point and hosting

Replacing a commercial PACS removes the license line, but it does not remove cost. The Orthanc core is free to obtain under the GPLv3 or later license, so the spending moves into work that someone must perform: moving studies, running two systems for an overlap period and retraining staff. Illustrative example: a hospital retires a vendor PACS when its contract ends, keeps the old system available read-only for a period, and trains clinicians on the new viewer before cutover.

Migration effort: Transfer, verification counts and identifier mapping are paid as services or staff hours, and they grow with archive size and the number of source systems.
Parallel running: Hardware, support contracts and any read access to the old system continue until the overlap period ends.
Staff training: Radiologists, technologists and administrators need training on the new interface. Most of this cost is staff time.
Integrations: Modality connections, worklists and viewers must be rebuilt or confirmed, which is one-time build work.
Ongoing support: Orthanc Team sells pre-paid dedicated support hours valid for 12 months, quoted on request, so recurring support is a service purchase rather than a license fee.

Confirm what the old contract covers after cutover, how long read access must remain available, and who owns migration verification.

Orthanc cost of ownership surprises that appear after go-live

Orthanc has no license fee, so most of its running cost sits in storage, databases, backups, upgrades, support hours and staff time. The surprises below tend to appear months after go-live, when the cost model no longer matches how the archive is used.

Storage growth underestimated

Storage is often sized from the raw size of one study, which leaves out compression settings, retention periods and re-transfers from modalities or peer archives that store the same instances twice. Before go-live, model monthly ingest by modality group, apply the retention period agreed with the clinical and records teams, and add an allowance for re-transfers. In the cost model, keep a growth table with one row per modality group, showing compressed size, retention and yearly total. Ask any quote to show these inputs.

Backup copies left out

The primary storage is only one copy of the archive. Database dumps, object storage snapshots and any off-site or immutable copy required by the client's backup policy each consume additional storage and operator time. Confirm the backup scope with the client's backup owner before sizing, and include a restore test in the plan, since a copy that has never been restored is not yet a backup. In the cost model, add a recovery line that lists each copy, its location, retention and storage consumed, plus recurring restore test effort.

Database outgrowing the built-in index

Orthanc's built-in SQLite index is a single file, and the Orthanc Book scalability FAQ advises replacing it with an enterprise database engine once the server stores several hundred thousand DICOM instances. Choose the database engine during design, and plan the PostgreSQL plugin if the archive is expected to grow large. If the archive already runs on SQLite, schedule the move as a separate one-time task. In the cost model, record the database migration, database hosting and tuning as one-time items, and database administration as a recurring line.

Upgrades queued behind change control

Core releases such as 1.13.0, released on 2026-08-15, and plugin updates for viewers and storage connectors each need testing before they reach clinical systems. When clinical change control meets only on a fixed calendar, these upgrades queue, and the archive drifts onto old versions with known fixes missing. Agree a standing change category for routine Orthanc and plugin upgrades, keep a test environment that mirrors production, and publish an upgrade calendar. In the cost model, record recurring test and change board time for each release cycle.

Support hours expiring mid-year

Dedicated support hours sold by Orthanc Team SRL are valid for 12 months, so a block bought at the start of the year can run out before the year ends. Incidents and change requests that arrive late in the year then have no funded hours behind them. Before purchase, map expected incident and change volume to the hours, track consumption monthly, and decide in advance whether to buy a second block or move to a retainer. In the cost model, show hours used, hours remaining and the expiry date for each block, and ask quotes to state validity terms in writing.

Configuration known by one person

Routing rules, plugin settings, authorization configuration and maintenance scripts often live with the engineer who built them. When that person leaves, the archive keeps running, but changes become slow and risky, and external support hours are spent rediscovering decisions. Keep configuration in version-controlled files, write runbooks for routine and emergency tasks, and cross-train at least two named operators. In the cost model, add one-time time for documentation and cross-training, a recurring refresher line, and a contingency for external help if a key person leaves.

What finance, IT and clinical owners provide for a quote

An accurate cost of ownership estimate for an Orthanc archive depends on the inputs the client supplies before any quote is written. Because the Orthanc core is free to use, the quote is driven almost entirely by how much data the archive will hold, how it is hosted, who operates it and what evidence the organization must keep. Missing inputs do not stop a quote, but they widen the range, and a wide range makes the comparison with a commercial PACS license hard to defend to finance. Start with the imaging volume. Ask for the current study and instance counts, the growth history over the last two to three years, and a projection for the next three to five years, stated as separate figures for modalities that produce large series (CT, MR, digital pathology where applicable) and those that produce small ones. Include the modality list with AE titles, the daily transfer volume in each direction and the peak hour. Compare these figures with the scale the Orthanc Book reports for production hospital deployments, which is useful context but not a sizing guarantee for your site. Retention and recovery decide much of the storage bill. Ask for the written retention policy by modality and study type, the rule for deleting or migrating old studies, and the backup and disaster recovery targets, including how long the archive may be unavailable and how far back a restore must reach. Ask for the hosting options already in use, such as cloud object storage, on-premises storage arrays or a data center contract, and the rates currently paid for them. Where a commercial PACS quote exists, request it in full, including maintenance, support, storage and interface fees, so the two options can be compared line by line. Name one accountable owner each for finance, infrastructure, clinical sign-off and security. Finance confirms the cost model and budget period. Infrastructure confirms hosting, network and backup standards. Clinical sign-off confirms which studies, reports and workflows the archive must support and who accepts the cutover. Security confirms the access model, audit expectations and any compliance evidence the organization needs, such as control mappings for its assessor. DeployOpen prepares systems and evidence for these reviews but does not issue audit reports or certifications, so the owner for compliance should confirm with the relevant auditor what evidence they will accept. Ask for the written scope and the quote assumptions to be shared back for review before work starts. Confirm which items are one-time (design, migration, testing, integration) and which recur (hosting, storage growth, backups, support hours, staff time, upgrades). Pre-paid support hours offered by Orthanc Team SRL are quoted on request and are valid for 12 months, so ask whether they are in scope and how unused hours are handled.

Orthanc cost of ownership questions buyers ask

Does Orthanc have a license fee to pay?

No. Orthanc has no paid edition, so there is no license fee to buy. The Orthanc core is licensed under GPLv3 or later, and scalability and cloud plugins, such as the PostgreSQL and web viewer plugins, are licensed under AGPLv3 or later. The money you spend shifts to infrastructure (servers, storage, database hosting, backups, network), data (growth and retention), support (vendor or partner hours) and people (the staff who install, configure, monitor and upgrade the system). Because the AGPL has obligations that differ from the GPL when software is offered over a network, ask your legal or licensing advisor to confirm what applies to your planned use before you deploy.

What drives the running cost of an Orthanc archive?

The running cost depends on your own volumes and design choices, so no single figure applies to every archive. The main drivers are data volume and growth (instances, studies and how fast they accumulate), database choice (the built-in SQLite index is meant for smaller archives, and the Orthanc documentation says to move to an enterprise engine such as PostgreSQL once you store several hundred thousand instances), storage type (local disk or object storage such as S3, Azure or Google Cloud), backup and retention rules, availability design (several instances can share one database), the number of viewers, plugins and modality connections, and hosting environment and staffing. For scale context only, the Orthanc Book cites production hospital deployments holding more than 65 TB, 340,000 studies and around 150 million instances. Ask any partner for a cost sheet that prices each driver separately.

How long does an Orthanc cost study take?

The duration is set by the scope you agree. Most DeployOpen engagements are fixed-scope, so the scope, deliverables and timeline are written down before work starts. The number of sites, the number of modalities and integrations to document, how much storage history you need to model, whether you need hosting options compared, and how quickly your team can supply data all change the schedule. Ask for the timeline in the written scope, along with the dependencies that could move it, such as access to current storage reports and named contacts in radiology IT and finance.

Can our own team build an Orthanc cost model without a partner?

Yes. A capable internal team can build the model using the component list and cost sheet on this page. Start by inventorying each component (compute, database, object or file storage, backup, network, viewers, plugins, monitoring and staff time). For each line, record whether the cost is one-time (installation, migration, initial configuration) or recurring (hosting, storage growth, support, backup retention, patching labor). Then add growth assumptions for studies and instances, and run a low, expected and high scenario so finance can see which drivers matter most. Have finance and your hosting provider validate the unit prices, since these vary by region, contract and environment. Engage a partner only where you lack skills, such as database migration or security testing.

What inputs does an Orthanc cost study need from our side?

The study needs readiness inputs from your organization before it can produce a reliable estimate. Prepare current study and instance counts, historical growth figures, and the list of modalities, PACS or archive sources and DICOM clients that will connect. Document your hosting constraints (cloud region, data center, air-gapped network), retention and backup rules, identity and access requirements, and any compliance obligations that affect storage or logging. Also state the availability and support expectations, the viewers your clinicians use, and the named owners who can approve decisions. Missing inputs usually show up later as wide cost ranges, so agree on who will provide each item and by when.

How is Orthanc support priced?

Orthanc Team, the company that sells Orthanc deployment, configuration and development services, offers pre-paid dedicated support hours that are valid for 12 months. These hours are quoted on request, so there is no public rate card to compare. When you request a quote, ask for the number of hours, the rate basis, what the hours cover (incident response, configuration help, plugin questions, upgrade assistance), how unused hours are handled at expiry, and how urgent requests are routed. Separately, DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and those are also quoted from a written scope.

How DeployOpen scopes, models and hands over Orthanc costs

DeployOpen approaches Orthanc cost of ownership as a written, fixed-scope piece of work inside your own infrastructure. We model the recurring costs that come with a free core, such as storage, database, backups, viewers and support hours, so the figures in your decision file trace back to a defined architecture.

How we scope

Confirm the expected instance count, study volume and growth rate with your radiology and IT teams before any cost model is written.
Record which plugins, viewers and modality connections the design needs, since each one adds build, test and upkeep work.
Agree deliverables, assumptions and timelines in writing, and list which costs you pay directly to cloud, storage or staff providers.

How we build

Model the database and object storage tiers against your expected growth, including backup copies and retention periods you set.
Test the chosen storage and database plugins in a staging environment so the cost assumptions match measured behavior on your hardware.
Document each cost line, its owner and the trigger that would change it, such as a new modality or a larger archive.

How we hand over

Deliver the cost model as a spreadsheet with inputs, formulas and the assumptions behind each recurring line item.
Walk your finance, IT and clinical owners through which costs are one-time and which recur each year.
Provide runbooks for backup, restore and capacity checks so your team can update the model as volumes change.

How we support

Engagements are fixed-scope, and ongoing support, upgrades and testing are available as a retainer if you want continuity.
Review the cost model when Orthanc or a plugin releases a version that changes storage, database or resource behavior.
Confirm with Orthanc Team SRL the terms of any pre-paid dedicated support hours, since they are quoted on request and sold separately from the software.