I use OrthoRay as a secondary tool — preoperative planning, teaching, research. Clinical reads go through certified PACS, as they should. The app requires explicit consent at launch acknowledging it's not certified for clinical use.
Since you work in this space, I'm curious: is there a realistic FDA/CE pathway for an independent developer, or is certification fundamentally an enterprise-level investment? How do open-source tools like 3D Slicer or OHIF handle this same liability question?
I've never worked on anything subject to medical regulation, but regarding open source tools, common open source licenses such as the MIT License [1], BSD License [2], GPL 2 & 3 [3] [4] all include "no warranty" / "limitation of liability" language to (i) state that there is no warranty & the software is not fit for use for any particular purpose and (ii) state that the authors of the software will not be liable for any damages users might suffer from using it.
> To follow up with some research I did on this:
>
> No free DICOM viewer on the market carries FDA clearance or CE marking. Not 3D Slicer [1], not Horos [2], not OHIF. Even RadiAnt — which is paid and arguably the most popular Windows viewer — explicitly states "our viewer is not a medical product" and has no FDA/CE certification or timeline for one [3]. Interestingly, RadiAnt is also a solo-developer operation (Medixant, Poznań) — so the indie medical imaging developer is not a new phenomenon.
>
> The only DICOM viewer with both FDA 510(k) and CE Class IIa is OsiriX MD — paid (~$69/mo), Mac-only.
>
> What's interesting is how the open-source ecosystem handles this. As @shoo noted, license disclaimers provide baseline liability protection. But beyond that, both 3D Slicer and OHIF have served as the foundation for FDA-cleared commercial products — Kitware built an FDA-cleared lung imaging tool on top of Slicer [4], and OHIF's GitHub explicitly notes it has "served as the basis for many FDA Cleared medical imaging viewers" [5].
>
> So the pattern seems to be: the platform stays uncertified, companies build certified products on top of it. The certification barrier appears to be fundamentally an enterprise-level compliance investment (ISO 13485 QMS, 510(k) submission, post-market surveillance) — not a reflection of software quality.
>
> OrthoRay sits in the same regulatory space as every other free viewer. The difference is the intended audience — orthopedic surgeons doing preoperative planning, teaching, and research — not primary radiological diagnosis.
>
> What I'm more curious about is the performance side. I built OrthoRay's rendering pipeline in Rust/wgpu because I kept hitting walls with existing viewers when doing real-time 3D volume rendering and MPR reconstruction on large datasets. The bottleneck wasn't the UI — it was the engine. I think there's an underserved gap in academic and research workflows where real-time GPU-accelerated rendering matters — intraoperative planning, surgical simulation, 3D reconstruction from CT/MRI for teaching.
>
> @verdverm — from your position in the commercial space, do you see demand for this kind of native, GPU-first rendering performance? Or is the industry moving entirely toward cloud/server-side rendering and the local viewer is becoming irrelevant?
>
> [1] https://www.slicer.org/commercial-use.html
> [2] https://groups.google.com/g/horos-project/c/TksXEbIDDek
> [3] https://www.radiantviewer.com/dicom-viewer-forum/ce-certific...
> [4] https://www.kitware.com/kitware-supports-development-and-lau...
> [5] https://github.com/OHIF/Viewers
Documentation: For those interested in the technical details and usage, I wrote extensive documentation here: https://orthoarchives.com/en/orthoray/docs/getting-started/w...
How are you using this in your practice? What liabilities might arise?
disclaimer, I work with a company that builds one of those expensive offerings
Fair questions.
I use OrthoRay as a secondary tool — preoperative planning, teaching, research. Clinical reads go through certified PACS, as they should. The app requires explicit consent at launch acknowledging it's not certified for clinical use.
Since you work in this space, I'm curious: is there a realistic FDA/CE pathway for an independent developer, or is certification fundamentally an enterprise-level investment? How do open-source tools like 3D Slicer or OHIF handle this same liability question?
Would appreciate your perspective.
I've never worked on anything subject to medical regulation, but regarding open source tools, common open source licenses such as the MIT License [1], BSD License [2], GPL 2 & 3 [3] [4] all include "no warranty" / "limitation of liability" language to (i) state that there is no warranty & the software is not fit for use for any particular purpose and (ii) state that the authors of the software will not be liable for any damages users might suffer from using it.
[1] https://opensource.org/license/mit
[2] https://opensource.org/license/bsd-3-clause
[3] https://opensource.org/license/gpl-2-0
[4] https://opensource.org/license/gpl-3-0
> To follow up with some research I did on this: > > No free DICOM viewer on the market carries FDA clearance or CE marking. Not 3D Slicer [1], not Horos [2], not OHIF. Even RadiAnt — which is paid and arguably the most popular Windows viewer — explicitly states "our viewer is not a medical product" and has no FDA/CE certification or timeline for one [3]. Interestingly, RadiAnt is also a solo-developer operation (Medixant, Poznań) — so the indie medical imaging developer is not a new phenomenon. > > The only DICOM viewer with both FDA 510(k) and CE Class IIa is OsiriX MD — paid (~$69/mo), Mac-only. > > What's interesting is how the open-source ecosystem handles this. As @shoo noted, license disclaimers provide baseline liability protection. But beyond that, both 3D Slicer and OHIF have served as the foundation for FDA-cleared commercial products — Kitware built an FDA-cleared lung imaging tool on top of Slicer [4], and OHIF's GitHub explicitly notes it has "served as the basis for many FDA Cleared medical imaging viewers" [5]. > > So the pattern seems to be: the platform stays uncertified, companies build certified products on top of it. The certification barrier appears to be fundamentally an enterprise-level compliance investment (ISO 13485 QMS, 510(k) submission, post-market surveillance) — not a reflection of software quality. > > OrthoRay sits in the same regulatory space as every other free viewer. The difference is the intended audience — orthopedic surgeons doing preoperative planning, teaching, and research — not primary radiological diagnosis. > > What I'm more curious about is the performance side. I built OrthoRay's rendering pipeline in Rust/wgpu because I kept hitting walls with existing viewers when doing real-time 3D volume rendering and MPR reconstruction on large datasets. The bottleneck wasn't the UI — it was the engine. I think there's an underserved gap in academic and research workflows where real-time GPU-accelerated rendering matters — intraoperative planning, surgical simulation, 3D reconstruction from CT/MRI for teaching. > > @verdverm — from your position in the commercial space, do you see demand for this kind of native, GPU-first rendering performance? Or is the industry moving entirely toward cloud/server-side rendering and the local viewer is becoming irrelevant? > > [1] https://www.slicer.org/commercial-use.html > [2] https://groups.google.com/g/horos-project/c/TksXEbIDDek > [3] https://www.radiantviewer.com/dicom-viewer-forum/ce-certific... > [4] https://www.kitware.com/kitware-supports-development-and-lau... > [5] https://github.com/OHIF/Viewers