Class IIA: ISO 13485 and Software Documentation

1. Key takeaways

Acuerdo No. 0631-ARSA-2023, the Reglamento para el Control Sanitario de Dispositivos Médicos y otros Dispositivos de Interés Sanitario, provides in Article 44 that the dossier for Class IIA devices consists of the items listed in Article 43 plus three additions: 1 the currently valid version of ISO 13485, or other documentation issued by the regulatory authority proving that the ISO standard has been implemented; 2 for IVDs, an added validation report of the test, assay or product; 3 for medical computer systems (software), an added set of seven technical documents. Article 3 has already placed softwares within the device definition (Article 25), and Article 44, item 4, sets the most specific group of requirements for software in this market. The GRZAN regulatory team notes: ISO 13485 is submitted for the manufacturer, not the registering company; the name and address on the certificate must match item j of the application form, Manufacturer, word for word. A group certificate or an affiliate’s certificate will be treated as a party mismatch.

2. Legal basis

The table below maps each requirement of Article 44 to its provision and key point.

3. Expert insights

Insight 1: ISO 13485 is the dividing line for Class IIA, but the provision offers an alternative route. Article 44, item 2, reads: ISO 13485 in its currently valid version, or other documentation issued by the regulatory authority proving implementation of the ISO standard. This or leaves room for manufacturers without an ISO 13485 certificate — but the alternative document must be issued by a regulatory authority; a self-declaration by the company does not satisfy the requirement.

Insight 2: three of the seven software items are process evidence, not product evidence. Item 4 b), the design technical report; item 4 c), the cybersecurity and information storage and communications report; and item 4 d), the validation and verification test report — these three documents demonstrate that the development process was controlled, not that the final product is compliant. The GRZAN regulatory team recommends that software products start assembling these three documents at the classification stage; their preparation cycles are usually longer than for hardware materials.

Insight 3: item e) requires disclosure of unresolved anomalies and errors. The version history report must list both resolved and unresolved anomalies and errors. This is the point most often tampered with during localisation — local agents often suggest deleting the unresolved items. Our position is to disclose them truthfully together with risk mitigation measures, because Article 6, item 2, requires the manufacturer to assess and reduce foreseeable and known risks; concealment conflicts with those principles.

Insight 4: item f) turns the version validity period into a documentation requirement. The provision requires technical documentation establishing the current version and its validity period. This means software products must declare a version validity period, which — like the product description and indications in Article 43, item 1 l) — is information the reviewer can compare directly.

Insight 5: Class I software gains no extra items merely for being software. Article 43 sets no supplement for software; only Article 44, item 4, does. This is a common misunderstanding: the additional software burden starts at Class IIA. Budget software products by classifying first; do not assume cost on the premise that software is always the hardest.

4. Practical recommendations

• Check the manufacturer name and address on the ISO 13485 certificate word for word against item j of the application form.
• Where there is no ISO 13485 certificate, prepare an equivalent ISO implementation document issued by a regulatory authority, not a self-declaration.
• Start assembling the three process-evidence documents — design, cybersecurity and testing — for software products at the classification stage.
• List unresolved anomalies and errors truthfully in the version history report, with risk mitigation measures.
• Declare a clear current version and version validity period for software products.
• Classify software products before estimating the workload: nothing is added for Class I, and seven items are added from Class IIA.

5. Verification checklist

• □ The ISO 13485 certificate holder has been checked word for word against the manufacturer data in the application form
• □ Where no certificate exists, an equivalent document issued by a regulatory authority has been obtained
• □ Assembly of the three software process-evidence documents has started
• □ The version history report truthfully lists unresolved anomalies and errors
• □ The software product has declared its current version and version validity period
• □ The software documentation workload has been confirmed by class (nothing for I; seven items from IIA)

Related reading: [Article 21 — The sixteen Class I dossier items](/honduras-medical-device-registration/class-i-dossier-sixteen-requirements/) | [Article 23 — Class IIB device-specific ISO standards](/honduras-medical-device-registration/class-iib-device-specific-iso-standards/) | [Article 03 — What counts as a medical device](/honduras-medical-device-registration/medical-device-definition-article-25/)

Regulatory information verified as of October 29, 2026.

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