Thank you for the correction, @raff ! You’re right , I was mixing up my current work on the health/maintenance pages with the broader epic.
I’m glad you’re still keen on a GSoC project for the horizontal scaling space. Looking at the backlog, I see several ‘Ready for Work’ areas that could form a high-impact Large (350h) project:
Hardening & Security (TRUNK-6416): Implementing the SecurityManager to prevent backend disk writes for a true stateless architecture.
Infrastructure Evolution (TRUNK-6484 & TRUNK-6486): Migrating from Nginx Ingress to the Traefik Gateway API and moving from MinIO to Rook for cloud-native storage.
DevOps Automation (TRUNK-6446): Integrating ArgoCD into our infra for fully automated deployments.
My goal would be to move the cluster support from ‘functional’ to ‘production-ready/automated.’ Does this focus on hardening and modernizing the infra layer align with your vision for the project?
Thanks Raff. Thats really great to hear Thanks for sharing this!
It’s exciting that centralized logging and a basic Grafana setup are already planned. I see this proposal as a natural extension of that work, focusing specifically on structured Prometheus metrics for hardware utilization and aggregated business level insights.
I’ve been reading about this area over the past few days and was also looking at last year’s GSoC project on Enhancing Performance Testing Infrastructure (Gatling by Ganesh), since both relate to observability and performance from different angles.
I’ve also been exploring Grafana recently to better understand dashboards and metrics visualization.
Given the planned Grafana plus logging work in the next couple of months, would it make sense for contributors to start exploring how a Prometheus-compatible metrics module could integrate with that setup? Or are there any existing design discussions or experimental branches I should look into first ??
Hi @olewandowski and @wikumc,
I am really interested in the Native O3 frontend for the audit trail project for GSoC 2026.
Bringing clinical accountability and change history directly into modern O3 ui makes user experience much more ease.
I would love to contribute and help to make some changes.Could you please share the link to the GitHub repository? So i can start exploring the codebase.
Hi @Veronica Muthee,
I’m Adarsh Dubey (Dev-1 contributor) and I’m preparing my GSoC 2026 proposal. I’ve been reviewing the “Visit Summary (Printable; early discharge summary)” documentation and roadmap discussions in detail, and I’m very interested in working on this project.
From my understanding, the goal is to implement a printable clinic visit summary (not inpatient discharge), focusing on structured aggregation of visit-level data such as demographics, vitals, diagnoses, medications, lab results, and appointments, while keeping the output dense and cost-efficient for low-resource settings.
I had a few clarifying questions while studying the scope:
1-Audience Scope
Based on Burke’s comments, there seems to be a distinction between clinician-facing and patient-facing summaries.
Would you recommend:
A single configurable template that adapts per audience, or
Two clearly separated summary types (clinician vs patient)?
2- Visit Scope
Should the summary strictly include data from the current visit only, or should it optionally include selected historical context (e.g., active conditions, chronic medications)?
3-Template Customization
Since implementations may require custom sections (e.g., billing-focused vs referral-focused), do you envision a template-driven architecture configurable per site? Or should we initially scope a standardized default template?
I’m currently exploring:
Visit, Encounter, Obs, Diagnoses, Orders models
The updated commonreports module
The existing print-label feature implementation
Before drafting my formal proposal, I’d appreciate your guidance on how you’d prefer the scope to be shaped.
Thank you!
I’ve been exploring O3 recently and thinking about areas where we could improve reliability, especially in low-connectivity environments.
One idea I had was around adding better offline support for O3 workflows (like orders or forms). Right now, many actions depend fully on network availability. In places with unstable internet, it could be risky if clinicians lose progress while entering data.
I was wondering if it would make sense to introduce a reusable offline layer in the frontend — maybe something like a local queue (using IndexedDB) that syncs automatically once the connection is restored. It could also show simple status indicators like pending/synced/failed.
This could potentially be designed in a way that different O3 modules can plug into it.
Would love to know if this aligns with current priorities or if similar work has already been explored
@dubeyadarsh862 Here are the responses concerning the Visit Summary (Printable; early discharge summary)
This should be clinician-oriented (referral, insurance, and care coordination use cases), not a patient-education document.
It is a visit-scoped summary, not a longitudinal chart extract, but may include selected active context (e.g., active conditions, chronic medications, allergies) when clinically relevant.
The template should ship with a dense, standardized default layout, with controlled section-level configurability to accommodate site-specific needs.
