Launching a Telemedicine Platform in Bangladesh: Legal Decisions Before the First Consultation

Summary. A telemedicine platform is not merely a video product with doctors attached. In Bangladesh, the launch model determines who provides medical practice, controls the patient relationship, may issue a prescription, holds the record, and answers when a remote consultation should have become an emergency referral. The Bangladesh Medical & Dental Council (BM&DC) Telemedicine Guidelines remain the central operational reference for registered doctors. They require explicit consent, identity checks, suitable technology, clinical judgment about remote care, records and disciplined prescribing. The Personal Data Protection Act, 2026 is also part of the launch analysis, but its commencement architecture matters: most provisions are treated as effective from 6 November 2025, while specified institutional and penalty provisions await later government notification. This article separates binding law, professional guidance, operating practice and unresolved points, then turns them into decisions founders can make before the first consultation.

The commercial problem is not the app

A founder can build a polished booking flow in weeks. That does not answer the harder questions. Is the platform a marketplace, a clinic operator, an employer of doctors, a technology processor, a pharmacy channel, or several of those things at once? Does it contract with the patient, the clinician, the hospital, or all three? If the service accepts a photo and sends back a medicine list, has it crossed from health information into clinical practice? If a clinician is unregistered, misidentified, or unavailable when a patient deteriorates, which contract can realistically protect the business?

Those questions are not drafting detail. They are the operating model. A Bangladesh launch should therefore begin with a service map, not a privacy policy. The map should show the patient journey from account creation to triage, clinician matching, consultation, prescription, payment, pharmacy fulfilment, referral, complaint and record retention. Each step should identify the responsible person, the permitted data use, the clinical decision-maker and the evidence retained.

This article is current as at 23 September 2026. It focuses on a platform arranging or enabling consultations with patients in Bangladesh. It does not assume that every service needs the same licence or that a 2026 reform has answered every question. The BM&DC Guidelines are professional guidance for registered medical doctors, while statutes create separate obligations for professional registration, medicines, private facilities, consumers, electronic records and personal data. The practical answer is a joined-up control system.

Decision one: choose the service you are actually selling

The first launch decision is the boundary between technology enablement and healthcare delivery. A platform may provide scheduling, secure communications, identity tools and record storage while independent doctors provide the clinical service. Another model may employ doctors, set consultation protocols, collect the consultation fee, market a branded “clinic”, control follow-up and fulfil medicines. A hospital group may use the software only for its own patients. These models are commercially different and should not be documented as if they were interchangeable.

The BM&DC Guidelines describe telemedicine as care delivered through information and communication technologies and identify registered medical doctors as the professional actors. They state that a registered medical doctor must apply professional judgment, maintain the same standard of care as in-person practice within telemedicine’s limits, and may refuse or refer a case. [1] That makes the doctor’s clinical role impossible to outsource to a user interface. The platform can support the workflow; it should not quietly become the clinical decision-maker.

A founder should write a one-page model statement before incorporation or procurement. It should answer:

1. Who contracts with the patient for the consultation?
2. Who selects, verifies, supervises and removes doctors?
3. Who decides whether a patient is eligible for remote care?
4. Who issues the prescription and keeps the clinical record?
5. Who provides emergency escalation and in-person referral?
6. Who receives the money and issues the receipt?
7. Who is responsible for the platform, the clinician and any pharmacy or laboratory?

The answers should flow into separate documents. A platform agreement with a clinician should not pretend that the platform controls medical judgment. A patient-facing term should not disclaim away the doctor’s professional accountability. A hospital agreement should distinguish the hospital’s facility and clinical obligations from the software vendor’s security and uptime obligations.

The Medical and Dental Council Act, 2010 requires the Council to maintain the register of professional medical and dental practitioners. It also criminalises deliberate false representation as a registered doctor and restricts the use of “doctor” titles by persons without the required qualification. [2] Verification is therefore a launch control, not a marketing exercise. The platform should collect registration number, name as registered, qualification, current contact details, speciality claims, renewal or validity evidence, disciplinary status where available, and a documented re-check cycle. A badge saying “verified” is not enough unless the business can show what was checked and when.

The platform should decide whether the doctor is a supplier, employee, partner or hospital secondee. That choice affects tax, employment, supervision, insurance, intellectual property, confidentiality, conflicts and termination. It also affects incident response. If a clinician leaves, the platform must preserve patient records and continuity without allowing the departing clinician to download an unbounded patient database. The contract should address access, handover, record ownership or custody, consultation fees, refunds, complaints, clinical escalation, professional indemnity, investigations and cooperation with regulators.

For market-entry planning, TRW’s verified Pharmaceutical & Healthcare practice page identifies digital health, telemedicine, professional governance, data handling, platform models and operating readiness as connected workstreams. That is the correct commercial lens: the legal route follows the operating model.

Decision two: make doctor verification and clinical governance real

A directory of names is not a clinical governance system. At onboarding, the platform should verify the person who will actually consult, not merely the person who uploaded a certificate. It should use the BM&DC register or a reliable confirmation route, match identity documents to the registration record, verify qualifications and specialist representations, and prevent a doctor’s account from being shared with assistants or unregistered staff.

The Guidelines say a telemedicine consultation should not be anonymous. The patient and doctor should know each other’s identity. The doctor should verify the patient’s name, age, address, email, phone number or another appropriate identifier, and the patient should have a mechanism to verify the doctor’s credentials and contact details. For a minor, the doctor should confirm age and consult with an identified adult. [1] Product design must make these requirements easy. A low-friction sign-up that omits age, location and guardian status may create a clinical failure before a doctor speaks.

The platform should have clinical policies for at least four situations. First, a doctor must be able to switch from text to audio or video, request records or tests, pause a consultation, or require in-person examination. Second, a doctor must be able to decline an inappropriate case without being penalised by an algorithm that rewards completion. Third, the product must surface emergency symptoms and local referral options rather than treating every interaction as a billable appointment. Fourth, a patient must be able to stop the consultation and understand what to do next.

The BM&DC flow charts place emergency assessment near the beginning of the consultation. If emergency care is needed, the doctor should provide appropriate immediate advice and guide referral. The business should convert that professional expectation into a documented escalation path: a visible emergency warning, a local emergency-services instruction, a callback or escalation queue where offered, an incident log, and a rule that platform support staff do not give clinical advice unless appropriately authorised.

Do not market “instant diagnosis” or “doctor in five minutes” if the operating system cannot safely handle a patient who presents with chest pain, stroke symptoms, severe breathing difficulty, obstetric emergency, self-harm risk or a child’s acute deterioration. Speed is a commercial promise. If it conflicts with clinical appropriateness, the promise becomes evidence against the operator.

Governance should also address incentives. A platform that pays per completed consultation may encourage doctors to continue when referral is safer. A ranking algorithm may privilege availability over competence. A subscription may create pressure to prescribe. Contracts and dashboards should therefore measure referrals, cancelled consultations, adverse incidents, complaints, record completion and response to escalation—not only conversion and revenue.

Decision three: consent must work at the point of care

The BM&DC Guidelines require explicit consent for any telemedicine consultation. Consent can be recorded by email, text, audio or video, but the doctor must record it in the patient record. The annexed model also contemplates the exchange of medical records, images, live audio and video, device output and other information, with safeguards for confidentiality and integrity. [1]

A long privacy notice is not a substitute for telemedicine consent. The platform should separate at least three decisions:

• consent to receive care remotely through the chosen channel;
• permission to collect and use information needed to assess and deliver that care; and
• optional permissions, such as marketing, analytics, product improvement, research, recording or sharing with a named hospital, laboratory or pharmacy.

The patient should know who the doctor is, what the service can and cannot do, how an emergency will be handled, whether the interaction is recorded, who will see the record, how a prescription is transmitted, and how to complain. The consent event should carry a timestamp, channel, version of the notice, patient or guardian identity, clinician identity and any withdrawal or refusal. If the patient cannot understand the notice, the platform should provide an accessible explanation and an appropriate guardian or support route.

The new data statute makes this more important, not less. The Personal Data Protection Act, 2026 defines health-related information as sensitive personal data and includes records of physical or mental condition, past or future health, ancillary service information, registration and payment information collected in providing care. [3] It defines consent as informed, clear, specific and voluntary, and says the data fiduciary bears the burden of proving consent. [3] A platform should therefore preserve evidence instead of relying on a database field reading “accepted terms”.

There is also a legal distinction between consent for clinical care and consent as a data-processing basis. The Act recognises consent, contract performance, legal claims, vital interests and other grounds in specified circumstances. For sensitive personal data, it separately recognises specific consent, contractual circumstances, healthcare duties, legal duties and other listed bases. [3] A platform should document the basis for each processing purpose. Emergency processing to protect life is not the same as marketing consent. Removing a marketing opt-in should not prevent a patient from accessing a clinical record required for continuity of care.

The terms should also avoid a false choice in which a patient must agree to broad commercial reuse or lose necessary care. The product owner should test whether each field is necessary. If the service does not need continuous location, it should not collect it by default. If an optional recording improves training, it should be separately explained and controlled. If the platform uses a foreign cloud, that cross-border flow should be disclosed and contracted rather than hidden behind an unqualified “we may share information” clause.

Decision four: prescribing is a controlled workflow, not a revenue feature

Prescription functionality is where a general technology platform can enter a tightly regulated perimeter. The BM&DC Guidelines state that prescribing by telemedicine is within the registered doctor’s professional discretion and carries the same professional accountability as an in-person consultation. Prescribing without an appropriate diagnosis or provisional diagnosis is professional misconduct. The permitted medicine categories depend on consultation type and mode, and the Guidelines list categories including medicines safe for any teleconsultation and broader categories for supported video consultations. [1]

The product should not make prescribing automatic. It should require the doctor to confirm patient identity, age, relevant history, allergies, existing medicines, diagnosis or provisional diagnosis, consultation mode, adequacy of information and referral advice. It should restrict the catalogue to medicines and indications the doctor is permitted to use, preserve the doctor’s signature or authentication, and prevent post-issue editing that is not traceable. A prescription generated by a rules engine without a registered doctor’s clinical decision is a different and riskier product.

The Drugs and Cosmetics Act, 2023 prohibits production, sale, storage, distribution or display of medicines without the required licence or outside licence conditions. It expressly addresses internet or web-based processes for selling, storing, distributing or displaying medicines, and prohibits those activities without the licensing authority’s licence. [4] It also requires marketing authorisation before distribution, marketing and sale of registered medicines, prohibits prescribing an unregistered medicine, and regulates medicine-related advertising claims. [4] The Directorate General of Drug Administration describes itself as Bangladesh’s drug regulatory authority, supervising medicine regulation from import and procurement through production, sales and pricing. [5]

That creates several models, each requiring different diligence. A platform can transmit a doctor’s prescription to a separately licensed pharmacy. It can operate an integrated pharmacy business with its own licences and controls. It can allow a hospital pharmacy to fulfil prescriptions under an appropriate arrangement. Or it can stop at the prescription. The safest starting assumption is that the platform must not imply that software authorises medicine sale. It should identify the licensed dispensing party, prevent substitution outside the prescription and applicable law, handle controlled or restricted medicines conservatively, and allocate responsibility for delivery, storage, authenticity, recall, refunds and adverse medicine reports.

Marketing needs the same discipline. Claims such as “cures diabetes”, “guaranteed treatment” or “the fastest route to antibiotics” create regulatory and consumer risk. The medicine statute requires prior approval for advertisements containing claims about medicine use, cure or treatment. [4] The Consumer Rights Protection Act, 2009 separately lists offences for false advertising, failure to supply a promised service, excessive charging and conduct that endangers a service recipient’s health or safety. [6] A growth team should have a regulated-claims review, not a post-publication apology process.

Decision five: know whether a facility licence is implicated

Not every virtual platform is a private clinic. The Medical Practice and Private Clinics and Laboratories (Regulation) Ordinance, 1982 defines a private clinic as a privately owned clinic, hospital or nursing home where patients are admitted and kept for treatment. It prohibits establishing a private clinic without a licence and provides for conditions, inspection and cancellation. [7] A software-only business that does not admit patients should not automatically describe itself as a licensed clinic. Conversely, a platform that owns or operates a physical consultation centre, admits patients, conducts tests, stores medicines or presents a facility as the provider should not assume the digital label avoids facility regulation.

The boundary should be tested against facts. Does the patient attend a branded premises? Are doctors employed there? Are observation beds, nursing staff, medicines, diagnostics or emergency equipment provided? Is the platform collecting the patient in a physical centre before connecting them to a remote doctor? Does a hospital group contract for the platform as part of its regulated facility? If yes, map the DGHS and facility requirements with the same care as the app.

The Ordinance requires registered practitioners and private clinics or laboratories to maintain patient registers, issue printed receipts and display charges or fees. [7] A digital platform should design an equivalent evidence trail: patient identity, consultation date, clinician, fee, receipt, refund, prescription, record access and complaint status. The law does not become less relevant because the receipt is an email. The ICT Act, 2006 provides a legal framework for electronic records and signatures, but it does not by itself convert an unlicensed clinical or dispensing activity into a permitted one. [8]

DGHS’s public portal shows that e-health, health-service systems, laws, guidelines and complaint-management routes remain active administrative workstreams. [9] A platform should document how it will identify the relevant local authority, facility route and escalation channel rather than placing “contact support” where a patient needs clinical direction.

Decision six: build the data architecture around health data

The proposition that Bangladesh had no 2026 data-protection law is now wrong. The official Laws of Bangladesh portal records the Personal Data Protection Act, 2026. Its section 1 treats most of the Act as effective from 6 November 2025, while sections 23 and 31–35 are deferred until a date the Government specifies by Gazette after the stated 18-month period. [3] That commencement structure is commercially important. A founder should not wait for every authority, penalty and subordinate instrument before building controls, but should not describe every deferred provision as fully operative either.

The Act applies to data fiduciaries, processors and related persons connected to Bangladesh, including certain processing outside Bangladesh linked to goods, services, monitoring or profiling of data subjects in Bangladesh. [3] A health platform will usually have at least these roles: the platform as data fiduciary for account, payment and product operations; a hospital or clinician as a separate or joint fiduciary for clinical care; and cloud, communications, analytics, payment and support vendors as processors or independent controllers depending on the facts.

The platform should create a data inventory before signing vendor terms. It should distinguish identity, contact, health history, consultation notes, images, voice or video, prescriptions, payment data, location, device data, guardian data and complaint records. It should record purpose, legal basis, source, access, storage location, retention period, deletion or archival rule, onward transfer, security control and owner. A health record should not be copied into an analytics workspace merely because an API makes it easy.

The Act places responsibility on the data fiduciary for processing by its processor and requires reasonable measures to ensure the processor complies. [3] A vendor contract should therefore cover instructions, confidentiality, access control, encryption, segregation, subcontracting, incident notice, assistance with data-subject requests, audit information, retention, deletion, return, business continuity and exit. A generic cloud agreement may allocate uptime but say nothing useful about a patient-record breach.

The statute recognises rights to access, portability, correction, updating and deletion, subject to the statutory structure and procedures. It also provides for privacy, security, retention and breach provisions, with some institutional and penalty provisions subject to delayed commencement. [3] The product must be able to find a patient’s record, verify the requestor, respond consistently, preserve an audit trail and explain any refusal. Clinical integrity matters: deletion cannot casually destroy information needed for ongoing treatment, a legal claim or a statutory retention obligation. The operating policy should reconcile the patient’s request with those limits rather than promising absolute deletion in marketing copy.

Cross-border access deserves explicit treatment. An overseas doctor, cloud region, support desk, model provider or group company may access Bangladeshi health data even if the server is not in Bangladesh. The platform should identify the transfer, document the recipient and purpose, limit access by role, test whether the transfer or location triggers the Act or another rule, and obtain specialist advice on any required notice, authorisation or localisation measure. “Hosted on a reputable cloud” is not a legal analysis.

For a system using machine learning, the risk expands. A model may infer health status from symptoms, suggest a treatment, rank clinicians or expose data through logs. TRW’s verified Artificial Intelligence & AI Governance practice page cautions that the relevant questions depend on purpose, affected people, data, deployment, hosting, supervision, supplier role and escalation. The sensible launch rule is simple: an automated output should not silently become a diagnosis or prescription. Define the model’s permitted role, human review, prohibited uses, monitoring, change control and incident route.

Decision seven: put complaints and incidents into contracts

A complaint route should be visible before the first complaint. The patient should know how to raise a clinical concern, billing issue, privacy request, technical problem, prescription error or safeguarding concern. The platform should separate clinical review from customer-service handling and set response times proportionate to risk. A complaint about a missed appointment is not the same as a complaint that a child was told to remain at home during an emergency.

The Consumer Rights Protection Act includes provisions on service price display, false advertising, failure to provide promised services and acts that risk a service recipient’s health, life or safety. [6] The platform should disclose consultation fees, cancellation terms, refund rules, doctor identity, the scope of the service, expected response times, pharmacy or laboratory dependencies, limitations of remote care and the route for escalation. A bold claim is not harmless because it was written by marketing.

Clinician agreements should contain a clinical incident protocol. The doctor must notify the platform promptly of an adverse event, suspected prescription error, unsafe technology, patient complaint, professional investigation, credential change or data incident. The platform should preserve relevant logs without altering the clinical record, notify the appropriate counterparty, cooperate with the doctor and facility, and avoid public statements that prejudge liability.

Technology contracts need equally practical terms. The platform should allocate responsibility for downtime, failed calls, lost messages, delayed notifications, unauthorised access, backup restoration, subcontractors and evidence preservation. Service levels should not be drafted as if a missed video call were only a commercial inconvenience. If the platform promises continuity, it should define a fallback communication method and what happens when the consultation cannot safely proceed.

Investors and hospital groups should diligence the same controls before funding or integrating the business. Ask for the doctor register, sample consent record, prescribing policy, medicine list, facility analysis, data map, vendor schedule, incident log, complaint register, insurance, regulator correspondence, terms of service, refund data and evidence of security testing. A clean user interface is not evidence of compliance. A defensible launch is evidence.

What to do next: convert the model into a launch gate

Before the first consultation, the founder should require a signed launch memo covering the service perimeter, entity and contracting model, BM&DC verification, clinician governance, consent, emergency escalation, prescribing, pharmacy or laboratory relationships, facility licensing, data flows, cybersecurity, complaints, insurance and incident response. The memo should identify law, professional guidance, operating practice and uncertainty separately. It should name the decision owner for each unresolved issue.

The immediate sequence should be:

1. Freeze the patient journey and clinical service description.
2. Confirm whether the platform, clinic, hospital, pharmacy or laboratory is the provider at each step.
3. Verify every clinician and restrict access to the verified individual.
4. Implement explicit telemedicine consent and an auditable record.
5. Test emergency triage, referral and failed-connection scenarios.
6. Lock prescribing and medicine-fulfilment controls before marketing launch.
7. Map health data, processors, cross-border access, retention and breach response.
8. Sign clinician, hospital, pharmacy, laboratory, cloud and payment contracts.
9. Publish accurate fees, claims, limitations, complaint routes and contact details.
10. Run a tabletop incident exercise and record the remediation owner.

This is the point at which TRW’s Our Practices directory is useful: the issue will rarely sit in one silo. Healthcare regulation, technology, data, contracts, corporate structure, investment and disputes may all be on the critical path. For an initial conversation, use the verified TRW contact route. The public contact page asks parties not to send confidential, privileged, patient or time-sensitive information through the initial route; follow that instruction.

Conclusion: the first consultation is the last safe deadline

A telemedicine launch succeeds when clinical responsibility is visible, evidence is retrievable and the platform knows when not to proceed. Bangladesh already has an operative professional framework for registered doctors, medicine controls that reach internet-based activity, statutory registration rules, facility regulation, consumer remedies and a new personal-data statute with a staged commencement structure. The law does not reward a platform for calling itself “just technology”.

The commercial decision is therefore not whether to add a disclaimer. It is whether the service has been designed so that the right doctor, with the right information, can make the right decision through an appropriate channel, while the business preserves consent, records, escalation and accountability. Resolve that before the first consultation. The cost of doing so is a launch workstream. The cost of discovering it after harm is a business event, a regulatory event and potentially a dispute.

Primary CTA: Contact TRW to discuss the Bangladesh launch model, clinician arrangements, healthcare regulation, data architecture and commercial contracts. Please send only non-confidential context through the initial enquiry route.

FAQs

1. Must a telemedicine platform in Bangladesh itself be licensed as a clinic?

Not automatically. The answer depends on what the platform actually does. The 1982 Ordinance regulates private clinics, defined around privately owned facilities where patients are admitted and kept for treatment, and requires a licence to establish such a clinic. A software-only service may not fall within that definition, but a branded physical consultation centre, hospital-operated service or platform that admits patients may raise facility-licensing questions. The facts should be mapped with DGHS before launch. [7]

2. Can any doctor provide telemedicine through the platform?

No. The platform should permit consultations only by appropriately registered medical or dental practitioners within the relevant professional scope. The BM&DC Guidelines require identity and credential verification, and the Medical and Dental Council Act, 2010 creates registration and offences for false representation. Verification should be documented and repeated, not treated as a one-time upload. [1] [2]

3. Is patient consent required for every telemedicine consultation?

The BM&DC Guidelines say explicit consent is necessary for any telemedicine consultation and that the doctor should record it in the patient record. The Personal Data Protection Act, 2026 also makes health data sensitive personal data and places requirements around informed, specific and provable consent or another lawful basis. Clinical consent and data-processing consent should be designed as connected but distinct events. [1] [3]

4. Can a telemedicine doctor prescribe any medicine online?

No. Prescribing remains the doctor’s professional responsibility and is subject to the BM&DC framework, consultation mode, clinical information and medicine category. The Drugs and Cosmetics Act, 2023 also prohibits prescribing unregistered medicines and regulates internet-based sale, storage, distribution and display. The platform should not automate or market unrestricted prescribing, and any pharmacy arrangement requires separate diligence. [1] [4]

5. Does Bangladesh now have a 2026 data-protection law?

Yes. The official Laws of Bangladesh portal records the Personal Data Protection Act, 2026. It treats most provisions as effective from 6 November 2025, but excludes specified provisions, including sections 23 and 31–35, until a later government notification after the stated 18-month period. The core launch controls should be implemented now, while deferred commencement, regulations and authority practice should be checked before publication. [3]

6. What should a founder put in the clinician contract?

At minimum, the contract should cover registration and re-verification, scope of practice, clinical independence, consent and records, emergency referral, prescribing, fees, refunds, complaints, incident reporting, confidentiality, data access, insurance, audit information, patient continuity, suspension and termination. It should allocate platform, clinical and facility responsibilities without pretending that a contract can remove a registered doctor’s professional accountability.