Clinical Agent Suite
four AI agents for the parts of care that are actually paperwork
- Client
- HSI Labs
- Role
- Software Engineer
- Duration
- 13 months
- Delivered
- 31 Aug 2025
- Status
- shipped
Outcomes
40%
physician documentation time saved
Measured during pilot deployments, not at sustained full scale.
4
clinical agents designed and shipped
Medical scribe, patient intake, clinical decision support, medical coding.
2
academic health systems integrated
Howard University and the University of Central Florida.
The problem
A great deal of clinical time goes on work that is administrative rather than medical: writing the note, taking the intake history, looking up what the coding guidelines want, checking against guidance. Each of those is a different problem with a different tolerance for error, and treating them as one generic assistant produces something that is unreliable at all four.
Constraints
- Four distinct agents with genuinely different stakes — a mistake in a coding suggestion costs money, a mistake in decision support could affect care. They could not share one confidence threshold
- Output had to satisfy EHR-compatible data models, or adoption would fail regardless of quality
- Deployed into two academic health systems, whose environments and expectations differ from a startup's
- Improvements had to be demonstrable to clinicians during pilots, not asserted
What I did
- Designed and built four separate agents — medical scribe, patient intake, clinical decision support, and medical coding — on Next.js, LangChain and LLM orchestration frameworks
- Fine-tuned and deployed language models for real clinical workflows rather than against benchmark sets, which improved both diagnostic assistance accuracy and the quality of the structured documentation coming out the other side
- Implemented the NLP pipelines that automated clinical note generation, which cut physician documentation time by 40% during pilot deployments
- Integrated EHR-compatible data models and workflows so output could be adopted directly, including in academic health environments
- Kept each agent's failure mode explicit, so a clinician could tell the difference between a confident answer and a hedge
The hard part
Four agents meant four different definitions of “wrong”. A scribe that omits something can be corrected by the clinician reading it. Decision support that is confidently wrong is a different category of problem entirely, and coding suggestions have a financial consequence attached. Building them as one system with one threshold would have meant tuning for the average and being badly calibrated at both ends. So each got its own bar: when to answer, when to hedge, and when to defer to a person.
Outcome
All four agents shipped and were integrated into EHR-compatible workflows, including in two academic health systems. The documentation pipeline cut physician documentation time by 40% in pilots — the number the clinicians themselves cared about.
What this did not do
- The 40% figure is from pilot deployments, not sustained measurement at full scale. Pilots are also the most attentive users a system ever gets, so I would expect the steady-state number to be lower.
- Diagnostic assistance accuracy improved; I do not have a published external validation of it, and would not present internal improvement as clinical validation.
- None of the four agents removed a clinician from a decision. Decision support suggests and cites; it does not decide.
- Long-tail presentations are the weakest case for any system of this kind, and they are also where help would matter most. That is why each agent got its own abstain threshold rather than a shared one.
Stack
Screens
Four agents, four definitions of wrong, four escalation paths. 
Documentation time during pilot deployments.
Further reading
Related results
Results
- viditparashar.meviditparashar.me › projects › medscribe
MedScribe — an ambient scribe that turns a consultation into a note an…
Case studyLive2025
31 Dec 2025 — … shape of the same conversation for a different reader. Worked directly alongside product and clinical teams during deployment to two hospital chain clients, adjusting…
- 2hospital chain clients deployed to
- 3clinical document types generated
- 2 monthsfrom empty repo to hospital deployment
- Next.js
- TypeScript
- Node.js
- Python
- LangChain
- LLMs
- +2 more
- viditparashar.meviditparashar.me › projects › ai-companion
AI Companion — a companion that listens and speaks at the same time
Case studyLive2026
1 Jun 2026 — a companion that listens and speaks at the same time. Half-duplex voice assistants take turns: you speak, they wait, they answer. Real conversation does not work that…
- Python
- TypeScript
- Next.js
- Node.js
- LangChain
- LLMs
- +4 more
- viditparashar.meviditparashar.me › experience › ainoviq
Full-stack and AI Engineer at Ainoviq (Blackngreen) (Mar 2026 – present)
Full-timeMar 2026 – present
1 Mar 2026 — Building AI products inside Blackngreen's AI division and running several at once — an AI companion on a full-duplex model, and the automation that now handles hiring,…