Skip to results

Suggestions appear as you type. Use the up and down arrow keys to review them, Enter to search.

MedScribe

an ambient scribe that turns a consultation into a note an EHR will accept

Client
Plato Tech, seed-stage healthtech
Role
Founding Software Architect
Duration
2 months, from founding
Delivered
31 Dec 2025
Status
live

Outcomes

The problem

Clinicians spend a large part of every day writing down what just happened in the room. The tools meant to help mostly produce transcripts, and a transcript is not a clinical note — it has no structure, no separation between what the patient reported and what the clinician concluded, and nothing an electronic health record can file. So the documentation burden moves rather than disappears: someone still has to turn the wall of text into a SOAP note.

Constraints

  • Two large hospital chain clients were waiting, across multi-specialty outpatient workflows — so the output had to be right for several specialties, not tuned to one
  • Medical terminology accuracy was the acceptance bar. A note that reads fluently but records the wrong drug or dose is worse than no note
  • Compliance shaped the architecture from the start rather than being retrofitted, because the buyers were hospitals
  • Seed-stage: every architectural decision made once and lived with

What I did

  • Built the core pipeline end to end — real-time speech-to-text through medical NLP into a structured, EHR-ready note — and owned the architectural decisions the product would inherit
  • Developed the full set of clinical documentation workflows: SOAP notes, encounter summaries, and patient-friendly visit reports, each a different shape of the same conversation for a different reader
  • Worked directly alongside product and clinical teams during deployment to two hospital chain clients, adjusting against what clinicians actually did rather than what the spec assumed
  • Made the scalability and reliability calls early, because a seed-stage team gets to make them once — the alternative was rewriting them under a hospital deadline
  • Kept the compliance-driven constraints — auditability, data handling, what may and may not be inferred — as design inputs instead of a later checklist

The hard part

The distance between a transcript and a clinical note is almost entirely structure, and structure is exactly what conversation lacks. A consultation arrives out of order: the clinician asks something in the middle that belongs in the history, the patient volunteers a symptom while being examined, and nothing is labelled. Turning that into a SOAP note means deciding which utterance is subjective report, which is objective finding, which is assessment, and which is plan — and being willing to leave a field empty rather than fill it with a plausible guess. Getting that judgment right across several specialties, where the same phrase means different things, was the whole job.

Outcome

MedScribe went into two large hospital chain clients across multi-specialty outpatient workflows, generating all three document types from live consultations.

What this did not do

  • I was there for two months, at founding. The architecture and the first deployments are mine; anything the product achieved after I left is not, and I would not claim its later outcomes.
  • Accuracy was assessed internally against clinician review, not by an independent benchmark or a published study. I would describe it as good enough for clinicians to accept and edit, which is the useful bar — not as validated.
  • I did not own regulatory certification. I made the design decisions compliance implied; the formal work sat elsewhere.
  • Nothing here removed the clinician from the loop, and it was not meant to. Every note is reviewed before it is filed.

Stack

Screens

  • MedScribe encounter view showing a SOAP note generated from a live consultation
    The output is a structured note, not a transcript — separated into subjective, objective, assessment and plan.
  • Three document types generated from one consultation transcript
    One conversation, three readers: the record, the referral, and the patient.

Results

  1. viditparashar.meviditparashar.me › projects › clinical-agents

    Clinical Agent Suite — four AI agents for the parts of care that are…

    Case studyShipped2025

    31 Aug 2025… pilots, not asserted. Designed and built four separate agents — medical scribe, patient intake, clinical decision support, and medical coding — on Next.js, LangChain…

    • 40%physician documentation time saved
    • 4clinical agents designed and shipped
    • 2academic health systems integrated
    • Next.js
    • TypeScript
    • Python
    • LangChain
    • LLMs
    • Node.js
    • +2 more
  2. viditparashar.meviditparashar.me › projects › ai-companion

    AI Companion — a companion that listens and speaks at the same time

    Case studyLive2026

    1 Jun 2026a 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
  3. viditparashar.meviditparashar.me › experience › ainoviq

    Full-stack and AI Engineer at Ainoviq (Blackngreen) (Mar 2026 – present)

    Full-timeMar 2026 – present

    1 Mar 2026Building 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,…