Privacy Policy

Who we are

Demed ("Demed," "we," "us") is a product of Demed Technologies. Demed is an infectious-disease clinical decision-support tool used by physicians and hospital staff — during the pilot phase, deployed under agreement with each participating hospital or research organization. This policy describes how we collect, use, and protect information across the Demed web application (app.demed.in) and this marketing site (demed.in).

What we collect

Account information: When a clinician signs up: name, email address, and hospital/organization membership, handled by our authentication provider, Clerk.
Clinical case data: Entered by clinicians in the course of using Demed: patient MRN, age, sex, ward, allergies, comorbidities, active medications, infection details, lab values, and the recommendations Demed generates along with each clinician’s accept/modify/reject decision. This is entered by hospital staff, not by patients directly, and belongs to the hospital that entered it.
Usage analytics: Product usage (e.g. which screens are used, feature adoption) tracked via PostHog. This is configured to never receive clinical content — no patient identifiers, drug names, or case details are ever sent as event data, and automatic click/text capture is off. Only a user’s Clerk account and organization ID are attached to analytics events, not their name or email.
Support and feedback: Anything you send us directly — a support email, or an in-app feedback rating and message.

How we use it

Clinical case data is used solely to generate and display recommendations within the hospital's own Demed workspace — it is never used to train models, sold, or shared with any other hospital or organization using Demed. Account information is used for authentication and to route you to your hospital's workspace. Analytics are used only to understand product usage and improve the application..

How AI is involved

Demed uses Anthropic's Claude models, accessed through AWS Bedrock, to help synthesize guideline text into a recommendation and to read lab report photos. Any clinical case data sent to Bedrock for this purpose is processed only to generate that response and is not used by AWS or Anthropic to train their models. Deterministic calculations that matter most for safety — renal dosing, allergy cross-reactivity blocking, clinical severity scores — are computed by plain code, never by AI, and every AI-assisted recommendation still requires a physician's own review and confirmation before it takes effect..

Subprocessors — who else touches this data

We use the following infrastructure and service providers to run Demed. Each is used only for the purpose below, under its own data processing terms:.

AWS (Bedrock, Transcribe, S3): AI-assisted recommendation generation, lab report and voice transcription, file storage. Data residency: ap-south-1 (Mumbai).
Supabase (PostgreSQL): Primary database. Every table enforces row-level tenant isolation, so one hospital’s data is never visible to another, even within our own infrastructure.
Clerk: Authentication and account/organization management.
Railway: Backend application hosting.
Netlify: Frontend and marketing site hosting.
Resend: Transactional email (e.g. lab-upload completion notices).
PostHog: Product usage analytics — configured to never receive clinical content (see above).
Sentry: Error monitoring. Configured to automatically redact patient names, MRNs, dates of birth, phone numbers, and email addresses before any error report is sent.

Your rights under DPDP

Demed builds technical support for rights under India's Digital Personal Data Protection Act (DPDP) directly into the product, as a first-class feature rather than an afterthought:.

Access: A full export of a patient’s record — episodes, labs, recommendations, and consent history — can be generated on request.
Erasure: A patient record can be de-identified in place (identifying fields replaced) while preserving the clinical audit trail, where a case needs to be retained for audit purposes without identifying information attached.
Consent: Consent capture is a built-in, versioned record tied to each patient or clinician, not an assumption.

Exactly how these map to your hospital's own consent process, and what counts as sufficient legal basis for a given use, is a determination made jointly with each hospital's own data protection process during pilot onboarding — this policy describes the technical capability, not a substitute for that agreement.

Data retention

Clinical case data is retained for as long as the hospital's agreement with Demed is active, plus whatever period that agreement or applicable law requires for audit purposes. Every write to clinical data is captured in an immutable audit log regardless of later edits or de-identification, so the record of what happened and when is never lost even as identifying details can be removed. Specific retention terms are set per hospital agreement, not by a single global default..

How we protect it

Encryption in transit: All traffic to and from Demed is served over HTTPS.
Tenant isolation: Enforced at the database level (PostgreSQL row-level security), not just in application code — one hospital’s data cannot be queried by another, even in the event of an application bug.
Audit trail: Every clinical write is logged immutably: who, what, and when.
Least-privilege access: The application connects to the database as a restricted role with no ability to bypass tenant isolation.

Cookies and local storage

Demed uses cookies for authentication (via Clerk) to keep you signed in, and local storage for analytics (PostHog) and onboarding-progress state. We don't use third-party advertising cookies or trackers..

Changes to this policy

We'll update the date below whenever this policy changes, and for material changes, notify pilot hospitals directly rather than relying on this page alone..

Contact

Questions about this policy, or a request to access, export, or de-identify data: hello@demed.in.