Armenia SaMD Medical Device Registration: Software as a Medical Device in the EAEU

1. Key takeaways

Under the Union rules, stand-alone software is expressly treated as an active medical device, and it must therefore undergo an independent risk classification and prepare independent registration documentation; it cannot be filed as an incidental accessory of a hardware product. The conclusion of GRZAN: for software products, the compliance focus shifts from physical performance testing to classification argumentation, lifecycle documentation and algorithm validation; after Decision No. 65 of 2023 aligned the software classification criteria with the IMDRF, classification outcomes may change, and legacy software products must be reviewed.

2. Legal basis

3. Expert insights

Insight 1: the two rules characterize software identically, so the definitions corroborate each other. Article 2 of Decision No. 27, in defining an active medical device, states that stand-alone software is regarded as an active medical device; Article 3 of Decision No. 173 likewise provides that stand-alone software is regarded as an active medical device. GRZAN points out that the identical wording in both places leaves no exception: as long as a product meets the definition of a medical device and is supplied in a stand-alone form, it is handled as an active medical device, with all the consequences for classification, testing and inspection that follow.

Insight 2: the test for being active is the source of energy. Article 2 of Decision No. 27 defines an active medical device as a medical device used alone or in combination with other medical devices whose operation depends on a source of energy not generated by the human body and not generated by gravity. It further provides that a medical device used to transmit energy or substances from an active medical device to the user without substantial change is not an active medical device. GRZAN points out that software runs on the power supply of computing equipment and therefore falls within the category of energy not generated by the human body, which is why it is active.

Insight 3: the 2023 amendment aligned software classification with the IMDRF. When Board Decision No. 65 of 2023-05-23 amended the classification rules, it took into account changes in enforcement practice in this field as well as changes in the IMDRF documents on software as a medical device. GRZAN points out that software classification is no longer the simple heuristic that any diagnostic aid is Class 2a; the classification must weigh the degree to which the information influences diagnostic or therapeutic decisions, the seriousness of the condition being managed, and similar factors, so high-impact software may rise to Class 2b or Class 3, which in turn triggers mandatory production inspections.

Insight 4: the route to compliance with the general requirements differs from hardware. Within the general requirements of Decision No. 27, the items on mechanical and thermal risks and on the delivery of energy and substances do not apply to software; the core burden of proof for software falls on the principles of risk management, the provision of information, labeling and instructions for use, and performance and effectiveness. Article 4 of Decision No. 27 sets out the risk management principles in order of priority: identify known or foreseeable hazards and assess the risks; eliminate the risks through appropriate technical solutions in design and manufacture; adopt appropriate protective measures to reduce residual risks; and inform users of the residual risks. These apply to software as well. GRZAN points out that for software, informing users of residual risks typically lands on interface warnings and the caution items of the instructions for use, and each item must be mapped individually.

Insight 5: Articles 9 to 11 of Decision No. 27 are the main battlefield for software compliance. Article 9 requires that each medical device be provided with the information necessary to identify the device, its manufacturer and its country of origin, together with information for users on safety, functional properties and operating characteristics; this information may appear on the device itself, on the packaging or in the instructions for use. Article 10 requires that the medium, format, content and placement of the information be appropriate to the medical device, its intended purpose, and the technical knowledge, experience, education or training of the user. Article 11 provides that the information required by Article 9 appears in Russian on the label and in the instructions for use and, where the legislation of a member state so requires, in the national language of that state. GRZAN points out that for software this means the software interface, the electronic instructions for use and the labels must all satisfy these language requirements.

4. Practical recommendations

1. Build a stand-alone dossier: classify stand-alone software independently and prepare its registration documentation separately, without consolidating the filing with a hardware product.
2. Review the classification under the 2023 criteria: redo the classification argumentation for legacy software products, paying particular attention to whether the result rises to Class 2b or Class 3 and thereby triggers mandatory production inspections.
3. Map the risk management item by item: draft the software risk management report following the four-step sequence of Article 4 of Decision No. 27, landing each residual risk on interface warnings and instructions-for-use cautions.
4. Plan language localization early: include the Russian versions of the software interface, electronic instructions for use and labels, and the Armenian versions as needed, in the development plan from the start.
5. Confirm the technical testing route in advance: whether and how technical tests apply to software should be confirmed with the competent authority of the reference state before filing (a practical estimate: the testing arrangements for software products vary case by case in practice).

5. Verification checklist

1. □ It has been confirmed that the software meets the definition of a medical device and is characterized as an active medical device.
2. □ The classification argumentation has been completed under the IMDRF-aligned criteria as amended in 2023.
3. □ It has been confirmed whether the classification outcome triggers mandatory production inspection, Class 2b and Class 3.
4. □ The software risk management report has been drafted following Article 4 of Decision No. 27.
5. □ The Russian localization, and the Armenian localization as needed, of the software interface, electronic instructions for use and labels has been completed.
6. □ The applicability of technical tests has been confirmed with the competent authority of the reference state in advance and the exchange is documented.
7. □ A stand-alone registration dossier with technical documentation version control has been established for the software.

Regulatory information verified as of October 30, 2026.

GRZAN service note. GRZAN supports software manufacturers with Eurasian Economic Union and Armenia registration, including stand-alone software classification under the IMDRF-aligned criteria, lifecycle documentation, risk management reporting and multilingual interface localization. Regulatory monitoring is updated continuously and confirmed against the official sources cited above. For inquiries, contact info@grzanglobal.com.