PancreAI

PancreAI helps clinicians review gene-expression research results and turn them into clear, doctor-approved messages for patients. No scores, no jargon.

Comment

Inspiration

While exploring public blood RNA-seq data from pancreatic disease patients, we were struck by how much a small blood sample can reveal, and how little of it ever reaches patients in a form they can understand. We wanted to improve that last step: turning complex research results into clear, caring messages, approved by a clinician.

We were also inspired by the Japanese anime film I Want to Eat Your Pancreas (Kimi no Suizō wo Tabetai). Its heroine lives with a serious pancreatic illness and keeps her feelings about it in a private diary, Living with Dying. It reminded us that behind every sample is a person trying to understand their own story, and that how we communicate matters as much as what the data says.

What it does

PancreAI is a research companion for pancreatic disease. It has two portals: one for clinicians and one for patients. It connects a blood RNA sample to a message the patient can understand, and a clinician approves every word.

For clinicians:

  • Run a trained model on a patient’s plasma extracellular-vesicle RNA-seq profile (preloaded GEO samples, or an uploaded ensembl_id,tpm CSV). It separates pancreatic ductal adenocarcinoma (PDAC) from chronic pancreatitis (CP).
  • See the class scores, the genes that pushed the score each way, and cohort-level validation metrics with their counts. All of it is labeled as research output, not a diagnosis.
  • Write a message to the patient. Gemini can rewrite it into plain, warm language, with a template fallback if Gemini is off or unavailable.
  • Every patient message goes through a deterministic risky-phrase check, for example to block false reassurance. Nothing is sent until the clinician reviews it and approves it.

For patients:

  • A calm, mobile-first portal: participation status, the sample’s journey, a study-level explanation of the genes the research looks at, the clinician-set care plan, and messages their doctor approved.
  • By design, patients never see individual scores, labels or gene contributions. Individual research predictions are too easy to mistake for clinical results, so the patient side shows only what a clinician has chosen to say.

The demo follows Alex, a fictional patient with chronic pancreatitis, through quarterly check-ins: sample in → analysis → Gemini-softened message → clinician approval → the message arrives on Alex’s phone.

How we built it

  • Data: GEO series GSE133684 (Yu et al., Gut 2020): 501 plasma EV long-RNA samples (284 PDAC, 100 CP, 117 healthy) across 54,148 genes in TPM. We verified every label against the GEO metadata and documented the gaps.
  • Model: a scikit-learn pipeline fitted on the training split only.
    • Steps: expression filter (14,792 genes) → log1p → SelectKBest → StandardScaler → L2 logistic regression.
    • Tuning: 5-fold stratified CV.
    • Held-out internal validation: ROC-AUC 0.979, sensitivity 0.99 (71/72 PDAC), specificity 0.84 (21/25 CP).
    • Published-signature comparison: we also rebuilt the published eight-gene signature as a reference experiment (7 of the 8 genes are in the matrix).
  • Backend: FastAPI, SQLite and pandas, with Gemini for clinician-approved message rewriting.
  • Frontend: React 19, Vite, Tailwind CSS v4, Framer Motion and Recharts, with a separate visual theme for each portal.
  • Quality:
    • Tests: Vitest and Testing Library (194 frontend tests) plus pytest (154 backend tests), run on every pull request through CI.
    • Patient-page check: automated tests fail the build if any patient page shows a score, label or diagnosis term.
    • Accessibility: Lighthouse scores 100 on the key pages.
  • Team workflow: a two-person team working with AI coding agents. Claude Code worked the first half and Codex took over the second, through a written handoff.
    • Ownership and messages: each person owned specific folders, and everyone, agents included, posted on a shared GitHub-issue message board.
    • Guardrails: hooks blocked pushes to main and reads of secret files, and merges ran only through a script that waits for CI to pass.

Challenges we ran into

  • Keeping the disclosure policy honest. Showing the patient their own score is the obvious design, and it’s exactly the wrong one. We wrote tests that fail the build if any patient page shows a prediction, label or condition term outside the clinician’s care plan.
  • Messy real data.
    • The 100 CP samples have no GEO metadata, so their labels come only from column names.
    • One of the eight published genes (MARCH2) isn’t in the matrix at all.
    • The model scored healthy samples as PDAC-like, because it had never seen healthy samples. We added an out-of-scope guard so those samples return no score at all.
  • Not overclaiming. With only 25 CP samples in the test set, one sample moves specificity by 4 points. Every metric in the app is labeled “internal validation, single held-out split”, with its counts beside it, and is never set against the published AUC as if it were a replication.
  • LLM reliability. During a rehearsal, Gemini returned a cut-off rewrite. We added a completion guard and a template fallback, so a message can always be sent.
  • Coordinating humans and agents. Two people, two AI agents, a mid-project handoff, and one shared codebase. We relied on clear ownership, a message board, protected files, and merging only when CI passed.

Accomplishments that we're proud of

  • One complete flow working on real data with a real model and live Gemini: RNA-seq → model → Gemini rewrite → clinician approval → patient phone.
  • Patient safety built into the code: score-free patient pages enforced by tests, a risky-phrase check on every message, and approval required before anything is sent.
  • Honest science: documented data provenance, a model card, and metrics labeled with their limits.
  • A polished, accessible UI: Lighthouse accessibility 100 on the landing page, the patient portal and the clinician workspace, and usable from a 375px phone screen up to desktop.

What we learned

  • In healthcare AI, deciding what not to show the patient matters as much as the model.
  • An LLM works best here as a clinician’s writing assistant, with deterministic checks and a human approving the result, not as an autonomous voice to the patient.
  • AI coding agents move fast when the guardrails (ownership, CI, protected files, handoffs) are explicit, and they break things fast when they aren’t.

What's next for PancreAI

  • External validation on an independent cohort, and a three-class model that includes healthy controls.
  • Robust raw-data intake (FASTQ → TPM) and stronger validation of uploaded data.
  • Clinician co-design sessions and patient-comprehension testing of the rewritten messages.
  • Real authentication, audit logs and privacy controls (e.g. HIPAA) before any real patient use.

Built With

Share this project:

Updates

Submission history