RareReg

A multi-agent registry for rare-disease intake, longitudinal natural history and trial readiness.

Comment

Inspiration

My partner and I both live with rare diseases. My partner lives with GNE Myopathy, an ultra rare and progressive muscle wasting disorder. When you live in the rare disease space, you quickly realize that finding a cure is not just about laboratory science. The biggest bottleneck is often just data. Specifically, building a patient registry.

To design a clinical trial for a disease like GNE Myopathy, researchers need to track the "slope of muscle decline" across a patient population year over year. But because patients are so few and spread out, their data is trapped. It lives in fragmented clinic spreadsheets, complex genetic lab reports, or just in the patient's own memory.

Right now, patients are asked to bridge this gap by filling out massive paper forms. The current clinical sheet we deal with has over 400 lines and 17 sections. Patients are expected to manually type out complex genetic mutations and remember their exact functional scores from years ago. It is exhausting and error prone.

I built RareReg because building a patient registry should not be a data entry job. It should be a natural conversation.

What it does

RareReg is a multi-agent patient registry built on the PromptOpinion platform. It turns static medical forms into a coordinated team of AI agents that work together to collect, verify, and analyze patient data. We are starting with GNE Myopathy, but the architecture is built to scale to any of the 7,000 known rare diseases.

When a patient interacts with RareReg, they are not just talking to a single chatbot. They are talking to an orchestrator that delegates tasks to specialized sub-agents:

  • Conversational Intake: Patients can chat in their preferred language. Instead of typing out complicated genetic alleles, they just take a photo of their genetic lab report. The agent reads the image, extracts the exact mutation and zygosity, and saves it.
  • Longitudinal Tracking: The system asks the patient simple questions about their functional abilities today, like how hard it is to climb stairs or stand up from a chair. It records these scores on a 1 to 10 scale.
  • Slope Computation: An analytics agent looks at the patient's historical data to calculate their exact rate of muscle decline over time. If the decline is accelerating, it flags it for researchers.
  • Clinical Trial Matching: The system cross references the patient's genetic data and current mobility status against a clinical knowledge base to find active clinical trials they qualify for, explaining the match in plain language.

How we built it

RareReg architecture diagram

We built RareReg using PromptOpinion's Agent to Agent (A2A) architecture. I forked the official po-adk-python starter repo and completely rewired it to support a team of four agents.

The system runs on Google Cloud Run and uses Google's Gemini models. We used Gemini 3.1 Flash Lite for fast agent routing and logic, and Gemini 2.5 Flash for the vision OCR tasks on the genetic reports.

Here is how the four agents break down:

  1. RareReg Orchestrator: The main entry point. It wraps the other agents as tools and routes the patient's messages to the right specialist.
  2. Intake Agent: Handles new patient consent, multi-lingual translation, and the vision OCR. It writes data directly to the PromptOpinion HL7 FHIR server as Condition and Observation resources.
  3. Registry Analytics Agent: Connects to the FHIR server with read only scopes. It groups historical functional scores by date to compute the progression slope.
  4. Clinical Knowledge Agent: A RAG based reference agent loaded with medical papers, natural history benchmarks, and clinical trial criteria from ClinicalTrials.gov.

A critical part of the build was making sure the agents could talk to each other. The Analytics agent actually makes a direct HTTP A2A call to the Clinical Knowledge agent to interpret patient trial eligibility.

Challenges we ran into

Building AI for real healthcare workflows is very different from building a generic chatbot. The biggest hurdles were around strict data compliance and managing state.

First, the PromptOpinion FHIR server is incredibly strict. We spent a lot of time debugging rejected payloads because we were trying to upload certain Observation categories that the server did not like, or trying to do single resource reads under a search only SMART scope. We had to rewrite our FHIR helpers to carefully extract resources from search bundles to make sure every read and write was compliant.

Another major challenge was statelessness. PromptOpinion's General Chat sends task IDs for follow up messages, but our agents are designed to complete their task in a single turn. This caused looping errors. I had to build custom middleware to strip incoming task IDs and force new task creation on every turn, keeping the system stable without losing the patient's context.

We also had to fight the LLM's natural urge to be overly chatty. Early on, the orchestrator would try to narrate its own routing decisions or answer medical questions directly instead of delegating to the sub-agents. We implemented strict prompting guardrails and used the ADK's skip_summarization flags to force the system to pass the sub-agent responses through verbatim.

Accomplishments that we're proud of

I am incredibly proud of the genetic report OCR integration. Getting an AI to reliably read a blurry phone photo of a lab report, understand HGVS genetic nomenclature, format it into structured extensions, and write it to a FHIR Condition resource feels like magic. It completely removes the biggest point of friction for patients trying to join a registry.

I am also really happy with the multi-agent assembly. Seeing the Analytics agent successfully hand off a complex patient profile to the Clinical Knowledge agent, get a verified trial eligibility response back, and deliver it to the patient is exactly what the Agents Assemble challenge was all about.

Finally, we did all of this using completely synthetic, de-identified patient data to guarantee zero real PHI was exposed during development.

What we learned

We learned that open standards like A2A and FHIR are the only way healthcare AI will ever make it to production. Building custom API wrappers for every agent would be a nightmare. Because we built on the Model Context Protocol and A2A standards, we could plug these agents together like Lego blocks.

We also learned a lot about how PromptOpinion injects JWT bearer tokens to bridge authentication. Understanding how to extract those tokens in the middleware to authorize our own FHIR calls was a huge learning curve but a very valuable skill to take away.

What's next for RareReg

The immediate next step is to pitch this working prototype to NIMHANS, India's premiere institute for neuroscience. It's currently working on building a patient registry for GNE Myopathy. Showing them that this data can be collected conversationally and stored in standard FHIR format could change how they run their natural history studies.

Beyond GNE Myopathy, the Clinical Knowledge agent was deliberately designed to be separate from the core FHIR logic. By simply swapping out the RAG corpus, we can easily configure RareReg to support intake and longitudinal tracking for almost any other rare disease out there.

Built With

Share this project:

Updates