Facing a medical device audit can be daunting, but with meticulous preparation and strategic responses, companies can turn this challenge into an opportunity for building a robust quality system.
Tips for Mastering Medical Device Audits
This article provides a detailed roadmap for mastering medical device audits, covering essential steps from internal audits to adeptly handling regulatory findings.
1. Demystifying Audits
Understanding the fundamental concepts behind medical device audits is crucial. ISO 19011 defines audits as systematic, documented, and independent processes for obtaining objective evidence.
This section also outlines the different types of audits, including internal and external audits conducted by regulatory bodies.
2. Navigating US and EU Audits
Medical device audits are mandatory for all device classes, but specific requirements vary depending on regulatory bodies and device classification.
In the EU and US, audits for medium to high-risk devices typically involve Notified Body audits for MDR/IVDR compliance and ISO 13485:2016 certification, FDA inspections for 21 CFR 820 compliance and manufacturing capability verification, and periodic surveillance audits.
Additionally, manufacturers are subject to unannounced and “for cause” inspections triggered by various issues.
3. Strategic Audit Preparation
Thorough preparation for an audit or inspection involves continuous auditing practices, mock audits, and self-identification of issues. Internal audits should be conducted rigorously, acting as rehearsals for external audits.
Mock audits, conducted by independent third parties, can reveal areas for improvement. Self-identifying issues and implementing corrective actions promptly demonstrates a proactive approach to compliance.
4. Selecting the Ideal Audit Host
When selecting an audit host, it’s crucial to choose someone who represents the company well, possesses in-depth knowledge of its operations and quality management system, and can handle pressure effectively.
The audit host is pivotal in ensuring a smooth and successful audit, so selecting the right individual is essential.
5. Document Readiness for Audits
To ensure a smooth audit process and avoid delays, organizations should pre-identify and readily have all necessary documents, including regulatory information, certificates, and records.
A centralized regulatory information management (RIM) system can significantly streamline the process by storing and linking to relevant documents from other systems.
6. Audit In-Action
During an audit, it is crucial to actively manage the process. The company host should introduce the organization and conduct a facility tour. While the auditor directs the audit, the host should assist and guide them throughout the process.
For unannounced inspections, a procedure should outline the reception and handling of such audits, including designating primary contacts and alternates.
Ideally, multiple company representatives should accompany the auditor, and they should not be left alone at any point. A “front room” team should transcribe every interaction and relay information to a “back room” team for support.
7. Best Information Sharing Practices
Employees should provide requested information to auditors but should consult with executives before sharing sensitive documents. Auditors should access information through photocopies or limited computer access.
Original documents can be presented but should not be kept by auditors. All information should be prepared, verified, recorded, and marked “Confidential” or “Proprietary” before being provided to auditors. An extra copy should be made for audit files.
8. Addressing Gaps in Information
Address missing or incorrect information by acknowledging the issue and discussing appropriate actions under the existing quality system. Be prepared to receive findings from any inspection and ensure that they are understood by both parties.
Address all findings diligently and respond to the regulatory body in charge of the audit with a satisfactory plan for correcting and preventing the recurrence of the identified issues.
Conclusion
In conclusion, medical device audits, though challenging, can be navigated successfully with thorough preparation and strategic responses.
Embrace the audit journey as an opportunity for continuous improvement, showcasing a commitment to compliance and the delivery of safe and effective medical devices.
Mastering medical device audits is not just a regulatory requirement – it’s a pathway to excellence in quality systems and product lifecycle management.
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:
Post Market surveillance requirements are set out in Title 21 Code of Federal Regulation (CFR) Part 822. This section aims to put an adequate post-market surveillance authority into practice to increase the possibility that post-market surveillance (PMS) plans will result in valuable data gathering.
These data can show unanticipated adverse events, the actual frequency of anticipated adverse events, or other details important for public health protection.
FDA will assign a post-market surveillance (PS) order number (i.e., PS######) to each post-market surveillance order. Manufacturers should cite the assigned PS order number when submitting a proposed post-market surveillance plan.
PMS plans are reviewed under the assigned PS order number. If the same PS order has multiple questions, manufacturers must provide a separate plan explaining the methodologies to address each question. The submission of the PMS plan must be made within 30 days of receipt of the 522 Order.
The FDA will review and respond within 60 days of receiving the plans. FDA intends to review post-market surveillance plans immediately and collaborate with the manufacturer to decide within 30 days of receiving the plan.
To ensure that a full review of the surveillance plan can be completed within 60 calendar days of the 522-order date, the manufacturer should give any deficiencies in the plan identified by the agency top priority and collaborate actively with the FDA.
Sections of a Post Market Surveillance Plan
The following sections must be included in a PMS plan. These sections are outlined in 21 CFR 822.10.
PMS plan objectives addressing surveillance questions
The surveillance approach, i.e., the design or methodology used
Variables and endpoints used to answer the surveillance questions
Subject of study
Sample size
Description of data source and its relevance
Description of the data collection plan
Data collection forms, informed consent forms and Institutional Review Board
(IRB) approval or IRB exemption documentation, where applicable
Patient follow-up plan or schedule
All data analysis and statistical tests planned
Investigators agreement
Procedures for monitoring the conduct and progress of the surveillance,28 and estimate of the duration of the surveillance
Content and timing of PMS reports
In addition to the above, FDA also recommends the following:
An interim data release plan which includes the frequency of interim analyses, type of analysis, data endpoints that will be assessed, content and frequency of posting on the FDA page for post-market surveillance.
Background on the device, including device description, indications of use and regulatory history.
Evaluation of PMS plan
To determine whether the proposed surveillance plan is complete, whether the person designated to conduct the surveillance has the necessary training and experience to carry out such surveillance, and whether the plan will result in the collection of valuable data that can reveal unforeseen adverse events or other information required to protect the public health, FDA will assess the proposed surveillance plan.
This evaluation will help FDA determine the answer to the surveillance question (s).
Considering this, FDA may send one of the subsequent letters:
Not acceptable letter
Approval letter
Major deficiency letter
Disapproval letter
The not-acceptable letter is issued when the submission is incomplete and does not include the items in 822.9 and 822.10.
The approval letter demonstrates the FDA’s approval of the proposed surveillance plan in its submitted form and any requirements or suggestions the agency may have had for the plan.
Major Deficiency Letter identifies grave deficiencies in the plan’s ability to produce the data necessary to address the surveillance issues. Before the surveillance plan is approved, the manufacturer must fix these issues and respond to requests for specific information within the allotted timeframe.
The disapproval Letter demonstrates the FDA’s disapproval of the proposed plan because, in FDA’s opinion, it is unlikely to result in the gathering of relevant data necessary to address the post-market surveillance issues raised by the 522 order.
The letter instructs the manufacturer to update its post-market surveillance plan by submitting a completely new submission within the allotted timeframe that suggests a new post-market surveillance plan meant to address the post-market surveillance concerns in the 522 order.
FDA evaluation outcome of Post-Market Surveillance plan
Changes to the Approved PMS plan
Manufacturers must get FDA clearance in writing before making changes to approved post-market surveillance plans if those changes would impact the nature or validity of the data gathered. These changes could be changes to sample size, endpoints and so on
It is not recommended for a manufacturer to combine their surveillance approach along with any 522 reports, but instead should include the request in a supplement to the PS order number (PS######) with the updated post-market surveillance plan for FDA review.
FAQ
How is the review done for the PMS plan?
FDA reviews post-market surveillance plans and responds within 60 calendar days of receipt. FDA intends to promptly review post-market surveillance plans and work alongside manufacturers to issue a decision within 30 calendar days of receiving the plan. The checklist used by FDA to evaluate the PMS plan can be found in the guidance document for post-market surveillance.
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.
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.
