Terms of Service

These terms describe the arrangement between CareSewa and the people who use it. There are two very different kinds of user and this draft keeps them apart, because conflating them is how terms become unreadable.

Providers — hospitals, clinics, dental practices, laboratories, diagnostics centres, pharmacies, ambulance operators, blood banks and practitioners — hold a tenant account and subscribe to the portals they run.

Patients hold a platform-level account that belongs to them, use CareSewa One and the Patient Portal, and connect to providers of their own choosing.

Where a section applies to only one of them, it says so. Where it applies to both, it is written to be read by both.

A provider account is a tenant. There is no second-class “vendor” object in the system — a single-vehicle ambulance operator and a four-hospital group are the same kind of thing to the engine, with the same isolation, the same audit trail and the same marketplace access. One account can own one portal or all ten, each entitled on its own.

Every tenant is issued an eight-character public code (a tenantUniqueId). It is deliberately public and searchable — that is how patients find you. It gets someone to your listing; it does not get them into your data.

A patient account belongs to the patient. Not to a hospital, not to the clinic that registered them, not to us. It is created by the patient and it survives them changing providers entirely. A provider does not acquire a patient account by treating the patient, by registering them at a front desk, or by paying us.

You are responsible for your credentials and for what is done under your account. Providers are responsible for the staff they create and the grants they give them — the platform enforces the grants precisely; it cannot decide who deserves them.

Portals are subscribed to from the marketplace. Subscribing provisions the portal, seeds its default models where sensible defaults exist, and issues fresh tokens carrying the new entitlement — so the next request you make can already reach it. There is no implementation project between you and a working system.

Entitlement is enforced, not merely recorded. Which portals your account may reach is carried in your token and asserted on every record operation. A request for a portal you have not subscribed to is refused with a named error rather than answered with a filtered result.

You can disconnect a portal at any time. The entitlement leaves the same way it arrived. A marketplace that is easy to 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.

Fees, billing cycles, taxes and what happens on non-payment are commercial terms this draft does not attempt to state, because they resolve per market — CareSewa is multi-country and a figure written into a template here would be wrong in most of it. See pricing for the plan structure, and expect the reviewed version of this document to carry the commercial detail.

Your models are yours. 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 seeded defaults were a starting point you were always meant to throw away; three of the ten portals ship with none at all for exactly that reason.

Your records are yours. They live in your tenant, every query filters by it, and no other tenant reads them. Every model you define exposes a REST API with the same auth as everything else, which means getting your own data out is a capability you already hold rather than a favour to request from support.

Your pricing is yours. Each service you publish carries your price, your mode and your note. We do not impose a rate card, do not set a floor, and do not reorder who gets seen based on what they pay us.

We need a limited operational licence to your content in order to run the platform at all — to store it, transmit it, back it up, and show it to the people you have authorised to see it. Precisely scoping that licence is legal drafting this document has not yet had. What we can commit to plainly: it exists to operate the service you asked for, and it is not a licence to sell your data or to use your clinical records for anything you did not ask for.

Providers should read this section as a description of a constraint, not an appeal to good behaviour, because it is enforced by the engine.

A provider sees nothing about a patient until that patient connects and explicitly shares. Connection alone is a relationship, not access. Revocation hides everything from that provider immediately.

The cost of this to providers is real and we state it rather than hide it: you cannot quietly accumulate a patient population you have no relationship with. That is not a defect we intend to fix. The compensating benefit is that every patient in your system chose to be there, and their records arrive complete from every provider they use.

Attempting to work around the consent model — by pressuring patients into sharing, by misrepresenting what sharing means, or by any technical means — is a misuse of the platform, not a clever growth tactic.

Three constraints govern every booking, and they cut both ways.

An active connection is required. A patient cannot book a provider they are not connected to. No cold bookings routed by an algorithm; no leads you did not ask for.

The provider must offer the service. A booking can only be created against a service the provider has actually published. If it is not in your offerings, it cannot be created against you — the engine refuses rather than sending it and hoping.

Status is forward-only. Booking status advances and never reverses. A completed booking cannot be walked back to pending to make a report look better, and every transition is audit-logged with the actor and timestamp.

What a booking is, and is not: it is a request to a provider for a service that provider publishes. The care itself is delivered by the provider, under their clinical judgement and their professional obligations. Cancellation, rescheduling and refund terms are between the patient and the provider, and CareSewa does not overrule a provider’s clinical decision about a booking.

Do not:

Attempt to reach data belonging to another tenant, or to circumvent tenant isolation, entitlement checks, staff permission grants or the consent model. Every attempt is audit-logged; the trail records the actor, the IP and the timestamp whether the attempt succeeded or not.

Use another person’s credentials, share credentials between staff, or continue using an account you know should have been revoked.

Attempt to defeat the rate limits or pagination caps, or to extract data at a volume the API was plainly not offered to you for.

Impersonate a clinician or an organisation, publish offerings you do not provide, or misrepresent verification status in the community.

Use the platform for anything unlawful in the jurisdiction you operate in — including recording, in models you defined, data you have no lawful basis to hold. The engine lets you define any field you like. That is a capability, not permission.

Security research is welcome and is not what this section is about. Report what you find through the process on the security page, give us a window to fix it, and please do not test against real tenants or real patient data.

This section matters more than any other on this page, so it is written plainly rather than in capitals.

CareSewa is software. It does not practise medicine. Care is delivered by the providers you connect to, under their own clinical judgement, their own licensing and their own professional obligations. We operate the system their records live in. We are not a party to your treatment and we do not review, verify or endorse the clinical decisions a provider makes.

Nothing on the platform — including community answers, including answers marked as coming from a verified clinician — is a substitute for a consultation with a doctor who has examined you. A verified badge means the answer came from a clinician account and shows their organisation. It does not mean the answer is right for you, and it does not create a doctor-patient relationship.

In an emergency, contact your local emergency services. Do not use an app, a booking form, or a web page. The ambulance functionality on this platform is a tool operators use to run their fleets; it is not, and must not be treated as, a substitute for an emergency number.

We aim to keep the platform running and we are not going to print an uptime figure in a template document to sound confident. Where a service commitment is contractually agreed with a provider, that agreement governs — not this paragraph.

The platform changes continuously by design. Schema changes take effect on the next request and the mobile apps update over the air, which is the point: the gap between “this should change” and “it has changed” is meant to be an afternoon, not a quarter.

Roadmap items are roadmap items. Deeper health features, family accounts, reminders, a provider-side booking UI and broader billing are described on our about page as planned rather than delivered. Do not contract on the basis of something we have labelled as not shipped, and if a salesperson ever tells you otherwise, this sentence overrules them.

The full account is in the Privacy Policy, which is a draft carrying the same notice as this one. The parts that matter as terms:

Medical records are soft-deleted rather than destroyed. Removing a field from a model stops collecting it; it does not erase what was already recorded. Every mutation is audit-logged with actor, tenant, action, resource, before, after, IP, user agent and timestamp, and that trail is append-only — nobody edits it, including us.

The platform is deployable per region and assumes no single country. That is an architectural capability, not a certified guarantee about where your account’s data resides today. Confirm residency for your deployment with us directly.

Providers can disconnect a portal at any time, or close an account. Before you do, take your data — the REST API on every model you defined is how, and it is already available to you.

Patients can revoke any provider’s access at any time without closing anything, and closing a patient account is the patient’s decision to make, since the account is theirs.

We may suspend an account for the reasons in the acceptable use section — principally attempts to reach other tenants’ data or to circumvent the consent model. Where we do, we will say why.

The interaction between account closure, medical records a provider is legally required to retain, and the append-only audit trail is genuinely complicated, and it is one of the specific things this draft is waiting on review to state accurately. It will be stated, rather than left to be discovered.

Every terms document has a section here in which a company disclaims as much as it can. Ours will too, when it has been drafted by someone qualified to draft it. Writing a limitation of liability into a template and letting you believe it had been reviewed would be worse than leaving this honest.

So, plainly, and pending that review: the specific warranties, disclaimers, liability caps and indemnities that will govern a commercial relationship with CareSewa are not stated in this document, and this document does not create them. If you are evaluating CareSewa and need to know where that stands before you can proceed, ask us — you will get the real position rather than a page.

One thing that is true regardless of drafting: no security architecture makes a system invulnerable. Everything described on our security page narrows what can go wrong and makes what did go wrong legible. Neither is the same as “nothing can go wrong”, and that page contains an explicit section on what we do not claim — including that we hold no compliance certification.

This is the section a template document is least able to fake. CareSewa is multi-country by design: the platform assumes no single national market, and neither can its terms. Naming a jurisdiction here because the shape of the document expects one would be inventing a fact.

Governing law, jurisdiction and dispute resolution will be stated in the reviewed version, and will depend on where you are and where your deployment runs. Until then, they are a conversation, not a paragraph.

This document will change, and the most significant change ahead of it is the one in the notice at the top: a reviewed, jurisdiction-specific version replacing this draft entirely.

The last-updated date reflects the current text. Where a change materially affects the arrangement, we will do more than silently move that date.