Bioinformatics
AfriPharmaGen: pharmacogenomic interpretation for African populations
An agentic system that interprets a patient genotype where CPIC and DPWG guidelines were never calibrated for the population in front of it.
Research software. It is not validated for clinical use, and its output should not guide diagnosis or treatment without review by a qualified clinician.
Sources for the numbers on this page: Frontiers in Pharmacology (2025), ancestry of PharmGKB study participants; Allele catalog preprint (medRxiv).
Problem
Pharmacogenomics guidelines are built almost entirely on European-descent data. Across 1,225 pharmacogenomic studies annotated in PharmGKB, 3,031 of 651,532 participants (0.46%) were of African ancestry. African populations carry star alleles, structural variants, and haplotypes that the standard callers (PharmCAT, StarGazer, Aldy) return a "no call" for, because those alleles are absent from the reference definitions the tools depend on.
The clinical cost is concrete. CYP2B6 slow-metabolizer phenotype, which governs efavirenz dosing in HIV treatment, runs two to three times more common in some African groups than in Europeans. TB, HIV, and malaria co-treatment stacks drugs whose gene-drug pairs have no CPIC guideline at all. A patient gets dosing guidance calibrated to a population that does not represent them, and adverse reactions follow.
The tools stop where the guideline stops, and for these populations the guideline usually stops early.
How it works
AfriPharmaGen is structured as an agent that keeps gathering evidence until it is either confident or explicitly stuck. The agent package separates concerns into a planner, a reasoner, a reflector, a tier classifier, a guideline lookup, an exemplar selector, a working memory, and a firewall that inspects both what reaches the model and what it returns.
Inference runs on a local Ollama model by default. Cloud LLM backends (Anthropic, OpenAI) are an opt-in extra that requires explicit consent, because the input is patient genotype data and the privacy default has to be on-device. A PII layer scrubs free-text evidence before it reaches any model.
The knowledge layer is explicit code: African-specific allele definitions, CPIC and DPWG tables, PharmVar mappings, and a drug-interaction model, each validated against Pydantic schemas so a malformed entry fails when it loads, before any interpretation starts.
Architecture pipeline flow
End-to-end executionPatient genotype input
Panel or whole-genome variant calls in VCF format
PII scrub & firewall
Strict egress boundary with on-device Ollama inference default
African allele catalog
Curated star-allele haplotypes missing from reference databases
Agentic reasoning loop
Planner and reasoner evaluate multi-drug polypharmacy chains
Calibrated report
Guideline lookup with stated uncertainty for novel variants
Patient VCF / panel
|
v
[ Planner ] --> [ Guideline lookup ] --> [ Reasoner ] --> [ Reflector ]
| (CPIC / DPWG / | |
| African alleles) | v
| | confident? --no--> gather more evidence
v v |
[ Firewall + PII scrub ] [ Tier classifier ] yes
(egress + ingress) |
v
Clinical report + evidence chainHard parts
- Reasoning past "no data available": for a novel variant absent from every database, the agent gathers functional prediction, population-frequency context, and literature evidence and reasons about likely impact and reports it.
- Population-specific frequency context: metabolizer-phenotype prediction is conditioned on the specific population (for example Yoruba, Luhya or Mende).
- Polypharmacy interaction chains: the drug-interaction model reasons across TB, HIV, and malaria co-treatment (rifampicin, efavirenz, isoniazid) across the whole drug combination.
- Calibrated uncertainty: where no guideline exists, the system produces a provisional, research-only interpretation with its uncertainty stated.
- A firewall on both directions: an egress rule scopes what leaves to citation domains, and an ingress path scrubs PII from free-text evidence before it reaches the model.
My contribution
This is my own research project. I designed the agent architecture, wrote the planner, reasoner, reflector and tier-classifier, and built the knowledge layer: the African-specific allele definitions, the CPIC/DPWG tables, the PharmVar mappings and the drug-interaction model, each behind a Pydantic schema. The population-frequency foundation it reasons over comes from two companion repositories I also built, a curated allele catalog and a Bayesian frequency estimator. The pharmacogenomics framing draws on work with my co-author Bolaji Oyeyemi, published as preprints; the system design and implementation are mine.
Results
The evaluation harness runs published-case, scenario, and stress suites against the interpreter, with results kept under version control. The differentiator over PharmCAT, StarGazer, and Aldy is behavioural: where those tools return a no-call for a novel African allele, AfriPharmaGen returns a reasoned functional impact with its evidence chain and a confidence score.
- African allele coverage the standard callers miss, called with population-aware haplotype definitions.
- Provisional, research-only interpretations with stated uncertainty for gene-drug pairs that have no CPIC or DPWG guideline.
- An evaluation suite (published cases, scenarios, stress) kept in the repository so outcomes are reproducible.
Limitations and trade-offs
- Research use only. The output is a research interpretation, not clinical dosing guidance, and it is not validated for patient care.
- The on-device privacy default trades capability for safety: the local Ollama model is weaker than a frontier cloud model, and using a stronger backend requires explicit opt-in consent because the input is patient genotype data.
- For gene-drug pairs with no CPIC or DPWG guideline, the interpretation is provisional by construction, carries stated uncertainty, and should be read as a hypothesis, not an answer.
- African-specific coverage is only as complete as the curated allele definitions behind it. A variant absent from both the public databases and the curated layer is reasoned about from functional prediction and literature, which is weaker evidence than a validated allele call.
- The evaluation suite checks behaviour against published cases and scenarios, not against a large held-out clinical cohort, which does not yet exist for these populations.
Artifacts
The interpreter ships as a Python package with a local-LLM default and opt-in cloud backends. A companion curated allele catalog and a Bayesian allele-frequency estimator (separate repositories) supply the population-frequency foundation the interpreter reasons over.