iDoc: an AI clinical reference tool we chose not to launch
A Flutter application that structures patient symptoms through a rules-based questionnaire before generating AI-assisted clinical reference information — available to registered physicians only, in private beta, and staying there until we are satisfied it should not.
Built with SmartDocx AI Systems Private Limited, a healthcare technology venture co-founded by GegoSoft's founder.
iDoc is restricted to a small number of invited, registered medical practitioners. It is not on any app store, is not available to patients or to the general public, and is not a diagnostic device. Every output is reference information for a qualified physician to evaluate against their own clinical judgement — never a diagnosis, never a prescription, and never intended for anyone acting on it without medical training.
- SECTOR
- Healthcare AI
- PLATFORM
- Mobile (Flutter)
- TEAM
- 3 members
- ACCESS
- Registered physicians only
- STATUS
- Private beta
Why this one is not in the app stores
iDoc works. It has worked for some time. It is not public, and that is a decision rather than a delay.
A general-purpose language model will answer almost any medical question put to it, fluently and immediately. Wrapping that in an app is a weekend of work. What is difficult — and what determines whether the thing should exist — is everything around it: who is allowed to ask, what they are told about the answer's reliability, what happens when the model is confidently wrong, and whether a person without clinical training can distinguish a plausible output from a correct one.
A medical AI that is right most of the time is not a product. It is a liability with a good demo.
So iDoc went to a small group of doctors instead of an app store. They can evaluate an output against their own judgement, which is the only safe way to find out where it fails. We would rather publish a case study explaining a cautious decision than publish an app and hope.
Constraining the input, not just the output
Most medical AI applications are a chat box with a system prompt. The failure mode is obvious once you have watched people use one: the quality of the answer depends entirely on how well the question was asked, and users do not know what they left out.
iDoc does not accept free-text symptoms. A rules-based questionnaire collects structured clinical information first — presenting complaint, duration, severity, associated findings, relevant history — with the questions branching on prior answers. Only once that structure exists is a prompt assembled from it.
Two things follow from this. The prompt is reproducible — the same structured input produces the same request, which makes failures investigable rather than anecdotal. And the interface never invites a question the system was not designed to handle, because there is no box in which to type one.
What the beta has told us
The open questions are not engineering ones. They are the reason the beta continues.
Confidence is not calibration
Model output reads with the same assurance whether the underlying reasoning is sound or not. Presenting that to anyone unqualified to challenge it is the central risk.
Structure helps, but does not solve
Constraining input measurably improves consistency. It does not make the model correct, and we have been careful not to let one be mistaken for the other.
Physicians only, deliberately
A tool that assists a doctor and a tool that informs a patient are different products carrying different obligations. Access is restricted to registered medical practitioners, and we have no plans to open it to the general public.
Regulatory position matters first
Software producing diagnostic suggestions may fall within medical device regulation depending on jurisdiction and claim. That determines the launch path, not the roadmap.
Technology choices and why
A deliberately conventional stack. Nothing here is novel, which is the point when the interesting risk sits elsewhere.
Flutter
One codebase across Android and iOS for a three-person team, with the questionnaire rendered from server-defined rules rather than hard-coded.
Laravel REST API
Holds the questionnaire rules, validation and prompt templates server-side, so clinical logic can change without an app store release.
OpenAI models
Called through a controlled template rather than exposed as a chat interface. The application decides what is asked, not the user.
AWS EC2 and S3
Compute and document storage, with the beta deliberately kept on infrastructure we control end to end.
How the team built it
Three people. GegoSoft engineers use Claude Code as standard daily tooling, and here it carried the Flutter interface work, API scaffolding and validation logic.
The prompt templates, the questionnaire rules and every decision about what the application refuses to do were made by the team, reviewed with the clinicians in the beta. On a product of this kind that division is not a formality — the engineering was the easy half.
Where it stands
iDoc remains in private beta, restricted to invited registered physicians. There is no public release date, no consumer version planned, and we will not widen access before the regulatory position is settled.
The work has fed directly into our other healthcare products. The structured-input pattern and the principle that an application should control what is asked of a model both carried into the LifeBridge platforms, where the clinician selects exactly which records reach the AI.
Common questions
Can I download iDoc?
No. Access is limited to invited registered physicians. iDoc is not on any app store and is not available to the general public. There is no release date, and a public consumer release is not planned.
Can patients use iDoc to check their own symptoms?
No. iDoc is for registered medical practitioners only. It is not a symptom checker and is not intended for anyone without clinical training to act on. If you have a health concern, see a doctor.
Does iDoc diagnose patients?
No. It produces structured reference information for a qualified physician to evaluate against their own clinical judgement. It is not a diagnostic device and does not replace clinical assessment.
Why constrain input instead of using a chat interface?
A chat box makes answer quality depend on how well the user framed the question, and users cannot tell what they omitted. A branching questionnaire collects the same clinical information every time, which makes both the prompt and the failures reproducible.
Can GegoSoft build AI features into our healthcare product?
Yes, and we will also tell you when we think a proposed feature should not ship. We have built clinical AI into an EMR, a dental platform and this application, and the useful part of that experience is knowing where the boundaries are.
Is this an example of what you would build for a client?
The engineering approach, yes. The restraint too — if a client's AI feature carries clinical risk, we will say so during scoping rather than after launch.
Related work
Considering AI in a clinical product?
Tell us what you want the AI to do and who will act on its output. We will give you an honest read on whether it is a shipping product, a supervised pilot, or something that should not exist yet.
Start a conversation See all case studies