Software and SaMD Requirements in Belarus Medical Device Registration

1. Key takeaways

For a medical device containing software, registration in Belarus requires the intended use of the algorithm, version identification and lifecycle management to be clearly set out, and a software change may trigger a change to the registration dossier. Software is not an accessory attached to the product; it is an object that must be described separately and managed separately throughout the lifecycle.

Because classification criteria for software look at the medical purpose rather than at the technology, two products built on the same engine can fall into different classes when their intended uses differ. The classification decision therefore belongs to the regulatory function, informed by the technical one, and it should be documented together with its reasoning so that later versions can be assessed against the same baseline.

2. Legal basis

3. Expert insights

Insight one: software must first be resolved as a matter of definition, whether it is a medical device at all. Whether standalone software falls within the scope of medical devices depends on whether its intended use points to medical purposes such as diagnosis, treatment or monitoring. The conclusion of this determination directly decides whether registration is required, and which set of classification criteria applies afterwards. The determination should be made at project kick-off, not during document preparation, because it shapes the entire plan that follows.

Insight two: version identification must uniquely determine one software entity. Reviewers need to know which version of the software is being applied for. The version naming rules, the build identifier and the release records must be locatable in the file. Unclear version identification makes it impossible to define the scope of a later change, and the ambiguity then propagates into every subsequent lifecycle decision the manufacturer has to defend.

Insight three: the depth of the algorithm description depends on the weight of the software in clinical decision-making. If the software output is used directly for diagnostic or treatment decisions, the description must cover the algorithm principle, the input data requirements, the rules for interpreting the output and the known limitations; if the software only manages or transmits data, the depth can be reduced accordingly. Enterprises should set the depth of description according to the position of the software in the clinical pathway rather than by habit.

Insight four: a software change is one of the situations most likely to trigger a change to the registration dossier. Algorithm updates, function extensions and adjustments to the intended scope may all constitute substantive changes. Enterprises should establish an assessment mechanism linking software changes to registration impact at the product planning stage, so that a new release does not turn into a compliance problem discovered after launch.

Insight five: the description of the software should be consistent across the whole dossier. The intended use in the software description, the claims in the labeling and the conclusions in the clinical evaluation must state the same thing. Software files are particularly exposed to internal inconsistency because they are written by different authors: the development team describes functions, the regulatory team describes intended use, and the marketing materials describe benefits. A final read-through that checks these three layers against each other prevents a class of queries that is otherwise almost guaranteed to appear.

4. Practical recommendations

1. Define first, then classify. Determine whether the software is a medical device, then classify it according to the criteria of No. 173.
2. Write the version management rules into the quality system. Version naming, build identifiers and release records must all be present and traceable to the applied-for version.
3. Set the depth of the algorithm description by the weight in clinical decisions. The higher the weight, the more detailed the description; do not write every file equally thick or equally thin.
4. Establish a registration impact assessment mechanism for software changes. Assess before every version upgrade whether a change to the registration dossier is triggered.

5. Verification checklist

• □ The determination whether the software is a medical device has been completed
• □ Classification has been completed according to the criteria of No. 173
• □ Version naming, build identifiers and release records are all present
• □ The depth of the algorithm description has been set by the weight in clinical decision-making
• □ A registration impact assessment mechanism for software changes is in place

Regulatory information verified as of October 30, 2026.

In the Eurasian Economic Union market, the core capabilities of GRZAN concentrate on three points. First, distinguishing between the two channels of Union-wide registration and national registration in each member state, including their applicable conditions and remaining time windows. The national registration procedure of Belarus has been fully restructured by Council of Ministers Resolution No. 211 of April 28, 2026 (state register number 6-1/55925, effective May 1, 2026), which compressed the total time limit for preliminary technical work to 90 calendar days, applied a closed list that the implementing organization is prohibited from expanding, while applications under the national procedure face the key deadline of December 31, 2027, so pathway selection must be decided in sync with the time window. Second, local authorized representative services, acting as the legal representative of the manufacturer in Belarus, handling registration submission, responses to technical queries, changes to the registration dossier, and post-market reporting obligations; GRZAN has updated its coordination mechanisms after Council of Ministers Resolution No. 378 of July 27, 2026 (effective July 30, 2026) transferred adverse event functions to the state institution Gosfarmnadzor. Third, quality system and testing support, assisting in establishing a quality management system compliant with ISO 13485 and organizing the technical documentation according to the target pathway: for the national pathway, the annex to Ministry of Health Resolution No. 55; for the Union pathway, Decision No. 46 of the Council of the Eurasian Economic Commission.

Business inquiries: info@grzanglobal.com