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) |
8. Consent-API in detail
8.1 What Consent-API is
Consent-API is a new backend service. It becomes the single source of truth for patient consent in AMRIT. No other service stores or decides consent. They all ask Consent-API.
| Item | Description |
|---|---|
| Type | New microservice, separate repo Consent-API |
| Tech Stack | Spring Boot 3.2, Java 17, same structure as Common-API and Identity-API |
| Database | New consent tables in db_identity |
| Cache | Redis, for fast consent checks and instant cache clearing on withdrawal |
| File Storage | Object storage for voice clips, signatures, thumbprints and video |
| Login / Security | The same JWT login as the other AMRIT services. Admin APIs need admin roles. The patient self-service page uses a short OTP session. |
| Response Format | The standard AMRIT OutputResponse (data, statusCode, errorMessage, status), so existing UIs work unchanged |
8.2 What Consent-API does
| Module | Responsibility |
|---|---|
| Purposes | Keeps the list of reasons data is used (Registration, Treatment, Reminders, Research and so on) and whether each is required |
| Notices | Stores the consent notice in every language, with version, audio file and reviewer sign-off |
| Consent Capture | Saves the patient's yes/no for each purpose, how consent was taken (mode) and the proof |
| Access Requests | Handles "a doctor wants access for 7 days": request, OTP, approve or deny, expiry |
| Consent Check | Answers "Is this allowed?" for every other service, in milliseconds |
| Withdrawl | Lets the patient take back consent |
| Evidence | Uploads and stores voice clips, signatures, thumbprints and video, and links them to the consent |
| Audit Log | Records every action in a tamper-proof log |
| Rights Requests | Tracks patient requests to see, correct or delete data, and complaints |
| Scheduled Jobs | Expires consents, sends reminders, deletes copies of shared data, checks the audit log |
8.3 How other services use it
1. Front-end apps call Consent-API directly to show the notice and save consent.
2. Backend services (HWC, TM, MMU, Common, Identity) add one line above any API that reads patient data that requires consent.
3. That line checks Redis first, and asks Consent-API only if the answer isn't cached.
4. If consent is missing, the API returns 403 with a reason (for example CONSENT_WITHDRAWN or CONSENT_EXPIRED).
9. How we capture consent: modes
Every consent records how it was taken (the capture mode) and what proof was kept. The system picks the right mode for the situation. At least one form of proof is always required.