Clinical Oracle

Polypharmacy risk intelligence ,real FDA FAERS signals, zero PHI transmitted, clinician always in the loop. MCP superpower for safer prescribing.

Comment

Inspiration

I kept thinking about a simple, terrifying scenario: an elderly patient at a government hospital comes in on five medications, a sixth gets added, and nobody has time to cross-check everything. Not because the doctors don't care , they do, deeply, but because the patient load is overwhelming, the tools are nonexistent, and there are fifty more patients waiting outside.

India has over 100 million people above 60, and polypharmacy is rampant — especially in patients managing diabetes, hypertension, and heart disease simultaneously. Adverse drug reactions from dangerous combinations are a leading cause of preventable hospitalization, yet most clinicians are working from memory and experience alone, with no real-time decision support.

I wanted to build something that could sit quietly in a clinician's workflow and say "before you sign this prescription — here's what real patients have experienced on this exact combination."

What it does

Clinical Oracle gives clinicians a real-time second opinion on drug combinations, grounded in actual FDA adverse event reports — not textbook rules, not LLM guesswork.

Three tools work together in sequence:

  • signal_scan asks: what has actually happened to real patients on this drug combination? It queries the FDA FAERS database live and returns real report counts.
  • risk_score asks: given this specific patient — their age, kidney function, current INR — how worried should we be? It uses RAG to ground every claim in the retrieved FAERS data, never in training memory.
  • alert_draft produces a clean, EHR-pasteable note with a Confirm/Dismiss/Escalate checkbox. The clinician always makes the final call. Always.

How I built it

FastMCP as the MCP server framework, Groq running llama-3.3-70b for the RAG layer, the FDA FAERS public API for real adverse event data, HAPI FHIR for patient context, deployed on Render, and published on the Prompt Opinion marketplace with A2A enabled so other agents can call it as a composable skill.

The architecture follows strict separation of concerns — FHIR bridge strips PHI before anything reaches the LLM, the risk engine builds prompts from retrieved data only, and the MCP server handles all tool orchestration with no business logic of its own.

Challenges we ran into

Two painful ones. First, Prompt Opinion runs on Gemini under the hood, which rejects the additionalProperties field that FastMCP auto-generates in tool schemas. I had to patch the MCP protocol layer to strip incompatible fields before schemas are transmitted — not documented anywhere, figured it out through trial and error.

Second, Prompt Opinion's agent-to-tool data passing sometimes wraps tool outputs in an MCP content envelope instead of passing the raw dict. I had to add defensive unwrappers in both the risk engine and alert draft to handle both cases gracefully so the pipeline never silently fails.

Accomplishments that we're proud of

  • The full pipeline — signal_scan → risk_score → alert_draft — runs end to end on the Prompt Opinion platform, calling real FDA data, producing a CRITICAL risk tier with patient-specific amplifiers, and delivering an EHR-pasteable note in under 30 seconds
  • Zero PHI ever reaches the LLM. phi_in_prompt=False is enforced, verified, and logged on every single call
  • Every alert includes a demographic bias disclosure — FAERS data may underrepresent non-white and female patients. This matters especially when the data is US-centric but the clinical need is global
  • SHARP/FHIR context is fully wired — pass a patient ID and the tool pulls their medication list automatically from the EHR
  • Published on the Prompt Opinion marketplace with A2A enabled — any other agent on the platform can call Clinical Oracle as a composable skill right now

What I Learnt

You can't bolt compliance onto a healthcare AI tool at the end. PHI handling, regulatory framing, demographic bias acknowledgment, clinician confirmation — these have to be architectural decisions made at the very beginning, not disclaimers added before submission.

The other thing: MCP composability is genuinely powerful. The moment Clinical Oracle was published on the marketplace, any other agent on the platform could call it as a skill. That's the vision — not one monolithic clinical AI, but specialized tools that work together. Agents assembling.

What's next for Clinical Oracle

  • Indian drug database integration — FAERS is US-centric. The next version integrates CDSCO adverse event data and the Indian pharmacopoeia so the signals are relevant for Indian drug brands and patient populations
  • Expanded FHIR integration — pulling allergies, past adverse reactions, and active diagnoses from the EHR to make risk scoring even more patient-specific
  • Pharmacist workflow — a dedicated alert format for clinical pharmacists, not just prescribing physicians
  • Regional language support — alert summaries in Hindi and other Indian languages for community health workers who may not be comfortable with English clinical terminology
  • Real-time INR and creatinine monitoring — trigger automatic re-assessment when lab values change, not just at the point of prescribing

Built With

  • a2a
  • fastmcp
  • fda-faers-api
  • fhir-r4
  • groq
  • hapi-fhir
  • llama-3.3-70b-versatile
  • mcp
  • openai
  • prompt-opinion
  • python
  • render
  • sharp
Share this project:

Updates