Privacy Policy

CareSewa (“CareSewa”, “we”, “us”) operates a healthcare platform used by two very different kinds of people, and this policy has to be honest about the difference, because our obligations differ.

Patients hold a platform-level account that belongs to them. For that account and the records within it, CareSewa is the party responsible for holding the data and for enforcing the patient’s choices about who sees it.

Providers — hospitals, clinics, dental practices, laboratories, diagnostics centres, pharmacies, ambulance operators and blood banks — hold a tenant account. They decide what clinical data they record about the people they treat, in models they define themselves. For that data, the provider makes the decisions and CareSewa operates the system it lives in. Where the two roles are usually named “controller” and “processor”, we have deliberately avoided those terms in this draft rather than use them loosely: the precise allocation is exactly the kind of thing that needs the legal review this document has not yet had.

Visitors to this website are a third, much simpler case, covered in the section on this site below.

This is the single most important statement in this document, and everything else follows from it.

Patient accounts are platform-level and belong to the patient. They are not owned by a hospital. Not by the clinic that first registered the person. Not by the provider who paid for a subscription. Not by us. A patient creates their own account and their own Health ID, and they keep it when they change providers, change cities, or stop using a provider entirely.

The practical consequence is that a provider sees nothing about a patient until that patient connects to them and explicitly shares. Filling in a form at a front desk does not grant a provider access to a patient’s platform account. Neither does treating them. Neither does paying us. Access exists because the patient granted it, and for no other reason.

Consent on CareSewa is three distinct acts, and keeping them distinct is the point.

Connect. A patient chooses a provider — typically by searching their eight-character public code — and connects to them. A connection is a relationship. It is not, by itself, access to the patient’s records.

Share. Sharing is a separate and explicit act. Until the patient shares, the connected provider does not see the profile. Nothing is shared by implication, by default, or because a checkbox was pre-ticked somewhere.

Revoke. A patient can revoke at any time, from their own account, without asking the provider and without contacting us. Revoking hides everything from that provider immediately — not on next sync, not at the end of a billing period, not after a support request.

One honest limit, stated rather than buried: revocation controls what a provider can see through CareSewa going forward. It cannot reach into a copy a provider lawfully made and holds in their own records, nor undo what a clinician has already read. Clinical records that a provider is required by law to retain remain the provider’s to retain. We are describing an access control that works, not a memory-erasing device that does not exist.

Account data. What is needed to have an account and be reachable: identity details, contact details, credentials in hashed form, and the settings and preferences you choose. For providers, this includes the organisation record and its public code.

Clinical and operational records. Here we have to be more careful than most policies are, because of how the platform works. CareSewa does not hard-code a fixed patient model. Providers define their own models at runtime — their own fields, across the platform’s field types, with their own relations and validation. So the specific clinical data recorded about a person is determined by the provider treating them, not by a schema we shipped. What we can tell you precisely is how it is held: every record carries a tenant, every query filters by it, and every write is validated against the model it targets.

Connection and consent state. Which providers a patient has connected to, what has been shared, and what has been revoked. This is the state the access control reads, so it must be recorded.

Bookings and service activity. Bookings made against providers, the services involved, and status as it advances.

Audit data. Every mutation writes an entry: the actor, the tenant, the action, the resource, the state before, the state after, the IP address, the user agent and the timestamp. This includes an IP address and a user agent, which are personal data — we would rather say so here than let you find it in the audit section.

Technical operating data. The logs and telemetry any production system needs in order to run, be debugged, and be defended against abuse.

To operate the platform: to authenticate you, to enforce entitlements and permissions, to store and return the records you and your providers create, to make bookings work, and to keep the whole thing running, debuggable and defended against abuse.

To enforce the rules described on this page: consent state exists so it can gate access; audit entries exist so a mutation can be attributed; tenant identifiers exist so a query can be scoped. These are not secondary uses. They are the mechanism.

To communicate about the service, including security notifications, which are not optional in the way marketing communications are.

Not to sell your data. Not to sell access to it. Not to build advertising profiles from medical records. Not to rank providers by what they pay us. If any of that ever changes, it will change here first and loudly, not quietly in a paragraph nobody reads.

Every ModelDefinition and every DynamicRecord on the platform carries a tenant identifier, and every query filters by it. There is no implicit cross-tenant read. Relations are constrained the same way: a record can only reference records within the same tenant, so a link that leaks across tenants cannot be constructed in the first place.

Super-admin access across tenants exists — a platform this size cannot be operated without it — but it is explicit rather than implicit, and it is audit-logged like every other action. We would rather tell you that it exists and is recorded than imply that nobody at CareSewa can ever reach anything.

The practical meaning for a patient: one provider you connected to cannot see what another provider recorded. Your record travels with you because you carry it, not because your providers can read each other’s systems.

The full architecture is described, at length, on the security page, including an explicit section on what we do not claim.

Two separate identities. Tenant users and patients authenticate as different kinds of identity with different tokens. A patient token presented on a tenant route is rejected, and a tenant token presented on a patient route is rejected. They meet only where the patient has consented.

Short-lived access tokens. Access tokens are JWTs with a short time-to-live, exchanged via longer-lived refresh tokens, so the credential that lives longest is the one used least.

Portal entitlements. Which portals an account may reach is carried in the token and asserted on every record operation. An unentitled request is refused with a named error rather than answered with a filtered result.

Staff permissions, read fresh. Within a provider, staff hold per-portal and per-model create, read, update and delete grants. Those grants are read from the database on every request rather than trusted from whatever was baked into a token at login — which is why revocation takes effect on the very next request rather than whenever a session happens to end.

API hardening. Requests are rate limited. Pagination defaults to 20 records and is hard-capped at 100, so there is no call that returns everything. Standard security headers are applied and cross-origin access is restricted.

Deleting a medical record marks it deleted and removes it from view. It is not hard-deleted by default. This is deliberate: in a clinical system, an accidental deletion at a busy front desk is a patient safety problem, and an audit trail that points at a record which no longer exists is not an audit trail.

Removing a field from a model stops that field being collected and displayed. It does not erase the values already recorded against existing records. A protocol changing in March does not mean February’s observations were never made, and a system in which a dropdown edit could rewrite clinical history would not be one you should put patients into.

Where genuine erasure is required — and in some jurisdictions and circumstances it is — that is a deliberate, privileged operation rather than the thing that happens when someone clicks the wrong row. If you need data genuinely destroyed, that is a request to make of us and of your provider, not a button we hide behind a menu.

Retention periods are one of the things this draft cannot responsibly state yet, because the honest answer depends on the jurisdiction and on what your provider is legally required to keep. A reviewed version will be specific. We would rather leave this paragraph visibly incomplete than fill it with a number we invented.

Every create, update and delete on the platform writes an audit entry recording the actor, the tenant, the action, the resource, the state before the change, the state after it, the IP address, the user agent and the timestamp.

The trail is append-only. There is no update path and no delete path on it. Administrators can read it; nobody edits it, and that includes us. An audit trail that can be tidied up afterwards is a diary.

This means the audit trail itself contains personal data — including IP addresses and, by definition, before-and-after states of records. It is subject to the same tenant isolation as everything else. It also means that a request to erase data has to reckon with the trail, which is another reason erasure is a deliberate operation rather than a button.

CareSewa is Asia-first, which for this section means something concrete rather than aspirational: nothing in the architecture assumes a single country, a single identifier scheme, a single currency, or a single regulatory regime. The stack is deployable per region, and tenant isolation holds identically wherever a deployment lives.

Read that precisely, because the distinction matters. It describes an architectural capability. It is not a certified guarantee about where your specific tenant’s data resides today, and it is not a legal opinion about what your local law requires. Which region an account runs in is a deployment matter to confirm with us directly, for your account, rather than to infer from a web page.

Where data moves across borders — because a provider operates in one country and a patient connects from another, for instance — the applicable safeguards are exactly the kind of question this draft cannot answer responsibly before review. It will be answered specifically in the reviewed version.

Like any production system, CareSewa depends on infrastructure and service providers to run — hosting, storage, delivery of messages, and the operational tooling required to keep a platform up and defended.

We are not going to publish an invented list of vendor names in a template document. The reviewed version will name them, state what each one processes, and say where. Until then, if you need to know who is in the chain before you can make a decision, ask us and you will be told rather than pointed back at this page.

What we can say now without qualification: we do not sell personal data, we do not sell access to it, and we do not share it with advertisers or data brokers.

The specific rights you have — and the exact process and timeframe for exercising them — depend on where you are, and enumerating them accurately is precisely the work this draft is waiting on. What follows is what the platform already does, which is a better guide to reality than a list of statutes copied from another company’s policy.

Control over provider access. A patient can see which providers are connected, what has been shared, and revoke any of it themselves, at any time, without asking anyone. This is not a rights request. It is a button, and it takes effect immediately.

Access to your data. Records are visible to the patient in CareSewa One and in the Patient Portal. For providers, every model you define exposes a REST API with the same auth as everything else, so getting your own data out is a capability you already hold rather than a favour you have to request.

Correction. Correcting a clinical record is a request to the provider who recorded it, because they are responsible for its accuracy. The correction is audit-logged, with the before and the after.

Erasure. See the retention section. The short version is that medical data is not casually destroyed, that some of it a provider is legally required to keep, and that genuine erasure is a deliberate request rather than a hidden button.

Complaint. If you think we have got any of this wrong, tell us. Where you also have a right to complain to a supervisory authority, that right is not affected by telling us first.

This marketing site is a much smaller story than the platform, and it is worth separating so it is not lost in the above.

The contact form on this site is not connected to a backend. Submitting it validates your input in your browser and composes a message for you to send from your own mail client. Nothing is transmitted to us from that page on its own — which is stated on the page itself, before you type, rather than discovered here afterwards.

There is no advertising tracker on this site, no lead-scoring pixel, and no newsletter you can be opted into by a hidden checkbox. When you do write to us, we hold what you sent us in order to reply to it, and we do not feed it into a nurture sequence.

Children receive care, so a healthcare platform that pretended otherwise would be useless. Today, a child’s clinical records exist the same way any patient’s do: recorded by a provider, in models that provider defined, under the same isolation and audit rules.

Family accounts — one adult formally managing care for children or parents — are on our roadmap and are not shipped. We are stating that plainly here because the age and guardianship rules that attach to a family account are significant, and drafting them before the feature exists would be writing fiction. The reviewed version of this policy will cover it when it is real.

The controls that protect this data are described in full on the security page, which also contains an explicit section on what we do not claim — including that we hold no compliance certification and that architectural controls are not the same thing as certification. That section is worth reading before this one.

No architecture makes a system invulnerable. What the controls above do is narrow what can go wrong and make what did go wrong legible afterwards — the audit trail is precisely what lets us say who was affected rather than guess. If an incident affects your data, the affected parties hear from us.

If you have found a vulnerability, please report it. The process is on the security page, and it routes to people who can act on it rather than to a sales queue.

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

The last-updated date at the top of this page reflects the current text. Where a change materially affects how your data is handled, we will do more than silently move that date.