Build Journal · Start here
What building clinical decision support across streams of medicine taught me
By Ganesh R Datta. I build healthcare AI end to end: clinical decision support, clinic intake, and the marketing and operations around them.
Clinical decision support works when it is built around how one kind of practitioner already reasons, keeps the clinician responsible for every decision, and fits the clinic's existing day. Everything else, the model, the stack, the dashboard, is secondary. I learned that by building it more than once, in different streams of medicine, and watching the same mistakes try to come back each time.
I have now built clinical decision support for Ayurvedic practitioners (AyurDoc), for an integrative heart, brain and longevity practice (THC CDSS), and intake and documentation software for outpatient clinics (CliniqFlow). Different medicine, different patients, different vocabulary. The same five lessons kept showing up. This is the piece I would hand a founder, a CTO, or a clinic owner before they spend a dollar on "AI for our clinic".
1. Start from how the practitioner already thinks
The fastest way to build software nobody uses is to take a general-purpose EMR and translate it. An Ayurvedic practitioner reasons in Nidana (causes), Samprapti (how the condition developed) and constitution. An integrative physician reasons across modern diagnostics, lifestyle and a structured 12-week program. A functional-medicine intake wants a different history than a chiropractic one.
If the software's structure doesn't match the reasoning, the reasoning still happens. It just happens in the room, and the documentation happens later, after hours, as a rewrite. That after-hours rewrite is the clearest signal that a tool was built for someone else.
So the first thing I do on any CDSS is sit with the practitioner's actual reasoning and make the data model match it. In AyurDoc that meant the note is organised around Pancha Nidana, not a translated SOAP note. In THC CDSS it meant the assessment output maps directly to the heart, brain and longevity programs patients actually enroll in.
2. Decision support, not decision making
Every system I build draws the same line: the software prepares, organises and suggests; the licensed clinician decides. That line is not legal boilerplate. It shapes the product.
It means drafts are drafts. In CliniqFlow, SOAP notes start in draft status and nothing reaches a chart until a clinician approves it. It means evidence and data gaps stay visible instead of being smoothed over by confident prose. It means "suggest the next question" in AyurDoc is a prompt the practitioner can ignore, not a script.
Practitioners trust a tool that shows its work and leaves them in charge. They abandon one that pretends to be sure.
3. Fit the day the clinic already has
Clinics already have an EHR, a front desk, a billing process and habits. A CDSS that asks them to replace all of it does not get adopted. Each of my products deliberately works alongside the existing system: AyurDoc covers the consult and the reasoning while the clinic keeps its records system; CliniqFlow is an intake and documentation layer and says plainly that it is not an EHR.
The question I ask is: where in the current day is the most repeated, most avoidable effort? Usually it is re-gathering history the patient could have given before the visit, or rewriting notes that could have been drafted during it. Build there first.
4. Security is a product decision, not a checkbox
Patient data changes what you can show, who can sign in, and how you demo. THC CDSS puts every page behind clinician sign-in. AyurDoc is practitioner-only, not a patient app. CliniqFlow uses tenant-isolated access and role-based permissions.
Those choices cost something: you cannot show the inside of the product on a public website, and sales conversations take longer. They are still the right default. In healthcare, the one breach is the story people remember.
5. Adoption is the real product
A CDSS that is technically correct and unused is a cost. The work that decides whether it gets used is not the model; it is onboarding, the trial, the first week. AyurDoc offers three months free with no card so a single practitioner can try it without a procurement process. CliniqFlow lets a clinic send its first intake link the week it signs up.
This is also where my background in marketing and operations matters more than people expect. The same person who designs the assessment flow should care about how a practitioner first hears about it, what the trial feels like, and who owns follow-up when they go quiet.
What I would tell a healthcare founder
Pick one practitioner type. Map how they reason. Build the smallest piece that removes the most repeated effort from their day, keep them in charge of every decision, protect the data by default, and treat the first week of use as part of the product. Then do it again for the next stream of medicine, and notice how much of the first one you can reuse.
That reuse is why I can move faster on each new stream. The structure underneath, intake, reasoning support, review, plan, follow-up, stays. The medicine on top changes.