Plug into the hospitals and patients already around you.
Labs, pharmacies, ambulance operators, blood banks, clinics — you are not small participants in someone else’s system. You are what the network is made of. Get an account, connect the systems you run, publish what you offer, and start taking demand from people who chose you.
Your data. Your models. Your prices. Disconnect anytime.
How a patient finds you
Your laboratory
tenantUniqueId · 7QK4M2XD
Your published offerings
Lab test
At your lab or at home
Health checkup
At your lab
The code is public and searchable. Everything behind it — your records, your staff, your stock — is not.
Four things you get that you cannot build alone
You already run a good operation. What you do not have is a way to be reachable by the people and providers three streets away — and that is not a problem more software solves. It is a problem a network solves.
Be findable
Patients search by your eight-character public code and connect directly. You stop depending on who happens to remember your name.
Get demand, not referrals
Bookings arrive from connected patients in a queue you control. It is demand from people who chose you, not leads sold to you.
Connect to the providers around you
Prescriptions arrive as data rather than photographs. Results return into the record instead of onto paper. The re-typing stops.
Run it your way
Your models, your fields, your status flows, your prices. The engine does not have an opinion about how your business works.
The lab does not know the hospital. That is the whole problem.
Every result printed, carried and retyped is a place a patient can be harmed and your work can be wasted. Connecting is not a growth tactic. It is the job.
A partner account is not a lesser account
There is no second-class “vendor” object in the system. Your account is a tenant — the same first-class thing a hospital group gets.
That has consequences worth spelling out. You get the same tenant isolation: every record carries your tenant, every query filters by it, and no other tenant reads your data. You get the same append-only audit trail on every mutation. You get the same marketplace. And you get the same rule that one account can own many ERPs — so if you run a lab today and open a pharmacy next year, that is a subscription, not a second company on a second platform with a second login.
- Your account is a tenant — isolated, audited, first-class
- One account owns many ERPs; each is entitled and billed on its own
- Each ERP is a portal, and each portal gets its own subdomain
- One staff directory and one login across everything you run
One account, many ERPs
Your account = one Tenant
tenantUniqueId · 8 characters
Laboratory ERP
lab.caresewa.com
Pharmacy ERP
pharmacy.caresewa.com
Diagnostics ERP
diagnostics.caresewa.com
Subscribe and the portal provisions, default models seed, and fresh tokens issue carrying the new entitlement. Disconnect and the entitlement goes the same way it came.
Eight characters is the whole introduction
Every tenant gets a tenantUniqueId — a short public code. It is the one thing about you that is deliberately searchable, and it is how a patient goes from hearing your name to being connected to you.
Public by design
The code is meant to be shared — printed on a report, on a card, on your door. Anyone can search it and find your public profile and the services you have published. That is its entire job.
Public code, private tenant
Knowing your code gets someone to your listing. It does not get them into your data. Your records, your staff, your stock and your patients sit behind tenant isolation that the code has no bearing on whatsoever.
Connection, not capture
A patient searching your code connects to you. Connecting is a relationship, not consent — they share separately, and they can revoke. You never quietly acquire a patient who did not choose you.
Add what you grow into. Drop what you stop.
Subscribing to an ERP is a self-serve act that takes effect immediately — not a contract negotiation followed by an implementation project.
When you subscribe from the marketplace, three things happen at once: the portal is provisioned, its default models are seeded where we have sensible ones, and fresh tokens are issued carrying the new entitlement — so the very next request you make can already reach it. There is no waiting period, no overnight job, no ticket.
And you can disconnect anytime. We are aware that a marketplace which is easy to leave is a marketplace that has to keep earning you. That is the arrangement we want.
What subscribing does
1Provisions the portal
It exists, on its own subdomain, immediately
2Seeds default models
A starting point — keep it, cut it down, or delete it
3Issues fresh tokens
Carrying the new entitlement, so the next request works
4And is reversible
Disconnect whenever. The entitlement leaves the same way
Publish what you actually do, at what you actually charge
There are 12 bookable care services on the platform. You publish the ones you provide — each with your own price, your own mode and your own note. Patients book them directly.
An offering is yours, not a listing we assign you
You choose the service, set your price, say whether it happens at your place, at the patient’s, or either, and add whatever note matters — prep instructions, turnaround, what to bring. Nothing is imposed and nothing is reordered by an algorithm deciding who deserves to be seen.
| Service | Mode | Price | Note |
|---|---|---|---|
| Lab test | At your lab or at home | yours to set | Fasting required for panels |
| Health checkup | At your lab | yours to set | Report within 24 hours |
| Vaccination | At your lab | yours to set | Bring prior records |
Prices resolve per market. CareSewa is multi-country, so a currency baked into the platform would be wrong in most of it — the amount is yours and it is settled where you operate.
The twelve services
Publish any that apply to you. Most partners publish two or three.
Three constraints that protect you as much as the patient
Marketplaces usually write their rules to protect the marketplace. These are enforced by the engine, they cut both ways, and they are the reason a booking on CareSewa means something.
An active connection is required
A patient cannot book you unless they are connected to you. No cold bookings from strangers routed by an algorithm, no leads you did not ask for. Every booking is from someone who chose you.
Protects you: You are never handed demand you did not agree to serve.
You must offer the service
A booking can only be created against a service you have published. If it is not in your offerings, it cannot land in your queue — the engine refuses to create it, rather than sending it and hoping.
Protects you: Nobody books you for something you do not do.
Status is forward-only
Booking status advances and never reverses. A completed booking cannot be quietly walked back to pending. Every transition is audit-logged with the actor and the timestamp.
Protects you: A disputed booking has a record, not two conflicting memories.
Notice what is absent. There is no ranking fee, no paid placement above your neighbours, no rule that lets us reroute a patient who was looking for you. The constraints are about making a booking mean what it says — and a booking that means what it says is worth more to a small operator than any promotion we could sell you.
A workspace per system, and a team you control precisely
Two practicalities that matter enormously on day one and are usually an afterthought.
Every ERP is a portal, and every portal has its own subdomain
Your lab team lives at the lab subdomain and your pharmacy team at the pharmacy one. Same account, same login, same staff directory — separate workspaces, so nobody is scrolling past a system they do not use to reach the one they do.
Staff get named grants, not “access”
Permissions are per portal and per model, with individual create, read, update and delete grants on each. A technician can update samples without ever being able to open billing — not because they are trusted not to, but because the grant does not exist.
- Per-portal and per-model create / read / update / delete grants
- Permissions read fresh from the database on every request
- Revocation takes effect on their next request — not when a token expires
- Every mutation is audit-logged with the actor, the before and the after
Someone leaves at 4pm. Their access ends at 4pm.
Everything that was yours before you joined
The oldest trick in platform software is to make joining easy and leaving expensive. We would rather say plainly what remains yours — because if the only thing keeping you here is the cost of leaving, we built the wrong product.
Your data
Your records live in your tenant. Every query filters by it, so no other tenant reads them — and every model you define exposes the same REST API our own apps use, so getting your data out is a capability, not a support ticket.
Your models
The fields, the relations, the validation, the status flows — you defined them, they describe your operation, and they are not a template we can change under you. Our defaults were only ever a starting point you were meant to throw away.
Your pricing
Each offering carries your price, your mode and your note. No imposed rate card, no floor, no algorithmic reordering of who gets seen. What you publish is what patients see.
Your exit
Disconnect a portal whenever you want. A marketplace you can leave is the only kind worth joining — if the only thing keeping you here is the cost of leaving, we have built the wrong product.
Six steps, and none of them involve us
No implementation project. No consultant on site. You configure it yourself, because the product was built to be configured by the person who understands the operation — which is you, not us.
Create your account
One account for the whole organisation becomes a tenant, with an eight-character public code. Minutes, not a procurement cycle.
Subscribe to the ERPs you run
Open the marketplace and connect what you operate — Laboratory, Pharmacy, Ambulance, Blood Bank and more.
Shape it to how you work
Open Studio. Keep the default models, cut them down, or build your own. Changes land on the next request — nothing to deploy.
Publish your offerings
Say which care services you provide, at your price, in your mode. Until you publish it, nobody can book it against you.
Bring your team in
Create staff with per-portal, per-model grants. Revoke someone and it takes effect on their next request.
Take your first booking
Patients connect from CareSewa One, book what you published, and carry the record away. Nobody re-types anything.
If you deliver a piece of care, this is your system
Every one of these runs on the same engine. Only the starting point — and the portal you subscribe to — differs.
What operators ask before they commit
Mostly about control, data and how hard it is to leave. All fair.
A tenant. There is no separate, lesser “partner” object in the system — a partner account is the same first-class tenant a hospital group gets, with the same isolation, the same audit trail and the same access to the marketplace. A single-vehicle ambulance operator and a four-hospital group are the same kind of thing to the engine. Only the portals they subscribe to differ.
Become a partner
Bring what you run. Keep what is yours. Start taking demand from the people already around you.
Multi-country by design · tenant-isolated · every change audit-logged