Already an IBA member? Sign in for a better website experience
Software as a medical device in Brazil: a bird’s-eye view of the current legal framework and prospective regulation
Renata Fialho de Oliveira
Veirano Advogados, São Paulo, Brazil
Beatriz Gonçalves Marconi
Veirano Advogados, São Paulo, Brazil
The current regulatory framework applicable to software as a medical device
The National Health Surveillance Agency (ANVISA) is responsible for the regulation of the pharmaceutical and life sciences sector in Brazil. Its scope of authority also encompasses licensing at the federal level and issuance of good manufacturing practices certificates. Despite ANVISA’s extensive regulation on several matters, it has not yet published specific rules concerning software as a medical device.
When ANVISA exercises its authority with respect to software as a medical device, it applies Resolution No 185/2001, which relates to medical devices in general. From the letter of Resolution RDC No 185/2001, one realises that the resolution intended to regulate physical (tangible) products, not digital (intangible) ones. It was enacted and built for another time when acceleration of digitisation in health as per today’s standards was far from being anticipated. As a result, certain issues with the ‘one size fits all’ approach arise when it comes to applying to software as a medical device the same specifications applicable to medical devices in general.
To explain what kind of software may be deemed a medical device subject to sanitary surveillance, ANVISA published Technical Note No 4/2012. A Technical Note is not a rule, therefore it is not binding, but rather aims at expressing ANVISA’s understanding of a specific matter with the purpose of guiding and assisting regulatory technicians and experts, as well as companies dedicated to regulated products, in their evaluations and regulatory compliance.
Under Technical Note No 4/2012, ANVISA classifies software in three categories:
- software as a medical device, per se;
- software that is part (or accessory) of a medical device; and
- software that is not a medical device.
Software as a medical device
This is software that serves the prevention, diagnosis, treatment, rehabilitation or anti-conception of human beings but does not require a hardware classified as medical device for being executed. As a standard, it is executed by an isolated computer. Examples under the Technical Note are: software for radiotherapy planning; intended to perform medical data processing, with a view to diagnosis and monitoring; or for the calculation, estimation, modelling and prediction of surgical placements (surgical navigators) or dosimetry regimes.
Software that is part (or accessory) of a medical device
This is those that need a hardware classified as a medical device to which it connects to properly function, thus being an integral part (or accessory) of it. In this case, as a rule, the software is subject to the same regulatory clearance pathway (enrolment/registration) together with the hardware. In some specific cases when the software has a risk classification higher than that of the medical device and it is not provided by the manufacturer of the medical device, it must have separate registration. Examples include: software that controls or monitors the functions of a medical device; a surgical browser on a separate computer that connects with an X-ray machine; or software that transfers information from medical equipment (such as picture archiving and communication system).
Software that is not a medical device
This includes those that do not fit the definition of RDC 185/01, that is, are not used in human beings for prevention, diagnosis, treatment, rehabilitation or contraception. In this case, for example, software that ‘transmit information to the patient solely for its knowledge, indicating that said information is not intended for prevention, diagnosis, treatment, rehab or contraception’ are not considered medical devices. Examples under the Technical Note are software that: transmits data to patients for their mere knowledge; is used as information manager and storage (such as electronic medical records); or is used to assist in the general maintenance of medical devices or medical device components (eg, parts lists or service drawings).
Technical Note No 4/2012
The Technical Note itself, besides not being mandatory, is roughly 10 years old and rarely affords clear-cut answers with respect to classification. In addition to the uncertainty concerning classification of a software as a medical device or not, the lack of specific regulation presents at least two additional issues.
One is the difficulty that software developers face to meet the general regulatory requirements for obtainment of regulatory clearance, since the rules were created considering physical products. Considering that a requirement to obtain a Good Manufacturing Practice Certificate (GMPc) is that a ‘company's facilities are properly designed in order to provide the performance of all operations, prevent exchanges or contamination of components, manufacturing materials, intermediate and finished products and ensure their correct handling, including adequate flow of people’, how does a software developer obtain a GMPc?
Also, relevant aspects for the assurance of security and effectiveness of a health-related software are not required by the general regulation. Examples of such are cybersecurity measures to protect the user access or requirements related to quality management systems or compliance with international standard (such as ISO 13485 – Medical Devices – Quality Management Systems – Requirements for Regulatory Purposes).
The undergoing process for regulatory improvement
As of 2012, there has been an effort to make regulation in Brazil, as a rule, more result-orientated. Such trend is a reflection of Law No 12,376/2010, as further amended, which reformulated the framework of Brazilian legal system (Lei de Introdução às Normas do Direito Brasileiro) and emphasized the need for ‘analysis of practical results’ of decisions by public authorities. It is also as a result of the requirement of ‘regulatory impact analysis’ by regulatory agencies, as well as the concept of ‘abuse of regulatory authority’ set forth inthe Decree No 10.178/2019, which regulates the ‘Declaration of Economic Freedom Rights’ and the right to require update of rules that are technically outdated.
In this context, in view of the lack of appropriate regulation ensuring adequacy and safeness of software as a medical device, ANVISA launched a regulatory impact analysis in 2019. The study reviewed the regulation on the matter in several jurisdictions (such as the US, Canada and Europe) and compared the alternatives to address it (creation of a specific regulation, of a mandatory certification, of a simple guidance or of a ranking of the products). The study’s result targeted the preparation and enactment of a specific regulation, since it is faster to be prepared, readily enforceable and affords better levels of scrutiny to ensure product safety.
On 8 April 2021, ANVISA published a public consultation (Public Consultation No 1035/2021) proposing a new regulation of software as medical devices, to fill the regulatory gap for this type of product. The agency aims to increase safe access to products subject to sanitary surveillance, improve pre-marketing actions and clearance based on risk classification and have a more harmonised set of rules with international entities it is a party to, such as the International Medical Devices Regulators Forum (IMDRF). The Public Consultation has already ended, and the contributions are under scrutiny of the agency.
Overview of the draft regulation
According to the draft rule made available through Public Consultation No 1035/2021, the new regulation will not be a substitute, but rather will complement the old rules in certain aspects. Thus, most parts of the general regulation will remain in place as suitable for software as medical devices. For example, software will continue subject to the regulatory clearance being subject to notification or registration, depending on its risk classification. Still, as expected, the upcoming regulation may contain some novelties.
First, the new regulation may set forth additional requirements and documentation for regulatory clearance of software as medical devices that are not necessary or applicable for physical products. One example relates to the documents and information that should be included in the technical dossier of software. This is an important point considering that the current regulation does not require any software-specific documentation. Also, the new rule intends to establish specific safety and effectiveness requirements to ensure repeatability, reliability, and performance according to their intended use and the need to comply with international parameters (such as: IEC 62304:2006, IEC 62366-1:2015 and ISO 14971:2007).
The draft regulation also lists the software that are not considered to be medical devices, those:
- used for wellness;
- listed as products that ANVISA does not regulate;
- used exclusively for administrative and financial management in healthcare services;
- that processes medical, demographic and epidemiological data without any clinical, diagnostic or therapeutic purpose; and
- embedded in medical equipment are not software as medical devices.
The approach is like the one set forth in Technical Note No 04/2012, but the intention is to clearly determine it through a mandatory regulation.
A few critiques to the draft resolution
One of the deficiencies of the proposed regulation is that it does not clearly determine the software that is considered medical devices or establish detailed requirements for framing software as a medical device. Currently, it is difficult to determine whether a software will be considered as a medical device, because in practical terms there are cases in which it is questionable whether its function could be considered as diagnostic or therapeutic by the authorities, for instance, when the software’s purpose is monitoring a medical condition or calculating the dosage of a drug that a patient should use. In this sense, the draft regulation has not afforded greater clarity when compared with the current regulatory framework.
Also, the new proposed rule does not clarify issues related to Good Manufacturing Practices that ANVISA Resolution RDC No 185/2001 and ANVISA Resolution RDC No 40/2015 refer to. The gap in the understanding of the application of these requirements for software as a medical device remains.
By reviewing the contributions to the Public Consultation, further critiques to the draft resolution include the fact that ANVISA did not consolidate the matter in a single resolution, but added a new set of rule to all others, obligating the regulated agent to comply with the various sparse legal provisions; there are several concepts and specifications that were not expressed in the resolution; and the risk classification is not aligned with the IMDRF.
As previously indicated, the update of regulation is a requirement under Law No 12,376/2010, and Decree No 10.178/2019. Recently, authorities have been striving to improve and update the regulatory framework in a way that the new technologies are covered by sector regulation, to facilitate the general understanding of the rules and guidelines that must be complied with by the players of the sector for the performance of its activities. In this context, regulatory sandboxes may prove a useful tool for the continued revision and update of the rules in force.
Hopefully, ANVISA will follow the trend and facilitate the entry of new technologies related to regulated software as medical devices and any other matter that deals with the new technologies. The Agency shall review and consider the contributions and seek to adjust the final draft resolution to afford greater legal certainty concerning software as medical devices. The creation of the regulatory sandbox by new legal framework for startups (Supplementary Law No 182/2021 – usually called ‘Marco Legal das Start-Ups’) may be helpful for ANVISA to allow for exceptional regulatory environment when it comes to low-risk products, removing or simplifying some of the existing legal standards and requirements to grant temporary authorisation for the development of new business/technologies.