A clinic system that starts empty and becomes exactly yours
Lightweight management for single-doctor and multi-doctor practices. Start from a blank workspace and build the three or four models your practice actually uses.
What changes on day one
- Open in a day, not a quarter
- Model only what you use — nothing more
- Take bookings from CareSewa One patients
- Grow into labs and pharmacy without changing systems
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 Clinic ERP
The surfaces this ERP 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.
Start blank, on purpose
Clinic ERP ships with no default models. Most practices need four or five, so we let you name them instead of deleting ours.
Patient register
Define the register your practice keeps — the fields, the order, the required ones.
Visits & notes
Consult records shaped around your speciality rather than a generic template.
Appointments
Slots, walk-ins and a day view your front desk can run from.
Bookings inbox
Requests from CareSewa One patients arrive in a queue you confirm, reschedule or complete.
Grow into the suite
Add Pharmacy or Laboratory ERP later from the marketplace. Same account, same login.
It arrives completely empty. That is the feature.
Clinic ERP ships with no default models at all — and we are going to defend that rather than apologise for it.
Blank by design
A two-doctor dermatology practice and a twelve-doctor polyclinic both pick Clinic ERP, and they keep genuinely different registers. Any default we shipped would be wrong for one of them and probably both. So instead of handing you a deletion exercise, we hand you the builder.
Want a head start instead? Copy the default model set from Hospital ERP and cut it down to what you use. Both routes take minutes. Both end somewhere you chose.
Your first hour, roughly
- 01
Name your models
The three or four things you actually track. Not ours.
- 02
Add your fields
Eighteen types — text, select, date, relation, file and the rest.
- 03
Order the form
Drag it into the sequence your staff actually work in.
- 04
Open
The API, the table and the form exist the moment you save. There is no step five.
Change any of this yourself
Every field on every clinic 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 Clinic ERP 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.
Demand that arrives instead of demand you chase
A small practice does not have a marketing department. What it has, on CareSewa, is a listing patients can connect to and book against — with no reception phone ringing through a consult.
They find your practice
Patients search your public code or your published services in CareSewa One and request a connection.
Bookings land in a queue
Requests arrive as records you confirm, reschedule or complete — not as voicemail your front desk transcribes later.
They bring their history
A connected patient shares records from every other provider they use. Your first consult starts from context, not from zero.
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.
Staff are created once on your account, then granted specific portals and specific create, read, update and delete rights per model. A clinic receptionist and a clinic manager are the same directory entry with different grants — not two systems with two passwords.
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
Clinic ERP
clinic.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
Clinic ERP 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 Clinic ERP
If yours is not here, ask us directly — a real person answers.
Because a two-doctor dermatology practice and a twelve-doctor polyclinic need different registers. Defaults would be wrong for both, so we give you the builder instead.
Connect Clinic ERP 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 Clinic ERP shaped around your workflows
Not a generic demo tenant — single and multi-doctor practices, polyclinics, chains 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