Quick answer: A compliant Indian telemedicine platform must verify that the consulting doctor is registered with a State Medical Council (now via the NMC), follow the Telemedicine Practice Guidelines on consultation type, patient identity, and prescription rules, integrate (at least optionally) with ABDM — ABHA for patient identity, HPR for practitioner registry, HFR for facility registry — and handle prescription, payment, and record retention with audit-grade trails. Build for both the TPG 2020 and the ABDM architecture from day one.
The two frameworks every Indian telemedicine platform lives inside are the Telemedicine Practice Guidelines 2020 (issued jointly by the Ministry of Health and Family Welfare, the Medical Council of India, and NITI Aayog) and the Ayushman Bharat Digital Mission (ABDM) architecture. The first defines what doctors can and cannot do over a screen. The second defines how patient identity, records, and consent flow between providers.
Step 1 — Practitioner registration and ABDM identities
Every doctor on your platform must:
- Hold a valid registration with a State Medical Council / NMC
- Have completed the mandatory online module on telemedicine practice (or equivalent) where required by NMC norms
- Optionally — increasingly an expectation — be registered on the Healthcare Professionals Registry (HPR) under ABDM, which issues a unique HPR ID
Build the doctor onboarding flow to capture the State Medical Council number, the registration certificate, and the HPR ID. Validate against the public registries during onboarding.
Step 2 — Patient identity — ABHA + traditional fallback
ABDM gives patients a unique ABHA (Ayushman Bharat Health Account) identity — a 14-digit health ID that lets records follow them across providers. Your platform should:
- Offer ABHA creation in the patient onboarding flow (via mobile, Aadhaar, or enrolment ID)
- Offer ABHA linking for patients who already have one
- Accept a traditional patient profile as fallback (ABHA is opt-in for the patient)
- Store the ABHA number against the patient profile with the consent artifact
Step 3 — The four consultation types and what they imply
The Telemedicine Practice Guidelines recognise:
- Patient-to-Doctor — First Consult — patient and doctor have not interacted before
- Patient-to-Doctor — Follow-up — continuing consultation within the prescribed follow-up window
- Caregiver-to-Doctor — for patients unable to consult themselves
- Health Worker-to-Doctor — a health worker assists the patient
Each type has implications for what the doctor can prescribe (see Step 4). Your platform UX should surface the type explicitly so the doctor knows which prescribing rules apply.
Step 4 — Prescription rules
The Guidelines split medicines into categories — including a list of medicines the doctor may or may not prescribe via telemedicine depending on the consultation type and the patient relationship. Generally:
- List O (over-the-counter style) — broadly prescribable
- List A — prescribable in specific consultation types
- List B — prescribable for follow-ups within prescribed windows
- Prohibited list — never prescribable via telemedicine (typically Schedule X narcotics and psychotropic substances)
Build the prescribing UI with category-aware prompts and hard blocks on prohibited substances.
Step 5 — Consent — explicit, recorded, retrievable
Before the consultation begins, the patient must:
- Confirm identity (or caregiver / health worker confirms it)
- Provide explicit consent for the telemedicine consultation
- Be informed of the right to terminate the consultation
Store the consent as a tamper-evident artifact with timestamp and (where appropriate) the patient’s signed audio/video acknowledgement.
Step 6 — Record retention and ABDM linkage
Maintain:
- Consultation record (transcript or summary)
- Prescription (digitally signed by the doctor)
- Investigation reports referenced
- Consent artifact
- Payment record
If the patient has linked their ABHA and consented to share records, push the consultation record to the patient’s PHR via the ABDM gateway. This is where ABDM’s value to the patient actually shows up — their records follow them.
Step 7 — Health Facility Registry (HFR)
Your platform — or your partner facilities — should register on the Health Facility Registry. This produces an HFR ID that becomes part of the metadata for every record exchanged through the ABDM gateway. It also positions you to participate in cross-platform care continuity flows as the network matures.
Step 8 — Payment, refund, and grievance
The Telemedicine Practice Guidelines require:
- Clear pre-consultation disclosure of fees
- Refund policy if the consultation cannot be completed
- A named grievance redressal officer
- Reasonable response timelines
Build the payment, refund and grievance handling as first-class features, not afterthoughts.
Step 9 — Security and privacy
Telemedicine handles sensitive personal data and (under the DPDP Act 2023 framework) sensitive personal information. Non-negotiables:
- End-to-end encrypted video and chat
- At-rest encryption of records, with key management documented
- Role-based access (only the treating doctor sees the record)
- Audit logs of every access (immutable)
- Data localisation per the operative legal framework
Step 10 — The tech stack that actually ships
Components you must build or buy:
- Video infrastructure (low-latency, India PoPs, recording)
- Patient app (web + mobile)
- Doctor app (with prescribing UI and category-aware prompts)
- ABDM gateway integration (ABHA, HPR, HFR, consent manager)
- Payment integration
- E-prescription with digital signature
- Records repository (encrypted)
- Admin / compliance dashboard
CTA: OpenMalo’s telemedicine module ships with ABDM integration, the Telemedicine Practice Guidelines-aware prescribing UI, and the video infrastructure pre-built. See the module →
Closing
The bar for “compliant telemedicine in India” is higher than it was five years ago, and that is a good thing — the platforms that build to the Telemedicine Practice Guidelines and ABDM architecture are the ones that will compound trust with patients, doctors, and insurers. Treat the framework as a feature spec.
