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.
| Mode | When it's used | How it works | Proof we store |
|---|---|---|---|
| Self-read (on Screen) | The patient can read, at a facility or in the app | The patient reads the notice, sets each switch and taps Accept | Notice version and language, the exact text shown (hash), time, device |
| Read aloud (assisted) | The patient can't read | The health worker plays the audio notice or reads it, then records the patient's answers | Health worker's ID and confirmation tick, and that the audio played to the end |
| Voice clip (new) | Assisted or low-literacy patients, in a facility, van or home visit | After the notice, the device records the patient saying their consent (for example "I agree to this"), about 30 to 60 seconds | Audio file, its hash and duration |
| Witnessed | Extra safety for assisted consent, or when there's no phone | A second person (family member or staff) confirms they saw consent given | Witness name and relationship |
| Verbal (Helpline call) | 104, 1097 and ECD calls | The agent reads the notice script in the caller's language, and the caller says yes or no | Call ID and a link to the call recording |
Consent from existing beneficiaries: Existing patients will be asked for fresh consent at their next contact with AMRIT: a facility or van visit, an FLW/ASHA home visit, or a helpline call. The system shows "Consent pending" and opens the same consent screen used for new patients.
Rules for every mode:
- The notice is always shown or played in full before consent is taken.
- In an assisted mode (read aloud, voice, witnessed), the health worker must tick a confirmation box, and their user ID is saved automatically.
- A guardian can give consent through any mode for a child or a person with a disability. The guardian's details are saved.
- Suggested default per setting: facility with a literate patient → self-read. Low literacy → read aloud plus voice clip. Helpline → verbal. No phone → witnessed
10. How consent works offline
Mobile vans (MMU/TM) run their own local AMRIT server and database, and sync with the central server when internet is available. The FLW and CHO mobile apps keep data on the phone. Consent follows the same pattern.
| Stage | What happens |
|---|---|
| Before going out (online) | The van downloads the latest notices (text in all languages), the purpose list, and the current consent status of patients in its area, along with the other master data |
| Capturing Consent (offline) | The notice is shown from local storage. Consent is saved in the van's local database with a unique ID created on the device, so it can't clash with others. The consent is digitally signed with the van's own key. |
| Checking consent (offline) | The van's services check consent against the local database, including expiry dates on the van's clock |
| Withdrawing (offline) | A patient can withdraw in the van. It takes effect in the van immediately and is sent to central at the next sync. |
| Back Online (sync up) | Consents and audit log entries are uploaded through the existing van-to-server sync. Evidence files upload separately. |
| Central Processing | Central checks the van's signature, ignores duplicates (same unique ID), checks the audit chain, and deletes the local file once the upload is confirmed |