I Built NipCure for My Grandparents 🩺
This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend
When I saw the Build for a Friend challenge, I immediately thought about my grandparents and how difficult medical reports can be to navigate when you're not familiar with medical terminology.
A medical report can contain medications, instructions, warnings, follow-up appointments, dietary information, and other important details spread across several pages. The problem isn't necessarily accessing the report. It's understanding what information matters, what needs attention, and what should be remembered afterward.
So I decided to build something around that problem.
That project became NipCure.
Meet NipCure
NipCure is a healthcare assistant designed with older adults in mind. The main idea is simple: the user uploads a medical report, and NipCure transforms the information already contained in that document into a structured Care Plan that is easier to read and follow.
I wanted the interface to stay simple enough for someone who isn't very comfortable with technology. That influenced the layout, typography, navigation, and the number of actions presented on each screen.
The user can create an account and provide some information about themselves.
The profile can include information such as age, allergies, dietary restrictions, food preferences, and additional notes. This information provides context for personalization, but it does not replace the medical report. The report remains the primary source of medical information.
Demo
Here is a short walkthrough of NipCure, showing the main flow from uploading a medical report to generating and reviewing the Care Plan.
The demo focuses on the actual application workflow: creating a profile, uploading a medical report, processing it with the local AI pipeline, reviewing the generated Care Plan, exploring educational resources, and using voice assistance.
Turning a Medical Report Into a Care Plan
The main workflow starts with a PDF. The user uploads their medical report directly into NipCure.
The backend extracts the text from the document and sends it through the AI pipeline. This is where Gemma 3 becomes the core of the application.
I'm running Gemma 3 locally through Ollama, rather than relying on a proprietary cloud LLM for the core medical-document processing.
The workflow looks like this:
Medical Report
↓
PDF Text
↓
Gemma 3
↓
Structured Medical Plan
↓
Profile Comparison
↓
Care Plan
The goal isn't simply to summarize the PDF into another paragraph. I wanted the result to be structured around information that is actually useful to the person reading the report.
The Care Plan can organize medications mentioned in the report, instructions, important warnings, dietary information, follow-up appointments or tests, and questions that may be worth discussing with a doctor.
Instead of searching through several pages of medical terminology, the user gets a clearer view of the information already contained in the original document.
An important design constraint is that NipCure should not invent medical information. The medical report remains the source, while the AI organizes the information into a more accessible format.
Personalization Without Changing the Source
The patient profile becomes useful when the information in it needs to be compared with the report.
For example, a profile may contain an allergy or dietary restriction that appears to conflict with something mentioned in the medical document. I didn't want the AI to simply decide which information was correct and silently modify the result.
Instead, NipCure can identify the potential conflict and mark it as Needs verification.
The report remains the primary source, while the profile provides additional context. The AI can therefore surface something that deserves attention without making the medical decision itself.
The principle is straightforward:
Medical Report = Source
Patient Profile = Context
AI = Organizer
Uncertainty = Visible
This keeps the system focused on document understanding and personalization rather than autonomous medical decision-making.
Why Gemma 3 Runs Locally
One of the main technical decisions behind NipCure was running Gemma 3 locally through Ollama.
Medical reports can contain sensitive personal information, so I wanted the core AI workflow to be capable of running directly on the user's machine instead of making the application dependent on a proprietary cloud LLM.
The architecture is straightforward:
PDF
↓
FastAPI
↓
Ollama
↓
Gemma 3
↓
Structured Care Plan
This is also where the open-weight nature of Gemma becomes particularly useful. With Gemma 3 + Ollama, I can control where inference happens and how the model is integrated into the application.
Instead of treating the model as a remote API that receives a document and returns an answer, the model becomes part of the application's local architecture.
For NipCure, that was an important design choice because the application is built around personal documents.
Voice Assistance with ElevenLabs
Another part of the project is making the generated information easier to access.
NipCure includes voice assistance so that the Care Plan can be listened to instead of relying entirely on the visual interface. The application uses ElevenLabs for text-to-speech, with a browser speech fallback when the external service is unavailable.
This fits into the accessibility goal of the project: the Care Plan should not only be structured clearly, but should also be available through more than one interaction method.
Educational Resources with SerpApi
The Care Plan isn't always the end of the user's journey. Someone may want to learn more about a medical topic mentioned in their report.
For this, NipCure includes an educational resources section.
I use SerpApi to retrieve relevant educational search results. These results are intended for learning and exploration and are kept separate from the medical-plan generation process.
In other words, a search result doesn't get to rewrite the medical report or modify the Care Plan generated from it.
This separation helps keep the medical document as the primary source while still giving the user a way to explore related information.
What's Under the Hood?
NipCure combines a local AI stack with a few external services.
The frontend is built with HTML, CSS, and JavaScript, while the backend uses Python and FastAPI. PostgreSQL stores users, profiles, and reports, with JWT-based authentication handling access to user-specific data.
The AI layer is built around Gemma 3 and Ollama. For additional functionality, ElevenLabs provides voice generation and SerpApi provides educational resource discovery.
The overall architecture looks like this:
NipCure
│
┌──────────────┴──────────────┐
│ │
Frontend FastAPI
│ │
│ ┌───────────┼───────────┐
│ │ │ │
│ PostgreSQL PDF Text Ollama
│ │
│ Gemma 3
│
├── Care Plan
├── Voice → ElevenLabs
└── Resources → SerpApi
I also added structured output validation around the AI response so that the frontend doesn't simply trust whatever format the model happens to return. The model output needs to match the structure expected by the application before it becomes part of the Care Plan.
Why Open Innovation Matters
For me, the value of open innovation isn't simply being able to say that I used an open model. It's the control it provides during development.
With Gemma 3 and Ollama, I can run the core model locally, experiment with the inference setup, and integrate the model directly into the backend without making the entire application dependent on a proprietary LLM API.
That changes the architecture from simply consuming an AI service to actually integrating an AI model into the application.
For a project involving personal documents, having that choice is particularly useful.
A Few Important Boundaries
NipCure is a document understanding and personalization assistant, not a doctor and not a replacement for professional medical advice.
The application should not invent medications, dosages, diagnoses, or warnings. It should not silently change information from the medical report, and external search results should not be treated as medical advice.
The medical report remains the primary source, the patient profile provides additional context, and potential conflicts are surfaced as Needs verification rather than automatically resolved.
For development and testing, the project should use synthetic or properly de-identified medical documents.
🏆 Prize Categories
Best Use of Gemma
NipCure uses Gemma 3 locally through Ollama as the core AI model for understanding uploaded medical reports and generating the structured Care Plan.
Build for a Friend
NipCure was built with my grandparents in mind, with a focus on making medical information easier to understand and access for older adults.
Why "NipCure"?
The name comes from Nippur + Cure.
Nippur is associated with one of the oldest known medical texts, so I wanted the name to connect the history of recorded medical knowledge with a modern AI approach.
In a way, NipCure takes an ancient idea — recording and organizing medical knowledge — and gives it a 21st-century AI upgrade.
What's Next?
NipCure is still a project, and there is plenty of room to improve it. Better document understanding, stronger structured-output validation, additional accessibility features, multilingual support, and more robust conflict detection are some of the areas I would like to explore next.
The core idea, however, remains simple: take the medical information that a patient already has and make it easier to understand, navigate, and review.
Built for my grandparents. Built for a friend. 🩺
Code
NipCure is open source. The complete source code is available on my GitHub repository:
NipCure — GitHub: https://github.com/MohamedAli1937/NipCure
Top comments (0)