OHIF Viewer vs Weasis: which one fits your radiology workflow?
If you are choosing a viewer for radiologists, referrers or researchers, the core answer is this: pick the OHIF Viewer for a browser-only service sitting on a DICOMweb archive, and pick Weasis when you need a desktop application, one-click launch from a portal, or support for classic DICOM networking. The decision turns on four factors: which archive protocols your PACS or VNA speaks, where users sit (inside a hospital network, on managed workstations, or across sites with no installed software), how users authenticate, and how much advanced viewing or export they need.
The OHIF Viewer is the better choice when your archive already implements DICOMweb and you want a zero-footprint web client with nothing installed on the workstation. It is MIT licensed and built as a configurable, extensible progressive web application, so it suits a team that will maintain its data source configuration and extensions. Weasis is the stronger choice when radiologists need a full desktop viewer, when your estate still depends on DIMSE query/retrieve and store, or when an EHR or RIS portal must open studies with a single click through the weasis:// protocol. Confirm with your archive vendor which DICOMweb endpoints (QIDO-RS, WADO-RS, STOW-RS) it exposes and whether it also offers DIMSE, because that answer alone can settle the choice.
Weigh the advanced features against real clinical use before you commit. Weasis documents support for multi-frame and enhanced CT, MR and ultrasound, SR, SEG, RT, ECG and parametric maps, multi-monitor calibration, and export to DICOMDIR, ZIP or an ISO with the viewer embedded for CDs. OHIF lists multiplanar reconstruction, MIP, labelmap and contour segmentation rendering, whole slide microscopy and longitudinal measurement tracking. Ask each vendor to demonstrate the specific modalities and export formats your referrers and researchers use, and confirm that your identity provider (for Weasis, Basic, OAuth 2.0 or OpenID Connect) works with your setup before any pilot.
Which viewer fits which clinical or research scenario
This table maps common clinical and research situations to the viewer that fits best and the condition that drives the choice. Read each row against your archive, portal and user population, because several scenarios depend on whether your PACS speaks DICOMweb, classic DIMSE, or both.
| Scenario | Better fit | Condition that drives the choice |
|---|---|---|
| Browser-only reading service over an existing DICOMweb archive | OHIF Viewer | Your archive exposes QIDO-RS, WADO-RS and STOW-RS, so OHIF can be configured against it directly with no installed client on reader workstations. |
| PACS that only exposes DIMSE (classic C-FIND, C-MOVE, C-STORE) | Weasis | Weasis supports classic DIMSE query, retrieve and store, while OHIF needs a DICOMweb endpoint. Without one, OHIF requires a DICOMweb gateway or a server that translates the protocol first. |
| Referrer opening studies from an EHR or RIS portal | Weasis, in most portal setups | Weasis can be launched from browsers and portals with a single click through the weasis:// protocol. Confirm that your portal can invoke that protocol and that the referrer's workstation can install the client. |
| Referrer on a locked-down machine with no install rights | OHIF Viewer | A browser-based viewer avoids desktop installation. Confirm whether your portal can reach an OHIF launch URL and that authentication works from the referrer's network. |
| Research team needing segmentation, longitudinal tracking and extensions | OHIF Viewer | OHIF includes segmentation rendering as labelmaps and contours, a longitudinal measurement tracking mode and an extension system for building custom workflows. Confirm the specific tools your protocol needs against the current release. |
| Team distributing studies on CD or disc to patients or outside sites | Weasis | Weasis can export DICOMDIR, ZIP or an ISO with the viewer embedded for CDs. OHIF is a web application and does not cover disc authoring. |
| Mixed estate with DIMSE modalities and DICOMweb web users | Either, with a gateway or dual configuration | Weasis can connect to both DIMSE nodes and DICOMweb sources directly. OHIF serves the DICOMweb side, so the DIMSE side typically needs a bridge. Confirm this with your PACS vendor. |
How each viewer is built, deployed and operated
OHIF Viewer and Weasis reach clinicians through very different delivery paths, and each path puts different work on your infrastructure team. The archive you connect to matters nearly as much as the viewer, because it sets how studies are queried, retrieved and stored. The cards below take each part of that operating model in turn.
Zero-footprint web delivery
OHIF Viewer is a progressive web application that runs in the browser, so nothing is installed on workstations. Your team serves the static application from a web host and points it at DICOMweb root URLs for query, retrieve and store. Updates land on the server, and every user gets the new version on their next load. Check how your web hosting, caching and certificate management will serve the application to radiologists on hospital networks.
Desktop and portal-launched distribution
Weasis ships as a desktop application for Windows, macOS and Linux, and it can also run in web-based use. Clinicians often reach it with one click from a browser, EHR or RIS portal through the weasis:// protocol. Updates are the part to plan: each workstation needs the new desktop build unless you manage deployment centrally. Confirm how your endpoint management will push versions and how the launch link behaves on locked-down workstations.
What your team hosts
With OHIF Viewer, the infrastructure you host is the web application, the archive and the identity layer in front of them. With Weasis, you host the archive and gateway, and the desktop build is installed per machine or through endpoint tooling. Write down which components your platform team owns, which the imaging team owns and which sit with the vendor or a managed service. Ambiguity here is a common source of delayed go-lives.
Archive choice shapes operations
OHIF Viewer is documented against DCM4CHEE Archive 5.x and Orthanc, with Orthanc as the main example. Weasis connects through classic DIMSE query, retrieve and store, or through DICOMweb QIDO-RS, WADO-RS and STOW-RS. If your PACS only speaks DIMSE, Weasis may need less re-plumbing, while OHIF usually depends on a DICOMweb layer. Confirm which endpoints your archive exposes before choosing the viewer.
Authentication lives in different places
Weasis supports Basic, OAuth 2.0 and OpenID Connect authentication that works against Keycloak and Google Cloud Healthcare. OHIF's sign-in behavior depends on how you configure the web application and the identity provider in front of it. In both cases, decide where sessions expire, how roles map to archive access, and who can revoke a user. Test these paths with real clinician accounts before rollout.
Versions and archive compatibility
OHIF Viewer v3.13.13 was published on 16 October 2026, and Weasis v4.7.3 on 25 August 2026. Each release can change configuration keys, supported archive versions or plugin behavior, so pin the version you test and plan a staging check before each upgrade. Keep a rollback path for both the web build and the desktop installers, and record which archive version each viewer was validated against.
Capabilities, protocols and authentication side by side
This table compares how each viewer is licensed, distributed, connected to archives, launched, authenticated and extended, plus the advanced viewing and export features that matter to radiology and research workflows. Read each row against your archive and EHR setup: a capability marked as a point to confirm is one the supplied material does not settle, so verify it with the vendor or in a test environment before you commit.
| Capability | OHIF Viewer | Weasis |
|---|---|---|
| License | MIT | Dual-licensed under EPL 2.0 and Apache 2.0 |
| Distribution model | Browser-based progressive web application, zero-footprint on the client | Desktop distributions for Windows, macOS and Linux, plus standalone and web-based use |
| Archive protocols | DICOMweb (QIDO-RS, WADO-RS, STOW-RS) with independent root URLs | DIMSE query/retrieve and store, DICOMweb QIDO-RS, WADO-RS and STOW-RS, plus WADO-URI |
| Launch from EHR or RIS portals | Launched by URL in a browser; confirm the exact launch pattern your portal needs | Single-click launch from browsers, EHR and RIS portals through the weasis:// protocol |
| Authentication methods | Confirm supported schemes and identity provider integration in your configuration | Basic, OAuth 2.0 and OpenID Connect, with Keycloak and Google Cloud Healthcare named as working targets |
| Advanced viewing | Multiplanar reconstruction, 3D viewing, MIP, segmentation as labelmaps and contours, whole slide microscopy, PDF and DICOM SR rendering, longitudinal measurement tracking | Multi-frame and enhanced CT, MR and ultrasound, SR, SEG, RT, ECG and parametric maps, plus multi-monitor calibration |
| Export | Confirm export formats and any embedded-viewer options for your deployment | DICOMDIR, ZIP, or an ISO with the viewer embedded for CD distribution |
| Extensibility | Configurable and extensible through its extension system | Confirm plugin and customization options with the maintainers before relying on them |
What the licenses allow and what is paid for
The OHIF Viewer is licensed under the MIT license, which is one of the most permissive open-source licenses in common use. It allows you to use, modify, copy and redistribute the code, including inside a commercial product, provided the copyright and license notice are kept. OHIF work is supported primarily by the US National Institutes of Health, National Cancer Institute, through a grant to Dr. Gordon Harris at Massachusetts General Hospital (U24 CA199460). That grant funds development, so it is not a commercial support contract with the client.
- Permissive terms: You can fork the viewer, add extensions and ship a modified build without releasing your source under the MIT license terms.
- Grant-funded development: Roadmap and release timing follow the project's funded work, so confirm which features you depend on are maintained.
- No vendor edition named in the supplied facts: Confirm with the OHIF project whether any commercial support or hosted offering exists before you assume one.
- Your own build costs: Forking, hardening and upgrading a customized viewer is work you own, and it is usually the largest recurring effort.
Before you commit, ask the OHIF project or a services provider in writing which versions they support and for how long.
Weasis is dual-licensed under the Eclipse Public License 2.0 and the Apache License 2.0, so you can choose the license that matches your distribution model. Both licenses permit commercial use and modification. The EPL 2.0 includes file-level reciprocity for changes to its own source files, which matters if you patch Weasis itself and redistribute the modified build. Apache 2.0 is generally simpler when you embed components in a closed product, so your legal team should review which license applies to your use.
- Dual choice: Pick EPL 2.0 or Apache 2.0 when you redistribute, and record the choice in your software bill of materials.
- Desktop and portal use: Installing Weasis on workstations or launching it from an EHR or RIS portal does not by itself create a paid license.
- Modified builds: Patches to Weasis source carry reciprocity obligations under EPL 2.0 that you must track.
- Commercial support: The supplied facts do not name a paid Weasis edition or support provider, so ask the project and any integrator directly.
Check with the Weasis project and your counsel which license terms apply to the exact build and plugins you deploy.
The Orthanc core is licensed under the GNU GPL version 3 or later. Its scalability and cloud plugins, including the PostgreSQL and web viewer plugins, are licensed under the GNU AGPL version 3 or later. The AGPL extends source disclosure obligations to software accessed over a network, so a modified plugin offered to users as a service can trigger source release duties. There is no paid Orthanc edition. Orthanc Team SRL sells deployment, configuration and development services, including pre-paid dedicated support hours that are valid for 12 months and quoted on request.
- GPLv3 or later core: Standard copyleft terms apply to modifications you distribute.
- AGPLv3 or later plugins: Network use of a modified plugin can carry source obligations, so review any custom plugin.
- No paid edition: Licensing does not change with support, because the paid part is services.
- Pre-paid support hours: Orthanc Team SRL offers dedicated hours valid for 12 months, and the price comes from a written quote.
- Cost drivers: Scope, the number of environments and how much custom development you need drive the quote.
Ask Orthanc Team SRL for the hours included, the response expectations and what the 12-month validity covers before you buy.
What drives the running cost of each viewer
The running cost of either viewer is mostly the cost of the systems around it, not the viewer itself. For the OHIF Viewer, the recurring cost sits in the DICOMweb archive, the web hosting that serves the progressive web application, and any identity service you put in front of it. For Weasis, the recurring cost sits in the PACS or VNA nodes it queries and stores to, the gateway if you use one, and the work of deploying and updating desktop installs across workstations. Ask every bidder to price these components separately, because a quote that bundles them hides which line will grow as your user count or archive count grows. One-time costs are the setup work: standing up the archive or confirming the existing one, configuring the DICOMweb root URLs (QIDO-RS, WADO-RS and STOW-RS) for OHIF or the DIMSE nodes and DICOMweb sources for Weasis, wiring authentication, and testing with real studies. Each archive you connect adds configuration that must be written, reviewed and kept in version control. Recurring costs are hosting, operating staff, support contracts, and retesting after each release. The OHIF Viewer v3.13.13 was published on 16 October 2026 and Weasis v4.7.3 on 25 August 2026, so both move on a cadence that your team will need to plan for, with the desktop rollout adding extra work for Weasis. When you request a written quote, ask for: the named components and who operates each one; a separate estimate of one-time integration and testing; the recurring support hours and what they cover, including any pre-paid hours and their validity; how upgrades to each viewer and to each archive are tested and billed; and the effort to maintain configuration for every archive you connect. For Weasis, also ask who packages and pushes desktop updates. Confirm current support terms directly with the vendors and with DeployOpen, since no standing price list is published.
Moving from one viewer to the other without losing studies
This sequence moves a reading environment from OHIF Viewer to Weasis, or the reverse, while the studies stay in the archive and remain retrievable throughout. It ends with a tested, piloted cutover and a retired client, so no reader is left without a working path to a study.
Confirm which archive and protocols stay
Start by deciding what does not move. Identify the archive that holds the studies (for example, an Orthanc or DCM4CHEE instance, or a vendor VNA), and confirm which access protocols it serves: DICOMweb QIDO-RS, WADO-RS and STOW-RS, classic DIMSE query/retrieve and store, or WADO-URI. Both viewers can work against a DICOMweb archive, but Weasis also supports DIMSE, so an archive that serves only one protocol may constrain the choice. Ask the archive vendor or your integration team to confirm which endpoints are live, enabled and secured for the new viewer. The step is done when you have a written list of endpoints that will remain unchanged and the owner of each.
Inventory authentication and user groups
Document how readers sign in today and which groups map to which access. Record the identity provider, the protocol in use (Basic, OAuth 2.0 or OpenID Connect), token lifetimes, and any role or group claims that decide who can see which studies. Weasis documents support for OAuth 2.0 and OpenID Connect against Keycloak and Google Cloud Healthcare, while OHIF relies on the authentication layer you put in front of its web deployment, so confirm which pattern your environment already uses. Involve your identity and security team to review the list. The step is complete when every group has a documented mapping that the new client must honor, and any gaps are logged as open items.
Rebuild data source configuration and launch links
Recreate the connection settings in the target viewer. For OHIF, this means configuring the data source with the DICOMweb root URLs for the archive. For Weasis, it means defining DICOM nodes for DIMSE connections or DICOMweb sources directly, and, if the viewer is launched from an EHR or RIS portal, configuring the weasis:// launch path or a gateway such as ViewerHub. Test each configured source with a non-clinical account before the links go to users. The step is complete when every source returns a study list and every portal launch opens the correct study in the target viewer. Keep the configuration in version control so the setup can be reproduced.
Test retrieval, metadata and export with clinical samples
Validate the new client against representative studies that clinicians actually use. Select a sample set that covers multi-frame CT and MR, ultrasound, SR, SEG, and any RT or parametric map objects in your environment, and check that each one loads, displays its metadata correctly and renders the expected series ordering. Test exports too: if your readers rely on DICOMDIR, ZIP or CD output, confirm that the output opens in the expected external tools. Where a feature is needed but not confirmed by the researched material, such as a specific segmentation rendering or a custom extension, verify it on your own data. The step is done when a signed-off test log records each sample, the result and any known differences.
Pilot with a small reader group
Run a controlled pilot with a small group of radiologists, referrers or researchers who represent the different workflows in your organization. Give them the new launch path and a short list of tasks that match their normal reading. Collect feedback on layout, measurements, hanging protocols, and access, and record any defects against the test log. Include at least one person who uses the viewer for research or longitudinal tracking if that is part of your workload. The pilot is finished when the group confirms that their core tasks work, and all blocking defects are either fixed or accepted by the clinical owner.
Retrain users and rebuild custom layouts
Plan the work that does not transfer automatically. Viewer configuration, saved layouts, hanging protocols, keyboard shortcuts, custom extensions and any scripted workflow must be rebuilt in the target client, and users need training on the new interface. Assign an owner for each custom item, rebuild it, and test it against the pilot samples. Prepare short reference material for readers and referrers who open studies from the portal. The step is complete when every custom element from the inventory has a rebuilt equivalent or a documented decision to drop it, and each reader group has completed training.
Cut over and retire the old client
Switch all launch links and access rules to the new viewer, announce the change, and keep the previous client available for a defined rollback window that your clinical and IT owners agree in writing. Monitor access logs and support requests during the transition. Once the rollback window closes without issues, remove the old launch links, revoke its credentials and archive its configuration. The archive and the studies remain untouched throughout, so no study is migrated or re-imported. The step is done when the old client is retired, its configuration is archived, and the change record is signed by the system owner.
Where OHIF Viewer and Weasis projects usually run long
The longest part of an OHIF Viewer project is usually not the viewer build, it is making every archive behave the same way. On the OHIF side, the work centers on the DICOMweb data source configuration, where each archive needs its QIDO-RS, WADO-RS and STOW-RS root URLs set correctly, plus the identity configuration that sits in front of them and any extension work your radiologists request. On the Weasis side, the work is spread across desktop packaging and deployment to workstations, DICOM node definitions for DIMSE query, retrieve and store, DICOMweb source entries, the weasis:// launch integration from your EHR or RIS portal, and a gateway such as ViewerHub where you use one. Ask your team to list every archive, gateway and portal the viewer must reach before scoping either option, because each one is a separate test case.
Archive compatibility testing is where most schedules slip. OHIF documents DCM4CHEE Archive 5.x and Orthanc as configurable DICOMweb archives, but your PACS or VNA may implement only part of the DICOMweb set, return vendor-specific attributes, or paginate QIDO-RS results differently. Authentication edge cases come next: token expiry during a long reading session, role mapping between your identity provider and the archive, and how a launch from a portal passes context into the viewer. Weasis supports Basic, OAuth 2.0 and OpenID Connect against Keycloak and Google Cloud Healthcare, but you must confirm the exact flow your identity provider uses. Clinical validation of display, including calibration, multi-frame and enhanced series, and SR or SEG rendering, needs radiologist sign-off and cannot be closed by the implementer alone.
For Weasis, the ownership of desktop updates is a decision that is often left open until after go-live. Someone must decide who packages each release, who tests it against your archives, and how updates reach workstations that are not managed centrally. Weasis publishes new releases on its GitHub releases page, so your process should define how often you review them and how a rollback works. For OHIF, the equivalent cost is the upgrade of the viewer build and its extensions after your own configuration changes. DeployOpen implements, customizes, integrates and documents either system inside your own cloud accounts, data centers or air-gapped networks under a written, fixed scope, so the scope document should name who owns each archive test, each identity flow and each update cycle, and whether ongoing upgrades are covered by a retainer.
Questions buyers ask before choosing a DICOM viewer
Can OHIF Viewer read from a PACS that only supports DIMSE?
Not directly, as far as the supplied documentation shows. OHIF Viewer is built around image archives that implement DICOMweb out of the box, with independent QIDO-RS, WADO-RS and STOW-RS root URLs, and its documentation lists DCM4CHEE Archive 5.x and Orthanc among the archives it can be configured against. A classic DIMSE-only archive usually needs a DICOMweb gateway or an archive that exposes DICOMweb in front of it. Weasis supports DIMSE query, retrieve and store alongside DICOMweb, so it can talk to a DIMSE-only PACS without that layer. Confirm with your PACS vendor which DICOMweb services are enabled in your version and whether a gateway is needed before you commit to either viewer.
Can Weasis be launched from an EHR or RIS portal?
Yes, Weasis can be launched from browsers, EHR and RIS portals with a single click through the weasis:// protocol. Integration with PACS, VNA, RIS, HIS or EHR can go through a gateway such as ViewerHub or through direct configuration of DICOM nodes and DICOMweb sources. The effort depends on how your portal builds launch links, whether the desktop client is allowed on clinician workstations, and who manages the installation and updates across those machines. Ask your EHR or portal vendor whether they can generate weasis:// links and how they pass patient and study identifiers, and test the launch on the exact workstation image your clinicians use.
What authentication do OHIF Viewer and Weasis need, and what does Keycloak or Google Cloud Healthcare integration involve?
Weasis supports Basic, OAuth 2.0 and OpenID Connect authentication, and its README states that these work against Keycloak and Google Cloud Healthcare. OHIF Viewer is a browser application, so its authentication is typically handled by the identity layer in front of the viewer and the DICOMweb archive. The work usually includes registering clients with the identity provider, mapping roles to access to studies, setting token lifetimes and testing the token flow through the archive and any gateway. Confirm with each vendor which OpenID Connect flows and token handling they support in the version you deploy, and which parts of the integration your own team or a services partner would own.
What do the licenses mean if we embed the viewer in our product?
OHIF Viewer is licensed MIT, a permissive license that generally allows embedding and modification, subject to keeping the license notice. Weasis is dual-licensed under EPL 2.0 and Apache 2.0, so you can choose the license that fits your distribution model, and both are permissive or weak-copyleft terms. Your legal team should review the obligations for your exact use, including bundled third-party components, distribution to clinicians outside your organization and any hosted-service terms. Ask the vendor or your counsel to confirm how each license applies to modifications you plan to make.
How much effort does a pilot take, and what drives the cost?
The effort depends mainly on the number of archives and DICOM nodes to connect, the authentication model, the number of workstation types and the volume of studies you test with. Costs fall into three groups: the internal staff time for clinical and IT review, the infrastructure you run for the archive and viewer, and any external services for configuration or integration. Recurring costs include hosting, patching, certificate renewal and support. Neither project publishes a price for services. Ask for a written scope listing archives, authentication flows, launch paths, test cases and acceptance criteria, and ask what is one-time and what is recurring. No pilot duration is given here because none was supplied.
Can our own team deploy and run either viewer without outside help?
Often yes, if your team already runs a DICOM archive, manages a web identity provider and supports clinical workstations. OHIF Viewer is deployed as a web application, so the main skills are web hosting, configuration of DICOMweb root URLs and identity setup. Weasis needs a desktop distribution rollout plus configuration of DICOM nodes, DICOMweb sources and the launch path. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure, typically under a fixed-scope written agreement, and offers retainers for ongoing support. Decide based on which skills you can staff for the pilot and for the years of upgrades that follow.
How long does a migration from one viewer to the other usually take?
No migration duration was supplied, so treat any number from a vendor as something to verify. The length depends on how many studies must be re-pointed, whether the archive is changing as well as the viewer, how many clinical workflows and launch links depend on the old viewer, and how much validation your radiologists require before cutover. A practical approach is to run both viewers against the same archive for a period, then move workflows in stages. Ask your implementation partner for a written migration plan with the cutover steps, rollback path and the test evidence that signs off each stage.
How DeployOpen helps you choose and implement a DICOM viewer
DeployOpen helps teams decide between a browser-based DICOMweb viewer and a desktop and portal-launched viewer, then plans, implements and hands over the one that fits the archive, identity model and user groups. Work is scoped in writing against your own infrastructure, so the choice is tested before it reaches radiologists and referrers.
How we scope
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- The written scope lists which archives, DICOM nodes or DICOMweb endpoints the viewer must reach.
- We confirm which user groups need desktop, browser or portal-launched access, and which need classic DIMSE support.
- Scope also records authentication requirements, such as the identity provider and single sign-on flow in use.
How we build
- We configure the chosen viewer against your archive, including DICOMweb root URLs or DICOM node settings.
- Integration with your EHR or RIS portal is built and tested, including any launch method your portal supports.
- We test multi-frame, SR, SEG and export workflows against representative studies from your own environment.
- Hardening covers the viewer, the archive connection and access controls inside your own cloud or data center.
How we hand over
- Handover includes configuration documentation for the viewer, data sources, authentication and launch integration.
- Runbooks describe how to add a site, rotate credentials and update the viewer to a new release.
- Your team receives written test results showing which viewing, archive and export paths were verified.
- Any compliance evidence we prepare is provided for your assessors, who issue their own reports or certifications.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Upgrades are tested against your archive and portal before they are rolled out to clinical users.
- Retainer scope, response expectations and review cadence are written into the agreement before work starts.
- Periodic re-testing confirms that viewer changes, archive updates and identity changes still work together.
