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. In data-protection terms, the provider is generally the controller of the clinical data they record, and CareSewa is the processor that operates the system it lives in on their behalf. For the platform-level patient account and the data the patient themselves enters, CareSewa is the controller.

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.

How long we keep things. We keep personal data for as long as your account is open and for as long as we need it to provide the Services. When you close a patient account, we delete or irreversibly anonymise the personal data associated with it within 90 days — except where a provider or the law requires certain clinical records to be kept for longer (medical records commonly carry statutory retention periods), and except for the minimum needed in our append-only audit trail to keep that record trustworthy. Backups are on a rolling cycle and are overwritten within 30 days, so deleted data ages out of backups shortly after it leaves the live system. Where a provider is the party responsible for a clinical record, that provider’s own retention obligations also apply to their copy.

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.

Where data lives today. The production platform runs on cloud infrastructure hosted in the Asia-Pacific region — primarily data centres in India (Mumbai) — with our database and file storage located there. If we ever move your account to a different region, this section is where we will say so.

Because CareSewa is used across more than one country, data may be processed in a country other than the one you are in — for example where a provider operates in one country and a patient connects from another. When personal data moves across a border, we rely on the recipient being bound by confidentiality and security terms at least equivalent to those in this policy, and we do not transfer data to a party who will not accept them.

Like any production system, CareSewa depends on a small number of infrastructure and service providers to run. They act as our processors: they handle data only to provide their service to us, under contract, and never for their own purposes. They are:

Cloud hosting & storage — Amazon Web Services (compute) and MongoDB Atlas (database), which is where the platform and its records run; and Amazon S3 for uploaded files such as records and documents, stored privately. Push notifications — Expo, together with Apple Push Notification service (iOS) and Firebase Cloud Messaging (Android), used only to deliver the notifications you have enabled. Email — our transactional email provider, used to send login codes and service messages.

We share data with a provider you connect to only after you explicitly share it, and with our processors above. We may also disclose data where the law requires it, or to protect the rights and safety of our users. We do not sell personal data, we do not sell access to it, and we do not share it with advertisers or data brokers.

Subject to your local law, you have the right to access the personal data we hold about you, to correct it, to delete it, to object to or restrict certain processing, and to obtain a copy in a portable form. To exercise any of these, email info@caresewa.com and we will respond within the timeframe your law requires, and within 30 days at most. We will not charge you for a reasonable request or penalise you for making one. What follows is how the platform already puts these rights in your hands directly.

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.

Delete your account. In CareSewa One, go to Profile → Settings → Delete account to close your account and remove your personal data, subject to the limits in the retention section (clinical records a provider must keep by law, and the minimum needed in the audit trail). The short version is that medical data is not casually destroyed, but closing your account is a button you hold, not a favour you request.

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 sends the name, email and message you enter to our contact inbox so a person can reply. If that send fails, the form hands the same message back to you pre-composed as amailto:link so nothing is lost. We hold what you send only to answer it, and we do not feed it into a marketing sequence.

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.

CareSewa One is intended for adults (18 and over). It is not directed at children, and we do not knowingly let a child create their own account. If you believe a child has created an account directly, contact us and we will remove it.

Children still receive care, so the app lets an adult manage family members — including children and dependent adults — as profiles under their own account. When you add a family member, you are telling us you are their parent, guardian, or otherwise authorised to manage their health information and to consent on their behalf; you are responsible for what you record and share about them. A dependent’s data is held under the same isolation, consent and audit rules as any other, and a provider sees it only when you connect and share it. You can remove a family member, and their data, from your account at any time.

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.

We will update this policy as the platform and the law evolve. The last-updated date at the top of this page always reflects the current text.

Where a change materially affects how your data is handled, we will do more than silently move that date — we will tell you, through the app or by email, before the change takes effect.