OrthoRay – A native, lightweight DICOM viewer written in Rust/wgpu by a surgeon
9 comments
Documentation: For those interested in the technical details and usage, I wrote extensive documentation here: https://orthoarchives.com/en/orthoray/docs/getting-started/w...
Can this be used for Haller index?
Recently my family member start to deal with Pectus excavatum, the xray provider and the doctor were not on the same platform and witnessed doctor doing manual calculation for it. I wished there was a way do it with web upload and get the result right a way that is error prone and accurate.
Recently my family member start to deal with Pectus excavatum, the xray provider and the doctor were not on the same platform and witnessed doctor doing manual calculation for it. I wished there was a way do it with web upload and get the result right a way that is error prone and accurate.
Very cool! I’m exploring adding DICOM support to https://minfx.ai project. The idea is to better support machine learning in medical space and make DICOM viewing in web assembly. Not right now, but in next 2/3 months. What you’ve built looks very impressive! Are you planning to release Linux binaries?
Happy to collaborate!
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
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 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
[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
emailed you at the account in your HN profile
Why not use iced to have a native UI instead of WebView?
I am an orthopedic surgeon and a self-taught developer. I built OrthoRay because I was frustrated with the lag in standard medical imaging software. Most existing solutions were either bloated Electron apps or expensive cloud subscriptions.
I wanted something instant, local-first, and privacy-focused. So, I spent my nights learning Rust, heavily utilizing AI coding assistants to navigate the steep learning curve and the borrow checker. This project is a testament to how domain experts can build performant native software with AI support.
I built this viewer using Tauri and wgpu for rendering.
Key Features:
Native Performance: Opens 500MB+ MRI series instantly (No Electron, no web wrappers).
GPU-Accelerated: Custom wgpu pipeline for 3D Volume Rendering and MPR.
BoneFidelity: A custom algorithm I developed specifically for high-fidelity bone visualization.
Privacy: Local-first, runs offline, no cloud uploads.
It is currently available on the Microsoft Store as a free hobby project.
Disclaimer: This is intended for academic/research use and is NOT FDA/CE certified for clinical diagnosis.
I am evaluating open-source licensing options to make this a community tool. I’d love your feedback on the rendering performance.
Link: https://orthoarchives.com/en/orthoray