Clinic Inbox Assistant: My MedGemma Hackathon Project for Safer, Faster Triage

Arul Cornelious — Tue, 10 Mar 2026 17:58:10 +0000

Disclaimer: This project uses only synthetic examples and does not process real patient data. It is a technical demo, not medical advice or a clinical triage tool.

During the MedGemma Impact Challenge on Kaggle, I designed and built Clinic Inbox Assistant, a focused prototype that turns messy clinical inbox notes into structured, triage‑ready summaries. In this post, I’ll share why I chose this problem, how I used MedGemma inside a single Kaggle notebook, the safety constraints I built in, and what I learned about turning a raw health AI model into something closer to a real‑world workflow.

Project links

Kaggle writeup & notebook: https://www.kaggle.com/competitions/med-gemma-impact-challenge/writeups/clinic-inbox-assistant-medgemma-impact-challenge
Demo video (YouTube): https://youtu.be/t-7_SpzPxoc?si=fpkzGIPIA6ISjVUF
Source code (GitHub): https://github.com/Arul1998/clinic-inbox-assistant2

You can also read Google’s announcement of the MedGemma Impact Challenge here:

https://www.edtechinnovationhub.com/news/google-launches-medgemma-impact-challenge-to-advance-human-centered-health-ai

The problem: messy inbox notes

Every day, clinics receive phone call summaries, portal messages, and nurse notes written in free text. Important details and red flags can hide inside long paragraphs, and someone still has to read everything line by line under time pressure. I wanted a way to turn one unstructured note into a structured, machine‑readable summary that could support triage, without pretending to replace clinical judgement.

The idea: one note in, structured triage out

Clinic Inbox Assistant takes a single free‑text note plus its type (for example, “phone call”, “patient message”, “nurse note”) and produces a structured JSON‑like object describing the situation. The output includes:

Key symptoms and complaints
Onset and duration where possible
Relevant risk factors or comorbidities
Potential red‑flag indicators
Suggested urgency bucket (for example, routine, soon, urgent)
A short natural‑language summary
A clear disclaimer that this is not real medical advice or triage

This structure is designed so an EHR, rules engine, or downstream workflow could plug it in and build their own logic on top.

Tech stack and MedGemma integration

The entire project runs inside a single Kaggle notebook as required by the MedGemma Impact Challenge. I used:

MedGemma 4B instruct from Google’s Health AI Developer Foundations collection
Python for orchestration and formatting
Simple helper functions to validate input and normalise the JSON‑like output

At the core of the notebook is one carefully designed prompt that:

Explains the clinical inbox scenario in plain language
Lists exactly which fields the model should extract
Defines a strict JSON‑like schema to follow
Reminds the model to be conservative with red‑flag claims and to default to “unknown” when unsure

Here is a simplified version of the output format:

{
  "note_type": "phone_call",
  "summary": "Short description in plain language",
  "symptoms": [
    { "name": "chest pain", "duration": "2 hours", "severity": "moderate" }
  ],
  "risk_factors": ["hypertension", "smoker"],
  "possible_red_flags": ["sudden onset chest pain at rest"],
  "urgency": "urgent",
  "disclaimer": "This is not medical advice or a real triage decision."
}

The notebook then calls MedGemma with this prompt and the raw note text, parses the response, and prints both a human‑readable summary and the structured object.

Safety, privacy, and “this is not medical advice”

Because this is health‑adjacent, I made safety and privacy explicit goals. The project uses only synthetic examples and does not process real patient data in the notebook. Every output includes a strong disclaimer that this is a prototype and not a replacement for clinical judgement, triage protocols, or emergency services.

In a real deployment, I would expect:

Proper dataset curation and evaluation with clinicians
Guardrails for hallucinated red flags or missing critical symptoms
Integration into existing clinical workflows and EHR systems
Regulatory and privacy review before touching any real data

For the competition, the goal was to demonstrate a plausible workflow that could eventually be hardened, not to ship a production‑ready medical device.

Lessons from the MedGemma Impact Challenge

The challenge itself is focused on human‑centred, deployable healthcare AI that can run with privacy and edge constraints in mind. Working within a single notebook and model forced me to think more like a product designer than just someone calling an API.

Some key lessons:

Scope matters: doing one thing well (single‑note triage structure) beats a vague “AI for everything in the clinic” idea.
Prompt is product: most of the behaviour came from carefully iterating on the prompt and schema, not complex code.
Explainability wins: a structured JSON‑like output is easier to audit, debug, and plug into other systems than a free‑form paragraph.
Communication counts: the competition explicitly scores execution and communication, so the writeup and demo video matter almost as much as the notebook.

Even if this project never leaves the notebook, the design pattern of “one unstructured input → structured, auditable output” is reusable in many domains beyond healthcare.

How you can reuse or extend this idea

If you want to experiment with something similar, here are some easy variations:

Adapt the schema to other clinical documents (for example, discharge summaries, referral letters).
Use the same pattern for non‑medical inboxes: support tickets, HR requests, or legal notes.
Add a small rules engine or dashboard on top of the structured output instead of staying in a notebook.

If you build a spin‑off of Clinic Inbox Assistant, I’d love to see how you adapt the schema and safety choices for your own domain.

I Built a VS Code Extension to Clean Up Angular Codebases — Here's What It Does

Arul Cornelious — Sun, 08 Mar 2026 23:21:34 +0000

Why I built it

After refactors, Angular apps often end up with unused dependencies, dead exports, and lint drift. I wanted a single place in VS Code to run the usual code-quality tools and jump straight to the issues – without remembering CLI commands or switching to the terminal.

So I built Angular Code Quality Toolkit: a small VS Code extension that runs depcheck, ts-prune, ESLint, and stylelint from the editor and shows everything in the Problems panel and as squiggles in the code.

What it does

Run depcheck — Finds unused and missing npm dependencies; results show in Output and Problems.
Run ts-prune — Finds unused TypeScript exports; uses tsconfig.app.json when present.
Run ESLint — Runs your workspace npm run lint and shows diagnostics in the editor (with a nudge to migrate from TSLint if needed).
Add ESLint to Angular project — One-click run of ng add @angular-eslint/schematics.
Run stylelint — Lints CSS/SCSS (uses your npm script or a default glob).

All results go to one Angular Code Quality output channel and into View → Problems plus inline squiggles, so you can fix issues file-by-file.

How to use it

Install from the VS Code Marketplace or search Angular Code Quality Toolkit in Extensions.
Open an Angular project (folder with package.json).
Ensure the tools are available in that project (npm install --save-dev depcheck ts-prune, plus a "lint" script and optionally stylelint).
Ctrl+Shift+P (or Cmd+Shift+P) → run Angular Code Quality: Run depcheck (or ts-prune, ESLint, stylelint).
Open Problems and the Angular Code Quality output channel; click an issue to jump to the file and line.

Extension + CI, not either/or

The extension is for fast feedback while you code. For team-wide enforcement, use CI (e.g. GitHub Actions) and git hooks (e.g. husky + lint-staged) with the same tools. The README has a sample GitHub Actions workflow you can copy.

DEV Community: Arul Cornelious