The LibreHealth Radiology Viewer Modernization project aims to upgrade the existing radiology viewing capabilities by integrating the latest OHIF (Open Health Imaging Foundation) Viewer components. This upgrade will enhance visualization capabilities, improve performance, and provide a more extensive set of tools for radiological diagnosis while maintaining compatibility with existing PACS and imaging workflows.
Current OHIF Advantages:
Zero-footprint medical image viewing
Support for latest DICOM standards
Enhanced 3D visualization capabilities
Improved performance and loading times
Extended measurement tools
Better mobile device support
Structured reporting integration
Advanced hanging protocols
The deliverables of the project are as follows:
Integrate latest OHIF Viewer components with LibreHealth Radiology
Implement seamless PACS communication
Create customized UI/UX aligned with LibreHealth design patterns
Develop migration tools for existing configurations
Build comprehensive documentation for deployment and usage
Create extension points for custom tools and workflows
This modernization will significantly improve the radiology viewing experience in LibreHealth Radiology while maintaining compatibility with existing workflows. The integration of modern OHIF components will provide users with advanced visualization capabilities and tools, enhancing diagnostic capabilities and user experience.
The project emphasizes maintaining compatibility with existing systems while providing a path for future enhancements. The modular approach ensures that new features can be added without disrupting core functionality, while the focus on performance and usability ensures practical deployment in various healthcare settings.
I recently introduced myself over in the Meet the Community thread, and I am very eager to tackle this project for GSoC 2026.
I have been exploring both the lh-radiology and OHIF/Viewers repositories to map out my proposal. I see that the current implementation in the /Viewers directory relies on the legacy Meteor.js build of OHIF. My understanding is that the primary goal of this project is to replace that legacy code and integrate the modern OHIF v3 (React/TypeScript) to communicate with the Orthanc backend via DICOMweb.
I did have a quick question about the application process. I noticed that some of the other GSoC projects (like the Automated Security Assessment and Automated Dependency Testing Pipeline) have specific Preliminary Tasks listed in their project descriptions for applicants to complete.
Since this project thread doesn’t explicitly list any preliminary tasks, I wanted to ask what the best way to proceed is. Are there any specific warm up issues, mini tasks, or particular areas of the codebase you would recommend I tackle first to familiarize myself with the contribution workflow and demonstrate my skills?
While exploring the OHIF viewer locally, I noticed that studies are loaded through DICOMweb endpoints (/studies -> /series -> /instances -> /frames) and the viewer route is dynamically created through the mode system using routeName: 'viewer'
Before moving further, I wanted to clarify one architectural detail: when integrating OHIF with LibreHealth Radiology, is the expectation to run OHIF as a separate viewer application (launched via something like /viewer?StudyInstanceUIDs=), or should it be embedded directly within the LibreHealth Radiology frontend?
I explored the current LibreHealth Radiology repository and noticed that the existing OHIF viewer inside Viewers/OHIFViewer is the older Meteor-based version. I also ran the modern OHIF Viewer locally and examined its architecture (modes, extensions, and DICOMweb workflow).
I wanted to clarify a few things:
Should the new integration replace the existing Meteor-based OHIF viewer entirely, or is the goal to maintain backward compatibility with the current setup?
Would the modern OHIF viewer be expected to run as a separate application (similar to the current Ohif Viewer Url configuration), or should it be embedded directly into the newer lh-radiology-owa frontend?
Is Orthanc the primary PACS system expected for development/testing, and is there a recommended local setup for the DICOMweb endpoint?
Hi,
I’ve been working on my proposal for the Modern OHIF Integration project and have completed a detailed draft covering the current architecture, proposed system design, migration strategy, and implementation timeline.
Before finalizing it, I’d really appreciate any feedback from the mentors especially on whether:
the proposed integration approach (static OHIF & config-based switching) aligns with expectations
the migration strategy is realistic and safe for existing workflows
there are any gaps in scope or important aspects I might have missed
I’ve tried to base the proposal on a detailed analysis of the current Meteor-based viewer, Orthanc integration, and the modern OHIF architecture, but I’d like to make sure I’m heading in the right direction.
Proposal : LibreHealth proposal - Google Documenten
It’s been a while since I shared an update, so here I am back again.
From the past 3-4 days, I was working and trying to deeply understand how exactly Orthanc and OHIF Viewer works with each other. I was working more on understanding and learning the concepts (like orthanc configuration, DICOMweb, PACS, QIDO-RS, WADO-RS, extensions, modes, etc.), which will be critical during the development period. I was able to make orthanc work with the latest version of OHIF Viewer, added custom extensions, custom config and created a Proof of Concept for this project (as there were no specific POC mentioned in this project unlike other LH projects).
Usage of AI: I only used AI for improving the custom extension frontend part, and rephrasing the README.md file (content is mine), and rest of the code is written by me.
I have also started working on the proposal and will share the draft here pretty soon. Meanwhile, please check the POC and let me know if you have any suggestions <3
That’s disqualifying. No AI may be used because it introduces copyright issues. Not to mention the goal of this task to prove you have the competency to do the project. This is not okay, at all. Read the post below because I’m not happy. I’d rather accept nobody than accept people who will go ahead and use AI and not disclose it.
Alright, I totally get it now. Actually I used it as I was working on POC only, not on the actual project or the proposal. The POC was not even part of any prerequisite step, I worked on it for my understanding only, and used AI for the boring stuff, which will not be repeated while working on the actual project. I will assure you from now that the further work will be solely without use of any AI in any way possible. The proposal on which I am working, is completely being written by me (word to word) and will not have involvement of any LLM.
I am almost finished with the proposal except the wireframe part, I wanted to ask if hand drawn wireframes on paper (Low Fidelity) is accepted in the proposal or not? Or do we need to attach Software based wireframes (like Figma).
The whole proposal is written by me, with NO INVOLVEMENT OF LLM in it. Please review and let me know if any changes are required. I know it is already late, but I am ready to do make some changes if necessary.
