PGx-Guardian

AI voice agent that detects critical drug interactions and acts on behalf of clinicians via Auth0 Token Vault - emailing reports, scheduling follow-ups, and archiving to Drive.

Comment

Inspiration

As a Bioinformatician, I know that drug-gene interactions kill patients, not because doctors don't care, but because the information is too slow to reach them. A clinician at the bedside shouldn't have to pause, open a database, search for interactions, then manually email a colleague or schedule a follow-up. PGx-Guardian was born to eliminate that friction. v3 takes it further: the agent doesn't just inform, it acts.

What it does

PGx-Guardian is a real-time clinical voice agent. A clinician speaks a patient's medications and genetic variants, and the system instantly identifies critical drug-gene and drug-drug interactions using curated pharmacogenomics databases (DDInter, DGIdb, CPIC guidelines).

With v3 and Auth0 Token Vault, the agent can now act on behalf of the clinician:

  • 📧 Email the safety report to a colleague via Gmail
  • 📅 Schedule a follow-up appointment in Google Calendar
  • 💾 Archive the report to Google Drive for compliance
  • 📊 Log the analysis to a Google Sheets audit trail

All of this happens securely, no hardcoded API keys, no stored credentials, no re-authentication required after the initial setup.

How I built it

Voice layer: Google ADK + Gemini 2.5 Flash Native Audio for real-time bidirectional audio streaming and pharmacogenomics-aware transcript correction.

Backend: FastAPI + Python on Google Cloud Run, with WebSocket support for live voice sessions.

Authentication: Auth0 with session-based login. Users authenticate once via Google through Auth0's Universal Login.

Token Vault: The core of v3. When a clinician connects their Google account, Auth0 stores the OAuth refresh token securely in Token Vault. When the agent needs to send an email or schedule a calendar event, the backend exchanges the Auth0 refresh token for a short-lived Google access token — without ever storing Google credentials in our database.

The Token Vault flow:

  1. User connects Google via /me/v1/connected-accounts/connect
  2. Auth0 stores the federated refresh token securely
  3. Agent calls /oauth/token with grant_type: urn:auth0:params:oauth:grant-type:token-exchange:federated-connection-access-token
  4. Auth0 returns a short-lived Google access token
  5. Agent calls Gmail/Calendar/Drive/Sheets APIs directly

Data: 222,000+ drug-drug interaction pairs from DDInter, 1,897 drug-gene interactions from DGIdb, CPIC clinical guidelines.

Challenges I faced

Token Vault setup complexity: The documentation for Token Vault is sparse and the connected accounts API (/me/v1/connected-accounts) required specific tenant configuration that wasn't obvious. I had to work directly with Auth0 support to understand the correct token exchange flow, specifically that a refresh token (not an access token) must be used as the subject token, and that the grant type is a custom Auth0 extension of the RFC 8693 token exchange spec.

Voice + Auth in the same app: Integrating session-based authentication into a FastAPI app that also runs long-lived WebSocket connections for voice streaming required careful middleware ordering and session management to avoid dropping audio connections during OAuth redirects.

Scope management: Getting the right Google OAuth scopes through the Token Vault connected accounts flow, rather than the standard OAuth flow, required a different approach than typical Google integrations.

What I learned

Auth0 Token Vault solves a real problem in AI agent development: how do you give an agent the ability to act on behalf of a user without storing credentials or asking the user to re-authenticate constantly? The answer, a secure token exchange layer managed by a trusted identity provider, is elegant and production-ready.

The pattern I implemented here (voice agent → detects interaction → offers to act → user confirms → agent executes via Token Vault) is a blueprint for any clinical AI agent that needs to bridge the gap between insight and action.

What We Updated During the Submission Period

PGx-Guardian v2 existed prior to this hackathon as a voice-only pharmacogenomics analysis tool with no authentication and no ability to act on external services. During the submission period (after March 2, 2026), I added:

  • Auth0 Universal Login with session management
  • Token Vault connected accounts flow (full /me/v1 API implementation)
  • Refresh token exchange for Gmail, Calendar, Drive, and Sheets
  • Permissions dashboard with real-time connection status
  • 5 new action API endpoints
  • Step-up confirmation modals before sensitive actions
  • Popup-based OAuth connect flow preserving WebSocket sessions
  • Auto token refresh on expiry
  • Redeployment to Google Cloud Run with all new environment variables

The v2 codebase had zero Auth0 code. Every authentication and Token Vault line was written during this hackathon period, as evidenced by the commit history at github.com/LayalEit/pgx-guardian.

What's next

  • Slack integration for alerting care teams
  • Step-up authentication for high-stakes actions
  • Multi-patient session management
  • EHR integration via FHIR APIs

Bonus Blog Post

Why Healthcare AI Agents Need Proper Authorization, Lessons from Building PGx-Guardian v3

When I started building PGx-Guardian, I solved the easy problem first: making an AI agent that knows things. Give it pharmacogenomics databases, hook it to Gemini's voice API, and it can tell a clinician "this patient can't metabolize codeine" in real time. That part worked beautifully.

The hard problem, the one nobody talks about, is making an AI agent that does things safely.

The moment I wanted PGx-Guardian to send an email on a clinician's behalf, I hit a wall I didn't expect. How do you give an AI agent access to someone's Gmail without storing their credentials? How do you ensure the agent can only do what the user explicitly authorized? How do you prevent the agent from acting without confirmation?

This is exactly where Auth0 Token Vault changed everything for me.

The Token Vault pattern inverts the usual approach. Instead of my application storing OAuth tokens and managing refresh cycles, Auth0 becomes the custodian. When a clinician connects their Google account, Auth0 securely stores the federated refresh token. When my agent needs to send an email, it exchanges an Auth0 token for a short-lived Google access token, one that expires in an hour, can't be reused, and never touches my database.

The technical journey wasn't smooth. I spent hours debugging a "Profile not enabled for tenant" error that turned out to be the wrong grant type, the token exchange requires a refresh token as the subject, not an access token, and a custom Auth0 grant type that isn't in most examples. Auth0 support was genuinely helpful in unblocking this.

What I built in the end feels production-ready in a way my v2 never did. The agent asks before it acts. The credentials stay where they belong. And clinicians can trust that PGx-Guardian won't do anything they didn't explicitly authorize.

That's not just good engineering, in healthcare, it's the only acceptable standard.

Built With

  • auth0
  • ddinter
  • dgidb
  • fastapi
  • gemini-2.5-flash
  • google-adk
  • google-calander-api
  • google-cloud-run
  • google-drive
  • google-gmail-api
  • google-sheets-api
  • python
  • supabase
  • token-vault
  • websockets
Share this project:

Updates