The practitioner workspace, not another admin system
Schedule, consultations, prescriptions and earnings — the four things a doctor actually opens a system for.
What changes on day one
- See today at a glance and start the next consult
- Write a prescription the pharmacy can actually read
- Answer patients in the community as a verified voice
- Know what you earned without asking accounts
Everything below is a starting point, not a specification. Every model, field and form on this page is yours to change in Studio — without a developer, a release or a migration.
Inside Doctor Portal
The surfaces this portal ships with. Read them as a well-informed first draft — the shape is right for most, and where it is wrong for you, you change it rather than file a ticket.
Today’s queue
Who is waiting, who is next, and what they came for.
Consultations
Notes captured against the model your speciality uses.
Prescriptions
Structured prescriptions that reach the pharmacy as data, not a photograph.
Schedule
Availability across the facilities you practise at.
Earnings
What you earned, by period, from the same billing records finance uses.
Verified answers
Answer community questions with a verified-clinician badge and your organisation shown.
It arrives with these models. All of them are editable.
Subscribing provisions Doctor Portal and seeds 4 default models against your account. Not one of them is fixed: rename them, add fields, remove fields, or delete the model outright. They exist to save you an afternoon, not to define your organisation.
Consultation
ModelDefinition · seeded
Prescription
ModelDefinition · seeded
Schedule
ModelDefinition · seeded
Patient
ModelDefinition · seeded
And whatever else your organisation tracks
Records for every one of these live in a generic store, tagged with your tenant. That is why adding a field is instant and why removing one never destroys what was already recorded — the schema is data, and clinical data is soft-deleted by default.
Change any of this yourself
Every field on every doctor form is a record in a ModelDefinition, not a line in a codebase. That is not an implementation detail — it is the reason you can add the field you need on a Tuesday afternoon and have your staff using it before the shift ends.
No release. No migration window. No change request, no six-week quote, no field living in a spreadsheet because the vendor said no. You open Studio, you add it, and the form re-renders for everyone on their next request.
18 field types
Text, number, currency, date, select, relation, file, JSON and more.
Relations, not exports
Link a model to a model and the join is real, not a nightly CSV.
Auto-CRUD REST
Every model you define gets an API with the same envelope and auth.
Instant everywhere
The table, the form and the API all change on save. No deploy.
What Doctor Portal plugs into
This is not a standalone product with an integrations page. The other portals are on the same engine, the same account and the same patient — so “integration” is mostly a word for something that already happened.
All ten sit on one patient, one staff directory and one audit trail.
Connect another and there is nothing to migrate, nothing to sync, and nobody retyping a name from one screen into another.
You see the patients you were given, and no others
A practitioner does not get a directory of everyone in the building. You see what your grants and the patient’s consent allow — and the server checks that on every request, not once at login.
Consent, then access
A platform-level patient shares with a facility. Your grants at that facility decide what you can read of it.
History that is not a folder
When a patient has connected to their lab and their pharmacy too, you read one timeline instead of interviewing them about it.
Answers that carry weight
In the community, your answer is flagged professional, marks the thread answered, and shows your organisation. A peer’s answer does not.
And the part that is genuinely uncomfortable to say out loud
The patient can revoke you. Their account is platform-level and they own it, so the moment they revoke, your view of them is empty — not archived, not pending a support ticket, empty. We think that is the right trade: providers who are chosen get people who arrive with their whole history, instead of a clipboard and a memory test.
How CareSewa One worksPeople get exactly what you grant. Nothing more.
A practitioner does not get the run of the building. Each facility that grants you access decides which portals you hold and which models you can touch — and the server re-checks that on every request, not once when you signed in.
Entitlements ride in the JWT and are enforced server-side. A portal you do not hold returns 403 no matter what the browser renders, and a revoked grant stops working on the next request rather than the next login.
- Grants are per portal and per model, not per role-shaped guess
- Create, read, update and delete are separate rights
- Enforced on the server on every request — hiding a menu is not security
- Revocation takes effect immediately, not at the end of a session
Priya Menon
Staff · created once, granted per portal
Portal grants
Doctor Portal
doctor.caresewa.com
Laboratory ERP
lab.caresewa.com
Pharmacy ERP
pharmacy.caresewa.com
These grants are claims in the token and are re-checked server-side on every request. The UI reflects them; it does not enforce them.
The rules are in the engine, not in a policy document
Doctor Portal does not implement its own idea of security. It inherits the platform's — which means these constraints hold on every request, in every portal, without anyone remembering to apply them.
Tenant isolation is structural
Every model definition and every record carries your tenant id, and every query filters by it. There is no code path that reads across tenants without an explicit super-admin assertion.
Every mutation is audit-logged
Who did what, when, and from where — appended on write, readable by your admins, and editable by nobody. Including us.
Clinical records are soft-deleted
Removing a field stops collection and display; it does not destroy what was already recorded. Medical data is not hard-deleted by default, and that default is deliberate.
Consent gates the patient, not a setting
A patient is visible to a provider because they connected and shared. No admin toggle, no bulk import and no support request produces access that the patient did not grant.
What people ask about Doctor Portal
If yours is not here, ask us directly — a real person answers.
Yes. Your schedule spans the facilities that have given you access, and the portal switcher moves you between them.
Connect Doctor Portal on its own, or alongside the other nine
Each portal is entitled and billed separately, so you pay for what you connect and nothing else. CareSewa is priced per market rather than from one figure in one currency.
Nine more, on the same account
Add any of these later without touching what you already run. One login, one patient, one audit trail.
See Doctor Portal shaped around your workflows
Not a generic demo tenant — practitioners, consultants, visiting specialists have their own protocols, and the point of this platform is that it takes them.
Multi-country by design · tenant-isolated · every change audit-logged