1. Summary
AMRIT doesn't collect patient consent properly today. The system marks every patient as having agreed, even when they didn't. It also shares their data with family and doctors by default. This doesn't meet the DPDP Act.
We propose one Consent Manager that all AMRIT services use (HWC, TM, MMU, ECD, 104, 1097, and the FLW and CHO apps). With it, patients can:
- read a clear notice in their own language before giving any data
- say yes or no to each use of their data separately
- give a doctor access for a limited time only, after which access stops on its own
- change their mind at any time and withdraw consent
Every decision is recorded in a way that can't be secretly changed.
2. What we found in the current system
| Existing Issue | Why it Matters |
|---|---|
| Consent is always saved as "Yes", whatever the patient does | We have no real proof of consent |
| Closing the consent pop-up counts as agreeing | A patient can "agree" without knowing it |
| There is no "Decline" button | Patients can't refuse |
Sharing with spouse, family and doctor is switched on by default | The law doesn't allow pre-ticked consent |
The notice is in only 2 to 5 languages | The law expects English plus 22 Indian languages |
Helpline (104) consent is a fixed English script, and the answer isn't saved | We have no evidence the patient agreed |
We don't record who viewed a patient's data, or when | We can't answer audits or complaints |
Patient personal details aren't encrypted in the database | A data leak would expose them |
3. What we propose
1. A new Consent service: One central place that stores all consents, notices and access permissions.
2. One consent screen for all apps: The same screen is used at registration, revisit, helpline calls and in the mobile apps.
3. An automatic check before data is shown: Every service asks "Has this patient allowed this?" before opening a record. If the answer is no, the data isn't shown.
4. Time-limited access, similar to ABDM: A doctor requests access, the patient approves by OTP, and access ends automatically on the agreed date.
5. A tamper-proof record: Every consent action is logged and digitally sealed, so nobody can change it quietly later.
6. Works offline: Consent can be captured in mobile vans without internet and synced later without creating duplicates.
4. How it works for a patient
1. The patient chooses their language.
2. They read the notice, or it's read aloud to them. The "Accept" button stays locked until the whole notice has been shown.
3. They see a separate on/off switch for each use of their data. All switches start off.
4. "Decline" is as easy to find as "Accept". Closing the screen means no.
5. If a health worker helps (reading aloud, thumbprint or witness), the worker confirms it and their name is saved.
6. Only after this is the patient's data collected or opened.
5. Special cases
| Situation | Handling Mechanism |
|---|---|
| Child (under 18) | A parent or guardian gives consent, verified by OTP on their own phone. |
| Person with disability | A family member / guardian gives consent |
| Existing Patients (old data) | They are asked for fresh consent at their next visit, call or by SMS. |
| Patient Refuses or Withdraws | Data isn't deleted automatically. A reviewer decides whether to keep it , anonymise it or delete it. |
| Medical Emergency | A doctor can open the record without consent (called "break-glass"), but must give a reason. Access lasts 24 hours and is reviewed later. |
| Offline (No Internet) | Consent is saved on the device and synced later. A withdrawal always wins over an older consent. |
6. Security improvements
- Encrypt personal details (name, phone, address, ID numbers) in the database
- Mask phone and ID numbers on screens.
- Encrypt all data sent between systems
- Alert on unusual activity, such as bulk downloads or any emergency accesses
7. Implementation plan (high level)
What we will build
| Component | Description |
|---|---|
| Consent-API | A new backend service that manages all consents, built the same way as Common-API and Identity-API |
| Consent Database Tables | New tables in the existing db_identity database for consents, notices, access requests and the audit log |
| Consent Check | A small shared library that every service uses to check consent before showing patient data. Answers are cached in Redis for speed |
| Consent Screen | One reusable screen in Common-UI that replaces the current consent pop-up |
| Admin Screens | Screens in ADMIN-UI to manage notices, translations and purposes |
| Background Jobs | Jobs that expire access, send reminders and clean up data (Inside Consent-API using Quartz) |