Beyond “Free” and “Paid”: A Better Framework for Evaluating Clinical DICOM Viewers

It is tempting to divide DICOM viewers into two categories: free products that are assumed to be risky, and paid products that are assumed to be dependable. The evidence does not support that distinction. Peer-reviewed literature describes open-source digital-health projects that have improved accessibility and resilience, while established imaging projects such as OHIF and Orthanc demonstrate that open development can produce widely used and technically capable ecosystems.^[1][2][3]

Even the term “free” is ambiguous. It may describe genuinely open-source software, a no-cost research or educational edition, a freemium commercial product, an older community version or an unsupported fork. These categories have different development models, governance structures, intended uses and support arrangements. Treating them as equivalent obscures the questions that matter clinically.

Open source is not automatically safe, validated or suitable for diagnosis. It can face difficult questions about governance, funding, regulatory responsibility, documentation and long-term maintenance. A 2025 review of open-source medical-device projects makes precisely this point: open development may reduce costs, broaden access and preserve support for abandoned technologies, but sustainable clinical use requires structures that address regulation, liability and continued support. The same discipline should be applied to proprietary products. Paying a licence fee does not, by itself, establish clinical validation, security or future support.^[4]

The useful question is therefore not, “Is it free?” It is, “Who is accountable for this software throughout its intended clinical life, and what evidence supports that accountability?”

A viewer used for education, research, patient access or non-diagnostic review is not necessarily subject to the same requirements as software intended for diagnostic interpretation. Procurement teams should examine the labelled intended use for the exact product, version, operating system and jurisdiction—not rely on the general reputation of a product family.

In the United States, a 510(k) clearance means that the FDA found a device substantially equivalent to a legally marketed predicate for its stated intended use. It is properly described as FDA-cleared, not FDA-approved. Clearance is meaningful evidence, but it should not be expanded beyond the device’s labelling or treated as a guarantee that every local configuration has been validated.^[5]

For Falcon MD, the FDA database lists desktop clearance K232589 under the device name Horos MD and mobile clearance K242552 under Horos Mobile; Falcon’s compliance documentation maps those clearances to Falcon MD and Falcon MD Mobile. The desktop indication covers diagnostic and review use by trained healthcare professionals and excludes mammography. The mobile indication contains an additional limitation: it is not intended to replace a full workstation and should be used only when access to a workstation is unavailable.^[6]

Clinical software is not static. Operating systems, graphics frameworks, DICOM libraries, network components and security dependencies change. A credible supplier or project should be able to explain how requirements are defined, how releases are verified, how measurement and display functions are tested, how regressions are detected and how safety-relevant changes are assessed.

Regulatory clearance provides one part of this evidence, but lifecycle discipline remains essential after market entry. In February 2026, the FDA’s Quality Management System Regulation became effective and incorporated ISO 13485:2016 by reference into the US medical-device quality-system framework. For a buyer, the practical issue is whether there is an identifiable organisation maintaining design controls, release records, complaint handling, corrective action and post-market obligations.^[7]

Source-code availability can support transparency and independent review, but it is not a substitute for validation. Equally, closed source does not prove that validation exists. Evidence should be requested directly: intended-use documentation, test summaries where available, release notes, supported-platform matrices, risk controls and a clear policy for significant changes.

Medical-imaging software handles sensitive information and often connects to PACS, cloud services, identity systems and external networks. Security should therefore be assessed as an ongoing engineering and operational process, not as a feature list recorded at the time of purchase.

NIST’s Secure Software Development Framework recommends practices for protecting software, reducing vulnerabilities, recording component provenance and managing the complete software lifecycle, including communication about end-of-support. FDA’s February 2026 medical-device cybersecurity guidance similarly addresses secure design, labelling and documentation intended to make marketed devices more resilient to cybersecurity threats.^[8][9]

A serious evaluation should ask who receives vulnerability reports, how quickly supported releases are patched, which operating-system versions remain supported, whether end-of-life dates are communicated, how third-party components are tracked, and what controls protect data in storage and transit. These questions apply equally to community projects and commercial vendors.^[8][9]

“DICOM-compatible” is not a complete interoperability claim. The DICOM standard explicitly states that DICOM by itself does not guarantee interoperability. A conformance statement enables a first-level comparison of supported services and information objects, but the healthcare facility must still validate the required exchange with its actual systems.^[10]

A procurement review should therefore examine supported SOP Classes, transfer syntaxes, query/retrieve roles, storage behaviour, character sets, DICOMweb services, compression handling and error conditions. It should then test representative studies against the intended PACS, modalities, routers and archives.^[10]

Falcon MD publishes a DICOM Conformance Statement covering storage, query/retrieve and media operations. Revision 1.1 adds DICOMweb services including QIDO-RS, WADO-RS and STOW-RS. Publishing this document is useful evidence of technical scope; successful deployment still depends on site-specific integration testing.^[11]

Clinical reliability includes what happens when something goes wrong. Relevant questions include whether users can obtain qualified technical support, how incidents are escalated, whether previous versions can be restored, how configuration and calibration records are retained, and whether data can be exported in a usable standards-based form.

Open-source projects can provide strong community support and permit organisations to maintain or adapt code independently. They can also become dependent on a small number of maintainers or organisations. Commercial products may provide contractual support and an identifiable manufacturer, but they can also be discontinued, acquired or moved to a different licensing model. Sustainability is therefore a governance and resourcing question, not a licence-category question.^[1][4]

A useful assessment should identify:

• who owns each safety- and security-relevant responsibility;
• the support and escalation arrangements during clinical use;
• the policy for compatibility with new operating-system releases;
• the process for recovering from a failed update;
• the availability of documentation and training;
• the ability to retrieve and migrate data if the product or service ends.

A zero purchase price does not mean zero cost. A realistic calculation includes deployment, integration, validation, security review, hardware, display quality assurance, training, updates, support, downtime, data migration and eventual decommissioning. A commercial licence may cover some of these responsibilities, or it may cover only the right to use the software. An open-source deployment may be economical where an organisation already has the technical capacity to operate it, or expensive where that capacity must be created externally.^[4][8]

The calculation should be local and time-based. A five-year view is generally more informative than comparing annual licence prices in isolation. The purpose is not to make commercial software appear cheaper; it is to identify which party will perform each necessary activity, how that activity will be funded and what happens if the responsible party is no longer available.

Before selecting a clinical DICOM viewer, a healthcare organisation should be able to answer:

• What exact clinical use is the product labelled for, on this platform and in this jurisdiction?
• What regulatory evidence applies to the deployed product and version?
• How are verification, validation, release control and post-market issues managed?
• What is the security-update, vulnerability-response and end-of-support policy?
• Is there a current DICOM Conformance Statement, and has the intended workflow been tested with the actual PACS and modalities?
• What support, training, documentation and incident-escalation arrangements are available?
• What is the full lifecycle cost, including migration and exit?

A product that cannot provide satisfactory answers should not be assumed suitable merely because it is commercial. Equally, access to source code should not be interpreted as sufficient evidence for diagnostic use.

Falcon MD can be evaluated against this framework without relying on claims that competitors are unsafe merely because they are free. Its publicly verifiable evidence includes FDA clearances for defined desktop and mobile uses and a published DICOM Conformance Statement. Those are relevant facts. They do not eliminate the healthcare provider’s responsibility to control display quality, ambient light, image compression, integration, training and local quality assurance.^[6][11]

That is the more credible position for a clinical-software company: not that price determines safety, but that clinical trust depends on evidence and accountability. Open-source and commercial models can both succeed or fail. A sustainable DICOM viewer is one whose intended use is clear, performance is verified, changes are controlled, vulnerabilities are managed, interoperability is tested, users are supported and an accountable organisation remains responsible over time.