Software As a Medical Device and Its Clinical Evaluation

Software As a Medical Device and Its Clinical Evaluation

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.

  1. 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.     
  1. 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).   
  1. 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.

  1. 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.  
  1. 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):

  1. Software that controls the inflation or deflation of a blood pressure cuff
  2. Software that controls the delivery of insulin on an insulin pump
  3. 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 Pilot program by Health Canada & US FDA

eSTAR Pilot program by Health Canada & US FDA

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:

Health Canada


Once accepted into eSTAR pilot, FDA & Health Canada will provide the Sponsor with the following items:

  • eSTAR to prepare the submission
  • Submission process information via the internet and mail service. Sponsorer can choose which route to adopt.
Cybersecurity for Medical Devices – FDA and EU MDR Perspective

Cybersecurity for Medical Devices – FDA and EU MDR Perspective

FDA –Food and Drug Administration

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


Dispelling Myths and Understanding

Download the Fact Sheet (PDF – 175kb)

04/07/2022 Draft Guidance: Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions

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
  • 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 ( 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.


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.


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.

Testing Standard Requirements around the World

Testing Standard Requirements around the World

Medical device testing standard- an overview

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.

Canada’s list of Recognized Standards for Medical Devices mentions a combination of ISO and ATSM standards. For electromedical compatibility, it accepts CSA standards.

Australia accepts the list of standards referenced in  Conformity Assessment Standard Orders (CASO) and Medical Device Standard Orders (MDSO). It is not mandatory but conformance to these standards are recommended.


Why are testing standards important?

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.

Global Labelling Requirements

Global Labelling Requirements

Label, Labelling vs Instructions for Use (IFU)?

  • 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 NumberStandard Name
ISO 18113  In vitro diagnostic medical devices – Information supplied by the manufacturer (labelling) – Part 1, 2, 3, 4 and 5
ISO 28219Packaging – Labelling and direct product marking with linear bar code and two-dimensional symbols
ISO 15223  Medical Devices – Symbols to be used with medical device labels, labelling and information to be supplied – Part 1 and 2
ISO 3864  Graphical symbols – Safety colours and safety signs – Part 1, 2, 3
ISO 20417Medical devices – Information to be supplied by the manufacturer
ISO 14025Environmental labels and declarations – Type III environmental declarations – Principles and procedures
ISO 14021Environmental labels and declarations – Self-declared environmental claims (Type II environmental labelling)
ISO 14020Environmental labels and declarations – General principles
ISO 22742Packaging – 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.


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.

De Novo Request | FDA

De Novo Request | FDA

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
  • Compatibility and safety studies
  • The Benefit-Risk analysis data

Submission Procedure

  • Preparing the application inelectronic copy (eCopy) or electronic submission Template And Resource (eSTAR) format.
  • 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.