Ten systems that already know each other.
A hospital, a clinic, a dental practice, a lab, an imaging centre, a pharmacy, an ambulance fleet, a blood bank, a doctor and a patient. Ten workspaces, one account, one engine — and not a single re-entry between them.
One account. Ten systems. Zero seams.
Most healthcare software is sold as a product per building. So a group that runs a hospital, a lab and two pharmacies ends up with four vendors, four logins, four patient databases and one very tired person reconciling them.
CareSewa inverts that. An account is the unit — your organisation — and an ERP is a portal it owns. Own one, own all ten; the boundary between them is an entitlement in your token, not a different piece of software with a different idea of who your patients are.
- Subscribe from a marketplace — no procurement cycle per system
- Switch portals from one login, in one dropdown
- The same patient, staff and audit trail underneath every one
- Add the ninth ERP without touching the first eight
Four kinds of participant. One network.
Care is not delivered by one type of organisation. It is delivered by places, by the services those places depend on, by the practitioners inside them, and for the people at the end of it. The suite is shaped the same way.
Facilities
03Places where care is delivered.
Hospital ERP
Multi-department hospitals and hospital groups
Run the whole hospital from one system that bends to your protocols
Explore HospitalClinic ERP
Single and multi-doctor practices, polyclinics, chains
A clinic system that starts empty and becomes exactly yours
Explore ClinicDental ERP
Dental practices, orthodontists, dental chains
Dental practice management modelled on how you actually chart
Explore DentalServices
05The systems care depends on.
Laboratory ERP
Diagnostic laboratories, hospital labs, collection networks
From order to report, on your own test catalog
Explore LabDiagnostics & Imaging ERP
Imaging centres, radiology departments, diagnostic chains
Radiology and imaging, scheduled around your modalities
Explore DiagnosticsPharmacy ERP
Retail pharmacies, hospital pharmacies, chains
Stock, dispensing and expiry — without the spreadsheet
Explore PharmacyAmbulance ERP
Ambulance operators, hospital fleets, emergency networks
Dispatch that knows where every vehicle is
Explore AmbulanceBlood Bank ERP
Blood banks, hospital blood services, donor networks
Units, donors and requests — visible the moment they matter
Explore Blood BankPractitioners
01The people who deliver it.
People
01The people it is for.
The whole suite, on one line each
Ten ERPs, who each one is for, whether it arrives seeded or blank, and the address it answers on.
| ERP | Who it is for | Ships with defaults | Subdomain |
|---|---|---|---|
| Hospital ERP | Multi-department hospitals and hospital groups | 7 models, all editable | hospital.caresewa.com |
| Clinic ERP | Single and multi-doctor practices, polyclinics, chains | Blank, on purpose | clinic.caresewa.com |
| Dental ERP | Dental practices, orthodontists, dental chains | Blank, on purpose | dental.caresewa.com |
| Laboratory ERP | Diagnostic laboratories, hospital labs, collection networks | 5 models, all editable | lab.caresewa.com |
| Diagnostics & Imaging ERP | Imaging centres, radiology departments, diagnostic chains | Blank, on purpose | diagnostics.caresewa.com |
| Pharmacy ERP | Retail pharmacies, hospital pharmacies, chains | 5 models, all editable | pharmacy.caresewa.com |
| Ambulance ERP | Ambulance operators, hospital fleets, emergency networks | 4 models, all editable | ambulance.caresewa.com |
| Blood Bank ERP | Blood banks, hospital blood services, donor networks | 4 models, all editable | bloodbank.caresewa.com |
| Doctor Portal | Practitioners, consultants, visiting specialists | 4 models, all editable | doctor.caresewa.com |
| Patient Portal | Patients of connected facilities | 4 models, all editable | patient.caresewa.com |
Every default model is editable, renameable and deletable from day one. Nothing in this table is a lock-in.
Connecting an ERP takes a click, not a quarter
There is no implementation project between deciding you need a pharmacy system and having one. Subscribing is the provisioning.
Browse the marketplace
Every ERP is listed against your account — what it is, who runs it, seeded or blank. Nothing behind a sales call.
Connect the one you run
Subscribing provisions the portal against your tenant and claims its subdomain — models seeded in the same step.
A fresh token is issued
Entitlements live in the JWT, reissued the moment it lands. The new portal appears in the switcher, no logout.
The server enforces it
Every request to a portal you are not entitled to fails with 403. Hiding a menu item is not security.
Disconnect whenever
Removing the entitlement closes the portal on the next request. Your definitions and records stay intact.
What a portal you are not entitled to looks like
Entitlements are claims in the JWT, and every route re-checks them against the token on the server. The browser can render whatever it likes; the API is the one that decides.
GET /api/v1/pharmacy/records/medicine 403 Forbidden { "error": { "code": "PORTAL_NOT_ENTITLED", "portal": "pharmacy" } }
Three of the ten arrive completely empty
Not because we ran out of time. Because for these three, any default we shipped would be wrong for most of the people who chose them.
Blank by design
A two-doctor dermatology practice, a twelve-doctor polyclinic and an orthodontist all pick the same ERP and need entirely different registers. A vendor who ships defaults for that is really shipping a deletion exercise — you spend your first week removing fields you never wanted, and you keep the three you did not notice.
So for clinic, dental and diagnostics we hand you the builder and an empty workspace instead. Name your models. Add your fields. You will be taking patients the same week — and the register will be yours, not a residue of someone else’s assumptions.
Prefer a head start? Copy the default model set from Hospital ERP and cut it down. Both routes take minutes, and both end somewhere you chose.
Arrives seeded · 7 of 10
The other seven provision with default models because their shape is genuinely common — a lab has tests, orders and samples wherever it is. Those defaults are a starting point, not a contract: rename them, gut them, or throw them away entirely on day one.
Ten portals sitting on one spine
The reason this is an ecosystem and not a bundle: the things underneath the ten workspaces are singular. There is one of each, and every ERP reads the same one.
One patient, not one per system
The patient holds their own account at platform level. Connect them to your hospital and your lab and it is the same person, the same Health ID, the same record — not two registrations that will drift apart by the second visit.
One staff directory
A nurse is created once on your account, then granted the portals and the per-model rights she should hold. Onboarding is a grant, not a new account in a new system with a new password.
One audit trail
Every mutation in every ERP writes the same append-only record: who, what, when, from where. An investigation reads one log, not ten exports in nine formats.
One engine, one Studio
Eighteen field types and one model builder across the whole suite. Learn Studio for your clinic and you already know how to reshape your pharmacy.
One API shape
Every model you define in any portal gets auto-CRUD REST with the same envelope and the same auth. An integration written against one ERP reads like an integration against all of them.
One tenant boundary
Every definition and every record carries your tenant id, and every query filters by it. Ten portals do not mean ten places for that rule to be forgotten.
The dropdown that replaces four logins
When your account owns more than one ERP, a switcher appears in the header. It lists exactly the portals your token entitles you to — which for most staff is fewer than the account owns, and that is correct.
Picking one moves you to that portal’s subdomain with the same session. No second password, no re-entering the patient you were just looking at, no wondering which tab has the lab in it.
- Lists only the portals in your token — not the ones your account owns
- A newly connected ERP appears without a logout, because the token is reissued
- A revoked grant disappears on the next request, not the next login
- Each portal keeps its own subdomain, so bookmarks and links stay meaningful
Your portals · 3 of 10
Hospital ERP
hospital.caresewa.com
Laboratory ERP
lab.caresewa.com
Pharmacy ERP
pharmacy.caresewa.com
Browse the marketplace
Rahul is entitled to three portals. His account owns more — his token does not.
Every one of these is a starting point, not a specification
Read any of the ten pages and you will see a list of models and features. Treat all of it as a first draft. The engine defines models at runtime — a field is a database record, not a line of code — so the system you run in month six is the one you shaped, not the one we shipped.
18
field types
text to relation to file
10
connected ERPs
one account, one login
0
lines of code
to add a model
0
migrations
to change one
You pay for the ERPs you connect. Nothing else.
Each portal is entitled and billed on its own, so a single clinic is priced like a single clinic. CareSewa is priced per market rather than from one figure in one currency — because a number that is right in one country is wrong in the next.
What people ask before they connect the first one
The mechanics of owning ten systems on one account, answered plainly.
No. They are ten starting points on one engine. Every ERP uses the same model definitions, the same auth, the same audit trail and the same patient identity — what differs is the workspace you land in, the default models it provisions with, and the subdomain it answers on. That is why moving between them costs you nothing and why data does not need to be copied between them.
Start with the one you run today
Connect a single ERP, shape it to your protocols, and add the rest when you are ready. Nothing about the first one has to change for the ninth to work.
Multi-country by design · tenant-isolated · every change audit-logged