Seven Additional Requirements for Medical IT Systems: Article 6.3.2.3

1. Key takeaways

Article 6.3.2.3 of RTS 11.03.02:21 adds seven requirements for medical IT systems (sistemas informáticos de uso médico) on top of the twelve general items: a) a description or diagram of the main components and accessories, where applicable; b) a technical report on the system design and technical considerations; c) a technical report on cybersecurity, information storage and communication; d) verification and validation test reports for the system; e) a report on version history and on resolved and unresolved anomalies and errors; f) a technical file supporting the version deprecation date; g) a clinical evaluation study, where applicable. The total is twelve plus seven, that is nineteen items.

The list is unusual in that three of the seven items describe the evolution of the software rather than a single frozen version. The regulation therefore treats the software lifecycle itself as an object of review, not merely the build submitted with the application.

Two qualifying phrases also matter for scope. Items a and g are limited by where applicable, the first because a standalone software product may have no physical accessories to draw, the second because a clinical evaluation may not be required in every case. The remaining five items carry no such qualifier, which means that design, cybersecurity, verification and validation, version history and the deprecation file are expected in every medical IT system dossier regardless of how the product is configured.

• Seven additional documents apply to medical IT systems, for a total of nineteen items.
• Design and technical considerations must be argued in a dedicated report.
• Cybersecurity, information storage and communication form a single technical report.
• Version history must disclose unresolved anomalies, not only fixed defects.
• The deprecation date of a version requires its own supporting file.
• Clinical evaluation is required where applicable, which separates this list from the other-device list.

2. Legal basis

The additional items for medical IT systems are supported by the definitions in articles 3.14 and 3.17, which bring software within the device definition and treat the information programs needed for operation as part of biomedical equipment. The table records each provision and the obligation it creates.

3. Expert insights

First insight: the list shows that El Salvador reviews the software lifecycle, not only a build. Three of the seven items, namely the version history and defect report under e, the deprecation date under f and the verification and validation tests under d, point directly at how the software evolves rather than at a static snapshot. The consequence is that registration of a software product is not a one-off snapshot of a version: subsequent version evolution must be filed as a change notification under article 6.3.3 c). Planning the product roadmap and the regulatory calendar together therefore becomes a practical necessity rather than a refinement.

Second insight: item e requires unresolved anomalies and errors to be reported, which is an unusual disclosure duty. The provision refers to historial de versiones, anomalías, errores resueltos y no resueltos, covering both the resolved and the unresolved. Most markets accept software documentation that describes only known and fixed defects, whereas El Salvador brings unresolved items inside the scope of the report. The practical treatment is to list the unresolved items and to state the assessed impact on safety and performance together with the mitigation in place, so that disclosure is not later read as concealment.

Third insight: cybersecurity under item c follows a different route from the other-device list in article 6.3.2.5. Item c consolidates cybersecurity, information storage and communication into one technical report, a requirement specific to medical IT systems, while the nine items in article 6.3.2.5 for other devices contain no cybersecurity item at all. A hardware device with embedded software and a pure software system may therefore face different additional lists, and the determining question is whether the product is filed as a medical IT system. Settling that classification before drafting saves substantial rework, because the two lists diverge on exactly the documents that take longest to produce.

Fourth insight: the deprecation date under item f and the five-year validity under article 6.3.1 f) are managed on different clocks. The version deprecation date is a technical statement by the manufacturer about its support period for the software, whereas the five-year term is the legal duration of the registration. A software version deprecated inside the registration term does not automatically invalidate the registration, but it does trigger a change notification under article 6.3.3 c). Treating the two dates as one is a common source of missed notifications, because the technical date usually arrives first and quietly.

In practice the two clocks are best held in one table: one column for the legal term of the registration, one column for the support period of each version in the field, and one column for the notification obligation that follows when a version reaches its deprecation date. That table also answers the question a distributor will ask first, namely which version is authorised and until when.

4. Practical recommendations

• Build the medical IT system index on twelve plus seven, that is nineteen items.
• List resolved and unresolved anomalies in the version history report, with an impact assessment and mitigation for each unresolved item.
• Cover information storage and communication in the cybersecurity report, and do not substitute a penetration test result for the report itself.
• Decide whether the product is filed as a medical IT system or as another device, and select the additional list accordingly.
• Bring software version evolution into the change management process under article 6.3.3 c).
• Manage version deprecation statements and the five-year registration term separately, each with its own reminder.

5. Verification checklist

• □ IT system dossier complete at nineteen items
• □ Version history includes unresolved anomalies and their impact assessment
• □ Cybersecurity report covers storage and communication
• □ Product category determined as IT system or other device
• □ Software version evolution included in the change process
• □ Deprecation date and registration term managed separately

The regulations cited in this article are RTS 11.03.02:21, Dispositivos Médicos. Requisitos para la Regulación Sanitaria de Dispositivos Médicos (Acuerdo No. 14-2022, Diario Oficial No. 156, Tomo No. 436, 2022-08-23), articles 3.14, 3.17, 6.3.2.3 a)–g), 6.3.2.5, 6.3.3 c) and 6.3.1 f).

Regulatory information verified as at 29 October 2026.

How GRZAN can help. GRZAN provides medical device and IVD registration, quality system, authorised representative and local testing support for the Salvadoran market. Our team manages Ministry of Health (MINSAL) sanitary registration applications, prepares Spanish-language dossiers, and supports post-market vigilance obligations. Business enquiries: info@grzanglobal.com