With the advancement of digital technology, Software as Medical Devices (SaMD) has become an essential part of healthcare innovation. These allow diagnoses and therapies to be carried out through digital platforms, without being tied to specific hardware. To ensure the safety and effectiveness of these products, Anvisa’s RDC 657/2022 establishes regulatory requirements, and the agency also provides a Q&A document to clarify any questions.
In this article, we explore the details of the specifications and criteria for the regulation of SaMD, including topics like cybersecurity, interoperability, validation, and technical requirements, using charts and gap analysis tools to facilitate understanding.
- What is an SaMD?
According to RDC 657/2022, Software as a Medical Device (SaMD) is any software with a medical purpose, whether for diagnosis, monitoring, treatment, or other clinical applications, which is not physically integrated with medical hardware. These software programs can be used on various devices, such as smartphones and tablets, and include cloud-hosted systems like Software as a Service (SaaS).
Additionally, Anvisa’s Q&A document clarifies several specific situations, such as the exclusion of software designed solely for administrative management or well-being, which are not subject to regulation.
Practical example: Apps that help monitor well-being, such as tracking physical exercises, do not qualify as SaMD, as they do not have a direct medical function.
- Cybersecurity and Interoperability
Cybersecurity is one of the pillars of regulation for SaMD, as highlighted in both RDC 657/2022 and the Q&A document. Anvisa requires that software be protected against unauthorized access and that processed data remain secure. Additionally, the SaMD must ensure interoperability, meaning the ability to operate with other medical devices or IT systems without compromising functionality. For instance, integration with hospital systems through standard protocols like HL7* is essential to ensure smooth information flow.
*HL7 (Health Level 7) is a set of international standards for exchanging, integrating, sharing, and retrieving electronic health information. These standards are widely used in hospital information systems, laboratories, and clinics, allowing interoperability between different healthcare systems such as hospital management software, medical devices, electronic medical records systems, and other clinical tools.
Key characteristics of HL7:
- Interoperability: HL7 facilitates communication between different healthcare systems, ensuring that data, such as medical histories, test results, and patient records, can be exchanged in a standardized and understandable way across different platforms.
- Standardization: It defines specific protocols and formats to ensure data can be transmitted in a structured way, avoiding misunderstandings between systems developed by different vendors.
- Versatility: HL7 is used to communicate a wide variety of information, such as medical records, lab results, monitoring data, and alert messages between clinical systems.
Practical example:
A hospital using HL7-based clinical management software can easily integrate exam information from different laboratories or patient monitoring with medical devices from various manufacturers. This allows all data to be aggregated into the patient’s electronic medical record transparently. HL7 is essential to ensure that SaMD (Software as a Medical Device) is compatible with other medical systems, enabling efficient communication between software, medical devices, and hospital networks.
- Regulation and Risk Classification
The classification of software as medical devices follows Anvisa’s standards, particularly those described in RDC 657/2022 and RDC 185/2001. This classification is divided into four risk classes, based on the impact the software may have on human health:
- Risk Class I and II SaMD: Require notification and basic technical documentation.
- Risk Class III and IV SaMD: Require a more rigorous registration process, including clinical evaluation, technical validation, and cybersecurity measures.
The Q&A document complements RDC 657/2022 by providing examples of software that may be exempt from regulation, such as medical scheduling apps or symptom control apps without diagnostic purposes.
Document example: Software that only organizes elderly care information without medical or therapeutic functions does not qualify as SaMD and does not require registration.
- Analytical and Clinical Validation
Validation is a critical process to ensure that the SaMD is capable of fulfilling its function accurately and safely. This includes:
- Analytical Validation: Evaluates whether the software generates correct technical results from input data.
- Clinical Validation: Ensures the software provides clinically relevant and safe outputs, in line with its intended use.
The Q&A document also highlights that even non-innovative software requires validation, although the scope may be smaller.
- FAQs: What Is Not Considered SaMD?
The Q&A document clarifies various points that may confuse software developers. Here are some frequently asked questions and their answers:
- Do administrative or financial software require regulation? No. Software used only for hospital management purposes, such as billing or logistics control, is exempt from the need for regulation.
- Is an app that reminds the patient to take their medication considered SaMD? No. Apps that simply function as medication reminders, without therapeutic or diagnostic functions, are not considered SaMD.
- Validation and Performance Requirements
The validation of an SaMD includes both analytical and clinical validation, to ensure that the software is capable of performing its intended function accurately and safely. Anvisa requires robust evidence that the SaMD is effective and safe for clinical use.
Conclusion
The development of an SaMD requires companies to strictly follow the rules of Anvisa in RDC 657/2022. The Q&A document provides additional guidance on common questions, helping ensure that companies meet all regulatory requirements.
📝 Access RDC 657/22 and the Q&A document on SaMD:
The original text of this announcement is the official authorized version. Translations are provided solely for convenience and must refer to the original text, which is the only version that has legal effect.
- Click the link to access the Original Version – RDC 657/2022
- Click the link to access the Q&A – RDC 657/2022
If you have any questions, contact Brisa Advisors for specialized regulatory support.
Find out more about BPO in RA!
*Budget for registration ownership transfer, Market Access Strategy, and BPO in RA services for your company: www.brisa.com.br
