DialogicAI
AI patient simulation for medical training
An Aston University-funded platform that simulates patients with complex health conditions, so medical students can rehearse consultations and get rubric-based coaching before their licensing exams.
- enrolled medical students
- 500
- year-two deployment target
- 1,200
- infrastructure budget owned
- £5k
Role
AI Software Engineer & Full-Stack Developer
Stack
- Django
- Next.js
- PostgreSQL
- LLM workflows
- Prompt versioning
- CI/CD
- Docker
Context
Medical students get limited time with simulated patients before their licensing examinations, and feedback quality depends on who happens to be assessing. DialogicAI gives every student unlimited practice against AI patients with complex health conditions, with structured coaching after every consultation.
The platform is funded by Aston University and ran its pilot with 500 enrolled students. Year two targets 1,200.



System design
The core is a rubric engine: reusable evaluation packs covering communication, clinical reasoning, learner reflection, and coaching-style feedback. Rubrics drive dynamic prompt construction with versioning, on a model-agnostic LLM layer, so evaluation logic survives model swaps.
Safety guardrails detect and flag problematic interactions and propagate them to administrators, including surfacing learner behaviour that needs educator attention.
Production runs on infrastructure I designed and provisioned: a primary PostgreSQL database with a read-only replica configured for automatic failover, and a full CI/CD pipeline from pull request through review to automated build, test, and deployment, validated with stress tests under load.
- 01Next.js clientVoice and text consultation
- 02Django APISession, auth, transcript
- 03Rubric engineFrameworks, domains, criteria
- 04Prompt builderDynamic, versioned
- 05Model-agnostic LLM layerProvider swappable
- 06Guardrail filterDetect and flag
- 07Learner report and admin escalationScores, coaching, alerts
Data
PostgreSQL primary
Sessions, rubrics, scores
Read-only replica
Automatic failover
Delivery
CI/CD pipeline
PR, review, build, test, deploy
Containerised runtime
Stress tested under load
My role
I designed the rubric-based evaluation structures, built the backend workflows for rubric packs, scoring logic, and learner performance review, and engineered the guardrail system.
I was also entrusted with a £5,000 infrastructure budget to architect and deploy the platform's DevOps stack, taking the application from development to live production.
Outcome
Live in production with 500 enrolled medical students and scaling to 1,200 for year two.
A research paper on the platform, which I contributed to as an author, was accepted by the International Conference on AI in Healthcare and is scheduled for presentation at Imperial College London in August 2026.
Trade-offs
The model-agnostic LLM layer buys portability at the cost of per-model tuning headroom. Prompts have to hold up across providers rather than being sharpened for one, which leaves some quality on the table in exchange for not being locked to a vendor's pricing or deprecation schedule.
The read replica with automatic failover is over-provisioned for 500 concurrent students. It is sized for the 1,200 target rather than today's load, which means paying for headroom a year early to avoid a migration under pressure later.
The assessment hierarchy of frameworks, domains, sub-domains and criteria is deliberately open, so educators can model any curriculum without an engineer. The cost is that the prompt layer has to evaluate against whatever they author, which means feedback quality depends on rubric-writing discipline rather than being guaranteed by the system. Constraining the schema would raise the floor and lower the ceiling.