MedDox is an integration-first symptom-to-specialty routing layer for doctor-booking applications. I built a FastAPI triage API that returns specialty, urgency, red flags, source refs, and booking payloads before appointment-slot selection.
Quick read (60 seconds)
Stack: FastAPI + PostgreSQL + Cognito + Terraform on AWS.
MedDox is not a symptom checker. It is the cloud architecture centerpiece of this portfolio: I built the triage API, deterministic routing core, AWS-oriented deployment path, static demo fallback, mobile-aligned logic, PDF handoff artifact, and evaluation gates around one booking workflow.
I built the FastAPI triage surface, typed request/response schemas, booking-payload contract, source-reference mapping, and a deterministic service layer for repeatable routing behavior.
Safety Engine
I separated emergency escalation from AI output: red-flag rules run as deterministic overrides before normal specialty selection, with negation guards for cases like no chest pain.
Cloud Delivery
I mapped the deployment path across Vercel, FastAPI, Cognito, PostgreSQL, Docker/ECR, SSM, Terraform, GitHub Actions, and an Expo-aligned mobile demo.
02
Emergency Override Logic
Safety before specialty match.
Safety-critical escalation does not depend on AI output: deterministic red-flag rules override normal specialty routing before any optional AI layer can influence the result.
Emergency guidance
Red flags surface local emergency numbers: USA 911, Germany 112, and Georgia country 112.
These metrics are regression controls for the documented rule set, not clinical validation. The page only uses documented evidence from the local backend tests and golden eval report.
Proof Surfaces
Emergency ResultChest pain routes with urgent escalation.
Routine ResultRash routes to dermatology without red flags.
Visit Brief PDF
A handoff artifact, not a diagnosis.
The PDF brief packages the user wording, suggested specialty, urgency, matched signals, source basis, rule version, disclaimer, and booking payload into a compact visit-prep artifact.
MedDox Visit Brief
Symptom-to-specialty routing guidance. Not diagnosis or medical advice.
Reported SymptomsI have severe chest pain and sweating
Scope here means what I built: the API, service logic, cloud path, integration contract, reference clients, PDF artifact, AWS deployability, and regression checks that turn messy text into a safe booking payload.
Routing Core
Rules before model output
I implemented typo and synonym normalization, weighted specialty matching, negation handling, source-reference mapping, and deterministic emergency overrides as the core decision path.
I shaped the response around downstream booking systems: specialty code, priority, recommended pathway, red-flag evidence, rule version, and whether a safety override was applied.
OpenAPIPartner IDPayload schemaDecision audit
Clients
Web, mobile, and handoff
I aligned the Vercel demo, backend behavior, Expo demo logic, saved recommendations, and PDF visit brief so the same rule version is visible across surfaces.
VercelStatic demoExpoPDF brief
Cloud Path
AWS-deployable architecture
I designed the AWS reference stack with Terraform-managed networking, Cognito auth, EC2 Docker hosting, private RDS PostgreSQL, ECR image delivery, SSM deploy scripts, S3 frontend hosting, and CloudFront API edge.
EC2RDSS3CloudFront
AWS deployability
Built to deploy. Kept cost-safe.
The public Vercel demo is the recruiter-safe walkthrough. The README documents a real AWS path that can be switched on when the runtime is needed.
Provisioned Stack
Terraform application stack
The infrastructure module provisions VPC/subnets/security groups, EC2 API host, private RDS PostgreSQL, Cognito User Pool + Hosted UI, ECR backend repository, S3 static frontend bucket, CloudFront HTTPS API proxy, and optional WAF.
Deploy Path
Docker + ECR + SSM
Backend deployment builds the FastAPI Docker image, pushes it to ECR, renders config from Terraform outputs or safe manual env vars, deploys the container to EC2 through AWS Systems Manager, syncs frontend assets to S3, then runs smoke checks.
Why Not Always Live
Cost-aware runtime choice
The AWS runtime is intentionally not kept live by default. Push-triggered workflows validate deploy readiness, while real AWS deployment stays manual with deploy=true so a student/free-tier build does not burn money between demos.
Architecture Tradeoff
EC2 instead of Lambda/ECS
I chose EC2 for the first reference deployment because it keeps the deployment path simpler, demonstrates Docker-based hosting clearly, works well with SSM deployment scripts, and is enough for expected demo-scale traffic.
Security Posture
Auth, network, and data boundaries
Cognito handles OAuth code + PKCE and JWT issuance; the backend validates bearer tokens, applies request limits and security headers, keeps RDS in private subnets, separates API/database security groups, and avoids storing full medical records.
Cost Guardrails
Free-tier-aware cloud design
The stack avoids NAT Gateway and ALB by default, uses micro-sized compute/database, keeps the frontend static on S3/Vercel demo mode, and preserves deterministic fallback so the app can run without paid AI inference.
Engineering judgment
Credible because it has boundaries.
MedDox does not try to be a clinician or bypass GP/referral rules. The architecture is useful because it can prepare a plausible booking path while keeping medical authority with clinicians.
01Chose deterministic routing over AI-first behavior for safety, traceability, and repeatable evaluation.
02Kept AI optional and secondary so emergency escalation never depends on model output.
03Used public source labels for transparency while clearly avoiding any claim of clinical validation.
04Built the public demo as static Vercel infrastructure so the portfolio walkthrough works even when AWS runtime is offline.
