GSoC 2026 Proposal

Development Repo Management
1

Title: [Proposal] Integrated AI Disease Prediction & Image Detection Suite for O3

Hello OpenMRS Community,

My name is Alivia Hossain and I am a developer passionate about leveraging AI to support healthcare in resource-constrained settings. I am writing to propose a technical integration of an end-to-end Disease Prediction Suite into the OpenMRS 3.0 ecosystem.

The Project Overview

I have developed (and improving) a system designed to move from record-keeping to active clinical assistance. Key features include:

  1. Predictive ML Models: Trained on numeric patient data (vitals, labs) to flag risks.

  2. Bayesian Screening: A probability calculator for rapid symptom-based triage.

  3. Medical Imaging AI: CNN-based detection for skin and eye pathologies (e.g., melanoma, cataracts).

  4. Integrated Dashboards: An O3-compatible Doctor Dashboard for clinicians and a standalone Patient Dashboard (utilizing OMRS Auth).

  5. AI Chatbot: To assist with triage and context-aware patient/doctor FAQs.

Proposed Technical Approach

To maintain scalability and follow GSoC 2026 standards, I am planning the following:

  • Architecture: A Sidecar API approach (Python/FastAPI) to host the models, keeping the heavy ML processing separate from the OMRS Core.

  • Data Exchange: Utilizing REST/FHIR R4 to fetch observations linked to specific Concept IDs.

  • UI/UX: Building O3 Microfrontends (ESMs) to embed prediction widgets directly into the Patient Chart.

A Note on My Workflow & Strengths

My core strength lies in system architecture and clinical logic. I am a “thought-partner” developer—I leverage AI/LLM tools heavily to assist with the code generation and implementation phases. While I have a strong grasp of the project’s logic and data flow, I am still gaining experience with the specific nuances of the OpenMRS Java/React codebase and have occasionally faced hurdles with local environment setup.

My Current Status

I am currently familiarizing myself with the following repositories to ensure my project aligns with your standards:

  • openmrs-esm-patient-chart (to understand dashboard widgets)

  • openmrs-module-webservices.rest (for data fetching)

Request for Community Feedback

I would appreciate guidance from the core architects on:

  1. Does the Sidecar API + O3 Widget approach align with the GSoC 2026 roadmap?

  2. What are the best practices for storing/accessing clinical images for ML detection within the attachments module?

  3. Are there specific “Good First Issues” in O3 that would help me master the environment setup more effectively?

I am excited to “Write Code, Save Lives” and contribute to the evolution of O3!

Best regards, [Alivia Hossain / aliviahossain]

2

A slightly de-scoped version of what you’re proposing might, but a few things:

  1. What you’re proposing is ambitious; training even a single useful predictive model or “bayesian screening” or medical imaging CNN by itself is “big enough” to qualify as a GSoC project, but not one that we’re well-placed to mentor (among other things, to train models, you need data).
  2. We generally mentor projects that are selected by the community volunteers as mentors, and this means that we more likely to accept projects that we propose than projects proposed by GSoC hopefuls.
  3. OpenMRS is not really an imaging store… The attachments module is primarily for storing documents and maybe small images, but medical imaging storage is sort of outside of the scope of the application.
3

GSoC 2026 Proposal UPDATED

Title: [Proposal] Architectural Framework for AI Clinical Decision Support & Triage Chatbot in O3

Synopsis: This project aims to establish a standard, scalable pattern for integrating AI into OpenMRS 3.0. I propose building an AI Sidecar API that communicates with the O3 frontend to provide two high-value tools:

  1. Predictive Risk Widgets: Real-time clinical alerts based on patient observations (vitals/labs).

  2. Triage Support Chatbot: A microfrontend-based assistant to help clinicians with symptom-based triage and FAQ retrieval.

Technical Approach

  • Sidecar API (Backend): I will develop a Python FastAPI service to host ML models and the chatbot logic. This keeps resource-heavy AI processing isolated from the OpenMRS Core, ensuring system stability.

  • O3 Microfrontend (Frontend): I will build an ESM (EcmaScript Module) using React and TypeScript to embed prediction widgets and a floating chatbot interface directly into the Patient Chart.

  • Data Integration: All data exchange will follow FHIR R4 standards. The frontend will fetch patient observations via the OpenMRS FHIR module and send them to the Sidecar for analysis.

  • Chatbot Logic: The chatbot will use a retrieval-augmented generation (RAG) approach or a decision-tree model to assist with triage, ensuring clinical safety by staying within pre-defined parameters.

Project Deliverables

  • The “Bridge”: A reference implementation of an O3 widget calling an external AI API.

  • The Triage Bot: A functional UI component that guides clinicians through triage questions.

  • Documentation: A guide for future developers on how to add new “Sidecar” models to the framework.

Request for Final Community Feedback

  1. Alignment: Does focusing on the architectural pattern of the Sidecar API + Chatbot better meet the community’s 2026 goals?

  2. Existing Projects: Is there an existing “O3 Clinical Decision Support” or “Help ChatBot” project in the 2026 roadmap that I should merge this proposal into?