2026
RCPia
A mobile app for CHU Mohammed VI de Marrakech that help prepare oncology tumor-board meetings with nine specialized AI agents.
My role
Freelance, end to end: I built the mobile app and the web client, architected the backend and the database, collaborated on the RAG pipeline, and deployed the full stack. I maintain the whole application and all of its deployments.
Context
A retrospective study in the urology department of CHU Mohammed VI de Marrakech, affiliated with the Faculty of Medicine of Marrakech, tested whether AI can take part in a multidisciplinary tumor-board meeting (RCP) in urology. In an RCP, specialists such as the urologist, oncologist, radiologist and pathologist discuss one patient's cancer case together and choose a treatment collectively, for example surgery, radiotherapy or surveillance. It is held for every patient and ends in a personalised care plan (PPS). The study was presented at the Congrès Français d'Urologie 2025 and showed that AI can be integrated into these meetings.
Problem
Tumor-board meetings depend on the right specialists being in the room at the right time. Three things get in the way. Time: specialists are not always available in real time. Multidisciplinarity: some specialists are sometimes absent. Personalised care: a lack of time can lead to hasty decisions. Everything RCPia produces is a draft for physicians to review, not a validated medical decision.
Objectives
- Build RCPia as a mobile app for Android and iOS, based on specialized AI agents equipped with the latest guidelines from the learned societies.
- Generate a personalised care plan (PPS) for every patient record entered, so physicians review a draft instead of starting from a blank page.
- Start with prostate cancer and bladder cancer.
Architecture
The mobile app and the web client only talk to a FastAPI backend, which stores patients, jobs and plans in Supabase. The backend forwards each request to a separate AI service, a second FastAPI app built on LangGraph and LangChain, and polls it every 3 seconds. The AI service runs nine specialists (urologist, oncologist, radiologist, pathologist and others) in two parallel waves. Each retrieves guideline passages from a pgvector knowledge base of about 11,800 chunks from 168 guideline files, then calls Claude. A supervisor reads all nine reports and writes the PPS in six sections. A full run takes about 75 to 80 seconds.
Key decisions and trade-offs
Run the nine specialists in two waves instead of all in parallel: diagnosis first, then management.
Trade-off: The urologist, pathologist and radiologist run first. The other six start once those are done and read their reports, so treatment advice is informed by the diagnosis. It is slower than full parallelism, and the supervisor still finishes the run.
Never invent a substitute when generation fails.
Trade-off: If one specialist fails, its report is labelled as not generated and the run continues. If the supervisor fails, the whole job is marked as failed. A visible failure costs a retry, but it avoids a plausible care plan nobody can trace.
Keep the apps away from the AI service: they only talk to the backend.
Trade-off: Changes to the AI contract only affect the backend, and the AI service stays behind a shared secret. The cost is one extra hop and a second job record to keep in sync.
Keep the web client and the app private, with access restricted to the team.
Trade-off: The AI agents run on paid API keys, so an open app would let anyone start running them. Restricting access keeps the keys and the usage under control. The cost is that nobody outside the team can try it, so there is no public demo.
Challenges
- Retrieval kept returning generic prostate guidelines. With one search, the psychologist and nutritionist agents got none of their own specialty's passages from the top 40 candidates. We split retrieval into two passes per agent, one restricted to the specialty's own sources and one using the patient's case, and moved the filtering into a database function.
- Running jobs live in the AI service's memory, so a redeploy or crash loses them. The backend now detects the lost job, marks it as failed, and offers a relaunch.
- Model safety filters can decline oncology or genetics content. A refusal is treated as a failed report, never as an opinion, and a fallback model can re-run the request.
Outcome
A full plan is drafted in about 75 to 80 seconds. Abstract accepted as an oral communication at the 120th Congrès Français d'Urologie (2026), with the presentation scheduled for 18 November 2026.
Stack
- React Native
- Expo
- NativeWind
- Next.js
- FastAPI
- PostgreSQL
- Supabase
- pgvector
- LangGraph
- LangChain
- RAG
- Claude API
- AI Vision
- Python
- Docker
- Railway
- Vercel