Bangladesh SaMD: Software as a Medical Device

1. Key takeaways

In Bangladesh, software is a medical device, and there is no separate SaMD channel. The Drug and Cosmetics Act, 2023 (Act No. 29 of 2023, in force 2023-09-18) lists software directly among the device forms, so software as a medical device follows the same four-class scheme and the same two-step registration process as hardware. Class B, C and D products require notified body QMS certification in the same manner, and Class C and D products require a reference country CFS in the same manner. Nothing in the framework creates a lighter track for products whose only physical manifestation is a download or a hosted service. For software developers the question has therefore shifted from whether the product is regulated to which class it belongs to and what evidence that class demands.

• Software appears in the statutory list of device forms, without qualification.
• No exemption exists for standalone software or for low-risk software.
• Classification turns on the information purpose the software serves, not on its delivery model.
• Digital products still enter a paper-based submission system.
• Data location questions sit outside the guidelines and remain a pending verification item.

2. Legal basis

The statutory hook is a single word in the definition clause, and everything else follows from it. The table sets out the provisions relied on and flags the one row that rests on a single source rather than on the guidelines.

3. Expert insights

Insight one: software entered the statute recently, but the drafting is concrete rather than aspirational. The law that took effect in September 2023 names software in the definition, and in the same clause it names in silico reagents. The two together cover, at the level of legislation and in a single instrument, both standalone software and model-based diagnostic output. That closes the conventional defence that an algorithm service is not a device. A manufacturer cannot describe its product as a service layer, a decision-support tool or an analytics platform and expect the classification question to disappear; the statutory text already answers it. The argument has to be made on purpose and output, not on delivery technology.

Insight two: the class of a SaMD product resolves to its information purpose. Definition clause (a)(vi) describes the provision of information by examination of samples taken from the human or animal body. Most diagnostic SaMD will meet that limb. Products meeting (i) to (iv) instead, such as therapy planning software or software connected with life support, carry a higher risk level, because those purposes describe intervention rather than information. Classification must be argued back to the six purposes one by one. Treating software as a single category and assigning it a class by convention is the error that surfaces at review, when the purpose analysis is requested and cannot be produced. A signed, dated purpose-by-purpose table is the cheapest way to make that argument survive review.

Insight three: paper submission is an additional burden specific to software products. As of 2026 Bangladesh still operates a paper-based submission process, a point covered in the sixteenth article of this series. Software is naturally a digital deliverable, yet in Bangladesh it must be printed, bound into volumes, and accompanied at the packaging stage by a physical carrier and a label. For a product team accustomed to releasing builds, this is the workload most often underestimated. The volume of paper does not shrink because the product is intangible; if anything it grows, since the documentation has to describe behaviour that a reviewer cannot observe directly and must therefore reconstruct from written evidence.

4. Practical recommendations

• Separate the product form from the delivery form. Treat the product as a device for classification purposes, and treat the delivery as a paper dossier for submission purposes, including printing, binding, and preparing a physical carrier with a label. Printed volumes should follow the structure of the technical file, so that a reviewer can move between them without a separate index.
• Where the product is deployed on servers outside Bangladesh, prepare a written explanation of data processing and storage in advance. The item has no explicit basis in the guidelines, so it is recorded as pending verification; preparing it costs little, and being asked for it without a prepared answer costs a cycle.
• Complete the six-purpose classification with particular attention to (i) to (iv) and to (vi), and record the reasoning for the class assigned.
• Prepare notified body QMS certification for Class B, C and D before assembling the paper file, since the certificate is referenced inside it and cannot be inserted later without re-binding the volume in which it appears.
• Budget time for printing, binding and courier logistics as project tasks with named owners, rather than as administrative overhead absorbed at the end. A release schedule that ignores printing is a schedule that slips.

5. Verification checklist

• □ Software confirmed as falling within the device definition, with no claim of software exemption
• □ Classification completed against the six intended purposes, with attention to (i) to (iv) and (vi)
• □ Notified body QMS certification prepared for Class B, C and D
• □ Digital documents converted into bound volumes meeting paper submission requirements
• □ Data processing explanation for overseas servers listed as a pending verification preparation item

Regulatory information verified as of 27 October 2026.

How GRZAN can help. GRZAN provides medical device and IVD registration, quality system, authorised representative and local testing support across South Asia, including Bangladesh. Our team prepares dossiers to DGDA expectations, manages submissions and deficiency responses, and supports post-market vigilance obligations. Business enquiries: info@grzanglobal.com