Biopharma Hack Day at AWS

J

A

Happy Accidents

Create a platform for finding the positive unintended side effects of drugs during clinical trails

HackerSquadOpenAI CodexBright Data

# LabPilot — AI Virtual Lab for Drug Discovery Drug discovery has thousands of possible next experiments. LabPilot helps scientists decide which one to run next. LabPilot combines public scientific evidence, internal experimental data, quantitative models, simulation, and governed AI reasoning to turn everything already known into the next best experiment. ## The Problem Scientists often have to decide what to test next across a huge experimental search space: Compound × Target × Indication × Model × Assay × Condition × Mechanism × Combination Relevant evidence is fragmented across public databases, literature, internal experiments, and model outputs. This makes it difficult to understand what is already known, where uncertainty remains, and which next experiment would provide the most useful information. ## What LabPilot Does LabPilot creates a Virtual Lab workflow: 1. **Aggregate evidence** — connect public scientific databases and internal experimental results. 2. **Find evidence gaps** — identify under-tested or uncertain regions of the discovery space. 3. **Generate candidate experiments** — compare different models, assays, concentrations, mechanisms, and other experimental directions. 4. **Recommend the next best experiment** — rank candidates by expected information gain, biological relevance, redundancy, uncertainty, and feasibility. 5. **Simulate before running** — preview virtual/model-predicted outcomes while keeping predictions clearly separate from measured evidence. 6. **Brainstorm with LabPilot** — scientists can ask questions such as “What else should we test?” or “What would challenge this hypothesis?” 7. **Investigate the recommendation** — a governed recursive AI layer checks evidence, model assumptions, alternatives, counterarguments, and feasibility. 8. **Human approval** — LabPilot proposes; the scientist makes the final decision. ## Demo For today's demo, we use a preclinical oncology discovery program involving RMC-6236 / daraxonrasib and a KRAS G12D pancreatic cancer model. LabPilot combines the available evidence, identifies an under-sampled experimental region, compares several possible next experiments, and recommends a dose-response refinement experiment. The scientist can then: - inspect the evidence, - simulate the proposed experiment, - compare alternative experiments, - ask LabPilot questions, - run an AI investigation, - review the strongest counterargument, - and approve, modify, or reject the experiment. The oncology example is only a demo. LabPilot is designed as a general-purpose drug discovery platform across disease areas and experimental modalities. ## Governed AI LabPilot deliberately separates authority: - **Scientific models** handle quantitative predictions and experiment scoring. - **AI Copilot** handles scientific exploration, explanation, and brainstorming. - **Recursive AI investigation** challenges recommendations and produces an auditable Lab Run Receipt. - **Human scientists** retain final experimental authority. Predicted results are never represented as measured experimental data. ## Vision Today, drug discovery teams ask: “What experiment should we run next?” LabPilot aims to make that decision evidence-driven, computationally testable, traceable, and dramatically faster. **LabPilot turns everything already known into the next best experiment.**

HackerSquadOpenAI CodexAWSConvoke

LabPilot Virtual lab

**Pathogen Pathfinder** is a governed AI research workspace that analyzes pathogen resistance data, challenges apparent biological signals with a bounded RLM, and connects validated mechanisms to Convoke’s drug-development landscape. Every conclusion remains traceable to its source and is labeled supported, contested, or insufficient evidence.

HackerSquadOpenAI CodexConvoke

OneSource: the traceability layer for pharma content. PROBLEM (Statement 5, Reducing Redundant Content Development at Scale) Pharma content starts in Regulatory Affairs, in the approved label. It then flows to Medical Affairs, MSLs, and Sales, and each function rewrites the same facts by hand. That duplicates effort, and nobody can prove the sales one-pager still matches the label. WHAT ONESOURCE DOES One approved source goes in. Audience-ready assets come out. Every sentence carries a pointer back to the exact paragraph of the approved source that authorizes it. A sentence that cannot be traced to a source claim is blocked, not published. The core object is the claim ledger. The engine decides every fact; the model only writes the words. HOW IT WORKS 1. Ingest. One public FDA label from DailyMed (ELIQUIS / apixaban, set id e9481622, version 30), fetched through Bright Data Web Unlocker. 2. Atomize. The HL7 v3 SPL is split into 401 numbered claim units. Each has a stable id (SRC#<setid>#<section>#p<n>), a SHA-256 of its text, a type, and a tier. 3. Type. efficacy | safety | dosing | contraindication | pk, assigned deterministically from the label's own outline number. No model touches typing. 224 of 401 claims are tier 3. 4. Repackage. OpenAI gpt-5.4 receives only the filtered claim set plus an audience style guide, and returns sentences with the claim ids each one drew on. It may not add facts. 5. Guard. Every sentence must cite at least one claim id that exists in the current source version. Unmapped sentences are flagged UNSOURCED and blocked. Sentences citing an unsigned tier-3 claim are flagged MLR REQUIRED and withheld. 6. Ledger. Source version, claim ids used, prompt hash, output hash, model, and tokens are recorded per asset. WHAT MAKES IT DIFFERENT MLR sign-off is bound to the source text hash. When a label paragraph is revised, its hash changes, the sign-off stops matching, and every asset that relied on it falls back to withheld. Approval cannot silently outlive the sentence it approved. On a source version bump, OneSource diffs the two claim ledgers by id and hash and reports, per asset and per sentence: STALE (cites text that changed), INCOMPLETE (a new tier-3 claim no asset covers), and SIGN-OFF REVOKED. This is a hash comparison, not a model judgment. MEASURED, NOT CLAIMED - 401 claims atomized from the label, zero id collisions, byte-identical across re-runs. - Guard test suite: 11 cases, 8/8 negative cases blocked (invented id, id from another document, id with a plausible but absent section, no citation, real id plus fake id, revoked sign-off). - Live adversarial run: with the sourcing rule removed, gpt-5.4 wrote "no routine INR monitoring to guide ELIQUIS effect, helping simplify follow-up". No claim supports it. The guard blocked it. - Version bump v30 to v31: three edits produce STALE plus INCOMPLETE plus one revoked sign-off across all four assets. ARCHITECTURE NOTE Ported from Rosa Health, which solves this shape of problem in another regulated domain. The rule carried over: the engine decides every fact, the AI only writes the words. DATA Public FDA label data only. No patient data, no confidential sponsor material. RUN IT npm install node scripts/fetch-source.mjs # Bright Data ingest node scripts/atomize.mjs # 401 claims node scripts/sign-off.mjs BW 5 17 2 4 # simulate the MLR queue node scripts/build-assets.mjs # compose plus guard node scripts/test-guard.mjs # prove the guard blocks npm run dev # the three-pane UI

HackerSquadOpenAI CodexBright DataAWS

TRYAL

TRYAL converts clinical-trial requirements into executable, human-approved rules and continuously evaluates them against evidence joined across every system a trial runs on — surfacing compliance risks for human review before they become deviations or audit findings.

OpenAI CodexConvoke

GenMD

Pathway is an AI-powered treatment observability and clinical-trial access tool for patients with serious or rare conditions. Problem Patients may have cutting-edge treatment options available through clinical trials, but understanding and accessing those options is difficult. ClinicalTrials.gov shows what studies exist, but patients still need to understand: - which trials may actually be relevant to them - whether they appear to meet eligibility criteria - what clinical information is still missing - whether a recruiting site is realistically accessible - who to contact and what to do next Finding a trial is not the same as being able to access it. Solution Pathway turns a patient's medical story into an explainable list of potential clinical-trial options. A patient, caregiver, or clinician describes the patient's condition and treatment history in natural language. Pathway then: - Creates a structured patient profile. - Searches live recruiting studies through ClinicalTrials.gov. - Converts complex eligibility criteria into structured rules. - Evaluates each criterion as PASS, FAIL, or UNKNOWN. - Shows the exact trial evidence behind each decision. - Surfaces follow-up questions when information is missing. - Calculates an Access Outlook using eligibility, recruitment status, geography, and contactability. - Provides recruiting locations, study contacts, and draft outreach materials. Technology AWS Strands Agents SDK + Amazon Bedrock — patient and eligibility language understanding ClinicalTrials.gov API v2 — live trial, eligibility, site, and contact data Python — deterministic eligibility and Access Outlook logic FastAPI — backend React + Vite — patient-facing interface Bright Data — planned enrichment of public hospital, sponsor, referral, and trial-access information Our thesis Treatment observability should not stop at showing patients what trials exist. It should help patients understand which options may be relevant and how to take the next step toward accessing them.

HackerSquadOpenAI CodexBright DataAWS

CIOP

The Clinical Records Analyzer is a new capability on the apeX participant profile that reads a randomized participant's uploaded clinical documents — visit histories, lab results, imaging reports — and turns them into something a site team can act on: labs as values-over-time with abnormality flags, imaging and visit-note summaries, and a per-visit documentation audit that cross-references each record against the trial's blank eCRF and flags every completed visit missing its record. All documents are de-identified on our own infrastructure before any AI reads them (names removed, clinical dates kept), every claim cites its source page, and every access is logged. In its first pilot on production data, it de-identified 111 documents without a single failure — and surfaced 42 completed visits with no clinical history record on file, before any human review.

AWSClaudeCode, GPT 5.1, Google Drive

FieldSignal

FieldSignal is an AI-powered feedback-loop platform for medical affairs teams. Built on Convoke, it combines portfolio context, verified scientific literature, and conference programme data to turn strategic questions into measurable congress objectives and specific MSL assignments. Before a conference, FieldSignal identifies relevant sessions, experts, questions, and evidence. In the field, MSLs capture physician conversations, unanswered questions, and progress against each objective. Afterward, the platform connects those insights back to medical leadership, revealing what physicians understand, what is not landing, and which scientific content gaps should be addressed next. FieldSignal turns conferences from isolated events into continuous learning systems: evidence becomes objectives, objectives become field action, and field feedback shapes the next scientific content priority.

OpenAI CodexBright DataAWSConvoke

K

A

Synapse

turns fragmented public clinical trial and drug data into three focused tools: one for patients, one for trial designers, and one for R&D teams hunting for the next opportunity. Built with Bright Data and Convoke. The Problem Patients with serious or rare conditions struggle to find out what treatments — approved or experimental — are actually available to them. Most drugs fail in clinical trials, and those lessons rarely make it back into how the next trial is designed. Drugs that hit similar biological targets could work for other diseases too, but nobody has time to test every drug-disease pair. What We're Building Portal Audience Status Patient Portal Patients searching for treatment options Core Clinical Trial Portal Biopharma trial design teams Core R&D Portal Portfolio strategy / competitive intel / BD teams Stretch goal 1. Patient Portal Patients pick a condition and location, then see their options laid out clearly: approved drugs, trials not yet started, and trials currently recruiting — each tagged with phase, study number, and location. Clicking an option opens a plain-English explainer and study contact info. Only uses vetted public sources (openFDA, ClinicalTrials.gov, patient-friendly summaries) — no speculative reasoning is surfaced to patients. 2. Clinical Trial Portal Helps trial teams answer "how should we design or benchmark this trial?" by mining patterns from past trials — what worked, what failed, and why — using ClinicalTrials.gov as the backbone and Bright Data for sponsor, investigator, and conference-level context. 3. R&D Portal (stretch) An opportunity-mapping workspace for research and portfolio teams. Search a drug, target, or pathway and get an opportunity brief, a target-indication landscape map, drug repurposing hypotheses with confidence scores, a competitive intelligence feed, and a list of key risks and gaps. Data Sources ClinicalTrials.gov — authoritative trial data (REST API, daily refresh) openFDA — approved drug labeling and approval data Bright Data — public web context not packaged by official sources (sponsor pages, investigator sites, conference abstracts, press releases) Convoke — biotech knowledge reasoning for internal pharma users (Portals 2 & 3 only)

HackerSquadOpenAI CodexBright DataConvoke

Doses of Code

# Trial Compass See what's happening for a medical condition right now, and whether *you* qualify, in plain language. Backed by real data and an auditable AI verdict, not a black box. Built for Pharma Hack Day (AWS Builder Loft, SF). Problem statement: treatment observability for patients. **We've covered Problem Statement 3 in this project.** Search, live treatment landscape, an explainable/cited eligibility verdict, filters, tracking with a real change feed, and a help center are all built and working end-to-end on real data, no mocks. ## Why Patients searching for a diagnosis get either raw ClinicalTrials.gov listings (dense, unreadable) or a chatbot yes/no they can't verify. Neither works for a decision this serious. Trial Compass gives a real verdict with the exact source sentence behind it, so patients can bring it to their doctor instead of just trusting an AI. ## What it does **Treatment Landscape** (`/landscape/[condition]`). Live trial counts by status/phase, recent FDA label updates, recent novel approvals for the condition. Real-time, no seeded data. **Explainable Trial Matcher** (`/match`). Patient describes themselves in plain text ("62, stage 3 pancreatic cancer, one round of FOLFIRINOX, no diabetes, Boston"). App extracts a structured profile, runs every recruiting trial through a 3-agent eligibility debate, returns PASS/FAIL/UNKNOWN with confidence, a plain-language summary, and the exact criterion sentence that drove it. Filters (confidence, recruiting status, recency, nearby sites), plus per-trial "what's missing" and "simplify this" on demand. **Tracking** (`/tracked`). Save a trial, get a plain-language diff (status/site/enrollment/date changes) whenever you recheck it. **Help Center** (`/help`). FAQ on trial phases/statuses and how the matcher works. ## Why it's worth showing - Explainable, not black-box: every verdict cites the real criterion text, checked against the trial's actual source in code before it's shown. - Adversarial, not one-shot: a FOR and AGAINST argument are built independently, then a judge weighs both against the real criteria. - Confidence enforced in code, capped by what was actually verifiable, not just what the model claims. - No fake data: everything fetched live from ClinicalTrials.gov, openFDA, FDA.gov. ## Agentic architecture Seven narrow, single-purpose LLM calls, each with its own schema-validated output (`zodTextFormat`) and its own verification pass in code. No agent has memory or sees another agent's raw output except where the flow below hands it off explicitly. All defined in [`lib/llm.ts`](lib/llm.ts). | Agent | Trigger | Output | Verification | |---|---|---|---| | Profile extractor | intake text submitted | structured profile (age, diagnosis, stage, treatments, biomarkers, comorbidities, location) | explicit absences ("no diabetes") kept as facts, not null | | Qualification (FOR) | per trial | argument + verbatim cited criteria | citation checked against source text | | Disqualification (AGAINST) | per trial, parallel with FOR | argument + verbatim cited criteria | same | | Judge | after FOR + AGAINST | verdict, confidence, per-criterion met/not_met/unknown, primary citation | each criterion re-checked as substring of real text, unverifiable → `unknown` | | Missing Information | trial detail opened | 1-3 criteria worth asking about, plus why | filtered to only items matching real unknown-criteria list | | Simplify | trial detail opened | criteria rewritten at 2 reading levels | rejected if output array length mismatches input | | Eligibility-diff summary | tracked eligibility text changed | one-sentence plain summary | only called after a real diff is detected | ### The eligibility debate, in detail This is the core flow, run once per trial per match request: ``` Patient profile + trial's real eligibility text │ ├── Qualification agent (FOR): argues honestly, cites verbatim criteria └── Disqualification agent (AGAINST): argues honestly, cites verbatim criteria │ (run in Promise.all, neither sees the other) ▼ Judge agent: weighs both vs. real criteria, never splits the difference → verdict, confidence, per-criterion (met/not_met/unknown), primary citation │ ▼ Code-level guardrails (not the model's word): • every cited criterion re-checked as a real substring of the trial's own text • verdict downgraded to UNKNOWN if it contradicts the judge's own verified criteria breakdown • confidence capped: UNKNOWN → 40 max, unverified citation → 50 max, PASS with under half its criteria checkable → 50 max │ ▼ TrialMatch shown to patient, results sorted PASS → UNKNOWN → FAIL, then by confidence ``` Debate not single-call: one model asked "does this qualify" settles on whatever sounds plausible first. FOR/AGAINST built independently, judge reconciles both against real text, surfaces actual ambiguity. Judge still not trusted blind: `reconcileVerdict()` downgrades to UNKNOWN if the top-line verdict contradicts the judge's own verified per-criterion breakdown (PASS with a verified `not_met`, or FAIL with none). Confidence capped in code, not just prompted: `applyConfidenceGuardrails()` runs regardless of what the model claims, so a fluent but under-evidenced verdict can't read as 90% confident. ## Design decisions - **Verification in code, not prompts.** `isCitationVerified()` checks a claimed quote is a real substring of the trial's actual text; anything that fails is unverified, full stop. - **Server re-verifies client state.** `/api/trial-insights` re-derives verified criteria server-side before calling Missing Information or Simplify, no trusting client payloads. - **Defensive parsing.** `stripLeakedJson()` trims text fields where the model's own JSON syntax leaks into a string value. - **LLM only where input is genuinely free-form.** Profile extraction, the debate, diff summaries, simplification. Filtering, proximity match, snapshot diffing stay plain deterministic code. - **Fail visibly.** No API key → `503`, not a fabricated verdict. Mismatched `simplifyCriteria` output gets discarded, not guessed. ## Stack Next.js (App Router, TS, Tailwind v4). No separate backend, no database. Trial/FDA data fetched live; tracked trials live in `localStorage`. ``` app/ landscape/[condition]/ treatment landscape match/ explainable trial matcher tracked/ tracked trials + change feed help/ FAQ api/{trials,match,eligibility,trial-insights,track/check}/ lib/ clinicaltrials.ts openfda.ts novelApprovals.ts (data sources) llm.ts (all prompts + verification guardrails) trialFilters.ts trialDiff.ts tracking.ts faq.ts ``` ## Run it ```bash npm install npm run dev ``` Open `localhost:3000`. Landing and landscape work with no setup. For the matcher, tracking summaries, and simplification, set `OPENAI_API_KEY`. Without it, those routes return `503` instead of faking output. ## Ideas to extend Convoke pipeline data integration, voice/chat intake, multi-language summaries, per-trial "how to enroll", side-by-side condition comparison, FDA approval timeline view.

OpenAI Codex

N

Vexa

Vexa turns GxP User Requirements Specifications (URS) and design specifications into reviewable, executable qualification workflows for Physical AI in cell and gene therapy robotic drug manufacturing. The app currently supports sequential FAT, SAT, IQ, and OQ work. It creates structured test cases, preserves traceability back to URS requirements, and provides review, execution, evidence, and feedback records.

HackerSquadOpenAI CodexAWSConvoke

searchdoc

This is AI native search platform for doctors where they can search for drugs, appropriate dosage and prescribe accordingly by putting the medical history of the patient at the center. It is a chart-aware prescribing support workspace that helps clinicians move from patient context to drug decisions with more clarity and less web searching. It combines an AI-assisted question flow, structured drug profiles, evidence-backed source trust, and context-aware prescribing support so doctors can understand whether a drug is relevant, why, and what clinical data informs that answer. Instead of forcing doctors to rely on open Google searches, searchdoc ranks and organizes medical resources through a four-tier credibility system: Tier A, Tier B, Tier C, and Tier D. This helps ensure that recommendations are grounded in trusted, clinically relevant sources rather than random or low-confidence search results.

OpenAI Codex

SecondLife

DrugThread: Agentic pharmaceutical intelligence. Enter a drug name; a hierarchy of AI agents instantly reconstructs a complete, source-backed dossier: FDA label analysis, full clinical development history (including every failure and why), biological mechanism network, and cross-sectional findings — all linked to primary evidence. Built with Strands Agents, Convoke MCP, openFDA, and ClinicalTrials.gov.

OpenAI CodexBright DataAWSConvoke

Team Rosa.ai

Your autonomous computational scientist -- walks through your data with you using tools you're already familiar with.

OpenAI Codex

We Discover

# We Discover - **Home** (`src/routes/+page.svelte`) — loads all disease summaries from `data/graph/*.json`, client-side filter search, "Request a Disease" mailto fallback. - **Diseases index** (`src/routes/diseases/`) — same data, plain browse grid. - **Knowledge graph page** (`src/routes/knowledge/[disease]/`) — loads one disease graph + its agent charts; workspace tabs (graph/charts/trial-map) + sidebar (inspec tor/chat), all synced via shared `selectedNodeId`. - **Graph data model** (`src/lib/disease-graph.ts`) — pure functions: summarize counts, get one node's relationships, build a capped legible neighborhood around the f ocused node. - **Graph rendering** (`knowledge-graph.svelte`) — Cytoscape.js, custom fixed-column "Evidence Corridor" layout (disease → papers/trials → programs) instead of force- directed, click-to-focus. - **Node inspector** — sidebar panel showing selected node's props + clickable relationships. - **Trial finder** (`trial-finder.svelte` + `api/clinicaltrials.ts`) — live ClinicalTrials.gov search by condition, ZIP or geolocation radius. - **Enrollment modal** (`trial-enrollment-modal.svelte`) — full trial detail (eligibility, contacts, locations, apply link) by NCT id, in-memory cached. - **Trial map** (`trial-locations-map.svelte`, `server/trial-map.ts`) — MapLibre map of all trial sites for a disease, paginated + 5min cached. - **Chat copilot** (`graph-copilot.svelte`, `api/.../chat/+server.ts`, `server/graph-chat.ts`) — BYOK OpenAI chat with tools to search/inspect/aggregate the graph, fo cus nodes, open the trial map, and publish charts; UI live-updates as tools run. - **Agent charts** (`server/agent-charts.ts`, `agent-chart-gallery.svelte`) — Vega-Lite specs only (no code execution), validated + size-capped, stored in Supabase or a fallback JSON file. - **MCP server** (`mcp-server/index.js`) — standalone Streamable-HTTP server exposing `search_disease`, `get_disease_data`, `list_charts`, `create_chart` for external agents (Claude Code, Desktop, Cursor); same validation/storage rules as the in-app chat. No per-caller auth yet (known gap). - **Seed data pipeline** (`data/graph/`, `data/snapshot/`) — 8 pre-built diseases, deterministic exact-match entity resolution, no LLM; reference impl for a future li ve indexing pipeline. - **Everything else** — `components/ui/*` (shadcn primitives), `site-header.svelte` (nav, no auth), `markdown.ts`, `utils.ts`, `supabase/migrations/` (optional backen d schema).

HackerSquadOpenAI CodexConvoke

Claims Adjudication Simulator Biopharma Hack Day @ AWS — Problem Statement #4 Prior authorization for oncology drugs takes 3–10 days on average. Patients with late-stage cancer don't have that time. This project replaces the slow, opaque, manual prior-authorization (PA) review process with a real-time AI agent that evaluates every coverage rule transparently — one at a time, with confidence scores and cited evidence. The Problem Today's PA process for oncology drugs: Takes 3–14 business days for a manual review that often involves fax machines Produces a yes/no black box — no explanation for denials Has no urgency differentiation — a rapidly progressing Stage IV patient waits the same as a stable case Is error-prone when biomarker results are pending — reviewers guess instead of flagging The Solution An AI agent that reads a drug's coverage policy and a patient's prescription, then evaluates each rule individually with a structured, auditable output: Rule: PD-L1 Expression (TPS ≥ 1%) Status : ✅ SATISFIED Confidence: HIGH (99%) Evidence : PD-L1 TPS = 78% via 22C3 pharmDx, resulted 2025-10-10 Reasoning : TPS of 78% far exceeds the ≥1% threshold for first-line monotherapy Low confidence on missing data (e.g. biomarker pending) rolls up to NEEDS REVIEW — not a guess. Demo Output — 3 Synthetic Cases Case 1 — APPROVE (Standard) Patient: 65M, Stage IV NSCLC, PD-L1 78%, EGFR wild-type, ECOG 1, treatment-naïve Decision : ✅ APPROVE Urgency : 📋 STANDARD Rules Eval: 7 coverage rules examined — 7/7 SATISFIED All 7 rules satisfied with HIGH confidence (96–99%). Approved for 200 mg IV q3w, 6-month authorization. Case 2 — DENY Patient: 52F, Stage IV NSCLC, EGFR exon-19 deletion confirmed by NGS Decision : ❌ DENY Urgency : 🚨 EXPEDITE Rules Eval: 7 coverage rules examined — 1 FAILED (confidence 99%) Rule 4 (EGFR/ALK exclusion) failed with 99% confidence. Standard of care for EGFR-mutant NSCLC is an EGFR TKI (osimertinib), not a checkpoint inhibitor. Agent recommended re-submitting for Tagrisso. Case 3 — NEEDS REVIEW + EXPEDITE Patient: 71M, Stage IIIB NSCLC, PD-L1 / EGFR / ALK all PENDING, rapid weight loss, ECOG 2 Decision : ⚠️ NEEDS REVIEW Urgency : 🚨 EXPEDITE Rules Eval: 7 rules — 4 SATISFIED, 3 LOW CONFIDENCE (data missing) Three rules flagged LOW confidence (10–35%) because biomarker results aren't back yet. Agent listed exactly which results are needed and flagged EXPEDITE due to rapidly progressing symptoms and post-obstructive pneumonia. Architecture run_demo.py └── agent/claims_adjudication_agent.py (Strands Agent) │ ├── fetch_coverage_policy() Tool 1 │ Bright Data Web Unlocker → live payer policy │ Falls back to hardcoded Pembrolizumab/NSCLC policy │ ├── record_rule_evaluation() Tool 2 (called once per rule) │ rule_id, satisfied, confidence_score, evidence, reasoning │ ├── assess_clinical_urgency() Tool 3 │ EXPEDITE vs STANDARD based on stage, ECOG, progression │ └── finalize_adjudication() Tool 4 Aggregates rules → APPROVE / DENY / NEEDS REVIEW data/synthetic_cases.py 3 test prescriptions Decision logic: NEEDS REVIEW — any rule has confidence < 0.5 (data missing/ambiguous) DENY — any rule not satisfied with confidence ≥ 0.7 APPROVE — all rules satisfied with confidence ≥ 0.7 Tech Stack Component Technology Agent orchestration Strands Agents SDK LLM Amazon Bedrock — Claude Sonnet 4.6 (us.anthropic.claude-sonnet-4-6) Live policy fetch Bright Data Web Unlocker API Drug / indication Pembrolizumab (Keytruda) — NSCLC Patient data 100% synthetic — no real PHI anywhere Coverage Rules Evaluated Clinically realistic rules for Pembrolizumab in NSCLC (modelled on public payer policies): # Rule Why it matters 1 Histologic confirmation Small cell lung cancer is NOT covered 2 Disease stage ≥ IIIB unresectable / IV Pembrolizumab is not indicated for early-stage resectable disease 3 PD-L1 TPS ≥ 1% (22C3 pharmDx) Predictive biomarker — TPS drives monotherapy vs combo decision 4 EGFR/ALK exclusion EGFR/ALK-positive patients must receive targeted therapy first 5 ECOG performance status 0–2 ECOG 3/4 requires medical director review 6 Line of therapy First-line = no prior systemic chemo; second-line = documented progression 7 Organ function labs (within 28 days) Renal, hepatic, hematopoietic thresholds Setup git clone https://github.com/SenayYakut/Claims-adjudication-agent cd Claims-adjudication-agent python3.13 -m venv .venv source .venv/bin/activate pip install -r requirements.txt cp .env.example .env # Add your AWS and Bright Data credentials Environment Variables # Required — AWS (Bedrock) AWS_ACCESS_KEY_ID=... AWS_SECRET_ACCESS_KEY=... AWS_SESSION_TOKEN=... # if using temporary credentials AWS_DEFAULT_REGION=us-east-1 # Optional — Bright Data Web Unlocker (live policy fetch) BRIGHTDATA_API_TOKEN=... BRIGHTDATA_ZONE=hackathon_unlocker # Optional — override the default policy URL COVERAGE_POLICY_URL=https://www.aetna.com/cpb/medical/data/700_799/0770.html Running the Demo # Single case .venv/bin/python run_demo.py --case 1 # APPROVE .venv/bin/python run_demo.py --case 2 # DENY .venv/bin/python run_demo.py --case 3 # NEEDS REVIEW + EXPEDITE # All 3 without pausing .venv/bin/python run_demo.py --all What Makes This Different Today's PA This Agent 3–14 day manual review Real-time (< 60 seconds) Black-box yes/no Rule-by-rule breakdown with cited evidence Reviewer guesses on missing data Low confidence → NEEDS REVIEW (never guesses) No urgency differentiation EXPEDITE / STANDARD flag with clinical rationale Phone/fax workflow API-ready structured output Safety & Compliance Notes All patient data is 100% synthetic — no real patient information is used anywhere in this project The agent is explicitly designed to refuse to guess on missing biomarker data — low confidence is a first-class output, not a fallback This is a hackathon prototype, not a regulated medical device or FDA-approved clinical decision support system

The Denial Deniers

# Meridian ### Biopharma Hack Day @ AWS — Problem Statement #4 > **Prior authorization for oncology drugs takes 3–10 days on average. Patients with late-stage cancer don't have that time.** This project replaces the slow, opaque, manual prior-authorization (PA) review process with a real-time AI agent that evaluates every coverage rule transparently — one at a time, with confidence scores and cited evidence. --- ## The Problem Today's PA process for oncology drugs: - Takes **3–14 business days** for a manual review that often involves fax machines - Produces a **yes/no black box** — no explanation for denials - Has **no urgency differentiation** — a rapidly progressing Stage IV patient waits the same as a stable case - Is error-prone when **biomarker results are pending** — reviewers guess instead of flagging ## The Solution An AI agent that reads a drug's coverage policy and a patient's prescription, then evaluates each rule **individually** with a structured, auditable output: ``` Rule: PD-L1 Expression (TPS ≥ 1%) Status : ✅ SATISFIED Confidence: HIGH (99%) Evidence : PD-L1 TPS = 78% via 22C3 pharmDx, resulted 2025-10-10 Reasoning : TPS of 78% far exceeds the ≥1% threshold for first-line monotherapy ``` Low confidence on missing data (e.g. biomarker pending) rolls up to **NEEDS REVIEW** — not a guess. --- ## Demo Output — 3 Synthetic Cases ### Case 1 — APPROVE (Standard) Patient: 65M, Stage IV NSCLC, PD-L1 78%, EGFR wild-type, ECOG 1, treatment-naïve ``` Decision : ✅ APPROVE Urgency : 📋 STANDARD Rules Eval: 7 coverage rules examined — 7/7 SATISFIED ``` All 7 rules satisfied with HIGH confidence (96–99%). Approved for 200 mg IV q3w, 6-month authorization. --- ### Case 2 — DENY Patient: 52F, Stage IV NSCLC, EGFR exon-19 deletion confirmed by NGS ``` Decision : ❌ DENY Urgency : 🚨 EXPEDITE Rules Eval: 7 coverage rules examined — 1 FAILED (confidence 99%) ``` Rule 4 (EGFR/ALK exclusion) failed with 99% confidence. Standard of care for EGFR-mutant NSCLC is an EGFR TKI (osimertinib), not a checkpoint inhibitor. Agent recommended re-submitting for Tagrisso. --- ### Case 3 — NEEDS REVIEW + EXPEDITE Patient: 71M, Stage IIIB NSCLC, PD-L1 / EGFR / ALK all PENDING, rapid weight loss, ECOG 2 ``` Decision : ⚠️ NEEDS REVIEW Urgency : 🚨 EXPEDITE Rules Eval: 7 rules — 4 SATISFIED, 3 LOW CONFIDENCE (data missing) ``` Three rules flagged LOW confidence (10–35%) because biomarker results aren't back yet. Agent listed exactly which results are needed and flagged EXPEDITE due to rapidly progressing symptoms and post-obstructive pneumonia. --- ## Architecture ``` run_demo.py └── agent/claims_adjudication_agent.py (Strands Agent) │ ├── fetch_coverage_policy() Tool 1 │ Bright Data Web Unlocker → live payer policy │ Falls back to hardcoded Pembrolizumab/NSCLC policy │ ├── record_rule_evaluation() Tool 2 (called once per rule) │ rule_id, satisfied, confidence_score, evidence, reasoning │ ├── assess_clinical_urgency() Tool 3 │ EXPEDITE vs STANDARD based on stage, ECOG, progression │ └── finalize_adjudication() Tool 4 Aggregates rules → APPROVE / DENY / NEEDS REVIEW data/synthetic_cases.py 3 test prescriptions ``` **Decision logic:** - `NEEDS REVIEW` — any rule has confidence < 0.5 (data missing/ambiguous) - `DENY` — any rule not satisfied with confidence ≥ 0.7 - `APPROVE` — all rules satisfied with confidence ≥ 0.7 --- ## Tech Stack | Component | Technology | |---|---| | Agent orchestration | [Strands Agents SDK](https://strandsagents.com) | | LLM | Amazon Bedrock — Claude Sonnet 4.6 (`us.anthropic.claude-sonnet-4-6`) | | Live policy fetch | Bright Data Web Unlocker API | | Drug / indication | Pembrolizumab (Keytruda) — NSCLC | | Patient data | 100% synthetic — no real PHI anywhere | --- ## Coverage Rules Evaluated Clinically realistic rules for Pembrolizumab in NSCLC (modelled on public payer policies): | # | Rule | Why it matters | |---|---|---| | 1 | Histologic confirmation | Small cell lung cancer is NOT covered | | 2 | Disease stage ≥ IIIB unresectable / IV | Pembrolizumab is not indicated for early-stage resectable disease | | 3 | PD-L1 TPS ≥ 1% (22C3 pharmDx) | Predictive biomarker — TPS drives monotherapy vs combo decision | | 4 | EGFR/ALK exclusion | EGFR/ALK-positive patients must receive targeted therapy first | | 5 | ECOG performance status 0–2 | ECOG 3/4 requires medical director review | | 6 | Line of therapy | First-line = no prior systemic chemo; second-line = documented progression | | 7 | Organ function labs (within 28 days) | Renal, hepatic, hematopoietic thresholds | --- ## Setup ```bash git clone https://github.com/SenayYakut/Claims-adjudication-agent cd Claims-adjudication-agent python3.13 -m venv .venv source .venv/bin/activate pip install -r requirements.txt cp .env.example .env # Add your AWS and Bright Data credentials ``` ### Environment Variables ```bash # Required — AWS (Bedrock) AWS_ACCESS_KEY_ID=... AWS_SECRET_ACCESS_KEY=... AWS_SESSION_TOKEN=... # if using temporary credentials AWS_DEFAULT_REGION=us-east-1 # Optional — Bright Data Web Unlocker (live policy fetch) BRIGHTDATA_API_TOKEN=... BRIGHTDATA_ZONE=hackathon_unlocker # Optional — override the default policy URL COVERAGE_POLICY_URL=https://www.aetna.com/cpb/medical/data/700_799/0770.html ``` --- ## Running the Demo ```bash # Single case .venv/bin/python run_demo.py --case 1 # APPROVE .venv/bin/python run_demo.py --case 2 # DENY .venv/bin/python run_demo.py --case 3 # NEEDS REVIEW + EXPEDITE # All 3 without pausing .venv/bin/python run_demo.py --all ``` --- ## What Makes This Different | Today's PA | This Agent | |---|---| | 3–14 day manual review | Real-time (< 60 seconds) | | Black-box yes/no | Rule-by-rule breakdown with cited evidence | | Reviewer guesses on missing data | Low confidence → NEEDS REVIEW (never guesses) | | No urgency differentiation | EXPEDITE / STANDARD flag with clinical rationale | | Phone/fax workflow | API-ready structured output | --- ## Safety & Compliance Notes - All patient data is **100% synthetic** — no real patient information is used anywhere in this project - The agent is explicitly designed to **refuse to guess** on missing biomarker data — low confidence is a first-class output, not a fallback - This is a **hackathon prototype**, not a regulated medical device or FDA-approved clinical decision support system --- *Built at Biopharma Hack Day @ AWS · Problem Statement #4 · 2025*

HackerSquadOpenAI CodexBright DataAWSclaude

Hawthorn

A drug trial that sails through Boston can flatline in Tokyo. Not because the drug is worse, but because the enrollment rules were written for American patients and American labs. Sites sign on, enroll nobody, and the mid-trial fix runs six figures and burns months off the clock. Hawthorn reads a U.S. protocol and rebuilds it for Asia-Pacific in minutes instead of months, pressure-testing every eligibility criterion against ICH, FDA, PMDA, and NMPA guidance, proposing the exact edits that unlock local patients, and citing chapter and verse for each one. An interactive threshold explorer and evidence chat let your team run the what-ifs and trace every claim back to the source.

HackerSquadOpenAI CodexConvoke

JPC

# Drug Repurposing Candidate Finder A tool that helps spot new uses for existing drugs. ## What it does Many drugs already on the market, or already in clinical trials, could potentially treat diseases beyond what they were originally designed for. This happens because different drugs can act on the same biological "target" in the body — and if one drug on that target is showing promise for a disease, others that share the target might work too. This tool searches two ways: - **Search by drug** — pick a drug, and see what other diseases it might be worth testing, based on what other drugs sharing its target are already being tried for. - **Search by disease** — pick a disease, and see every drug currently being tested or already approved for it. Every result links back to a real clinical trial, so nothing shown is a guess made up out of thin air — it's either a documented trial or an explicit "we don't have a source for this yet." ## How it works, in short 1. **Raw data** comes from Convoke's drug program tracker — real records of which drugs target what, and what diseases they've been tested for. 2. **A build script** (`data/build_cache.py`) cleans that raw data into one simple file (`data/cache.json`) the rest of the app reads from. 3. **The matching logic** (`scoring.py`) does the actual thinking: find shared targets, find other drugs on those targets, filter out anything already covered or discontinued, and rank what's left by how far along the evidence is. 4. **The app** (`app.py`) is what you actually see and click around in.

Convoke

FDAccel

Design and de-risk your filings for the next stage of clinical trials with intelligent, data-driven insight. Check deployment here: https://fdaccel.vercel.app/

OpenAI Codexclinicaltrials.gov, Vercel

Team Kestrel

A prescribing check that stops a fatal dose, and a receipt that proves we knew. THE PROBLEM About 1 in 300 people cannot clear capecitabine, a common chemotherapy drug. For them the standard first dose is not treatment, it is poisoning. The science is settled: CPIC publishes 90+ gene-drug guidelines, free. A randomized trial of 6,944 patients (Lancet 2023) found genotype-guided prescribing cut clinically relevant adverse drug reactions from 28.6% to 21.5%. Europe requires DPYD testing before fluoropyrimidines. Almost no US hospital checks. HOW IT WORKS A clinician places an order. The patient's genotype resolves to exactly one row in a locally cached CPIC dataset (107 drugs, 3,547 rows) and the order is interrupted with CPIC's own words, verbatim, linked to the exact source row and its PMIDs. An FDA-labeled badge appears when the FDA's own pharmacogenetic associations table lists the pair. That table is published as HTML only, with no API or CSV, so we scraped it with Bright Data: 124 associations. The model never writes clinical text. It parses free-text orders and maps brand names to generics. Every clinical string on screen is copied verbatim from a cached authority. That is the only reason any of it can be cited. THE HALF NOBODY HAS BUILT Clinicians override these alerts constantly, because a pop-up with no visible basis is indistinguishable from the forty others they dismissed that morning. So we do not block the override. We change what one is. Each becomes a signed record: printed name, timestamp, meaning of signature, written rationale. Then two things happen to it. It is hash-chained. Edit any record afterward and every record from that point forward visibly breaks, while earlier ones stay intact. It expires on its own. The override was authorized against a specific version of the evidence: the CPIC guideline and the payer policy clause. Revise either and the authorization flags itself SUPERSEDED, naming the change that invalidated it. In the demo two overrides are signed and one policy revision is published. The capecitabine authorization dies, the codeine one survives, and the hash chain stays green throughout. Two red states that mean different things. Tampered means someone changed the record. Superseded means the record is intact but the decision is no longer warranted. Every audit tool answers the first. Almost none answer the second. BUILT WITH OpenAI Codex and Claude in a two-agent cross-check: Codex wrote the provenance layer, Claude wrote the clinical layer, and each audited the other's work. Neither certified its own code. Bright Data for the FDA table. AWS Bedrock supported as a provider (today's runs used OpenAI). Convoke's MCP for forward-looking pipeline data. 52 tests. No runtime network calls, so the demo runs offline. Synthetic patients and a synthetic payer policy only.

HackerSquadOpenAI CodexBright DataAWSConvoke

Drug shortages never feel sudden to the patients who need them. RespiraWatch helps planners move a week earlier by showing where respiratory medication demand pressure is building before supply strain becomes visible. By combining CDC respiratory activity, weather, air quality, and shortage signals, it turns scattered public data into an early-warning system for action.

HackerSquadOpenAI Codex

M

Trial Optimizer

Help design and review clinical trials by analyzing existing clinical trial records and analogs.

OpenAI CodexConvoke

SourceLock

SourceLock is an AI-powered pre-MLR review and regulatory change-impact workspace for pharma and biotech content teams. Problem: Approved clinical, safety, and regulatory claims are reused across Medical Affairs responses, MSL materials, patient content, training, and other downstream assets. When an approved source changes, teams must manually find outdated claims across many documents. This creates review delays, inconsistent messaging, and risk of unsupported or outdated content reaching the field. What SourceLock does: 1. Reviews incoming content sentence by sentence against a versioned approved-claim library. 2. Identifies supported, unsupported, prohibited, audience-inappropriate, and superseded claims. 3. Shows the exact source claim, source excerpt, source version, and reviewer-ready rationale for every decision. 4. Uses Amazon Bedrock for semantic evidence review and conservative rewrite suggestions. 5. Uses deterministic rules for claim approval status, prohibited language, audience permissions, source versions, and MLR readiness scoring. 6. Detects source updates and maps changed claims to affected downstream assets requiring re-review. 7. Maintains a human-in-the-loop audit trail; SourceLock does not autonomously approve or publish content. Demo: A fictional kidney-transplant investigational therapy, KTX-201, is used with synthetic hackathon data. An incoming MSL draft includes: - a source-supported Month 12 clinical endpoint; - an unsupported comparative claim; - prohibited claims of regulatory approval and universal superiority; - an outdated safety statement. SourceLock flags the risky language, links supported content to approved evidence, and demonstrates a source update from 7.4% to 8.1% serious infections. The Change Impact workflow identifies all downstream assets that now need re-review. Impact: SourceLock helps Medical, Legal, and Regulatory teams spend less time locating evidence and outdated content, while improving consistency, traceability, and version-aware review. Important: KTX-201 and all project data are fictional, synthetic hackathon data. This prototype is decision support only; it is not a compliant system and does not replace qualified Medical, Legal, or Regulatory review.

OpenAI CodexAWS

M

OPSL

Our drug repurposing approach pinpoints candidate Parkinson’s therapeutics by correlating epidemiological toxin data with overlapping molecular pathways shared by both toxins and known disease treatments.

HackerSquadOpenAI CodexConvoke

the Nguyeners

ClearTrial — Patients find trials, and trials find patients. ClearTrial is a two-sided clinical-trial intelligence platform for oncology. Patients describe their cancer history the way people actually talk — "stage IV lung cancer, four rounds of carboplatin and pemetrexed, PD-L1 around 60%, no brain mets" — and ClearTrial returns ranked matches against real, published eligibility criteria from 60 recruiting oncology trials, explaining criterion-by-criterion why each trial fits, why it doesn't, or what a doctor needs to confirm. One click drafts the email to the study team. The load-bearing design choice: the language model never decides eligibility. AI does exactly two jobs — extract structured clinical facts from messy text, and write explanatory prose. Every eligible / excluded / needs-review verdict comes from a deterministic TypeScript engine evaluating published protocol text, so any decision is replayable, unit-tested, and reviewable by a clinical team. That is the entire compliance and trust argument — you cannot audit a chatbot transcript, but you can sign off a rules file. The researcher side turns every rejection into protocol-design intelligence. Anonymized exclusion signals aggregate into a dashboard showing which criteria are costing recruitment across the portfolio — e.g. prior PD-1/PD-L1 therapy ruling out a large share of interested patients — automatically synthesized into a Protocol Optimization Alert for trial design teams, and exported as a versioned, provenance-backed decision record for Convoke. New: Pipeline Radar. IND filings are confidential and registry entries lag real-world announcements, so ClearTrial monitors SEC EDGAR filings and press-wire coverage for the sponsors in its portfolio, extracting evidence-backed milestones — trial initiations, IND clearances (numbers never published, by design), data readouts — and joining them to the monitored trials, Convoke program stage and catalyst dates, and live eligibility friction. The radar shows when an announcement led the registry entry, when a press release connects to a trial, and when a program catalyst is approaching while eligibility friction stays high. Built in a day on Next.js with the OpenAI API, live ClinicalTrials.gov data, the AWS Strands Agents SDK, and Convoke's knowledge graph. Deterministic where it must be, honest about what it cannot verify, and never storing patient data.

HackerSquadOpenAI CodexBright DataAWSConvokebright data didnt work because it said my account was suspended, so i used an automated agent to get API data from gov trials

KMR

Slipstream takes a drug name, researches canonical source data like FDA Labels, clinical trial output, clinical practice guidelines, and medical information scientific response docs, and packages it into grounded, cited assets for medical affairs, your medical science liaison, and your sales team.

OpenAI CodexConvokeCemented AI

Bridge

Bridge is a “pre-appointment intelligence layer” for clinical trials. Instead of asking patients to search through dozens of trial listings and decipher eligibility criteria themselves, Bridge translates their profile into a ranked set of potentially relevant trials and shows exactly what they still need to clarify with their doctor.

OpenAI CodexAWSNext.js + TypeScript + Tailwind + OpenAI + ClinicalTrials.gov + Vercel + Clerk

NovaTarget

Given a drug name maps to the target and then gives target linked drugs and associated diseases with scoring, citations based on clinical trials, chembl, open targets platforms.

HackerSquadOpenAI CodexBright DataAWSConvoke

B

BaYESians

Protein Hinge is a dating app for drugs and rare diseases: the drugs already exist, the diseases have been waiting forever, and somehow nobody has introduced them. Type in a rare disease and we swipe through known therapeutics — matching on broken biology, patient genetics, and trial history — then tell you who's single, who's taken, and who got ghosted after a failed Phase 3. And like any good matchmaker, we spill the tea with receipts. Every claim is hash-fingerprinted, so if anyone edits the evidence, the ledger calls them out in front of everybody. No AI wingman makes the call — plain, readable rules decide every match, and "we don't know" is a respectable answer. We set up the date; we don't officiate the wedding.

HackerSquadOpenAI CodexBright DataAWSConvokeclinical trials, FDA, Japan and Europe

NTU

# Drug discovery intelligence pipeline Target → marketed competitors → US patents and market exclusivity → LOE (patent cliff) timeline. ## 🖥 Web workbench The project is integrated with the root-level `index.html` into a single workbench: switch between EGFR, BRAF, and PDCD1, read the ChEMBL / Orange Book / Purple Book data snapshots directly, and build a source-annotated TPP draft from any marketed drug. Because browsers do not allow `file://` pages to read adjacent JSON, build the site first, then start a static server: ```bash npm run build python3 -m http.server 8765 -d dist/client # Open http://localhost:8765/ ``` The workbench does not infer CMC, toxicology, clinical, or regulatory-pathway content from target data; those fields are explicitly flagged as requiring human review. ## ☁️ AWS backend (optional) `backend/` contains an AWS SAM stack that connects the workbench to real cloud services: Bedrock (Claude generates the TPP draft) + Bedrock Knowledge Bases (RAG retrieval of guidance, replacing Kendra from the blueprint) + DynamoDB (evidence chain) + Cognito (regulatory/R&D role login) + S3/CloudFront (static hosting). After deploying, fill the Outputs into `aws-config.js` (template: `aws-config.example.js`) and the TPP Dossier tab will show an "AWS Live Mode" panel; without the config, the site stays in pure static mode with unchanged behavior. Full steps in `backend/README.md`. ## 📂 Folder structure ``` drug-discovery/ ├── scripts/ ← numbered pipeline, run in order │ ├── 00_check_sources.py ← endpoint health check (run monthly) │ ├── 01_fetch_target_drugs.py │ ├── 02_fetch_orangebook.py │ └── 03_build_loe_report.py ├── clients/ ← data-source wrappers with caching and retry │ ├── http.py ← shared HTTP layer (disk cache + backoff retry) │ ├── chembl.py ← target resolution, drug lists │ ├── openfda.py ← Orange Book small-molecule patents and exclusivity │ ├── purplebook.py ← Purple Book biologic exclusivity (no patents) │ └── normalize.py ← salt stripping, Orange Book scope determination ├── install_schedule.sh ← install the monthly endpoint check schedule (launchd) ├── tests/ │ ├── test_pipeline.py ← 41 offline regression tests (no API calls) │ └── fixtures/ ← sample data for tests ├── data/ ← intermediate artifacts + API cache (cache/) ├── reports/ ← generated markdown reports └── docs/ ├── DATA_SOURCES.md ← endpoint registry with last-verified dates ├── domain-knowledge.md ← pharma domain knowledge harvested from the predecessor project └── archive/ ← the predecessor project's 17 SKILL.md files (reference only) ``` ## 🚀 Running the pipeline ```bash cd agents/drug-discovery pip install -r requirements.txt python scripts/00_check_sources.py # Confirm the endpoints are alive first python scripts/01_fetch_target_drugs.py EGFR # ChEMBL: target → drug list python scripts/02_fetch_orangebook.py EGFR # openFDA: patents and exclusivity python scripts/03_build_loe_report.py EGFR # Produces reports/EGFR_LOE.md python tests/test_pipeline.py # Regression tests (offline, no API calls) ``` Endpoint rot is the only truly fatal failure mode for this kind of project, so schedule the monthly check with launchd: ```bash ./install_schedule.sh # Automatically runs 00_check_sources.py at 09:00 on the 1st of each month ``` Requesting a free openFDA API key and setting it as an environment variable is recommended; it raises the quota from 1,000 to 120,000 requests per day: ```bash export OPENFDA_API_KEY=your_key_here ``` ## 🔬 Methodology | Stage | What it does | Data source | Key design | |---|---|---|---| | 00 | Endpoint health check | All | Bypasses the cache and hits the live endpoints directly | | 01 | Target → drug list | ChEMBL mechanism | Uses the hand-curated mechanism data, not activity (too noisy) | | 02 | Drug → patents and exclusivity | Orange Book + Purple Book | Salt-stripped matching, ingredient dedup, small-molecule vs. biologic routing | | 03 | Patents → LOE report | Local computation | LOE = max(latest patent, latest exclusivity) | The report has two views: the **LOE timeline** answers "who is on the market and how long they are protected," and **clinical-stage competitors** answers "who is coming in." The latter comes from ChEMBL max_phase 1 through 3; those drugs are not in the Orange Book (which only covers approved products), but they determine competitive intensity over the coming years. Note that max_phase is the highest phase a molecule **has ever reached**, not whether it is still in progress — discontinued programs are never downgraded. Confirming whether a program is still alive requires a separate check against ClinicalTrials.gov. **Design principle**: every number must be traceable to some API response. If it can't be found, mark it "unknown" — no estimating, no imputing, no letting an LLM fill in blanks. Getting a patent expiry date wrong has real consequences. ## ⚠️ Coverage limitations **US only, and small molecules and biologics get different analysis depth.** Small molecules go through the Orange Book, which provides individual patent numbers and expiry dates, enabling a full LOE analysis. Biologics go through the Purple Book, which only provides approval dates, market exclusivity, and biosimilar entry status — **no patents**. This is not implementation laziness: Hatch-Waxman requires small molecules to publicly list their patents, while the BPCIA designed the patent exchange for biologics as a confidential process between the parties, and the FDA does not publish the patent numbers. The report splits the two into separate sections and states the depth difference explicitly, so readers do not compare exclusivity terms against patent terms. Take PD-1 (PDCD1) as an example: all seven marketed drugs are antibodies, so the LOE timeline is entirely empty, and the report opens with a direct warning that this reflects database scope rather than an absence of competition — after all, Keytruda is in that product line. Other items not covered: patents outside the US, patents on unapproved drugs, patent litigation and Paragraph IV challenge status, and process patents not listed in the Orange Book. ## 📖 How this project came to be The starting point was `huifer/drug-discovery-skills` on GitHub. That project claims to provide 17 drug discovery skills; in practice, only 1 of the 17 scripts actually fetched any data: - 7 return hard-coded fake data. Feed in a nonexistent gene, `BANANA9999`, and you get a complete safety assessment report and competitive landscape analysis **verbatim identical** to EGFR's. - 1 has a Python syntax error, which means it was never executed at any point in that repo's history. - 4 point at dead endpoints (the Open Targets domain has even disappeared from DNS). - 1 prints "✓ Fetched data" even after the fetch fails, producing a report full of unreplaced placeholders. The code was therefore discarded wholesale; only the domain knowledge in the `SKILL.md` files was kept (see `docs/domain-knowledge.md` and `docs/archive/`), and the data layer was rewritten to this project's standards. `scripts/00_check_sources.py`, `tests/test_pipeline.py`, and the coverage warnings in the reports are all safeguards designed against the failure modes above. The F-series tests (no data fabrication) map directly to the predecessor's worst defect: they verify that an unknown target returns None rather than made-up data, that an empty dataset produces no data rows, and that different inputs must not produce identical reports. The lesson from the predecessor project: **output that looks professional but is fake is far more dangerous than output that is plainly broken.**

HackerSquadOpenAI CodexBright DataAWS

The description can be a short one-liner about how your project works and what problems you're solving.

HackerSquadOpenAI CodexBright DataAWSConvoke

test