Inspiration

Researchers and clinicians waste hours manually cross-checking trial registries and safety reports. I wanted a tool that reads real trial data, runs analytics, and explains the results in plain English. The idea came from watching teams spend too much time on simple cross-checks that could be automated.

What it does

  1. Accepts a plain-language query about a disease or therapy (for example: “Evaluate CAR-T therapy for multiple myeloma”).
  2. Searches an Elasticsearch index of real clinical-trials data and an index of FDA adverse-event reports. Runs analytics (trial counts, phase distribution, yearly trends, and safety counts).
  3. Calculates a simple, transparent risk score and classifies risk (Low / Medium / High).
  4. Returns a short, well-formatted executive summary and the data used to reach that conclusion.

Example structured output:

  1. Total trials found
  2. Phase breakdown (Phase 1 / 2 / 3)
  3. 5-year growth % 4.Top reported adverse reactions
  4. Serious-event ratio and a numeric Risk Score (1–10)
  5. Short recommendation

How I built it

  1. Collected and indexed real clinical-trial records (ClinicalTrials.gov) and FDA drug-event reports into Elasticsearch indices (clinical_trials_real, fda_adverse_events_real).
  2. Built focused retrieval and analysis tools inside Elastic Agent Builder (Index Search + ES|QL tools):

biomed.search_trials - retrieve matching trial documents
biomed.trials_over_time - yearly trend aggregation on start_date
biomed.trials_by_phase - phase distribution aggregation
biomed.search_fda - safety retrieval and frequency aggregation
biomed.serious_event_ratio - counts of serious events vs total reports biomed.count_trials_by_condition – groups and counts trials by medical condition

  1. Wrote a concise agent instruction set so the Agent Builder LLM orchestrates tools (retrieve → aggregate → reason → summarize).

Challenges I ran into

  1. Schema mismatch: index field names vary across datasets — we had to inspect mappings and adapt queries to exact field names (start_date, conditions, reactions.keyword).
  2. Overly broad search: the default agent in Kibana used generic platform.core.search tools and produced noisy results. Fix: lock the agent to only our custom tools.
  3. Time and token control: a long reasoning trace can waste tokens. Solution: force the agent to do most heavy work via ES|QL aggregations and return concise summaries from the LLM.

Accomplishments that I'm proud of

  1. Indexed and used real clinical-trial and FDA data (not synthetic).
  2. Built an agent that does multi-step reasoning (retrieve → analyze → summarize) using Agent Builder tools only, fully compliant with the hackathon rules.
  3. Created clear, judge-friendly measurable outputs: trial counts, phase distribution, trend growth, serious-event ratio, and a reproducible risk score formula.
  4. Delivered a Kibana dashboard that visualizes the same metrics the agent reports.

What I learned

  1. Real data requires exact schema checks - always inspect _mapping before writing ES|QL queries.
  2. Keep heavy aggregation on the DB (Elasticsearch) and use the LLM for explanation - it saves tokens and improves reliability.
  3. For competitions, stable demos matter more than flashy integrations. Host the core on Kibana for consistency.

What's next for MedQuery Intelligence

  1. Add a reproducible Clinical Maturity Index and Innovation Velocity Score for clearer investment / research signals.
  2. Integrate an optional MCP toolset (semantic retrieval & advanced scoring) so external LLM clients can connect (future stretch goal).

Built With

Share this project:

Updates