How the OHIF viewer reaches Orthanc studies with the official plugin
A team that already runs an Orthanc server and needs clinicians or researchers to read studies in a browser has a supported route: the official OHIF viewer plugin. The plugin runs the OHIF zero-footprint viewer in the user's browser and points it at Orthanc's own web interfaces, so no separate imaging archive is needed to get started. The rest of this page covers the decisions and checks that the integration needs before it is put in front of readers.
At a high level, the browser loads the viewer application from Orthanc through the plugin. The viewer then sends its requests back to the same Orthanc server, asking for the study, series and instance metadata it needs to build a worklist, and then for the image data it displays. Orthanc answers from its own storage and database. Which data format the viewer reads, and whether it uses the DICOM JSON route or the DICOMweb route, is a configuration choice that affects load, caching and how images are delivered, and it is covered in the sections that follow.
The viewer does not store, index or modify studies. It holds no copy of the DICOM data beyond what the browser caches for the current session, and it does not transform, anonymize or re-encode the images it receives. Storage, indexing, transcoding and deletion all stay with Orthanc, so retention, backup and any change to study content must be planned on the Orthanc side. Teams should confirm this boundary with their own privacy and records owners, because it determines where patient data resides at rest.
Because the viewer calls Orthanc's web interfaces directly, the access path to the server is the access path to the images. Orthanc does not accept remote HTTP connections by default, and the security settings that open it to users, along with any reverse proxy in front of it, decide who can reach the viewer and the data behind it. Confirm which Orthanc version and plugin release you will deploy, since the Orthanc 1.13.0 release on 2026-08-15 rewrote storage-area access and transcoding, and check the plugin's compatibility notes for that version before you choose a target.
The sections that follow address the decisions this request path forces: choosing between the DICOM JSON and DICOMweb data sources, sizing the database that Orthanc uses for the study index, checking JPEG 2000 support for the images your modalities send, and placing access control in front of the viewer. Read them in that order, because the data source choice changes what the database and the access checks have to handle.
What you need before you connect the OHIF viewer to Orthanc
Connecting the OHIF viewer to Orthanc depends on a handful of choices made before any plugin is installed. The cards below cover the server build, the plugin, the database, sizing, the hostname and certificates, and the network paths clinicians use, so each decision is settled before configuration starts.
Orthanc deployment target and version
Decide whether Orthanc runs on Windows, macOS, a Linux distribution package, or as a Docker image, and pin one version line for the whole environment. Orthanc is distributed for all three operating systems and as Docker images, so the choice usually follows your hosting standard. Confirm the exact version against the Orthanc NEWS file and the current download page before you test, because the 1.13.0 release changed storage access and DICOM transcoding.
OHIF plugin packaging and compatibility
Confirm which build of the official OHIF viewer plugin matches your chosen Orthanc version and how it is delivered for your platform, whether as a packaged library or a container layer. Check the plugin release notes for supported Orthanc versions and any change to the data source options. Record the plugin version next to the Orthanc version so upgrades can be tested as a pair.
Database index: SQLite or PostgreSQL
Choose between the built-in SQLite index and the PostgreSQL plugin before loading production data, since moving a large archive between databases later is costly. The Orthanc scalability guidance says the SQLite index should be replaced by an enterprise engine once several hundred thousand instances are stored. PostgreSQL also enables multiple Orthanc instances to share one database, which matters for high availability.
Expected study volume and storage growth
Estimate the number of studies, instances and terabytes you expect in the first year, and split them by modality and by how long they must stay online. Ask your imaging team for current daily study counts and typical file sizes, and ask the vendor what the viewer loads for a large multi-series study. These figures drive the database choice, the storage backend, and the memory and disk sizing of the Orthanc host.
Viewer hostname, DNS and TLS certificates
Reserve a dedicated DNS name for the viewer and the Orthanc REST and DICOMweb endpoints, and issue a TLS certificate from the certificate authority your organization trusts. By default Orthanc accepts HTTP only from localhost, and the security guidance recommends HTTPS and a reverse proxy for any exposure beyond it. Confirm which names clinicians' browsers, the proxy and internal services will each use.
Browser and network paths
Map every path a clinician takes from a workstation to a study, including the viewer hostname, the reverse proxy, any identity provider, and the DICOM network that feeds Orthanc from modalities. Check which paths cross a firewall, a VPN or a segment with different trust levels, and confirm supported browsers with the plugin documentation. Remote access must stay controlled by authentication, so the access rules for each path belong in this inventory.
Access control and disabled routes
Decide who may reach the viewer and how authentication is enforced before the first user logs in. Orthanc requires authentication with registered users once remote access is enabled, and the advanced authorization plugin can delegate each request to an external service. Confirm that the script execution and export routes stay disabled, as the security guidance advises, and record that check in your acceptance list.
Choosing DICOM JSON or DICOMweb as the viewer data source
The first decision for the OHIF viewer on Orthanc is how the browser fetches study, series and instance metadata and pixel data. The first option uses DICOM JSON metadata served by Orthanc's own REST API. The second uses a DICOMweb endpoint, where the viewer runs QIDO-RS searches and WADO-RS retrievals against a standards-based interface. Both options are configured in the viewer's data source settings, but the choice depends on the plugin version you deploy. Before you decide, confirm which data source options your plugin version supports and check the exact configuration keys in the plugin documentation, because key names and defaults can change between releases. Do not copy settings from older blog posts or forum threads.
Start the decision by listing who else calls the same endpoints. If AI tools, a cloud archive, or a second viewer already speak DICOMweb, pointing OHIF at DICOMweb gives every consumer one interface to secure, test and monitor. If OHIF is the only client, the native REST path may keep the configuration smaller. A remote DICOMweb archive changes the picture further. If some studies live in an archive that Orthanc does not hold, confirm whether the viewer reaches that archive directly or through Orthanc, because the answer determines where credentials are stored, which network paths must be open, and which team owns failures. The Orthanc DICOMweb integration page covers the wider DICOMweb picture, including STOW-RS and remote servers, so read it before settling this question.
Caching and server load differ between the two paths, and you should measure both rather than assume. Study metadata is large for studies with many instances, so repeated metadata calls can dominate traffic when radiologists scroll through priors. A caching layer at the reverse proxy or in the browser can reduce those repeat calls, but any cached response must still respect your access rules, so confirm what each layer may cache and for how long. DICOMweb adds a translation layer in the plugin, which can change CPU and memory use under concurrent sessions. Orthanc 1.13.0 rewrote storage-area access and DICOM parsing and transcoding to improve caching and reduce memory use, so run your own load test on the exact Orthanc and plugin versions you intend to operate.
Test the choice with a representative set of studies before you commit. Include large multi-frame instances, compressed transfer syntaxes and at least one study stored on the remote path if you use one. Record the requests the viewer makes for a typical session, measure time to first image, and check that the same access controls apply to both the REST and DICOMweb routes. Document the chosen data source, the plugin version, the configuration keys you set and the proxy caching rules, so an upgrade later does not silently switch the viewer to a different path. If the configuration keys or defaults differ from what this section describes, follow the plugin documentation for your version.
Configuration sequence for the OHIF viewer on Orthanc
This sequence takes an Orthanc server from a clean install to an OHIF viewer that opens test studies in a browser behind authentication and HTTPS. Each step closes with a check you can run yourself, so a failed check stops the work before the next layer is added. Exact configuration keys are listed for confirmation against the plugin documentation during the build.
Install Orthanc on the chosen platform
Install the Orthanc server on the operating system or container platform your team has chosen, using the official package or Docker image for that platform. Confirm the version you install against the Orthanc release notes before you go further, and decide now whether the built-in index will be replaced by a database back end, since that choice is easier to make before data arrives. Done means the service starts, the Orthanc Explorer home page answers from the server's local address, and the service restarts cleanly after a reboot.
Enable remote access only with authentication
Leave the server reachable only from localhost until authentication is in place. Then allow remote access, turn on authentication and define registered users with strong credentials, following the Orthanc security FAQ. Keep the script execution and export routes disabled, because the security FAQ warns that they can run system commands or overwrite files. Check it by sending an unauthenticated REST request from another machine and confirming it is refused, then confirming a registered user is accepted.
Install the OHIF plugin and set its path
Install the official OHIF viewer plugin into the Orthanc plugin location, then set the path where the viewer is served. Confirm the exact configuration key and the pairing between the plugin and Orthanc version in the plugin documentation before you edit the configuration file. Done means the viewer start page loads for a registered user in a browser, shows no script errors in the developer console, and the anonymous request from the previous step is still refused.
Select and configure the data source
Choose between the DICOM JSON data source and the DICOMweb data source based on how the viewer must reach the archive, then configure that source in the viewer settings. Confirm with the plugin documentation which endpoint and settings the chosen source needs, and whether the Orthanc DICOMweb plugin must be installed alongside it. Done means the viewer lists the patients and studies already stored in Orthanc, and a direct DICOMweb query for a known study returns the same identifiers.
Place a reverse proxy with HTTPS in front
Put a reverse proxy in front of Orthanc and the viewer, terminate TLS at the proxy, and forward only the paths the viewer needs. Keep Orthanc bound to a private address so that clients cannot bypass the proxy, and confirm the proxy passes authentication headers through unchanged. Done means the viewer loads over HTTPS with a valid certificate, a plain HTTP connection to the Orthanc port fails, and the anonymous request is still refused when sent through the proxy.
Load test studies and verify end to end
Load a small set of test studies into Orthanc, using anonymized data or a public sample set, and open them through the viewer from a test browser. Include at least one large or multi-frame study to exercise image rendering, and confirm the expected study count and series in the study list. Done means each test study opens with the expected image count, a DICOMweb query through the proxy returns the same results as the local query, and the anonymous request is still rejected after all changes.
How Orthanc objects map to the viewer's patient, study, series and instance view
This table compares each Orthanc resource level with what the OHIF viewer shows, the identifiers and DICOM tags it uses for study lists and ordering, and the identity fields that drive access decisions. Read it when you configure the data source and authorization, then confirm each DICOM-derived value against a test dataset from your own modalities. The main takeaway is that Orthanc's internal identifiers drive navigation, while the displayed labels and sort order come from DICOM attributes that your source systems control.
| Orthanc resource or field | What the viewer shows or uses it for | Governed by | Confirm before go-live |
|---|---|---|---|
| Patient (Orthanc ID, PatientID) | Top level of the study list; patient grouping and the patient name shown in the header | Orthanc internal ID is generated on ingest; PatientID and PatientName come from the DICOM headers | Duplicate PatientID values across sites and how your modalities populate them |
| Study (StudyInstanceUID, StudyDate, AccessionNumber) | Study list rows, date filtering and the study URL the viewer opens | StudyInstanceUID is set by the acquiring device; StudyDate and AccessionNumber come from the DICOM data | Whether AccessionNumber is populated consistently for search by your RIS or worklist |
| Series (SeriesInstanceUID, SeriesNumber, SeriesDescription) | Series thumbnails, series ordering in the panel and the default hanging protocol choice | SeriesNumber and SeriesDescription are set by the scanner or modality; ordering follows these values | Series ordering for your common modalities, since some devices leave SeriesNumber blank |
| Instance (SOPInstanceUID, InstanceNumber, image position) | Slice order within a series and the frame or image the viewer requests | SOPInstanceUID is unique per object in the DICOM data; slice order depends on InstanceNumber and position tags | Multi-frame and mixed-orientation series, where slice order may not match InstanceNumber |
| Orthanc Study and Series IDs | Build the URLs the viewer calls for studies, series and instances through the DICOMweb or DICOM JSON data source | Assigned by Orthanc on ingest and used only inside the server; the viewer relies on them for routing | Behavior after re-import or reindexing, since internal IDs are not the DICOM UIDs |
| Identity from reverse proxy or authorization layer (user name or token subject) | Determines which studies and patients the user may list or open when the authorization plugin is in use | Set by your identity provider or proxy; the authorization plugin decides access per REST request | Which claim (such as subject or username) maps to the Orthanc user and whether group claims are passed through |
| Access decision per study (labels or tags from the authorization service) | Hides or allows studies in the list and blocks direct URL access to instances | Defined by your authorization service logic, not by DICOM tags | That a denied request returns HTTP 403 in the viewer and that cached study lists do not leak restricted studies |
Securing Orthanc and the viewer before clinicians log in
Orthanc accepts only localhost HTTP connections by default, and most of its exposure comes from a few settings that turn remote access on or enable risky routes. The cards below cover those settings, the transport and proxy layer, and the viewer configuration that sits in front of the imaging data.
Keep remote access off unless needed
By default Orthanc only accepts HTTP connections from localhost, and that is the starting point for the design. Before enabling RemoteAccessAllowed, confirm which clinical or integration systems need to reach the REST API and from which networks. Document each reason in the configuration review so that the setting can be reverted if a use case ends. Check the effective configuration on the running instance, not only the file in the repository.
Require authentication for remote users
When RemoteAccessAllowed is enabled, the Orthanc security FAQ says AuthenticationEnabled should be true, with each permitted user defined in RegisteredUsers. Build the user list from named accounts that map to real staff or service roles, and avoid shared credentials. Ask who owns the process for adding and removing entries, since the list lives in configuration and changes require a restart or reload that must be scheduled.
Put HTTPS and a reverse proxy in front
The Orthanc docs recommend HTTPS and a reverse proxy for any exposure beyond the internal network. Terminate TLS at the proxy, restrict which paths and methods it forwards, and confirm that Orthanc is not reachable directly on its HTTP port from outside. Decide where certificates are issued, renewed and stored, and test the renewal path before go-live. Record which proxy headers Orthanc trusts so that client addresses in logs are accurate.
Disable script execution and export routes
The Orthanc 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 should stay disabled in production. Confirm this in the deployed configuration and block the routes at the reverse proxy as a second control. Include a check of these routes in each upgrade and configuration change, because a default or a new setting can reopen them.
Encrypt DICOM exchanges between sites
Orthanc supports DICOM TLS for inter-site exchanges starting with version 1.9.0. Plain DICOM traffic between sites can expose patient data on the network, so list every peer modality and remote Orthanc that exchanges studies, and decide which links need TLS. Certificates for both ends must be trusted and rotated, and the peer on the other side must support the same configuration. Confirm the versions on each side before you plan the change.
Review viewer endpoints and CORS
The OHIF viewer runs in the browser and calls Orthanc endpoints, so its exposed routes and cross-origin settings define what a web page on another origin can reach. Review which origins are allowed, which endpoints the viewer uses, and whether any other service can read responses. Keep the list of allowed origins short and tied to the viewer URLs in use. Test the configuration from an unapproved origin to confirm that the request is refused.
Putting access control in front of the viewer and the Orthanc API
Access control for this stack has two layers, and both must be in place. The first is the OHIF viewer, which users open in a browser and which needs its own sign-in. The second is the Orthanc REST interface that the viewer calls to retrieve studies, series and instances. If that interface accepts anonymous requests, anyone who can reach its address can bypass the viewer entirely. By default, Orthanc accepts HTTP connections only from localhost. When RemoteAccessAllowed is enabled, the Orthanc security FAQ says AuthenticationEnabled should be true with users defined in RegisteredUsers, and it recommends HTTPS and a reverse proxy for any Internet exposure. The same FAQ warns that the /tools/execute-script route and the export route should stay disabled. Treat these settings as the baseline that the rest of the design builds on.
The advanced authorization plugin adds a decision point on top of authentication. For each REST request, it forwards the caller's token to an external web service, which allows or denies the request. A denial returns HTTP 403. The orthanc-auth-service reference project follows this pattern with Keycloak-issued user tokens and Orthanc Explorer 2: Keycloak signs the user in and issues a token, and the web service checks it before the request proceeds. Adapting this pattern to the OHIF viewer is the step that needs the most confirmation. The reader must confirm which requests the viewer sends to Orthanc and whether each one carries the user's token. Any request that carries no token cannot be evaluated by this model, so those paths need a different control or a change in how the viewer is configured.
Before writing the authorization rules, run a traffic review. Open the viewer in a browser with developer tools, load a test study, and list every request that reaches the Orthanc host. For each one, record the endpoint, whether an Authorization header or cookie is present, and how the viewer responds to a 403. Then decide how the viewer obtains its token: either through an OIDC sign-in flow inside the viewer, or through a reverse proxy that performs sign-in and forwards credentials to Orthanc. Each option needs testing with expired tokens, with revoked sessions, and with a user who lacks the required role. Record the results, because they determine whether the web service can make a correct decision for every request.
Define at least three roles before writing policy: clinicians, researchers and administrators. Clinicians need to open studies for the patients they are treating, which is usually a narrower scope than the whole archive, so the design should state how that scope is expressed in the request or the token. Researchers may need de-identified or project-scoped access, and they should receive clinical read access only when a documented project requires it. Administrators manage configuration, users and the server, and they should have no view rights to patient images unless a documented need exists. Map each role to Keycloak realm or client roles, and have the web service enforce those roles against each endpoint the viewer calls.
Set the audit trail requirements before go-live, because retrofitting them is harder. Decide which events must be recorded: successful and failed sign-ins, token issuance, each allowed and denied REST request with the user, role, endpoint and study identifier, and administrative changes. Confirm which of these Orthanc, the authorization service, Keycloak and the reverse proxy each log natively, and where those logs are stored. Agree on log retention and access with your compliance team, then test that a sample denied request appears in the trail with enough detail to reconstruct what happened. DeployOpen can plan, document and test these controls and prepare the evidence for a compliance assessment, but independent auditors and certification bodies decide whether the controls are adequate.
How to test the OHIF viewer deployment before go-live
Functional tests prove that a clinician can find a study, open it and read every image the viewer is expected to show. Run them in the same browsers, on the same network path and against the same Orthanc version that users will reach in production, because rendering problems often depend on the browser and the data source, not only on the server.
- Study search: Query by patient, accession number, date and modality, and confirm that results match the test records you loaded.
- Series loading: Open studies with many series and confirm that thumbnails, series ordering and series switching complete without errors in the browser console.
- Multi-frame and large series: Open multi-frame objects and series with a high instance count, scroll through them and confirm that frame order and slice position are correct.
- Data source path: Repeat the checks for the DICOM JSON and DICOMweb data sources if both are candidates, and record which one your team chose and why.
- Transfer syntax outcome: Load one object for each compressed transfer syntax in your archive, including JPEG 2000, and record in each browser whether it decodes. Treat the result as a test outcome to report, not as an assumption from documentation.
The test data for this tab should include synthetic or fully de-identified studies that cover each modality, multi-frame objects and every transfer syntax you store. Confirm the outcome for each browser version you support before go-live.
Security tests prove that the viewer and the Orthanc REST API refuse requests they should refuse. The goal is to exercise each access path from outside the trusted network, using both valid and invalid credentials, and to record the response for each case. Automated scanning is not a substitute for these checks, because authorization errors usually sit on specific routes.
- Anonymous access: Request the viewer, the REST API and any DICOMweb endpoint without credentials and confirm that access is rejected.
- Token checks on each path: Use valid, expired, revoked and wrong-audience tokens against each REST path the viewer calls, and confirm that every path enforces the same decision.
- Disabled routes: Confirm that routes you have disabled, including script execution and export routes, return errors rather than succeeding.
- Remote access settings: Check that remote access, authentication and registered users match the documented configuration for your deployment.
- Transport: Confirm that HTTPS is enforced at the reverse proxy and that plain HTTP is not reachable from outside.
The test data for this tab can be the same synthetic dataset, plus test accounts with narrow roles. Keep the request and response records as evidence for your security review.
Load tests prove that the deployment keeps the viewer responsive when several users open studies at the same time, and that the database and storage behave under that pressure. A realistic study mix matters more than a raw request count, because a few very large studies can dominate memory and bandwidth while many small studies dominate database queries.
- Build the study mix: Define the share of small, large, multi-frame and compressed studies from your own volume reports, and keep the proportions in the test plan.
- Concurrency: Increase simulated users in steps and record response times, error rates and memory use at each step.
- Database behavior: Watch query latency and connection counts on the index database, since this is where scaling limits usually appear first.
- Storage reads: Measure retrieval times for the storage backend you run in production, not a local disk used only in tests.
- Recovery: Restart a component during a run and confirm that users see a controlled error and can continue after recovery.
Use a synthetic or de-identified dataset that reproduces the size and modality mix of your archive. Ask your team to agree in writing on the acceptance thresholds before the run, so the result can be judged against them.
Common OHIF viewer and Orthanc failures and how to fix them
This table lists the failures teams most often see when the OHIF viewer runs on Orthanc, with the likely cause, a diagnostic check and the direction of the fix for each. Read each row from the symptom inward: start with the data source and proxy checks, then move to the database, authorization and transfer syntax rows if the first checks pass. Causes are tied to the choices covered on this page, so confirm each one against your own deployment before changing settings.
| Symptom | Likely cause | Diagnostic check | Fix direction |
|---|---|---|---|
| Viewer loads an empty study list | The viewer data source points to a DICOM JSON or DICOMweb endpoint that does not match the Orthanc configuration, or the DICOMweb plugin is not enabled | Query the study endpoint directly from the viewer host and compare the response with the studies visible in Orthanc Explorer 2 | Correct the data source URL and enable the DICOMweb plugin, then align the viewer configuration with the chosen data source |
| Images stall on large series | Viewer requests full-resolution instances from a server that is busy transcoding or reading from slow storage | Check Orthanc logs and CPU, memory and disk I/O while loading one large series; compare with a small series | Size the host for the transcoding and storage load, move the storage area to faster media and reduce concurrent viewer sessions per instance |
| Studies become slow after the index grows | The built-in SQLite index is carrying a dataset larger than it was designed for | Measure study query time as the instance count rises and review the index size and disk latency on the host | Plan a move to the PostgreSQL or MySQL/MariaDB plugin before the dataset reaches several hundred thousand instances, and test the migration on a copy first |
| Authorization returns 403 for valid users | Access rules in the authorization plugin or RegisteredUsers do not match the token or account the user presents to the viewer | Trace one denied request, confirm which user and token reached Orthanc, and check the external authorization service decision for that request | Correct the permission mapping in the authorization service or user list, and confirm that the viewer forwards the token on every REST call |
| Mixed content errors behind the reverse proxy | The viewer is served over HTTPS while Orthanc or the data source URL is configured with plain HTTP, or the proxy does not pass the external scheme | Open the browser console, list the blocked requests and check the scheme in the viewer configuration and the proxy forwarding headers | Expose every viewer and API URL over HTTPS through the proxy and set the data source to the external address, not the internal one |
| JPEG 2000 images do not render | The browser or viewer cannot decode the transfer syntax that Orthanc returns for these instances | Retrieve one JPEG 2000 instance through the viewer and check which transfer syntax the server returns and whether the viewer supports it | Confirm the transfer syntax support in the viewer and Orthanc build you run, then request a supported transfer syntax or transcode on the server as your testing shows |
| Remote access fails for everyone | Remote access is enabled without authentication, or the server still accepts only localhost connections | Check the RemoteAccessAllowed and AuthenticationEnabled settings and test a request from a remote host | Enable authentication with defined users and place Orthanc behind HTTPS and a reverse proxy before exposing it beyond localhost |
Questions teams ask before connecting OHIF to Orthanc
How much does it cost to connect OHIF to Orthanc?
Cost follows scope. The main drivers are the data source choice, whether the index database moves from the built-in SQLite index to PostgreSQL, identity integration, the number of environments you need, and how deep the testing goes. Orthanc has no paid edition, so the server software itself carries no license fee. The spend goes to people and infrastructure: your staff time, a partner's fixed-scope work if you hire one, and the servers, storage and proxies you run. Configuration, integration and acceptance testing are one-time costs. Patching, upgrades and support are recurring. Orthanc Team SRL sells deployment and configuration services and pre-paid dedicated support hours valid for 12 months, quoted on request. Ask any quote to price each driver separately and to list what is in and out of scope.
Can our own team connect OHIF to Orthanc without outside help?
Yes, if your team has the skills and time. The work needs Linux administration, reverse proxy configuration, and working knowledge of DICOM networking and DICOMweb. Someone also has to own the viewer configuration after go-live, including upgrades to Orthanc and its plugins. Teams that lack one of these areas often buy help for that part only. A written scope makes internal work easier to plan, because deliverables, environments and acceptance tests are listed before work begins. Confirm the skills with your engineers first, and check the Orthanc Book documentation for the plugin version you intend to run.
What do we need to provide before the engagement starts?
Most delays come from access and approvals, not configuration. Provide test DICOM data that reflects your modalities, study types and image sizes, de-identified where your policy requires it. Grant access to your identity provider so sign-in can be configured and tested. Get network and firewall changes approved in advance, and arrange certificates for the viewer and reverse proxy hostnames. Define clinical acceptance criteria in writing: which workflows, which user groups, and which image types must display correctly. Name one decision-maker who can accept or reject each test result.
How long does an OHIF and Orthanc integration take?
Duration follows scope, not a fixed number. The main drivers are the data source choice, whether the index database moves to PostgreSQL, how many environments must be built (for example development, test and production), how many identity providers and user groups are involved, and how thorough the testing is. The Orthanc scalability guidance says the built-in SQLite index should be replaced by an enterprise database engine once a server stores several hundred thousand DICOM instances, so a large existing archive adds migration time. Ask for milestones tied to the approvals and test data you provide, and confirm how long each approval step takes in your organization.
Does the license of the OHIF viewer plugin affect our deployment?
It may, so review it with your legal counsel. Orthanc core is licensed GPLv3 or later. The web viewer plugins, including the one used for OHIF, are licensed AGPLv3 or later. Because Orthanc has no paid edition, there is no separate commercial license to purchase for the server. The AGPL includes network-use terms that matter when software is accessed over a network, as a web viewer is. Counsel should confirm how these terms apply to your internal use, any sharing with outside parties, and any modifications your team or a partner makes. This page does not give legal advice.
Should we use the DICOM JSON or DICOMweb data source for OHIF?
Decide by how the viewer and other systems will reach the archive. The choice shapes how the viewer requests studies, how much work the server performs per request, and how easily other DICOMweb clients can share the same endpoint. Confirm with the plugin documentation for your version which path your OHIF build expects, because that determines what must be configured on the server. Test both options on representative studies, including large multi-frame images and slow networks, before choosing. Record the result in the written scope so the decision is traceable during audits and upgrades.
What usually breaks when OHIF sits behind a reverse proxy?
Authentication and HTTPS settings cause most early failures. By default Orthanc accepts HTTP connections only from localhost. When remote access is enabled, the Orthanc security guidance says authentication should be on, with users defined in the server configuration, and recommends HTTPS and a reverse proxy for any internet exposure. Common problems include mixed content warnings, forwarded headers that the server does not expect, timeouts during large image transfers, and cross-origin settings that block the viewer's address. Keep the script execution and export routes disabled, as the security guidance warns that they can be abused. Check these items first when testing.
How DeployOpen scopes and delivers the Orthanc and OHIF integration
DeployOpen plans, deploys and hardens Orthanc with the OHIF viewer inside infrastructure you control, from the data source choice through access control in front of the viewer. Engagements are fixed-scope, so the agreed written scope sets what is built, tested, documented and handed over.
How we scope
- Confirm the data source choice between DICOM JSON and DICOMweb for your viewer and workflows.
- Size the database back end against expected instance counts, since the built-in SQLite index is not meant for very large datasets.
- Define the access model for the viewer, including how users authenticate before any study is displayed.
How we build
- Install the official OHIF viewer plugin on a chosen Orthanc release, from packages or Docker images, in your environment.
- Configure PostgreSQL or another enterprise database engine when the dataset calls for it, with JPEG 2000 support checked against your modalities.
- Place HTTPS and a reverse proxy in front of the viewer and keep the script execution and export routes disabled.
How we hand over
- Document the deployed Orthanc version, plugin versions, configuration files and the access control design.
- Run verification of viewer loading, authentication, authorization denial and study retrieval against agreed test cases.
- Provide runbooks for upgrades, backups and restores so your team can operate the system after handover.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after the initial delivery.
- Plan Orthanc upgrades against the release notes, including changes to storage access and DICOM parsing, before applying them.
- Confirm with Orthanc Team SRL any dedicated vendor support hours you want alongside DeployOpen's work, since those are quoted separately.
