About HERA

HERA helps you find patients who may match a trial protocol. You describe inclusion and exclusion rules in plain language. HERA searches the electronic health record, narrows the cohort, and explains its reasoning for each candidate.

You stay in control. HERA suggests matches and cites chart evidence. It does not replace clinical judgment or formal eligibility sign-off.

HERA uses a three-stage funnel so searches stay fast but thorough:

1. Keyword search (FTS): scans notes and investigations for clinical terms you specify (e.g. “heart failure”, “LVEF”). Casts a wide net quickly.
2. Semantic search (vectors): understands meaning, not just exact words. Multiple rephrasings of your criteria are tried so different note styles still match.
3. Deep review (agentic): an AI agent reads each shortlisted patient’s chart, checks every criterion, and produces a structured verdict with quoted evidence.

Keyword and semantic search run at the same time. Their results are merged, duplicate note hits are dropped, and survivors are re-ranked(including a math guard for numeric cut-offs). Only the top few unique patients are passed to the LLM for full chart review — capped to keep cost and response time reasonable on this demo server (a single 8 GB / 4-CPU machine).

All patients in this demo are generated and not real EHR records. The pipeline has three stages:

1. Structured trajectories (clinical_data_gen/structured_clinical_data ) uses the OpenAI Batch API to produce longitudinal patient JSON: demographics, encounters, diagnoses, medications, labs, and investigations across cardiovascular, oncology, and ICU specialties.
2. SOAP notes(clinical_data_gen/soap_notes ) converts each structured encounter into unstructured SOAP progress notes (again via Batch API), so the search funnel has realistic clinical prose to index.
3. Load into Supabase(backend/app/db/schema.sql ) defines the Postgres tables. On startup, the backend prepopulate service reads the generated JSON datasets and upserts rows into Supabase over the REST API. A separate embedding ingest step (scripts/ingest_ehr) chunks those notes and indexes them in Pinecone (or pgvector) for semantic search.

Paths to the canonical JSON files are configured via PATIENT_TRAJECTORIES_PATH and SOAP_NOTES_PATH in the backend environment.

• Command Center : chat interface where you ask questions, start searches, or explore individual patients.
• Matching pipeline : runs in the background after you dispatch a search; progress is tracked by task ID.
• Audit dashboard (four-pane view) : chart timeline, metrics, eligibility ledger, and an optional copilot for follow-up questions.
• Audit log : clinician overrides and agent responses are stored for traceability.

• Frontend

  Next.js, React, Tailwind

• Backend

  FastAPI, Pydantic AI agents

• Database

  Supabase / Postgres + pgvector

• LLM routing

  OpenRouter / OpenAI-compatible APIs

• Task state

  Redis for chat history & progress

• Charts

  Matplotlib PNGs served from the API

• Demo tuning: This deployment uses smaller backend limits (typically in the 5–10 range) so searches return faster. Deep review is hard-capped by TIER3_PATIENT_CAP (min(n_candidates, TIER3_PATIENT_CAP) patients reach the analysis agent). Retrieval limits may also be reduced. Results and performance may vary and can be slightly less accurate than a full production run.
• Speed vs. depth: The funnel caps how many patients get a full chart review so responses stay practical; very large cohorts may need stricter criteria.
• Recall vs. precision: Semantic search casts a wider net; the deep review step filters false positives but adds latency.
• Synthetic data only: All patients in this demo are generated; behaviour on real EHR data would need validation and governance.
• LLM variability: Models can misread ambiguous notes; the audit dashboard and override flow exist so humans can correct mistakes.
• Privacy: Designed for de-identified research settings; production use would require HIPAA-grade controls and access policies.