Can Your Health App Give Medical Advice? Bangladesh’s Legal Boundary Between AI and Doctors

Summary

A Bangladesh health app does not become legally safe merely because its output is labelled “information”, “wellness” or “AI-generated”. The harder question is what the product actually does. A tool that organises records, flags a possible issue for a registered doctor and leaves the clinical decision with that doctor is materially different from a chatbot that tells a patient what condition they have, whether to seek urgent care, or which medicine and dose to take. This article maps that boundary as at 23 September 2026. It connects the Bangladesh Medical and Dental Council’s telemedicine framework, the Drugs and Cosmetics Act 2023, consumer-protection rules and the Personal Data Protection Act 2026 to product architecture, clinical supervision, marketing and responsibility. The practical message is direct: design the human clinical relationship first, then automate only what the evidence and governance can support.

The commercial problem: the interface can become the clinician

Healthtech founders often describe the same product in two different ways. In an investor deck it is an “AI triage and treatment assistant”. In a privacy notice it is a “wellness information tool”. In a marketing campaign it “knows what your symptoms mean”. Those descriptions are not interchangeable. They describe different risk positions, and a regulator, patient, court, insurer or commercial counterparty may examine the product’s conduct rather than its preferred label.

The question for Bangladesh is therefore not whether artificial intelligence is mentioned in the codebase. It is whether the service is making, communicating or operationalising a clinical judgment for a patient without the professional relationship and controls expected of a registered doctor. The distinction matters even more where the platform asks for symptoms, receives medical records, identifies a condition, recommends a medicine, generates a prescription, directs a patient away from emergency care or presents its output as a substitute for a consultation.

This article resolves five connected decisions. First, how to distinguish doctor-support software from an automated clinical service. Second, which design choices move a product towards the higher-risk side of that line. Third, what supervision, records and escalation should look like when a registered doctor is involved. Fourth, why advertising and investment documents can create exposure even before a patient is harmed. Fifth, how to allocate responsibility among the app company, doctor, clinic, model provider and other vendors.

The answer is not that every clinical software product requires the same licence, or that every automated statement is legally prohibited. Bangladesh’s framework is developing across professional regulation, medicines, medical devices, consumer protection, data governance and sector-specific administrative practice. Some questions remain fact-sensitive. That uncertainty is a reason to build a disciplined operating model, not a reason to assume that a disclaimer transfers responsibility.

Bangladesh health app medical advice starts with the clinical role

The Bangladesh Medical and Dental Council (BM&DC) describes itself as the statutory body responsible for maintaining standards in medical education and registering doctors to practise in Bangladesh.[1] The Bangladesh Medical and Dental Council Act 2010, Act No. 61 of 2010, is the operative statute shown in the official laws database. Its contents include registration of recognised medical doctors, prohibition of allopathic practice without registration, restrictions on false titles and an offence relating to prohibited medicines being prescribed.[2]

The legal significance for product teams is structural. The statute regulates the person who practises medicine; it does not turn a software company into a doctor merely because the company has built a sophisticated model. A platform may employ, contract with or enable doctors. That does not mean that the platform itself can silently absorb the doctor’s professional role.

BM&DC’s Telemedicine Guidelines, July 2020, are especially useful because they describe telemedicine as care delivered through information technology and state that the guidelines are an aid for registered medical doctors.[3] They recognise video, audio, text and digital platforms as possible tools. They also address identification of the doctor and patient, explicit consent, evaluation, patient management, health education, counselling, medication, privacy, records, fees and referral. The guideline’s flow charts put the registered medical doctor at the decision point: the doctor assesses whether the case is suitable for telemedicine, checks for emergency care, evaluates information, provides management or refers for in-person care.

That does not mean that every clinical algorithm is unlawful. It means that a business should be able to answer a basic question: who is exercising clinical judgment, and where is that person in the workflow? If the answer is “a named, registered doctor who reviewed the relevant information, can disagree with the model, communicates with the patient where necessary and owns the decision”, the product has a credible doctor-support architecture. If the answer is “the model generated the recommendation and no doctor needs to see it”, the business should not describe the service as ordinary doctor-led telemedicine merely because a doctor is available somewhere in the organisation.

A practical two-column distinction

Doctor-support model	Automated counselling or prescribing model
The software summarises, searches, alerts or proposes options for a registered doctor.	The software tells the patient what the condition is or what treatment to take.
A doctor verifies the patient, reviews inputs and makes the clinical decision.	The patient receives a clinical output without a meaningful doctor review.
The model output is an internal aid, with uncertainty and provenance visible to the doctor.	The output is presented as a definitive answer, diagnosis, triage result or prescription.
The doctor can reject, modify or escalate the suggestion.	The system automatically sends advice, medicine instructions or a prescription.
The patient knows who the responsible doctor or clinical service is.	The patient is invited to rely on an anonymous or “virtual doctor” persona.

The table is not a statutory safe harbour. It is a product-risk test. The more a platform occupies the right-hand column, the more difficult it becomes to argue that the business merely supplies neutral software.

Product design decides the legal posture before launch

Define the intended purpose in operational language

The intended purpose should be written as a workflow, not a slogan. “Supports doctors in reviewing patient-submitted symptoms” is measurable. “Provides personalised medical intelligence” is not. A product specification should identify the user, the input, the output, the decision owner, the allowed use, the prohibited use and the escalation route.

Consider three products. Product A converts a doctor’s consultation notes into a structured summary and highlights missing information. Product B compares a patient’s reported blood pressure with thresholds selected by the clinical team and asks the patient to contact a doctor when a threshold is reached. Product C asks symptoms in a chat, produces a likely diagnosis and sends a dosage recommendation. Product A is plainly decision support. Product B may be a monitoring and triage workflow whose risk depends on its clinical purpose and controls. Product C is much closer to automated clinical advice and potentially a treatment pathway.

The same machine-learning model could be used in all three. The legal and commercial assessment changes because the product’s role, interface and reliance pattern change. Investors should therefore diligence the deployed workflow, not only the model card or training data.

Do not hide the decision in the user interface

A product can make a clinical decision without using the word “diagnosis”. A button saying “Your symptoms are consistent with bacterial infection” is diagnostic in ordinary language. “Take amoxicillin 500 mg three times daily” is treatment advice whether or not it is accompanied by “consult a physician”. “You do not need emergency care” is a triage decision. A visual score, urgency colour or ranked condition list may have the same practical effect.

The interface should make the boundary visible. Internal doctor tools should identify suggestions as suggestions, display relevant inputs, show the model’s limitations and record the doctor’s acceptance or rejection. Patient-facing tools should use narrow, evidence-backed statements and avoid presenting an automated conclusion as a personal medical assessment. A route to a registered doctor should be real, not a decorative icon that appears after the patient has already been instructed what to do.

Triage is not a low-risk category

Founders sometimes treat triage as less regulated than diagnosis. The patient does not experience it that way. A triage instruction affects whether the patient seeks emergency care, waits, self-treats or shares information with a professional. BM&DC’s telemedicine flow charts begin by asking whether emergency care is needed and contemplate first aid and referral.[3] That is a clinical safety function.

A safe triage workflow should define red flags, language coverage, response times, geographical assumptions and failure behaviour. It should make clear what happens when the model is uncertain, the patient’s answer is incomplete, the service is unavailable or a child is using the app. If a red-flag response is generated automatically, the business should retain evidence that the rule set, content, testing and escalation were approved and monitored by appropriately qualified clinicians.

Prescribing requires a separate control layer

A prescription is not simply a text output. It identifies a patient, a medicine, a dose, a route, a frequency and often a duration. It can create a supply-chain event and may lead to online sale or dispensing. The Drugs and Cosmetics Act 2023 defines “drug” broadly, including medical devices and software used for medical purposes, and it prohibits internet or web-based sale, stocking, distribution or display of medicines without the required licence or outside licence conditions.[4]

The Act is not a complete software-regulation code, and the classification of a particular product requires a fact-specific assessment. But its breadth is a warning against treating a prescription engine as ordinary content. A business should separate: clinical decision; prescription issuance; pharmacy fulfilment; medicine advertising; and delivery. Each step can involve a different party, approval or record.

A model that recommends a medicine to a doctor for review is different from a model that automatically generates a patient-facing prescription. The latter should not be activated merely because a doctor signed a general protocol. The workflow should require patient identification, clinical review, contraindication checks, interaction checks, dosage boundaries, record creation and an auditable final action by the doctor or authorised service.

Medical-device risk cannot be dismissed as “software only”

The 2023 Act’s definition of medical device expressly includes software and in-silico diagnostic reagents used for diagnosis, prevention, monitoring or treatment.[4] This does not automatically determine that every health app is a regulated medical device. It does mean that the intended use, claims and functionality deserve a DGDA assessment where the app analyses patient data or drives a medical decision.

The Directorate General of Drug Administration’s official laws index lists the Drugs and Cosmetics Act 2023, the 2023 gazette and related drug rules.[5] The material opened for this article did not establish a separate, operative AI-specific product-approval regime. A founder should therefore seek the current DGDA classification and licensing position for the proposed software, rather than treating a draft, notice, policy discussion or commercial label as a legal clearance.

Clinical supervision must be real, continuous and documented

“Doctor in the loop” is not a slogan

A doctor’s name in the terms of service does not create clinical supervision. Nor does appointing a medical adviser who never sees patient outputs. A meaningful supervision model answers four questions.

First, which registered doctor or clinical team is responsible for the pathway? Second, what information must that doctor review? Third, what decisions may the model make without review, if any? Fourth, what happens when the doctor disagrees, the patient deteriorates or the model performs outside its tested population?

The BM&DC guidelines state that doctors using telemedicine should maintain the same professional and ethical norms as traditional care, within telemedicine’s limitations.[3] The guideline also requires doctor and patient identification, explicit consent, evaluation and documentation. The platform should turn those principles into product controls: verified doctor credentials; session records; consent capture; time-stamped review; escalation; referral; and a way to stop or correct an output.

Supervision should follow risk, not convenience

Low-risk administrative functions can usually be reviewed periodically. A tool that drafts a consultation summary may be sampled. A tool that flags possible sepsis, suggests a medicine or determines urgency requires closer clinical oversight. The supervision plan should match the foreseeable harm, the speed of the decision and the reversibility of the consequence.

A useful internal matrix may allocate each function to one of four states: permitted automation; doctor review before patient display; doctor review before action; or prohibited automation. The matrix should cover diagnosis, triage, treatment, prescribing, dosage, pregnancy, paediatric use, mental-health crisis, emergency advice and referral. It should also identify languages, population groups and conditions for which the model has not been validated.

Patient consent is not the same as model permission

A patient may consent to a teleconsultation without consenting to every secondary use of their data or to an automated medical decision. Consent screens should distinguish care delivery, quality monitoring, model improvement, marketing, research and disclosure to vendors. They should explain, in language the patient can understand, whether a doctor will review the output and what the system cannot do.

The Personal Data Protection Act 2026 now appears in the official Bangladesh laws database as Personal Data Protection Act 2026. The official text states that the Act applies to relevant Bangladesh processing and certain processing outside Bangladesh connected with services or monitoring of people in Bangladesh.[6] It identifies health-related data as sensitive personal data and defines health data to include physical or mental condition, past, present or future health records, and information collected in connection with registration, payment or healthcare delivery.[6]

The Act’s core provisions are stated to have effect from 6 November 2025, while specified provisions, including the authority and certain enforcement sections, are deferred until a government notification after 18 months.[6] That commencement structure matters. It is wrong to say there was no 2026 data-protection law; it is equally wrong to assume every institutional or enforcement mechanism is already live in its final form. Product teams should map the operative provisions and the deferred provisions separately.

For health apps, the immediate design implications include purpose limitation, evidence of consent where consent is relied upon, controlled processor access, security, retention and breach planning. The Act permits processing of sensitive data in defined circumstances, including specific consent, contractual grounds and treatment by a healthcare professional or emergency care.[6] A platform should not treat the “healthcare” label as a universal exemption. The legal basis should match the actual role and flow.

Records are part of the product, not an afterthought

If a platform supplies clinical services, it should be able to reconstruct the episode. The record should show who the patient was, what information was available, what the model produced, what the doctor saw, what the doctor decided, what the patient was told, what consent was captured and what referral or follow-up occurred.

The record should preserve relevant model version, ruleset version, prompt or configuration, decision thresholds and any human override. That does not mean retaining every internal token forever. It means retaining enough evidence to investigate a complaint, audit a clinical pathway, answer a regulator and improve safety. Retention must be aligned with the data-protection rules, clinical needs, contractual commitments and security capabilities.

Marketing claims can move a product into the clinical perimeter

Read the claim as a patient would

A marketing claim may be evidence of intended purpose. “AI-powered symptom checker” is broad. “Diagnoses 50 common illnesses in seconds” is direct. “Your 24/7 virtual doctor” invites reliance. “Prescriptions without waiting for a clinic” describes an outcome, not a technical feature. Claims can also arise through app-store copy, influencer scripts, onboarding text, push notifications, customer-support replies and investor presentations.

The Consumer Rights Protection Act 2009 lists false advertising, failure to provide a promised service, conduct endangering a service recipient’s life or safety and negligence causing harm among its subject areas and offences.[7] The application to a particular digital-health dispute is fact-specific, but the risk is clear: a health app should not promise clinical accuracy, safety, access or outcomes that the business cannot substantiate.

TRW’s Commercial Contracts practice page identifies scope, responsibility, evidence, risk allocation and change control as issues that can be structured in commercial documentation. Those contractual controls do not replace specialist clinical or regulatory validation. The product team should maintain a claim register linking each public claim to evidence, approval owner, territory, expiry and withdrawal process.

Disclaimers cannot reverse the customer journey

A small disclaimer at the bottom of a page is weak evidence if the product repeatedly tells a patient what to do. “Not medical advice” may help explain the intended boundary for genuinely general information. It does not automatically neutralise a personalised diagnosis, a medicine instruction or an emergency decision.

The more reliable approach is behavioural consistency. Use “general information” only where the output is genuinely general. If a patient’s symptoms are processed to produce a personalised recommendation, say that plainly. If a doctor will review the information, identify the clinical service and timing. If no doctor reviews it, do not imply doctor-level care. If urgent symptoms are possible, provide an appropriate emergency route rather than relying on disclaimers.

Investor materials create a second claims record

Investors should compare the product demo, website, app copy, regulatory memo, clinical validation, incident log and revenue model. A company that tells investors that its system “automates diagnosis” but tells regulators it only provides education has a credibility problem. The mismatch may also affect warranties, disclosure schedules, insurance coverage and valuation.

Diligence should ask whether the company has received complaints, takedown requests, adverse-event reports, medicine-related notices, data-subject requests or questions from BM&DC, DGDA, DGHS or consumer authorities. It should test whether the company can identify each doctor involved, each vendor with access to health data and each model version used in production. A low-cost growth strategy can become an expensive remediation project if the operating model was never documented.

Responsibility follows the workflow, not the branding

The platform may have several roles at once

A health app company can be a software supplier to a hospital, a platform operator for doctors, a healthcare service provider to patients, a data-fiduciary, a processor for a clinic and a distributor or referrer for a pharmacy. Those roles should be analysed separately. Calling the company a “marketplace” does not eliminate responsibilities created by its own patient-facing conduct.

The Personal Data Protection Act 2026 distinguishes the data-fiduciary that determines or oversees processing from the processor acting under a contract.[6] A platform should document which entity decides purposes, which entity controls access, who responds to data requests, who handles security incidents and where data is stored. The commercial agreement should not merely say “the vendor is responsible for compliance”. It should allocate actual tasks and evidence.

Contracts should allocate clinical and technical accountability

A doctor agreement should cover credentials, scope, availability, professional independence, consent, records, escalation, referral, incident reporting, use of model outputs, patient complaints and suspension rights. A hospital or clinic agreement should identify the service owner, clinical governance committee, approved pathways, data roles, audit rights and change approval.

A model-provider agreement should address training and input data, confidentiality, prohibited use, model changes, uptime, incident notification, audit information, performance monitoring, human review, indemnities, insurance and exit assistance. A pharmacy or fulfilment agreement should separate prescription validity from supply obligations and require controls against unauthorised or altered prescriptions.

No contract can make a prohibited act lawful or guarantee that a regulator will accept a private allocation. Contracts are still essential because they determine who must act first when something goes wrong and what evidence will exist.

What happens when the model is wrong?

Imagine a patient reports chest pain, shortness of breath and dizziness. The chatbot classifies the case as anxiety, gives breathing exercises and delays referral. There are at least six questions: what data did the model receive; what red-flag rule applied; was the model within its validated population; did a doctor review the result; what did the marketing promise; and which entity controlled the workflow?

Now change the facts. The tool is used by a registered doctor, the system highlights chest pain as a red flag, the doctor overrides the alert and the platform records a referral. The outcome may still be disputed, but the responsibility analysis is different because the doctor-led process and evidence exist.

The distinction is not a promise that a doctor or platform will avoid liability. It is a disciplined way to identify the alleged duty, breach, causation, evidence and contractual allocation. A platform that designs the workflow, sets the thresholds, controls the interface and markets the service should expect scrutiny even if the underlying model came from a third party.

A launch sequence for founders and investors

1. Draw the decision map

List every patient-facing output and label it administrative, educational, monitoring, triage, diagnostic, treatment, prescribing, referral or emergency-related. Identify whether the output is generated automatically, reviewed by a doctor or acted on by a clinician. Treat each separate module as its own use case.

2. Identify the professional relationship

Confirm whether the service is doctor-led telemedicine, a provider-facing tool, a self-care product or a hybrid. Verify doctor registration and define the clinical entity. Do not use “telemedicine” as a blanket description for a chatbot that has no doctor in the patient workflow.

3. Check product and medicine interfaces

Review whether the software could fall within the 2023 Act’s medical-device definition. If it touches medicines, separate prescription, sale, fulfilment, advertising and delivery. Obtain the current DGDA position and do not rely on a press summary, draft policy or investor assumption.[4] [5]

4. Build consent, identity and escalation into the interface

Require patient and doctor identification appropriate to the service. Capture explicit telemedicine consent where applicable. Provide emergency escalation, in-person referral and follow-up. Make the doctor’s role, availability and decision visible. Test the process in Bangla and English where both are offered.

5. Create a clinical evidence file

Retain the intended-purpose statement, clinical protocol, validation evidence, excluded populations, red-team results, error taxonomy, version history, monitoring plan, incident procedure and approval records. Document why the product is safe enough for each automation level. “The model performed well in a benchmark” is not a complete clinical evidence file.

6. Map health data under the 2026 Act

Identify data-fiduciary and processor roles, legal bases, specific consent where required, access permissions, retention, deletion, vendor locations, cross-border flows, security controls and breach response. The Act’s deferred provisions should be tracked separately from the provisions treated as already effective.[6]

7. Review every public claim

Create one approval process for website copy, app-store text, influencer content, sales scripts, clinical brochures, investor materials and customer-support macros. Remove claims that imply diagnosis, safety or outcomes unless the evidence and operating model support them. Keep a withdrawal route for claims that become inaccurate after a model or protocol change.

8. Contract for change, not only launch

AI systems change. A vendor may retrain a model, alter an API, move hosting, change a safety filter or deprecate a version. Contracts should require notice, testing, approval rights, rollback, audit information and cooperation. A health app needs an exit plan for a model provider and a clinical provider, not only a data-export clause.

What investors should ask before funding or acquiring

A regulatory diligence request should begin with the product as used, not the product as described. Ask for a live demo of every patient journey, including emergencies, uncertainty, paediatric use and a failed vendor connection. Ask which outputs are generated without doctor review. Ask to see a sample patient record with model version, doctor action and consent evidence redacted appropriately.

Request the clinical governance charter, doctor agreements, BM&DC registration-verification process, DGDA correspondence, medical-device assessment, medicine and pharmacy arrangements, complaint log, adverse-event log, incident response plan and insurance policies. Test whether the business can stop a risky feature immediately and notify affected users.

The investment documents should address undisclosed regulatory correspondence, patient complaints, data incidents, unapproved claims, model provenance, third-party rights, clinical validation, licence requirements and changes in law. A buyer should price remediation rather than assume that a general compliance warranty covers the product’s actual clinical operation.

What to do next

The safest Bangladesh health-app strategy is not to ask whether an AI model is “a doctor”. It is to decide, feature by feature, whether the model is supporting a registered doctor or delivering a clinical answer directly to the patient. The answer should be visible in the product, the clinical protocol, the records, the marketing and the contracts.

For a launch, funding round, vendor agreement, acquisition or incident review, prepare a short decision pack: system diagram, patient journeys, intended-purpose statement, model and vendor list, doctor workflow, data map, public claims and draft contracts. TRW’s Artificial Intelligence & AI Governance practice provides a product-and-accountability lens, while its Commercial Contracts practice is a verified route for considering scope, allocation, evidence and change control. The TRW practices hub is another verified starting point. For a first, non-confidential enquiry, use TRW’s contact route; do not send patient records or privileged material through an unsecured initial message.

This is a practical starting point, not a clearance opinion. The applicable route depends on the actual product, clinical arrangement, claims, patient population, data flows, licences, current notices and evidence.

Frequently asked questions

1. Can a Bangladesh health app diagnose a patient without a doctor?

There is no general safe harbour allowing an automated app to replace a registered doctor. The risk turns on what the app does and how it is presented. A personalised diagnosis, treatment recommendation, emergency decision or prescription without meaningful doctor involvement is materially different from software that supports a registered doctor. The business should obtain a fact-specific assessment of the professional, device, medicines, consumer and data implications before launch.

2. Does a disclaimer saying “not medical advice” protect an AI health app?

Not by itself. A disclaimer may help explain a genuinely educational service, but it cannot reliably contradict a patient journey that analyses symptoms and tells the user what condition they have or what medicine to take. Public claims, interface design and actual outputs should all match the intended non-clinical or doctor-led model. False or misleading claims may also raise consumer-protection concerns.

3. Can a doctor supervise an AI chatbot remotely in Bangladesh?

A doctor-supervised model is possible in principle where the clinical relationship, patient and doctor identification, consent, evaluation, records, escalation and professional responsibility are properly organised. BM&DC’s 2020 Telemedicine Guidelines contemplate technology-enabled consultations by registered medical doctors and place clinical decisions within the doctor’s workflow. A doctor who is nominally available but does not review or control the relevant output is not the same as meaningful supervision.

4. Can an AI health app issue prescriptions in Bangladesh?

Prescription functionality requires careful separation of the clinical decision from medicine supply and online sale. The BM&DC telemedicine framework addresses doctor-led medication and prescription pathways, while the Drugs and Cosmetics Act 2023 regulates medicines and restricts internet-based sale, stocking, distribution or display without the required licence or outside licence conditions. An automated prescription engine should not be launched without reviewing the clinical, medicine, device, licensing and pharmacy arrangements.

5. Is health data specially protected under Bangladesh’s 2026 data law?

Yes. The official Personal Data Protection Act 2026 identifies health-related data as sensitive personal data and defines health data broadly. Its commencement provisions treat core parts as effective from 6 November 2025 while deferring specified institutional and enforcement provisions until a later government-notified date after the stated period. A health app should map legal bases, specific consent where applicable, data-fiduciary and processor roles, security, retention, access, cross-border flows and breach response.

6. What should an investor diligence in a Bangladesh AI health company?

The investor should test the deployed product against its public claims and identify every automated clinical output. Key documents include doctor and clinic agreements, BM&DC registration controls, clinical validation, medical-device and DGDA analysis, medicine and pharmacy arrangements, consent and data maps, vendor contracts, model-change controls, complaints, adverse events, incidents, insurance and regulatory correspondence. The central question is whether responsibility is documented and operational, not merely allocated in a disclaimer.