As technology advances across all healthcare fields, Software plays a significant role in all products. It is widely integrated into digital platforms serving both medical and non-medical purposes. Medical device software is one of three types of Software related to medical devices.
The other two types of medical device software include Software that is an integral part of the medical device (medical device software) and Software used in manufacturing or maintaining the medical device.
Software as a Medical Device Introduction
The International Medical Device Regulators Forum (IMDRF) defines SaMD as “software intended for one or more medical purposes that perform those purposes without being part of a hardware medical device.”
FDA defines SaMD as “Software that meets the definition of a device in 181 section 201(h) of the FD&C Act and is intended to be used for one or more medical purposes without being part of a hardware device.”
The use of SaMD is experiencing a steady rise, with its application extending to various technology platforms such as medical device platforms, commercial “off-the-shelf” platforms, and virtual networks, among others.
This kind of software was previously referred to as “standalone software,” “medical device software,” or “health software” by industry professionals, international regulators, and healthcare providers, often leading to confusion with other software categories.
How Do I Know if My Product is SaMD?
As a member of the International Medical Device Regulatory Forum (IMDRF), the FDA recognizes the structural similarity between the two organizations’ definitions of SaMD. The definitions provided by the FDA and IMDRF highlight two criteria that must be satisfied for software to be designated as SaMD.
To evaluate if the Software is a medical device, it is important to assess its compliance with the regulatory authority’s definition. The IMDRF emphasizes that the Software must be “intended for one or more medical purposes”. On the other hand, the FDA references FD&C, or the Federal Food, Drug, and Cosmetic Act, Section 201(h), which outlines the definition of a device. This section defines a device as follows:
According to Section 201(h) of the FD&C, a device encompasses various articles such as tools, implements, instruments, machines, devices, appliances, in vitro reagents and other similar or related items, including components and accessories.
An article must also be legally recognised in the National Formulary, the United States Pharmacopoeia, or an analogous revision in order to meet the requirements of Section 201(h) of the FD&C Act’s definition of a device.
The product is intended to be used in the diagnosis of disease or other conditions as well as in the treatment, mitigation, treatment, or prevention of disease in people or animals, according to the definition of a device under FD&C Section 201(h).
In addition, a product must be intended to change any structure or function of the human or animal body without compromising its primary function for it to qualify as a device under Section 201(h) of the FD&C Act.
In addition, the definition of a device in Section 201(h) of the FD&C Act states that it must not achieve its primary purpose by chemical action in or on the human or animal body, nor must it rely on metabolism to achieve its purpose.
Note that the term “device” does not include software features that are excluded by Section 520(o). To apply this definition, it is essential to establish the intended use and indications for the use of your product. To refresh your understanding,
The intended use of a device refers to its designated purpose or the specific function for which the device is intended to be utilised. In other words, it defines the intended or intended application of the device
Indications for use pertain to the diseases or conditions that a device is designed to diagnose, treat, prevent, cure, or mitigate. These indications specify the target patient population and provide insights into why the device would be used on individuals with those diseases or conditions
Once the intended use and indications for the use of your product are defined, the second and third points in the FDA’s definition of a medical device will help determine whether your product falls under the regulatory scope of a medical device. These criteria will clarify whether your product meets the requirements for medical device regulation.
If you intend to market your software product in the United States, I recommend carefully reviewing the FDA’s guidance on Policy for Device Software Functions and Mobile Medical Applications.
This guidance provides valuable insights into the specific software functions that the FDA classifies as medical devices and functions that are not considered medical devices and, therefore, not subject to FDA regulation. Familiarizing yourself with this guidance will provide you having a thorough awareness of the regulatory environment for software products in the medical field.
If you’re still unsure about whether your product qualifies as a medical device, contacting the FDA directly for clarification is safest. Contacting the FDA now will provide reliable advice and ensure you receive accurate information tailored to your specific product and situation.
Is My Software Considered SaMD or SiMD?
When a product is found to fit the definition of a medical device, the second portion of the IMDRF and FDA definition of software as a medical device (SaMD) must be taken into account.
According to the IMDRF definition, Software must be used for its intended purpose only and must not be an integral part of a physical medical device.
According to the IMDRF, the FDA makes it clear that Software as a Medical Device (SaMD) is not a part of a hardware device and is instead intended for standalone usage for one or more medical purposes.
This further limit the scope of Software as a medical device (SaMD), as the Software used to operate or control a hardware device does not fulfil the requirements to be categorised as a SaMD. Instead, this type of Software is referred to as SiMD or “software in a medical device.”
Here are some examples of Software that assist in operating a hardware medical device, which falls under the category of Software in a Medical Device (SiMD) and not Software as a Medical Device (SaMD):
Software that controls the inflation or deflation of a blood pressure cuff
Software that controls the delivery of insulin on an insulin pump
Software used in the closed-loop control of a pacemaker.
“firmware,” or “micro-code,” indicating their classification as SiMD rather than SaMD.
To qualify as SaMD, a product must have standalone Software that independently carries out the functions defining it as a medical device, distinct from any associated hardware. The IMDRF guidance on “Possible Framework for Risk Categorization and Corresponding Considerations” further provides additional insights and clarifications regarding the SaMD definition.
1. SaMD is a medical device, including in-vitro diagnostic (IVD) medical devices.
2. SaMD can run on general-purpose computing platforms not specifically designed for medical purposes.
3. “Without being part of” means the Software is unnecessary for a hardware medical device to achieve its intended medical purpose.
4. Software intended to drive a hardware medical device does not meet the definition of SaMD.
5. SaMD can be combined, such as being integrated as a module, with other products, including medical devices.
6. SaMD can interface with other medical devices, including hardware medical devices, other SaMD software, and general-purpose Software.
7. Mobile apps that meet the defined criteria are considered SaMD.
Although it is crucial to distinguish between Software as a Medical Device (SaMD) and Software in a Medical Device (SiMD), both types of Software adhere to many common standards for development, including the global standard for software lifecycle procedures is IEC 62304. lifecycle processes.
If your Software falls under the category of SiMD, you will still find the guidance documents and standards outlined in this guide valuable and applicable.
What are Some Examples of SaMD?
1. Software that enables a mobile device to view diagnostic images from MRI, ultrasound, or X-ray scans.
2. Software that utilizes image processing techniques to aid in detecting breast cancer.
3. Software that diagnoses a medical condition by analyzing data from the tri-axial accelerometer on a smartphone.
4. Software that collects real-time patient data monitored by a healthcare professional and utilized to develop treatment plans.
Clinical Evaluation
Clinical evaluation is a methodical and well-organized process that creates clinical evidence by continuously creating, collecting, analyzing and evaluating clinical data on SaMD to create clinical trials that review the clinical context and performance indicators of SaMD.
The quality and scope of the clinical assessment is based on the SaMD function for the clinical objective, which also ensures that the SaMD score is clinically valid and can be used consistently and predictably.
3 Clinical Evaluation Software
To qualify the software, the following three criteria must be met. To qualify your software, you must meet the three criteria outlined below.
Valid Clinical Association of a SaMD
Analytical/Technical Validation of a SaMD
Clinical Validation
1. Valid Clinical Association of a SaMD
Verifying that your software’s output corresponds to the targeted clinical conditions is the main goal here. Use of secondary data analysis, clinical trials (new data generated), professional society guidelines, original clinical research, literature searches, and/or secondary data analysis are all options for carrying out that task. All SaMD should show a reliable clinical association.
2. Analytical/Technical Validation
Does your software correctly process input data to generate accurate, dependable, and precise output data?” is the question we are attempting to answer in this context. Develop supporting documentation that demonstrates your SaMD’s output met your expectations in terms of technicality.
This action is being assessed by a manufacturer as part of the software’s validation and verification phase (V&V).
3. Clinical Validation
SaMD has been evaluated in your target population and for your intended use; users are able to achieve clinically significant results through consistent and dependable use.
eSTAR (electronic Submission Template and Resource) is an initiative launched by the US Food and Drug Administration in February 2020. It is a free, interactive PDF Form that provides assistance to the applicants in preparing the CDRH medical device submission for 510(k)s and De Novos.
The content of the form is automated with an automatic verification feature, and the structure is complementary to the internal review and also harmonized with the IMDRF and guided construction for each submission section.
The US FDA has announced a pilot program in collaboration with Health Canada. The practicability of using eSTAR will be determined by the outcome of 9 participants. The pilot program has eligibility criteria as below:
Sponsorer must be in-process to submit an eSTAR application for the same medical device in Health Canada and US FDA within 6 months of acceptance into the pilot.
The submission must be for a new or significant change amendment to Class III or IV submission of Health Canada OR
A 510(k), De Novo or Pre-market Approval (PMA) original, 180-day, real-time or panel track supplement to FDA
The Sponsorer must complete the eSTAR application
The pilot program is NOT applicable to IVD devices, Combination products, CBER products or an FDA dual 510(k)/CLIA waiver application.
Limitations of eStar Pilot
Health Canada will not accept Regulatory Enrollment Process (REP) submission
Submissions are accepted only in English at present.
Interested device sponsors can send in their participation request at [email protected] and [email protected] with the subject line “Request for participation in eSTAR Pilot”. The participation email should cover the following points:
A statement asking to participate in the pilot
Applicant name
Contact name and title
Device trade name(s) `
The FDA primary product code, Global Medical Device Nomenclature (GMDN) and Preferred Name Code (PNC) of your device
A statement that the same medical device using the eSTAR will be submitted within 6 months of acceptance in the eSTAR pilot to both Health Canada and the FDA:
For Health Canada: specify if it is a new or significant change amendment for a Class III or IV submission
For FDA: specify if it is a 510(k), De Novo or PMA submission (specify if the PMA submission is original, 180-day, real-time or a panel track supplement)
The FDA and Health Canada intend to revert to emails within 3 business days. The file size should be Less Than 1 GB, and images and videos to be submitted in compressed format. The fee structure is as follows:
The revolution in the digital sector has resulted in the Internet of Things (IoT), Software as a Medical Device (SaMD), Internet of Medical Things (IoMT) and other connected devices permeating the healthcare environment, both in hospital and home, has ended up with the possibility of cyberattacks and intrusions against the connected medical devices and the networks to which such a device is connected.
Most Medical devices are connected to the Internet, hospital networks, and other medical devices to provide health care and increase the ability of healthcare providers to treat patients.
These features also increase potential risks for Cybersecurity. Medical devices, like other computer systems, are vulnerable to security breaches, potentially impacting the safety and effectiveness of the device.
Since 2005, the FDA has tried to accomplish and enhance medical device cybersecurity, and the latest FDA effort is to create draft guidance that expects security throughout the total product life cycle (TPLC).
Another effort is the Protecting and Transforming Cyber Health Care Act of 2022 (PATCH Act of 2022),which, if passed, would revise the existing Federal Food, Drug, and Cosmetic Act.
The FDA guidance establishes six broad expectations on the Secure Product Development Framework (SPDF), which covers all aspects of a product’s life cycle, for the development, release, support, and decommission and satisfy Quality System Regulations (QSR) under 21 CFR Part 820:
Cybersecurity is a fundamental part of device safety and the QSR
Security by design
Transparency
Security risk management
Security architecture
Testing/objective evidence
The FDA draft guidance, under QSR, also declares that verification and validation activities by the medical device manufacturers shall include sufficient testing performed on the Cybersecurity of the system, which validates their inputs and outputs.
Further, the FDA summarizes that cybersecurity controls require testing beyond standard software verification and validation to demonstrate that the device has a good assurance of safety and effectiveness.
The following cybersecurity testing and corresponding objective evidence would be considered as the minimum support for a premarket submission:
Security requirements
Evidence of their boundary analysis creates a rationale for their boundary assumptions.
Threat mitigation
Evidence that all the design input security requirements were implemented successfully
Evidence of testing their threat models that demonstrates effective risk control measures provided in the system and use case
Evidence of the adequacy of risk control.
Vulnerability testing – Evidence on the testing of malformed
Abuse case and unexpected inputs
Vulnerability chaining
Closed box testing of known vulnerability scanning
Software composition analysis of binary executable files
Static and dynamic code analysis
Penetration testing– Identify and characterize security-related issues that discover security vulnerabilities in the product.
Regular interval cybersecurity testing – It is performed at regular intervals to identify the potential vulnerabilities before exploitation
This draft guidance replaces the 2018 draft version, which emphasizes the importance of understanding that all medical devices are designed securely, enabling new cybersecurity risks to be mitigated throughout the Total Product Life Cycle, and it elaborates the outline of the FDA’s recommendations more clearly for premarket submission to address cybersecurity concerns.
03/08/2022 Cybersecurity Alert: Vulnerabilities identified in medical device software components: PTC Axeda agent and Axeda Desktop Server
The PTC Axeda agent and Axeda Desktop Server are cloud-based technologies that allow people to securely view and operate the same desktop through the Internet. The Axeda agent and its desktop server are owned by the computer software company PTC.
The FDA alerts all medical device users and manufacturers about a cybersecurity vulnerability identified for the Axeda agent and Axeda Desktop Server.
The agent and desktop server of Axeda are used in many medical devices across several medical device manufacturers, and all the versions of the Axeda agent and Axeda Desktop Server are affected.
On the 8th of March, 2022, the Cybersecurity and Infrastructure Security Agency (CISA) published an advisory, ICSA-22-067-01, on these vulnerabilities.
Any successful exploitation of this vulnerability could allow an unauthorized attacker to take complete control of the host operating system, resulting in full system access, remote code execution, reading or changing the configuration, system file access, accessing log information, and other denial condition.
These vulnerabilities may result in changes to the functions of the medical device and impact the availability of the remote support functionality.
As a result, PTC recommends that affected manufacturers:
To upgrade Axeda agent Version 6.9.2 build 1049 or 6.9.3 build 1051 while running older versions of the Axeda agent.
Also, to configure the Axeda agent and Axeda Desktop Server to listen only on the local host interface 127.0.0.1.
Then, Provide a unique password in the AxedaDesktop.ini file for each and every unit.
Remove the installation file.
Make sure to delete the ERemoteServer file from the host device.
Never use ERemoteServer in production.
When running the Windows operating system, first configure Localhost communications (127.0.0.1) between ERemoteServer and Axeda Builder.
When running in Windows or Linux, only allow connections to ERemoteServer from trusted hosts and block all others.
Configure the Axeda agent for the authentication information required to log in to the Axeda Deployment Utility.
So, Cybersecurity is one of the crucial aspects of today’s fast pacing digital world. The threats caused by Cybersecurity, especially on medical devices, are hard to deny. It is important to learn how to defend themselves from them and create a safe environment for the usage of medical devices.
EU MDR and IVDR
In the EU, both the MDR and IVDR Annex I create requirements for mandate consideration of medical device cybersecurity, and the Medical Device Coordination Group (MDCG), in its guidance, explains to the manufacturers of medical devices how to fulfil all the relevant essential requirements regarding Cybersecurity.
Source: MDCG 2019-16 Guidance on Cybersecurity of medical devices Figure 1: Cybersecurity requirements contained in MDR Annex I
The NIS Directive also provides for legal measures to increase the overall level of Cybersecurity in the EU.
GDPR (General Data Protection Regulation) helps the manufacturers of medical devices in regulating, protecting and processing personal data by the individual, company or organization that relates to the EU.
The EU Cybersecurity Act certifies Cybersecurity for ICT products, services, and processes.
According to the Cybersecurity Act, manufacturers are required to demonstrate state of art in the design, development, and improvement of their medical devices throughout their life cycle.
During that period, the manufacturers must consider the safety, security, and efficacy of the medical devices, and in vitro diagnostic safety mechanism design must be considered early during the manufacturing process.
Source: MDCG 2019-16 Guidance on Cybersecurity of medical devices Figure 4: Lifecycle stages
The MDCG has proposed some key philosophies of the staged security concept strategy (“defense in depth strategy”) as follows:
Security management
Specification of security requirements
Security by design
Secure implementation
Management of security-related issues
Security update management
Security risk management
The list of possible IT security requirements for the operating environment according to MDCG:
Compliance with national and EU regulations (e.g., GDPR).
Ensuring appropriate security controls are in place
Ensuring the physical security of the medical device through security measures
Ensure control and security of network traffic through proper measures
Life Cycle Aspects
Security measures specific to their workstations connected to the medical device.
Security vulnerabilities related to the device hardware/software and third-party hardware/software used with the medical device.
During the life of the devices, the manufacturer should implement the process to collect post-market information about the security of the device.
Source: MDCG 2019-16 Guidance on Cybersecurity of medical devices Figure 3: Cybersecurity measures may cause safety impacts
Based on the EU Cybersecurity Act, the manufacturer must provide the following information to the user of the medical device:
Specifications of the operating system
IT security risk assessment information.
Provisions for ensuring the integrity of software updates and security patches
Product installation
Security configuration options
Initial configuration guidelines
Step-by-step instructions for deploying security updates
Description of the backup and restore functions for data and configuration settings
Procedures for using all the medical devices in failsafe mode
The manufacturers are required to establish a post-market surveillance (PMS) system and actively keep these PMSs (Post Market Surveillance) up to date. Medical device cybersecurity requirements should be part of this PMS system.
Depending on the class of medical device, a PMS report or PSUR report will be generated, which concludes the analysis of all data from the market.
FAQs
How can we protect heath care from cyber-attacks?
· Vulnerability assessment and required testing · Training health care providers to protect from any breaches · Follow the standards of the regulations
Where is Cybersecurity used?
Cybersecurity helps in protecting the Datas, software or hardware connected with the system. This reduces unauthorized access to the data or the system.
What is the PATCH act?
PATCH act helps to meet all the Cybersecurity requirements for the manufacturer to complete FDA regulation standard.
What medical devices can be hacked?
MRI, Pacemakers, Implants, Heart rate monitors, Drug infusion pumps, medical records and other devices connected to the hospital network.
What are the new cybersecurity requirements according to EU MDR?
MDR Annex I explain the risks associated with the interaction between software and medical devices. Manufacturers should follow standard during life cycle, risk management, verification, and validation of the devices.
Disclaimer: Regulations/legislations are subjected to changes from time to time and the author claims no responsibility for the accuracy of information.
Medical device testing is a crucial step in manufacturing a product. This mandatory process ensures that the medical device is safe and effective. Testing of medical devices proves that the product complies with the standards and regulations of a country.
Moreover, it also sheds light on any product defects. This article discusses the testing requirements and the applicable standards.
Medical device testing applies to all medical devices, in-vitro diagnostic devices, combinational products, and active implantable devices. Some common testing of medical devices is given below:
Electrical safety tests
Functional safety tests
Performance tests
Electromagnetic compatibility (EMC) tests
Electromagnetic Interference (EMI) tests
Immunity Tests
Biocompatibility tests
Chemical testing
Cybersecurity tests (applicable to SaMDs or software that store data)
Storage and Transport
Ingress Protection
Medical device testing is crucial as the device intended for patient use must be safe. The tests a medical device must undergo depend on the device’s type. To explain further, medical equipment like a ventilator must undergo an electrical safety test.
At the same time, a device such as a cannula requires appropriate biocompatibility tests. Hence, the choice for a practical device test is taken with the help of the medical device’s intended use.
The testing procedure should be logical and must begin with a risk analysis. After identifying the failure mechanisms and hazards associated with a device, testing strategies and processes can be devised to quantify the size of these risks.
As a result, the purpose of a test method and procedure is to offer evidence that the hazards connected with a device are insignificant or, at the very least, acceptable when weighed against the benefits received from its use.
Types of medical device testing
Medical device testing is broadly categorized into physical, chemical/biological and cybersecurity testing. Physical testing involves the tests such as electrical testing, MRI safety, functional safety tests and EMC tests.
IEC 60601 series is a widely accepted technical standard for the safety and performance of electrical equipment. EMC/EMI tests ensure that the overall device is compatible with other medical devices and works optimally in the device environment when subjected to interference and immunity.
Conformance to this standard provides that medical equipment does not create electromagnetic fields that could impair the operation of other devices in the usual environment.
Chemical or biological testing help achieve device compatibility with the surface of the skin. Medical devices that contact skin must comply with the ISO 10993 series- Biological evaluation of medical devices.
For this, the manufacturer must consider the choice of material used compatibility between device materials and the biological tissues, cells, and body fluids. Testing methods like stress, shear testing, and ageing tests are performed so that the final product causes the least quality concerns.
Cybersecurity testing is crucial to medical devices so that risks such as unauthorised access to data and breaches are identified, and their occurrence minimised.
A common standard followed for medical device software is IEC 62304 and ISO27001. IEC 62304 standard specifies the life cycle requirements for medical device software, whereas in ISO 27001 focuses on data and information security.
It should be noted that each of the above standards is closely related to the ISO standard for risk management of medical devices (ISO 14971).
The risks associated with the medical device should be correctly identified, and appropriate tests should be done, proving that the relevant standards are met. Please read our article on global ISO requirements for a better understanding of the ISO standards.
Testing requirements around the world
To fully comply with the regulations of each country, one must also align with the testing standards accepted within each country. ISO and IEC standards are accepted across the globe.
Compliance with these ensures that the devices can be marketed without any major difficulties. This article discusses the testing standards followed in major medical device markets.
In Europe, close to 80% of electrical and electronic standards follow the various IEC International Standards. Standards for electromedical equipment include IEC 60601 series standards for the requirements for high-frequency surgical instruments, short-wave therapy equipment and so on.
The EU from time to time releases the harmonized standards list which are the most acceptable standards for the EU compliance.
In the US, accepts certain ISO standards however there are a list of recognized consensus standards that the FDA accepts for medical devices in the US. These include ANSI, AAMI, ATSM and so on.
ANSI standards are applicable to a variety of industries like the ISO whereas AAMI testing standards are specific to medical instruments and ATSM standards are specific for materials used in medical devices.
Testing standards ensure that the medical device is fit for use not just for the patient but also for the healthcare professionals handling them. Most countries do not have stringent requirements for testing standards, but it is recommended that the devices have some form of tests done.
Why are risk management and testing standards closely linked?
Risk analysis is a crucial step in designing a medical device. Certain identified risks can be managed with a minor change in the initial stages of the manufacture and these can be identified with the help of an appropriate test.
Disclaimer: Regulations/legislations are subjected to changes from time to time and the author claims no responsibility for the accuracy of information.
A Label is the written, printed, or graphic information that goes on the packaging of the medical device.
Instructions For Use (IFUs) or Package Insert is the essential information accompanying the medical device for its safe and effective use by the user. It can be a single to multiple-page document.
Labelling is the content that goes on the Label or IFUs.
What are the minimum requirements for labeling?
The ISO has published many standards applicable to the medical device industry. Some of them are as below:
Standard Number
Standard Name
ISO 18113
In vitro diagnostic medical devices – Information supplied by the manufacturer (labelling) – Part 1, 2, 3, 4 and 5
ISO 28219
Packaging – Labelling and direct product marking with linear bar code and two-dimensional symbols
Medical devices – Information to be supplied by the manufacturer
ISO 14025
Environmental labels and declarations – Type III environmental declarations – Principles and procedures
ISO 14021
Environmental labels and declarations – Self-declared environmental claims (Type II environmental labelling)
ISO 14020
Environmental labels and declarations – General principles
ISO 22742
Packaging – Linear barcode and two-dimensional symbols for product packaging
There are more specific product-oriented labelling standards available.
ISO 20417 has defines information to be disclosed by the manufacturer. Every medical device manufacturer, distributor, importer, or Authorized Representative is bound to comply with the standard before placing the device on market. The requirements are as follows:
Information on Label
Manufacturer details – Trade Name, address, country
Product description.
Product identification – model or catalogue number, Lot number, serial number, expiry date, UDI,
Storage instructions
Operating instructions
Warning or precautions
Presence of any harmful substances (>0.1% w/w), biological origin substances, medicinal substances, nanotechnology materials
Electronic IFUs (if available)
Mention of: Single-use/ Single patient multiple-use / Reuse / Limitation on reuse
If Sterile and method of sterilization
Explanation of safety-related colours
Information on Packaging
Name and address of the manufacturer or an authorized representative
UDI
Production controls – lot number, serial number, expiry date
Model number, catalog number, commercial name
Mention of: Single-use/ Single patient multiple-use / Reuse / Limitation on reuse
Storage or special handling requirements
Any special requirements for battery-powered medical device
Contraindications, warnings, or precautions
Information in IFUs
General information (as above)
Intended Use of the medical device
Safety information
Performance of the medical device
Any residual risk associated with the use of the medical device or its accessory
Any known contraindications
Document control number of the IFU
Safe disposal information
Any specific instructions for handling or preparatory treatment
Any warnings, precautions, or limitations
If any accessories or indicators are provided along with the device, instructions on their use to be provided in the IFU.
Technical description
The harmonized ISO standard makes sure true and uniform information is conveyed to a lay/common person.
Global Labelling Requirements
Most countries have a mandatory requirement for the IFUs or Labels in their local language. To streamline this requirement, ISO 15223 standard provides a list of signs and symbols that depict common terms such as Manufacturer, Lot number, storage conditions, Expiry, eIFU and many more.
The uniform symbols help in identifying the necessary information without the language barrier. Another advantage is it saves significant label space.
FAQs
Is it necessary to follow the ISO standards?
It is advisable to develop a medical device in compliance with the applicable harmonized standards. This shall favor in smooth marketing of the product along with its competitors.
Is it necessary to brief the symbols in IFU when symbols from standards are used?
Yes, it is required to brief every symbol in the IFU that is used on the label of the product.
Can a distributor or an importer label be affixed separately apart from the main label?
Yes, it is also allowed to affix these labels separately on the product. This is because one manufacturer may have several distributors or importers within EEA.
Is it necessary to create dedicated labels for accessories of medical devices?
Yes, it is. Not every time the accessory is shipped along with the medical device and it is required to identify them with appropriate labels.
If the manufacturer wants to provide an eIFU how to indicate this on the label?
Firstly, not all the medical devices are eligible for eIFU provision. Regulation 207/2012 states what are the categories of MDs that are eligible for eIFU.
What is the deadline to implement UDI carrier on device labelling?
Article 123.3.f states these timelines as:
Disclaimer: Regulations/legislations are subjected to changes from time to time and the author claims no responsibility for the accuracy of information.
The De novo request is a simpler marketing pathway to classify novel medical devices that provide a reasonable assurance of safety and effectiveness for the intended use and do not already have a predicate device on the market.
FDA also declares that the devices marked as Class I or II as per De novo request can be further used as a predicate device for future premarket 510(k) notifications.
De Novo Request Procedure
There are two ways to submit a De Novo request to the FDA for a risk-based evaluation of the device’s classification into class I or II.
Method 1: In response to a previous 510(k) submission that determines the product as high-level not substantially equivalent (NSE).
Method 2: The requester determines that no legally marketed devices can be treated as substantially equivalent. Then without first submitting 510(k), the device can receive a high-level NSE determination.
The FDA recommends that sponsors follow a pre-submission to get feedback from the appropriate premarket review division.
Points to Remember
FDA will reject if:
The Coversheet of the request does not mention “Request for Evaluation of Automatic Class III Designation.”
Administrative Information about the device
Device description
Classification information and supporting files
Clinical data (if applicable)
Non-clinical data, including bench performance testing
Once applied, receive a Unique Document number assigned by CDER/CDRH
Within 7 days, the centre communicates the applicant with a DeNovo number via acknowledgement letter
Stage:01 Acceptance Review (Refer to the Acceptance checklist) which is an initial review to evaluate the availability of the document
Stage:02 Substantive review – a detailed review along with an interactive review to discuss with the applicant for the deficiencies to be resolved
De Novo request decision
The FDA will make a final decision on whether to grant or deny the De Novo request after reviewing it. In some cases, the FDA will consider withdrawing the De Novo request.
If the FDA decides to withdraw a De Novo request, the requester is notified with the De Novo request number and the date the FDA decided to withdraw the De Novo request. These orders aren’t available on the FDA’s website.
De Novo Submission Fee Requirements
The Current fee requirements for De Novo request submission can be found here.
De Novo Submission Flowchart Representation
Refer to the final rule for more information on the content of the De Novo Request.
What are the immediate effects after the FDA grants the De Novo request?
The new device is authorized to be marketed and must be in compliance with applicable regulatory controls A new classification regulation for the device type is established The new device may now serve as a predicate device for 510(k) submissions of future devices of the same type, when applicable The FDA publishes in the Federal Register a notice that announces the new classification regulation and, for class II devices, the new special controls The FDA posts on its website a copy of the granting order notifying the requester we have granted marketing authorization The FDA generates and publicly discloses a decision summary
Why does the FDA decline the De Novo request?
General controls or general and special controls are insufficient to provide reasonable assurance of the safety and effectiveness of the device (or) The data provided in the De Novo request are insufficient to determine whether general controls or general and special controls can provide a reasonable assurance of the safety and effectiveness of the device (or) The probable benefits of the device do not outweigh the probable risks.
When does the FDA withdraw a De Novo request?
The requester submits a written notice to the FDA that the requester is withdrawing the De Novo request (or) The requester fails to provide a complete response to a request for additional Information (21 CFR 860.240), or deficiencies identified by the FDA (21 CFR 860.230) are not addressed within 180 days after the date the FDA issues such request (or) The requester does not permit an authorized FDA employee an opportunity to inspect the facilities (21 CFR 860.240) at a reasonable time and in a reasonable manner and to have access to copy and verify all records pertinent to the De Novo request.
Disclaimer: Regulations/legislations are subjected to changes from time to time and the author claims no responsibility for the accuracy of information.
