Verifiable, multi-modal patient consent for Indian healthcare

We shouldn't try to win “DPDP compliance” broadly. We should own one workflow that becomes the default place every Indian hospital records, signs, and proves a patient's consent.

Hospitals are among the most exposed Data Fiduciaries in India. Every outpatient encounter is a consent moment. The data is sensitive. The audience often cannot read English. The breach surface is large.

I don't think this market is won by another generic privacy management suite. It's won by whoever builds the fastest, calmest, most defensible consent capture experience for the OPD floor, and uses that as the starting point for the rest of the compliance stack.

Certinal already has a useful shape for this. Signing primitives are core IP. Hospital procurement relationships exist via the eSign business. The “sign on a phone in OPD” problem is similar to flows we've already shipped in other verticals. The 7-module product proposed below starts at M1 (Consent Capture), holds the registry and audit layer in M3-M4, and pulls dashboard, breach response, and template tooling in behind it.

The easy framing is “assume yes, define your conditions.” The question I want to spend my energy on isn't “should Certinal build this”. It's: given Certinal's shape today, what is the version of this product that has a real shot at winning?

My four conditions for saying yes:

• Stay close to the signature. If the product drifts into generic GRC tooling, we will lose to OneTrust on features and to Securiti on automation. Anchoring every module to a verifiable, signed artifact is how we play to the existing strength.
• Healthcare-first, not healthcare-only forever. India's DPDP Act applies to many other Data Fiduciary categories. We should build the schema so the same registry can serve adjacent verticals later without a rewrite.
• Three integrations are non-negotiable in v1. Hospital HIS/EMR (FHIR), Aadhaar OKYC, and ABDM HIE-CM. Without these, the product is a slide deck, not something a hospital can deploy.
• Patient UX is a moat, not a feature. The team treats the OPD waiting-room flow with the polish you would expect from a B2C consumer product. Most enterprise vendors will not.

DPDP cuts across every healthcare org that touches identifiable data - but the obligations bite unevenly. The segmentation below prioritizes by where the pain is sharpest.

The product needs to make all three of these people's lives better on different timescales.

Three layers. Capture is where consent is collected; Registry is the immutable signed truth; Enforcement is where the compliance team acts. Each module either captures, stores, or enforces - never two of those at once.

Click any node in the live /demo/architecture page to see the same diagram with module status, dependencies, and a side panel describing what each piece does.

M1 is the only module that has to feel like a B2C product. It is also the only one a patient ever sees. Get it right and Certinal becomes the default. Get it wrong and we get cheaper alternatives that don't actually capture comprehension.

The flow, end to end

Five steps, one signed artifact. The teach-back grade (step 02) is the wedge - it proves comprehension, not just a click.

The teach-back is the part most other vendors don't have. It changes the question from “did the patient click” to “did the patient understand,” which is what DPDP actually asks for.

Four archetypes drive the UX work. Each one has different reading literacy, different tech comfort, different identity verification options. The consent flow bends for them, not the other way around.

In India, consent is rarely individual. It happens in the presence of a spouse, a son, a daughter-in-law. The data model treats family co-signers as first-class citizens - captured, named, signed alongside the patient.

The 5-level identity assurance ladder

Risk class of the consent purpose picks the level. Click any rung to see when we use it.

• Priya, 28Digital native

  English, self-serve mobile. Aadhaar OTP. Target time: 90 seconds. The optimistic case - 70% of OPD volume looks like this.

• Lakshmamma, 67Low-literacy elderly

  Telugu, staff-assisted at the kiosk, family member present. Mobile OTP because the Aadhaar phone link is her son’s. Target time: 4 min.

• Ramesh, 45Visually impaired

  Hindi, audio-only flow with full Web Speech narration. Voice biometric + OTP for L3 assurance. Target time: 3 min.

• John, 52International medical tourist

  British passport, no Aadhaar. MediaPipe blink + head-turn liveness against passport photo. DPDP + UK GDPR notice; chooses jurisdiction.

All four are walkable in the prototype: /demo/patient picks the archetype, then the consent flow runs end-to-end with real Aadhaar OTP and a signed artifact at the end.

Section 8(6) of DPDP requires intimation of a personal data breach, and Rule 7 splits that into two asymmetric obligations. Each affected patient must be intimated “without delay”. The Data Protection Board gets an initial intimation without delay, then within 72 hours a detailed report that includes a report on the intimations sent to patients. The 72-hour clock is a reporting deadline to the regulator, not a notification window for the patient. Hospitals don't have the muscle memory for this - most won't until the first big fine lands.

The countdown timer in the prototype is real, and so is the AI classification pass. To see the flow end-to-end, open /demo/compliance/breach and click “Simulate breach”.

Five integrations carry 80% of the value. Each one is a 2-3 month build with a known vendor partner.

The realistic options for an Indian hospital today are: build it in-house, license OneTrust or Securiti, or buy from us. Below is the honest comparison. The numbers in the “per-hospital ARR” row are estimates from public deal sizes and may shift with negotiation.

1. The signing primitives are already ours. Every consent artifact is hashed and signed by default. A generic GRC vendor has to retrofit this layer; we get it for free. (In this prototype that layer is HMAC-SHA256 with constant-time verify; production would swap in Certinal's per-hospital P-256 ECDSA PKI, which is not built here.)
2. Hospital procurement relationships exist. Certinal already sells eSign into Indian hospital chains. The compliance product lands as an upsell on accounts where the trust is already there, which shortens the sales cycle.
3. Patient UX is unusual for the category. Most enterprise privacy vendors do not treat the OPD waiting-room flow as a B2C consumer product. We can.
4. AI is native, not bolted on. Comprehension grading and breach drafting are part of the core flow, not a chatbot tab on the side.
5. Indian-language depth from day one. Four languages in v1, schema ready for eleven. Global vendors will likely take 12-18 months to match this.
6. DPDP-shaped data model. The schema is built around DPDP Section 8 and Rule 3 directly, not GDPR with a translation layer.

The Indian hospital procurement environment is cost-sensitive and relationship-driven. Per-seat SaaS pricing is generally unwelcome. Annual committed deals tied to bed-count or facility-count fit the buying culture better.

First 18 months. I'd aim for around 20 design-partner hospitals in year one at ₹0 license fee, in exchange for case studies, integration learnings, and reference calls. Distribution co-sell would start with two established Indian HIS vendors (the specific partners would depend on existing Certinal relationships). One enterprise AE per top-six metro by month 9. By the end of month 18, the goal is roughly 50-70 paying logos and a transition from founder-led to channel-led motion.

Scope discipline matters more than scope ambition in this market. Below is what I would not build in v1, and the reasoning behind each cut.

• Generic GRC suite. OneTrust spans many frameworks. We cover DPDP healthcare deeply rather than ten frameworks shallowly.
• DSR self-service portal. In v1 we generate the request manifest; a human handles fulfilment. The portal lands in v1.5.
• Clinician-facing record review tool. That is the EMR's job. Building it ourselves picks a fight we cannot win.
• Pharma / clinical trial product. Adjacent and tempting, but a different buyer and different regulatory regime. Deferred to month 18+.
• Integration with every HIS in the country. We commit to four named HIS vendors in v1 and let the long tail wait for v1.5.
• White-glove eSign promotion in v1. Promote-to-eSign exists as an API in v1 and as a polished UI flow in v2. Pulling forward the UI work would slow M1.

The risks I'd worry about most before greenlighting this build, and the mitigation I'd pair with each.

The architecture is consciously DPDP-shaped, but the schema is jurisdiction-agnostic. The same registry can carry a UK GDPR consent or a Saudi PDPL consent with a different policy module attached.

The natural expansion order:

1. Year 2: Indian Pharma + clinical research (same customers, deeper modules around Schedule Y consents).
2. Year 3: Saudi PDPL (similar collectivist family-consent patterns; Aadhaar replaced by Absher).
3. Year 4: UK / Singapore for Indian hospital chains' international arms.

We are not chasing US HIPAA. The market is mature, the incumbents are entrenched, and the patient-UX argument doesn't carry the same weight there.

The 18-month roadmap split into three phases. v1 covers the core wedge. v1.5 closes the obvious gaps. v2 begins the adjacent expansion.

Everything described here is walkable. The prototype runs against a real Supabase instance, signs real artifacts, and uses real Aadhaar OTP via sandbox.co.in. The compliance dashboard shows live data - when you walk through a patient flow, the artifact appears in the registry within seconds.

Built with Claude (Sonnet 4.5, via OpenRouter). Honest split of who did what:

Net effect: more breadth than I'd have produced solo in a week.