Available now
In build
The whole team
Nineteen specialists, each with a defined job and an honest status label.
See all nineteenDoctor files health records, medications and appointments into a timeline you can search — and refuses, on purpose, to read a single one of them for meaning.
Doctor is a filing system for your own and your family's health records: reports, prescriptions, visits, medications and appointments, organised into one searchable timeline per profile. Every field it stores is either printed on the document or typed by the person filing it — a document date, an issuing facility, a clinician's name, a medication as the prescription states it.
It does not interpret any of it. There is no lab-value table, no trend chart, no severity or urgency field anywhere in its database, because the specification treats a disclaimer as insufficient — regulatory precedent (Ada Health's EU-MDR classification) holds that any output used to make a health decision is a medical device regardless of the wording around it. So the boundary is enforced in the schema, before it reaches a sentence anyone could write.
It never says whether a value is normal, high or low.
There is no value, unit or reference_range column anywhere in Doctor's database — not withheld by convention, but absent by design. That triple's only use is comparison against a range, and comparing a value to a range is where transcription ends and interpretation begins. Even the shared lab-digitisation platform, which extracts full parameter rows for other purposes, hands Doctor only the filing fields — document type, date, facility, clinician — and refuses the rest by an allowlist matched on field name, so a nested copy of a value cannot slip through either.
It never diagnoses, doses or advises on treatment.
No diagnosis, no dosage, no drug-interaction check, no adherence tracking, no urgency ranking. Every generated sentence Doctor produces is passed through the product's medical safety gate before it can be returned, and a sentence that names a likely condition, states a dose to take, or downplays severity is blocked outright rather than softened. Medications are stored exactly as entered (name_as_entered, dose_as_entered), never resolved against a drug database, because resolving one implies Doctor knows what the drug is and can be asked about it.
A clinical question gets a recorded escalation, not a search result.
Type "is my BP report normal" into search and Doctor does not run it. The query is classified first against roughly forty question shapes — what does this mean, is this serious, should I take a scan, how urgent — and a match returns HTTP 400 with a fixed catalogue of neutral questions for your own clinician, never a filtered or hedged answer. The refusal itself is a write: an escalation row is created and committed before the 400 is raised, so the record that you asked survives the error response. A 200 with an empty result list was considered and rejected — "nothing found" is itself a clinical claim.
It never books, cancels or reminds you to see a doctor.
An appointment is a calendar entry you already made; Doctor records it and never creates or suggests one on its own initiative, because deciding that somebody should see a clinician — and how soon — is triage. Status (scheduled, attended, cancelled) is set only by the person; there is no background process that marks a past appointment "missed" on Doctor's own judgement.
It never tells you whether you're keeping up with a medication.
There is no adherence log and no "marked taken" column. A reminder fires at the time you set and keeps no score, because reporting how consistently a course was followed is a clinical observation about behaviour, not a filing fact.
Getting started
Create a profile for yourself or a family member — spouse, parent, child, sibling, or a dependent who isn't a relative. For a child or a dependent, naming the guardian who consented is mandatory: the profile is refused with a 400 until guardian_consent_by is set, and correcting a date of birth downward later re-runs the same check in case it just turned an adult's profile into a minor's.
Add a report, prescription, discharge summary or vaccination record with its document type, date and issuing facility. Nothing is derived by reading the file for meaning — every field is either printed on the document or typed by you, and a misread date or facility has its own correction route rather than requiring a delete-and-refile.
Search for "March report" and you get your own filed documents. Search for "is my BP normal" and you get a 400 with neutral questions for your clinician instead — the same request shape, two entirely different outcomes, because the query is classified before it is ever run against your records.
Capabilities
Records, visits and appointments merge into a single chronological list per profile. An undated document sorts to the end rather than being guessed a date — Postgres and SQLite order NULLs differently, so the ordering is done in code, not left to the database's default.
Literal, case-insensitive text search over filing metadata and your own visit notes — never a semantic index, which is exactly the mechanism by which a search box quietly becomes an answering machine.
Will not: Will not run a clinical-shaped query. It escalates instead — see the refusal above.
A photo is staged as its own row, separate from the filed record — promoting it into a real record is a mandatory, explicit confirm step you drive, never automatic, so a misdetected type can't silently file into the wrong family member's profile. The raw image reference is cleared the moment it's confirmed, leaving the filed document as the one durable pointer to the bytes.
Needs: A document-AI/OCR credential (DOCAI_OCR_API_KEY) for automatic edge detection, perspective correction and type/date classification. Without it, you supply the document type and date directly at confirm time — filing still works.
A full machine-readable export of everything held works today with nothing computed, ranked or summarised on the way out. Share bundles are real too now: a bundle scopes a chosen set of one profile's records, gets a single-use hashed bearer token, a required expiry and an optional view cap, and revoking it takes effect immediately. Every access is checked live against the bundle's own state — revoked, expired or over the view cap all refuse — and is itself audited, with the accessing IP hashed rather than stored raw. What a bundle hands over is filing metadata plus a profile's visit notes, medications and appointments — the same depth the full export already returns — never the underlying scanned file.
Needs: Object storage with managed encryption keys plus malware scanning — the same gap document-vault-storage names — before a bundle can package the actual source files into a PDF or ZIP. A share link is exactly the route that gap exists to keep closed, so this stays intentional, not an oversight.
Per-person profiles with everything filed under exactly one of them. A profile holds no height, weight, blood group or condition field to compare across people — the specification forbids cross-profile or "family risk" scoring, and the cheapest guarantee against it is a profile with nothing comparable to score.
Date, facility, clinician and your own note about why you went, linkable to the records that came out of it. Nothing reads the note — it is matched by search the same way plain text is, never parsed or summarised.
A grant is one row for its whole lifecycle, its bearer token shown once and stored only as a SHA-256 hash. The invite is genuinely emailed through this deployment's configured email sender — that fails soft, recorded on the row, and never blocks the grant from existing even if the email doesn't go out. The view link re-derives its own live state (invited, active, revoked, expired) from the grant's own timestamps on every single access rather than a cached flag, so revoking takes effect immediately rather than only blocking a future login. Read-only regardless of role: naming someone a 'helper' is accepted and stored but unlocks nothing beyond 'viewer' today.
Will not: Will not extend write access to any invited person, whatever role is named — every grant is read-only. And the emailed link is not yet a page: the invite carries https://app.automixai.in/doctor/shared/{grant_id}?token=…, and this frontend has no /doctor/shared route, so a caregiver who clicks it lands on a 404 until that page ships. The grant, its token hash, its live state and its audit log are all real — pass the token to GET /api/v1/agents/doctor/shared/{grant_id} in the meantime.
Name, dose and frequency exactly as you or the prescription states them, optionally linked to the record it came from. No interaction check, no dose validation, no adherence.
Schedules are validated and stored as local wall-clock time plus a timezone, so an 8am dose stays 8am wherever you wake up rather than shifting when you travel.
Needs: A push, SMS or WhatsApp provider, to actually dispatch the nudge.
Appointments are tracked per profile and filtered to genuinely upcoming ones.
Needs: A push or SMS provider, for reminder delivery. Calendar export is not built.
A fixed catalogue of neutral, open-ended questions — "what should I watch for", "how will we know if this is improving" — works today with no configuration. Personalised generation calls the platform LLM, but every candidate line is independently passed through the same output-boundary filter before it can ever be stored: it must be question-shaped, free of dosage numbers and explicit diagnostic-assertion patterns, and still clear the medical safety gate. A rejected line is dropped, never returned, and if the LLM is unconfigured, fails, or every line it produced is rejected, this falls back to the same fixed catalogue, so you are never left with nothing.
Needs: An LLM key. This deployment already has one configured, so personalised questions work here today — the requirement is still named so a deployment without one falls back honestly rather than silently breaking.
Compilation is a layout job, not a summarising one: every field in the brief is copied verbatim from your filed records, medications, visits and appointments, frozen at creation so a later edit to the underlying rows can't silently rewrite a brief already handed to a clinician. It renders as a self-contained HTML page rather than a byte-level PDF file — this deployment has no PDF-rendering library, and a browser's own Print to PDF turns the page into a file just as well. Sharing issues an expiring, single-token link; there is no permanent public URL.
Will not: Will never write an LLM-generated summary paragraph in place of plain compilation — that is the exact change that would cross the clinical-interpretation line, and this route is not that change.
Filename, MIME type, size and a checksum are registered against a record, scoped to the workspace.
Needs: Object storage with managed encryption keys, plus malware scanning.
Will not: Will not serve a document's bytes until both are configured — there is no download route at all yet, which also means there is no route that could serve a file the scanner never cleared.
A lab report is digitised completely on the platform other agents share, parameter rows included. Doctor's own handoff receives only document type, date, facility and clinician — the value, unit and reference-range triple is withheld by an allowlist, not a convention, matched on field name so a nested copy is refused for the same reason.
Needs: An OCR credential, for scanned (non-text-layer) reports.
Will not: Will never receive the extracted value, unit or reference range — there is no column to hold one.
A fixed, generic default catalogue — vaccination record, current prescription, recent lab report, insurance document, discharge summary, none age- or condition-specific — plus items you add yourself. Presence is computed live against your filed records by document type rather than cached, so filing a report ticks an item off with no separate write needed to keep the two in sync. Copy is neutral (is_present, never 'overdue' or 'at risk') by design, and there is no column or code path anywhere that could hold an age- or condition-specific rule like 'diabetic — HbA1c every 3 months'.
Will not: Will never generate an age- or condition-specific reminder rule — the specification names that exact temptation to explicitly refuse.
A per-user language preference (English or Hindi today) and a static, genuinely translated string table for Doctor's own UI labels and generated text — document-type names, relationship names, navigation labels — with no placeholder translations padded in. A language request Doctor can't fully cover reports its fallback keys explicitly rather than silently mixing languages and calling it supported.
Will not: Will never translate an uploaded document's own content or a filed record's free text — there is no parameter anywhere on this surface that could route either to translation.
An ABHA address (or 14-digit ABHA number) is validated and declared per profile, and a consent request is scoped and stored per row — one specific facility id, one purpose, one non-empty data-category list, one required expiry — so no shape here can express a blanket 'always allow' grant. Every linkage and consent artifact is created honestly in a requested or blocked_no_gateway state rather than a fabricated granted one, and fetching records always refuses, naming exactly what is missing, rather than returning an empty list you could misread as 'no records exist'.
Needs: ABDM Health Information Exchange–Consent Manager gateway credentials (ABDM_CLIENT_ID, ABDM_CLIENT_SECRET, ABDM_CM_BASE_URL), which this deployment doesn't have — and even with those, this deployment would also need HIU registration and certification against ABDM's Health Data Management Policy before a real fetch could run, which is a business/legal step, not a code change.
Each consent must name the notice version it was granted against, one-call withdrawal with no confirmation funnel, and access, correction, erasure and nomination requests are all real routes. An erasure executes immediately — not queued for a human — and receipts back the exact counts of what was removed.
Named, not hidden
Understating the product is a smaller sin than overstating it, but it is still a page that stopped telling the truth. So the gaps are here, not left for you to discover.
Not built, and for the same reason Doctor has no value column at all: a chart exists to show a direction, and a direction is a clinical judgement about a trajectory. If this is ever built, it changes what Doctor is — a boundary decision, not a backlog item.
API surface
Every route below is mounted and reachable today. Requests and responses are real shapes, not illustrations.
/api/v1/agents/doctor/profilesAdd a person whose records are filed here. Refused with a 400 for a child or dependent with no named guardian.
Request
{
"display_name": "Amma",
"relationship": "parent",
"date_of_birth": "1958-03-11"
}Response
{
"id": "6b0d…",
"display_name": "Amma",
"relationship": "parent",
"date_of_birth": "1958-03-11",
"guardian_consent_by": "",
"guardian_consent_at": null,
"created_at": "2026-08-16T05:12:00+00:00"
}/api/v1/agents/doctor/profiles/{profile_id}Delete a profile and everything filed under it. Cascades in code so the counts can be returned and audited.
Response
{
"deleted": true,
"counts": {
"records": 6,
"documents": 2,
"visits": 3,
"appointments": 1,
"medications": 2,
"reminders": 1,
"escalations": 0,
"consents": 1,
"profiles": 1
}
}/api/v1/agents/doctor/recordsFile a document — what kind, when, who issued it.
Request
{
"profile_id": "6b0d…",
"document_type": "lab_report",
"document_date": "2026-01-14",
"issuing_facility": "Apollo Hospital",
"title": "January blood work"
}Response
{
"id": "9a41…",
"profile_id": "6b0d…",
"document_type": "lab_report",
"document_date": "2026-01-14",
"issuing_facility": "Apollo Hospital",
"title": "January blood work",
"tags": [],
"source": "manual_entry",
"retention_until": null,
"created_at": "2026-01-14T09:03:00+00:00"
}/api/v1/agents/doctor/search?q=is my BP report normalA clinical-shaped query is refused, not run — 400, with an escalation already recorded.
Response
{
"detail": {
"reason": "clinical_question_not_answerable",
"message": "Doctor organises records and cannot interpret them. Here are neutral questions to take to a qualified clinician, who can answer this properly.",
"escalation_id": "3f2c…",
"questions_for_your_clinician": [
"What do these results mean for me, in plain language?",
"What are my options, and what would you suggest we do first?"
]
}
}/api/v1/agents/doctor/consentsRecord a purpose-scoped consent against the notice text actually shown.
Request
{
"purpose": "record_storage",
"notice_version": "2026-06-01-v2",
"subject_profile_id": "6b0d…"
}Response
{
"id": "c710…",
"purpose": "record_storage",
"notice_version": "2026-06-01-v2",
"granted_at": "2026-08-16T05:20:00+00:00",
"withdrawn_at": null,
"active": true
}/api/v1/agents/doctor/data-requestsFile a DPDP data-subject request. An erasure request executes immediately.
Request
{
"request_type": "erasure",
"detail": "Close my account and remove my data."
}Response
{
"id": "0e5a…",
"request_type": "erasure",
"status": "fulfilled",
"fulfilment_summary": {
"records": 6,
"documents": 2,
"reminders": 1,
"medications": 2,
"appointments": 1,
"visits": 3,
"escalations": 0,
"consents": 1,
"profiles": 1
},
"fulfilled_at": "2026-08-16T05:22:00+00:00"
}Limits and gotchas
Every id lookup returns 404, never 403, for a row this workspace doesn't own. That is deliberate: a 403 on a health-record id would confirm the record exists, which is a bigger leak on medical data than on almost anything else in the product.
Registering a document's filename, size and checksum works today. Storing and serving the actual bytes needs object storage with managed keys plus malware scanning, and until both exist there is no route that could serve a file at all — not a broken one, an absent one.
A record with no retain_for_years is kept forever by default, and purging expired records is an explicit POST an operator makes — never a silent cron. A background job that quietly deletes health records has its first visible symptom be a person finding their reports gone.
GET /records/{id} writes an audit row before it returns — a read that is not recorded is a read nobody can account for in a breach investigation. The audit payload records that the record was viewed, never what it contained.
The refusal paths and boundary copy described here are built and covered by tests, but per docs/REQUIRED_FROM_USER.md §4 a registered medical practitioner has not yet reviewed this wording. That review is a condition of going live to customers, not a condition of building the agent — the two are tracked separately on purpose.
'Helper' is accepted and stored as a role name, but it unlocks nothing beyond 'viewer' today — there is no code path anywhere that grants an invited person write access to a profile they don't own.
This deployment has no PDF-rendering library, so the brief and its public share view both render as a self-contained HTML page; a browser's own Print to PDF turns it into a file just as well. If this ever changes to an LLM-written summary instead of plain compilation, that is a boundary change, not a formatting one.
Even with the gateway credentials configured, reaching India's real ABDM consent-manager network needs HIU registration and certification against ABDM's Health Data Management Policy — a process this deployment has not started, and one no API key by itself can skip.
What this needs from you
Everything else on this page works with none of these connected.
| Credential | Unlocks |
|---|---|
| Object storage + malware scanner | Storing and eventually serving document bytes (document-vault-storage), and letting a share bundle package the actual source file into a PDF or ZIP instead of filing metadata alone (record-sharing-export). Filing metadata and bundle links both work today with neither connected; there is no document download route until both exist. |
| Push, SMS or WhatsApp provider | Dispatching a medication or appointment reminder at the time you scheduled it. The schedule itself is validated and stored with no provider connected. |
| Document-AI / OCR credential (DOCAI_OCR_API_KEY) | Automatic edge detection and type/date classification on a photographed document, and digitising a scanned (non-text-layer) lab report on the shared platform. Filing still works without it — you supply the type and date yourself. |
| LLM key | Notes-tailored visit-prep questions, always through the medical output-boundary filter. The fixed neutral question catalogue works today with no key at all — this deployment already has one configured, so personalisation works here too. |
| ABDM gateway credentials (ABDM_CLIENT_ID, ABDM_CLIENT_SECRET, ABDM_CM_BASE_URL) | Reaching India's real ABDM Health Information Exchange–Consent Manager gateway to actually fetch records via a linked ABHA ID. Declaring an ABHA ID and scoping a consent request both work locally today with none of this configured. Even with these, HIU registration and Health Data Management Policy certification are still needed — a business/legal step, not a code change. |
Questions
No. Doctor has no column that could hold a value, a unit or a reference range, so there is nothing for it to compare. Ask it and the question is classified as clinical, refused with a 400, and recorded as an escalation carrying neutral questions for your own clinician — the record that you asked is kept even though the answer isn't given.
Yes, at three levels: a single record, a whole profile with its cascade counted and returned, or an erasure data-subject request that removes every row this workspace holds and executes immediately — it is not queued for a human to action later. Only the append-only audit trail survives, and it holds no clinical content by construction.
It is digitised in full — parameter rows included — on the platform other agents in this product share. Doctor's own handoff receives only document type, date, facility and clinician; the value, unit and reference-range triple is withheld by an allowlist before it ever reaches Doctor's database.
Yes — a profile per person, with everything filed under one. For a minor or a dependent, the profile can't be created without naming the guardian who consented, and correcting a date of birth downward re-checks that requirement in case it just turned an adult's profile into a minor's.
The schedule works today with no configuration — local time, days of the week, lead time. The actual nudge needs a push, SMS or WhatsApp provider connected; until then the reminder is stored and validated but nothing fires.
Only this workspace — every query filters on workspace_id, and a row that belongs to someone else returns the same 404 as a row that doesn't exist, so a probe can't tell the two apart. The audit trail records that a record was accessed, never its contents, so even reviewing access logs cannot recover what was in it.
Yes — invite them to a read-only link from that profile. The bearer token is shown once and stored only as a hash, the invite is emailed where email is configured but never blocks the grant from existing if it isn't, and you can revoke it at any time — revocation takes effect immediately, not just on their next login. Whatever role you name, access stays read-only.
Declaring your ABHA ID and scoping a consent request both work today, but nothing is dispatched to the real government system yet: this deployment has no ABDM gateway credentials, so a fetch always refuses with a clear reason instead of returning an empty result you could mistake for 'no records exist'. Even once those credentials are added, the deployment still needs formal HIU registration and certification before a real fetch can run — that is a business and legal step, not just a key.
Coming soon