SaMD Registration Path: Software Classification and Lifecycle Evidence in Chile

1. Key takeaways

Exempt Decree No. 25/2026 brings medical device software (SaMD) for oncology image processing, analysis and treatment planning into the controlled list, which moves SaMD in Chile from being a device in principle to being a device that actually requires registration. The legal chain is clean: the device definition in Article 2, item 1, of DS 825/1998 has expressly included software since 1998 — what was missing was only the listing decree, and that gap is now closed.

GRZAN’s assessment: the difficulty of a SaMD submission in Chile is not whether software is a device, but how to organize lifecycle evidence — software has no physical form, so its risk management and performance evidence must be built as a documented chain from requirements through verification to maintenance. The chain also has to be maintained over time: unlike a bolt or a syringe barrel, a software release can silently alter behavior that an earlier submission described.

2. Legal basis

• Regulation on the control of pharmaceutical products and medical devices | Decreto Supremo N° 825, de 1998 | August 21, 1999 | Article 2, item 1: the medical device definition expressly includes software (incluyendo software), with a principal intended action not achieved by pharmacological, immunological or metabolic means.
• Same instrument | Article 2, item 14 | the intended use is that indicated by the manufacturer on the label, in the instructions for use and/or in promotional material.
• Same instrument | Article 20 | the four risk classes; Article 21 | class-specific dossier requirements (including scientific literature, effectiveness and safety studies, and representative patient population studies for Classes III and IV).
• Decree listing devices under the sanitary control regime of Article 111 | Decreto Exento N° 25, de 2026 | March 19, 2026 | brings medical device software for oncology image processing, analysis and treatment planning into scope; conformity evaluation is benchmarked against NCh-ISO 16142-1 and 16142-2, NCh-ISO 13485, NCh-ISO 14971 and product-specific standards.
• Sanitary Code | DFL N° 725, de 1967 | Article 111(c) | Chilean official standards first; where no NCh standard exists, standards approved by the Ministry of Health apply.

3. Expert insights

Insight one: software entering the list is not new legislation; it is the new application of an old definition.

Article 2, item 1, of DS 825/1998 has said including software since publication on August 21, 1999. Exempt Decree No. 25/2026 merely advances it from definition coverage to actual control. The consequence for sponsors: there is no need to argue whether software is a device — the argument to prepare is which class of device this software belongs to. Redirecting the analysis from definitional debate to classification saves weeks of unnecessary legal work and matches how the ISP reads the framework. The classification should be documented with the same rigor as the intended use, because the class determines both the dossier scope and the applicable transition deadline.

Insight two: the industry benchmark for software lifecycle evidence is IEC 62304.

Article 111(c) establishes the hierarchy of NCh first, then alternatives. Software lifecycle activities — requirements, architecture, detailed design, implementation, verification, maintenance — are conventionally organized under IEC 62304. GRZAN recommends documenting the absence of a corresponding NCh standard in writing before invoking the alternative path. The written statement converts a silent substitution into a reasoned application of the statutory hierarchy, which is materially harder for a reviewer to object to. Mapping each IEC 62304 activity to the dossier chapter where it appears gives the reviewer the same navigability that the compliance table gives the essential principles.

Insight three: the intended use of SaMD is the easiest place to write too broadly.

Processing, analysis and treatment planning for oncology images is a clear functional boundary. Describing the software as supporting diagnosis, or worse as diagnostic, raises the risk class and the evidence requirement together. Article 2, item 14, anchors the intended use in the manufacturer’s own indications — writing narrowly and factually is the cheapest strategy in the whole project, because every word added to the indication multiplies the evidence owed behind it. Boundaries belong in the intended use statement: what the software processes, what it outputs, and what decision remains with the clinician.

Insight four: software has no batches, but it must answer for versions and changes.

Article 21(a), point 1, requires identification information to include batch numbers and coding; for software the counterpart is the version number and build number. Exempt Decree No. 25/2026 also provides that significant changes affecting quality, safety or performance require a new registration application. Software release cycles therefore need a mechanism that decides whether a given release is a significant change; without one, every release carries compliance uncertainty that grows with shipping frequency. The mechanism should record the decision for each release, so the history of the product’s regulatory position can be reconstructed at any time.

4. Practical recommendations

1. Do not litigate whether software is a device; go straight to class determination.
2. Organize the evidence by software lifecycle: requirements, architecture, design, implementation, verification and maintenance, each stage documented.
3. State the situation of NCh standards in writing, and invoke the alternative path of Article 111(c) where no NCh standard exists.
4. Write the intended use narrowly and factually, keeping it consistent across the dossier, label, instructions for use and promotional material.
5. Establish a release change evaluation mechanism: every release is assessed for whether it constitutes a significant change affecting safety or performance.

5. Verification checklist

• □ It is confirmed that the software falls within the device definition of Article 2, item 1, of DS 825/1998
• □ It is confirmed that the product is within the list of Exempt Decree No. 25/2026 (oncology image processing, analysis or treatment planning)
• □ The evidence chain is organized by software lifecycle
• □ The situation of NCh standards and the alternative path are stated in writing
• □ A mechanism for judging significant changes of software versions is in place

Regulatory information verified as of October 29, 2026.

For a product-specific feasibility assessment of Chile market entry, GRZAN’s regulatory team supports manufacturers and importers with registration dossiers, conformity documentation and ISP submissions. Contact info@grzanglobal.com to discuss your project.