When Is Healthcare Software Considered a Medical Device in Viet Nam? What Healthcare Organizations and Technology Companies Need to Know
POLICY & REGULATORY INSIGHTS
When Is Healthcare Software Considered a Medical Device in Viet Nam? What Healthcare Organizations and Technology Companies Need to Know
Last reviewed: 24 September 2026
Software is becoming part of almost every layer of healthcare. Hospitals now use applications for scheduling, electronic medical records, imaging, remote monitoring, clinical decision support, artificial intelligence, medication management and many other functions. From a regulatory perspective, however, these products are not all the same.
One of the most important questions for healthcare organizations and health technology companies in Viet Nam is therefore surprisingly basic: when does healthcare software become a medical device? The answer does not depend primarily on whether a product is described as “AI,” “digital health,” “clinical software,” “decision support,” “wellness technology” or “Digital Medicine.” It depends much more on what the software is intended to do, the claims made for it and whether its intended function falls within the legal definition of a medical device.
Under Viet Nam’s current medical-device framework, software can itself be a medical device. But software does not become a medical device simply because it is used in a hospital. Understanding this boundary matters because medical-device status can affect risk classification, market authorization, documentation, quality requirements, post-market responsibilities, procurement and how a healthcare organization should evaluate a product before relying on it in patient care.
The starting point is the legal definition of a medical device
Viet Nam’s medical-device framework is principally governed by Decree 98/2021/NĐ-CP, as amended and currently consolidated in Ministry of Health Consolidated Document No. 08/VBHN-BYT dated 6 March 2026.[1] The definition expressly includes software alongside devices, implants, instruments, materials, in vitro reagents and calibrators.
Under Article 2, software can fall within the medical-device definition when, alone or in combination and according to the intended purpose specified by the product owner, it is used for human beings for one or more defined medical purposes. These include diagnosis, prevention, monitoring, treatment or alleviation of disease; compensation for injury; examination, replacement, modification or support of anatomy or physiological processes; life support; contraception; disinfection of medical devices; or provision of information for diagnosis, monitoring or treatment through examination of specimens originating from the human body. The primary intended effect must also not be achieved by pharmacological, immunological or metabolic means, although those mechanisms may support the product’s effect.[1]
The practical implication is straightforward: software does not become a medical device merely because it operates in healthcare. The more important question is whether the software itself has an intended medical purpose that falls within the statutory definition. An appointment-booking system, payroll platform or ordinary hospital document-management tool would not ordinarily become a medical device simply because clinicians use it. By contrast, software intended to analyze patient images to identify suspected abnormalities, interpret physiological information or generate information intended to support diagnosis or treatment requires much closer medical-device assessment.
Intended purpose matters more than the technology label
For software, regulatory assessment should normally begin with the intended purpose rather than the technology itself. Decree 98 defines the product owner to include an organization or individual that supplies the device under its own identity and is responsible for matters including design, production, labeling or determining the intended use of the device.[1]
This makes product claims, instructions for use, technical documentation, labeling and marketing materials relevant to understanding how a product is intended to be used. Two systems can use similar algorithms and still have very different regulatory profiles. One may organize and retrieve images without interpreting them, while another may analyze those images and identify findings intended to support diagnosis. Both may use sophisticated artificial intelligence, but their intended purposes are materially different.
Terminology such as “assistant,” “clinical support,” “AI copilot,” “wellness” or “for reference only” does not determine regulatory status by itself. If the intended function and product claims fall within the medical-device definition, a softer commercial label should not be treated as a substitute for proper regulatory assessment.
Not every healthcare application is a medical device
Software limited to scheduling, billing, staffing, inventory management or other general administrative functions will ordinarily have a different regulatory profile from software performing a defined medical function. Similarly, an electronic medical record platform that primarily stores, displays or transmits information is different from a module that analyzes patient data and generates diagnostic information, a clinical risk prediction or a treatment recommendation.
This does not mean that every analytical function automatically makes software a medical device. The assessment still needs to return to the statutory definition, intended purpose and product architecture. Once software begins transforming patient-specific information into outputs intended for diagnosis, monitoring or treatment, however, medical-device assessment becomes increasingly important.
The same distinction can apply to consumer technologies. A general fitness application counting steps is different from software intended to monitor a defined disease and provide information used in clinical management. A general nutrition application is different from software marketed to deliver or guide treatment for a medical condition. Similar technology can therefore sit in different regulatory categories because its intended purpose is different.
Clinical decision-support software needs careful assessment
Clinical decision support covers a wide spectrum. At one end, software may retrieve clinical guidelines, organize laboratory results or present information already available in the medical record. At the other end, software may calculate patient-specific risk, detect abnormalities, recommend medication doses or provide treatment recommendations.
Healthcare organizations should therefore avoid asking only, “Does the software make the final decision?” A product does not necessarily need to replace a clinician or act autonomously before it can have a medical purpose. Software that produces patient-specific information intended to contribute to diagnosis, monitoring or treatment may still fall within the medical-device framework even when a healthcare professional remains responsible for the final decision.
The practical analysis should focus on the software’s intended function, the clinical significance of its output and how that output is expected to be used.
Artificial intelligence adds another regulatory layer, but does not replace medical-device regulation
Artificial intelligence and medical-device status are separate regulatory questions. Viet Nam’s Law on Artificial Intelligence No. 134/2025/QH15 took effect on 1 March 2026, followed by Decree 142/2026/NĐ-CP. Decision 33/2026/QĐ-TTg subsequently established the current formal list of high-risk AI systems, effective from 15 August 2026. The healthcare section of that list is presently relatively narrow and contains two specified categories involving AI-assisted surgery and surgical robotic systems.[2–4]
That does not mean an AI system used for radiology, endoscopy, clinical prediction or another healthcare purpose is outside medical-device regulation simply because it does not appear on the formal high-risk AI list. An AI product may be outside the current high-risk classification under AI law while still potentially meeting the medical-device definition under Decree 98. Conversely, an AI system’s classification under AI law does not by itself determine its medical-device class.
Healthcare organizations and technology companies therefore need to distinguish two separate questions: What is the system’s status under AI regulation? Does the product also meet the definition of a medical device?
“Software used for medical devices” is an important but easily misunderstood provision
One of the most important nuances in Decree 98 is its treatment of “software used for medical devices.” Article 3 provides that the Decree’s requirements on classification, issuance of circulation numbers and declaration of eligibility for trading do not apply to “software used for medical devices.” At the same time, Article 2 separately and expressly includes software within the definition of a medical device when the statutory requirements are met.[1]
These provisions should therefore not be read as a general exemption for all software used for medical purposes. Decree 98 does not, through this provision, establish a complete taxonomy equivalent to the international distinction between Software as a Medical Device and software that forms part of, drives or supports another medical device.
Whether a particular software product itself meets the Vietnamese medical-device definition, or instead falls within the specific provision concerning software used for medical devices, needs to be assessed from its intended purpose, functionality, architecture and the way it is supplied and used. Companies should therefore avoid assuming that software is exempt simply because it connects to, operates with or is supplied alongside a medical device. Where the distinction is unclear, product-specific regulatory assessment is more appropriate than relying on terminology alone.
Software as a Medical Device is useful internationally, but Vietnamese law comes first
Internationally, the International Medical Device Regulators Forum defines Software as a Medical Device, or SaMD, as software intended for one or more medical purposes that performs those purposes without being part of a hardware medical device.[5]
The concept is useful because it provides a common international vocabulary for standalone medical software. However, SaMD is not a substitute for applying Vietnamese law. A product described or regulated as SaMD in another jurisdiction is a useful signal that Vietnamese medical-device assessment may be needed, but foreign terminology or classification does not determine the Vietnamese outcome.
The operative questions remain whether the product meets the Vietnamese statutory definition and which domestic classification and market requirements apply.
If software is a medical device, risk classification comes next
Once software is determined to fall within the medical-device framework, the next question is classification. Viet Nam classifies medical devices into four classes based on risk: Class A is low risk, Class B is low-to-moderate risk, Class C is moderate-to-high risk and Class D is high risk. Where one intended purpose could fall into multiple classes, or where a device has multiple intended purposes with different levels of risk, the higher applicable class governs.[1]
The detailed classification rules are contained in the Ministry of Health’s implementing framework, currently reflected in Consolidated Document No. 12/2026/VBHN-TT-BYT dated 10 July 2026, which incorporates Circular 05/2022/TT-BYT as amended by Circular 24/2026/TT-BYT.[6,7]
Depending on a product’s intended purpose, functionality and configuration, different classification rules may apply. The framework includes specific rules for active diagnostic and therapeutic devices, in vitro diagnostic devices and other device categories. Under Rule 10, for example, certain active diagnostic devices are Class B, while specified higher-risk functions, including monitoring vital physiological parameters where variations could place a patient in danger or diagnosis in clinically dangerous situations, fall into Class C.[6]
For software, classification should therefore be performed product by product. It is not appropriate to assume that software is automatically Class A because it is intangible or has no physical contact with the patient.
The market pathway differs according to classification
Classification has direct regulatory consequences. For Class A and Class B medical devices, the current framework uses a declaration of applicable standards. Before these devices are placed on the market, the organization making the declaration must submit the required dossier to the relevant Department of Health, after which the declaration number and relevant information are made public through the medical-device management system.[1]
For Class C and Class D medical devices, the framework generally requires registration for issuance of a circulation number through the Ministry of Health, subject to the applicable dossier, review process and any specific pathway provided under Decree 98 as amended.[1]
The framework also establishes conditions for declaration or registration. For imported devices, Article 23 requires, among other things, manufacture at a facility certified to ISO 13485 and that the device has been placed on the market in at least one country, together with conformity with the applicable national technical regulation or the standard declared by the manufacturer.[1]
For software companies, this means that asking “Is our product a medical device?” is only the first regulatory question. If the answer is yes, the applicable class determines a substantial part of the pathway that follows.
Software updates and new claims can change the regulatory analysis
Software changes quickly. Features can be added remotely, algorithms can be updated and product claims may expand as a company develops its market. Medical-device assessment should therefore not be treated as a one-time exercise performed only at the beginning of product development.
A platform originally intended simply to display information may later add patient-specific risk prediction. An imaging platform may add automated lesion detection. A remote-monitoring platform may begin issuing alerts intended to trigger clinical intervention. A general wellness product may begin claiming to manage a diagnosed disease. Each of these changes may alter the intended purpose or functionality and therefore potentially change the regulatory analysis.
This is also relevant to healthcare organizations after procurement. The product name and user interface may remain unchanged while the underlying model or functionality changes materially. Version control and change management are therefore particularly important for software and AI-enabled medical devices.
Regulatory due diligence should happen before procurement or clinical use
Hospitals and clinics should consider medical-device status before purchasing, piloting or clinically relying on healthcare software. Statements such as “it is only software,” “it is only decision support,” “the physician still makes the final decision” or “it is already used overseas” do not, by themselves, answer the Vietnamese medical-device question.
A practical due-diligence review should examine the intended use, claims, instructions for use, applicable Vietnamese classification and declaration or registration status, supporting clinical evidence, exact software or model version, product owner or manufacturer, authorized Vietnamese entity where applicable, data flows and responsibilities for updates, incidents and post-market support.
Healthcare organizations should also confirm that the product being evaluated is the same product configuration and software version covered by the relevant regulatory documentation. This is particularly important with cloud-based software and AI, where underlying models can change without a physical device being replaced.
Regulatory authorization and clinical evidence answer different questions
A circulation number, declaration number or other applicable regulatory status answers an important legal question, but it does not automatically demonstrate that software will perform effectively in every hospital, patient population or workflow. Likewise, strong clinical evidence does not remove the need to comply with medical-device regulation when the product meets the statutory definition.
Healthcare organizations should therefore ask two separate questions: Is the product legally permitted for this intended use in Viet Nam? Is the evidence sufficiently relevant and strong to justify using it in this organization and clinical environment?
For Digital Medicine, responsible adoption requires both questions to be addressed. Regulatory status should not be treated as a substitute for evidence, and evidence should not be treated as a substitute for regulatory compliance.
Which types of software deserve early medical-device assessment?
Some categories deserve particularly early review because their functions often sit close to the medical-device definition. These can include software analyzing radiology, pathology, ophthalmology or endoscopy images to identify abnormalities; patient-specific risk prediction intended to influence clinical management; software calculating treatment or medication parameters; remote-monitoring platforms generating clinically actionable alerts; and software interpreting physiological or laboratory information for clinical purposes.
By contrast, software focused solely on appointments, billing, staffing, inventory or general administrative workflow ordinarily presents a different regulatory profile.
The boundary becomes more complex when one platform combines multiple functions. A hospital platform may contain administrative features, communication functions and a clinically significant analytical module. The regulatory assessment should therefore examine the actual product architecture and relevant functionality rather than assuming that a single commercial category determines the status of every component.
Generative AI makes intended-use discipline even more important
Generative AI introduces another layer of complexity because a general-purpose model may be technically capable of producing medical information even when healthcare was not its intended purpose.
A general-purpose conversational AI system is not automatically a medical device solely because a healthcare professional uses it to ask a medical question. The regulatory analysis changes, however, where a product is specifically intended, configured or marketed to perform a medical purpose that falls within the Vietnamese medical-device definition.
The important issue is not simply what an AI model is technically capable of doing. It is what the product is intended, configured and represented to do.
For healthcare organizations, this creates an additional governance issue. A vendor may not market a general-purpose AI product as clinical decision-support software, but local users could begin treating its output as if it were validated for diagnosis or treatment. That can create a significant gap between the product’s intended use and the way it is actually being used inside the healthcare organization.
Medical-device responsibilities continue after market entry
Medical-device regulation does not end when a product obtains the relevant market status. Decree 98 requires healthcare facilities to manage and use medical devices according to their intended purpose and function, preserve, maintain and service them appropriately, follow manufacturer technical instructions, perform applicable inspection or calibration and maintain the required management records.[1]
The framework also contains provisions dealing with defective devices and serious incidents. Where an incident seriously threatens public health or causes death, for example, the circulation-number holder has obligations relating to notification, suspension of the relevant lot, investigation and reporting. Device defects can also lead to corrective action or recall.[1]
For software, these requirements need to be translated into digital practice. Healthcare organizations should know which version is running, how updates are authorized, how abnormal clinical performance is identified, how incidents are escalated and what happens when a vendor changes an algorithm or other clinically relevant functionality.
The fact that there is no physical device sitting in a storeroom does not remove the need for post-deployment management.
Personal data and cybersecurity remain separate regulatory layers
Medical-device status is only one part of the regulatory picture. Clinical software frequently processes personal health information, so organizations also need to assess Viet Nam’s Law on Personal Data Protection No. 91/2025/QH15, Decree 356/2025/NĐ-CP and relevant health-data requirements under the Data Law and Decree 102/2025/NĐ-CP.[8–11]
Cloud hosting, international vendors and secondary use of information for algorithm training can raise additional questions concerning processing purposes, access, personal-data protection impact assessments and cross-border transfers.
Cybersecurity is separately governed under the Law on Cybersecurity No. 116/2025/QH15, effective from 1 July 2026, together with implementing regulations including Decree 331/2026/NĐ-CP on cybersecurity protection for information systems and Decree 333/2026/NĐ-CP, both effective from 19 August 2026.[12–14]
A product can therefore be properly regulated as a medical device and still be implemented poorly from a privacy, cybersecurity, workflow or governance perspective. Medical-device compliance should be treated as one component of responsible implementation, not as a complete governance framework.
A useful question for technology companies
For a health technology company, one practical early question is: If our software produces an incorrect output, what healthcare action could reasonably follow from it?
This is not the legal definition of a medical device, but it is a useful screening question for deciding when formal regulatory assessment should happen early rather than late. If software is only organizing information, the analysis may be relatively straightforward. If it is detecting disease, interpreting patient information, monitoring a medical condition, calculating treatment parameters or producing information that clinicians are expected to act upon, medical-device assessment should become a priority.
Companies should address this before finalizing claims, marketing materials and hospital pilot agreements. Trying to redesign a product’s regulatory positioning after clinical implementation has already begun is considerably more difficult.
A useful question for healthcare organizations
Hospitals and clinics can ask a similar question: Are we using this software mainly to manage or display information, or are we relying on it to measure, interpret, diagnose, monitor or influence treatment?
If the answer is the latter, the organization should not accept “it is just software” as sufficient reassurance. The vendor should be able to explain the intended use, regulatory status, applicable Vietnamese declaration or registration, evidence base, exact software version, data flows and post-market responsibilities. If these answers remain unclear, the uncertainty should be addressed before the software is relied upon in patient care.
The key distinction is function, not format
The central principle is simple: software is not outside medical-device regulation merely because it has no physical form. Nor is software automatically a medical device merely because it is used in healthcare.
The regulatory analysis turns primarily on intended medical purpose, functionality and the applicable Vietnamese legal definition.
This distinction is becoming increasingly important as AI, cloud software, remote monitoring and Digital Medicine become more integrated into Vietnamese healthcare. A hospital information system, AI-assisted endoscopy platform, remote-monitoring application and administrative scheduling tool may all be broadly described as “health technology,” yet they can sit in very different regulatory categories.
Getting that classification right early helps healthcare organizations ask better questions before adoption and helps technology companies build the appropriate evidence, regulatory and implementation strategy before their products enter clinical practice.
References and further reading
Government of Viet Nam. Decree No. 98/2021/NĐ-CP on medical-device management, as amended. See Ministry of Health, Consolidated Document No. 08/VBHN-BYT dated 6 March 2026 on medical-device management.
National Assembly of Viet Nam. Law on Artificial Intelligence No. 134/2025/QH15. Effective 1 March 2026.
Government of Viet Nam. Decree No. 142/2026/NĐ-CP detailing provisions and measures for implementation of the Law on Artificial Intelligence. Effective 1 May 2026.
Prime Minister of Viet Nam. Decision No. 33/2026/QĐ-TTg promulgating the List of High-Risk Artificial Intelligence Systems. Effective 15 August 2026.
International Medical Device Regulators Forum. Software as a Medical Device (SaMD): Key Definitions. IMDRF/SaMD WG/N10FINAL:2013.
Ministry of Health of Viet Nam. Circular No. 05/2022/TT-BYT detailing implementation of provisions of Decree No. 98/2021/NĐ-CP on medical-device management, as amended by Circular No. 24/2026/TT-BYT. See Consolidated Document No. 12/2026/VBHN-TT-BYT dated 10 July 2026.
Ministry of Health of Viet Nam. Circular No. 24/2026/TT-BYT on determination of risk levels and management measures for products and goods that are medical devices and amendments to Circular No. 05/2022/TT-BYT. Effective 1 July 2026.
National Assembly of Viet Nam. Law on Personal Data Protection No. 91/2025/QH15. Effective 1 January 2026.
Government of Viet Nam. Decree No. 356/2025/NĐ-CP detailing provisions and measures for implementation of the Law on Personal Data Protection. Effective 1 January 2026.
National Assembly of Viet Nam. Law on Data No. 60/2024/QH15. Effective 1 July 2025.
Government of Viet Nam. Decree No. 102/2025/NĐ-CP on management of health data. Effective 1 July 2025.
National Assembly of Viet Nam. Law on Cybersecurity No. 116/2025/QH15. Effective 1 July 2026.
Government of Viet Nam. Decree No. 331/2026/NĐ-CP on cybersecurity protection for information systems. Effective 19 August 2026.
Government of Viet Nam. Decree No. 333/2026/NĐ-CP detailing provisions and measures for implementation of the Law on Cybersecurity. Effective 19 August 2026.
Regulatory and educational note
This article provides a general overview of healthcare software and medical-device regulation in Viet Nam as of 24 September 2026. Medical-device status cannot be determined reliably from a product name, technology category or marketing terminology alone. It depends on factors including the intended purpose defined by the product owner, functionality, claims, product architecture, applicable classification rules and the manner in which the product is supplied and used.
The relationship between software that itself meets the definition of a medical device and the specific provision in Decree 98 concerning “software used for medical devices” requires particular care. The latter should not be interpreted as a general exemption for all medical-purpose software. Where the regulatory position is uncertain, product-specific assessment should be obtained rather than relying solely on terminology or foreign classification.
This article is educational and does not constitute legal, regulatory or clinical advice.