By centralizing document workflows and enhancing collaboration, CMS solutions offer unmatched efficiency and reliability. In this article, we explore how content management systems help medical device companies maintain compliance while boosting operational efficiency.

Why Compliance Matters in the Medical Device Industry

Compliance with regulations like ISO 13485, FDA 21 CFR Part 11, and MDR (EU Medical Device Regulation) is non-negotiable in the medical device sector. Non-compliance can lead to product recalls, financial penalties, or even the loss of market authorization.

Document management is at the core of regulatory adherence, as it involves:

• Maintaining device specifications and quality reports.
• Ensuring accurate tracking of design changes.
• Facilitating audits with accessible and organized records.

Without a robust system in place, companies risk errors, inefficiencies, and potential legal issues.

Example: The FDA recalls over 1,000 medical devices annually, often due to inadequate documentation or procedural errors.

How Content Management Systems Address Compliance

Content management systems offer a comprehensive solution by integrating key compliance functions into a single platform. Here’s how they work:

1. Centralized Document Repository

A CMS like smartDOC provides a centralized repository for all documentation, making it easier to manage, update, and retrieve critical records.

• Benefits:
  • Prevents duplication of files.
  • Ensures consistency in document formats.
  • Facilitates quick access during audits or inspections.

Quote: “Centralized document storage is the backbone of effective compliance strategies,” says John Taylor, a regulatory affairs expert.

2. Enhanced Version Control and Tracking

Medical device documents, such as design files, SOPs, and validation reports, undergo frequent updates. CMS tools ensure that every version is recorded, tracked, and accessible.

• Key Features:
  • Automatic version control.
  • Timestamped changes for traceability.
  • Role-based access to prevent unauthorized modifications.

Ensuring Regulatory Compliance with smartDOC

smartDOC, a cutting-edge content management system, is specifically designed to meet the unique needs of medical device companies. Let’s delve deeper into its compliance-focused features:

Automated Workflows

Regulatory processes often require multiple approvals and signatures. smartDOC automates these workflows, ensuring that every document follows a predefined path before final approval.

• Advantages:
  • Reduces human error.
  • Speeds up approval cycles.
  • Ensures accountability at every stage.

Compliance Reporting Tools

smartDOC offers detailed compliance reporting tools, enabling companies to generate audit-ready reports in minutes.

• Examples:
  • Instant reports for ISO audits.
  • Real-time compliance dashboards for management oversight.

The Impact of CMS on Medical Device Quality Management

A well-implemented CMS doesn’t just help with compliance; it also elevates overall quality management practices.

Improved Collaboration

Teams across R&D, manufacturing, and quality assurance can work seamlessly by accessing the same documents through a CMS.

• Scenarios:
  • Simultaneous review of design changes by global teams.
  • Integration with PLM (Product Lifecycle Management) tools for better traceability.

Reduced Risk of Errors

Automation and standardization minimize the risk of errors in document creation and handling, a critical factor in high-stakes industries like medical devices

Challenges in Traditional Medical Device Document Management

Before CMS solutions became prevalent, medical device companies relied on traditional systems, which were prone to inefficiencies:

• Paper-Based Systems: Prone to misplacement, duplication, and damage.
• Fragmented Digital Storage: Spreadsheets and local drives lacked security and searchability.
• Manual Processes: Time-intensive and error-prone workflows.

Key Features to Look for in a Medical Device CMS

Choosing the right CMS can be daunting. Below are essential features tailored to the medical device industry:

Compliance-Focused Features

• Support for FDA, ISO, and MDR standards.
• Digital signatures compliant with FDA 21 CFR Part 11.

Robust Security

• Role-based permissions.
• Encrypted storage to protect sensitive device information.

Scalability and Integration

• Compatibility with existing ERP or PLM systems.
• Scalable to accommodate growing documentation needs.

Practical Tips for Implementing a CMS

Successfully adopting a CMS like smartDOC requires careful planning:

• Stakeholder Involvement: Ensure cross-departmental buy-in for seamless integration.
• Training: Provide comprehensive training to end-users for better adoption.
• Customization: Tailor the CMS to fit your specific workflows and compliance requirements.

Conclusion

Content management systems are no longer optional in the medical device industry – they’re essential for ensuring compliance, maintaining efficiency, and driving innovation. Tools like smartDOC empower companies to streamline their documentation processes, meet regulatory requirements, and reduce the risk of non-compliance.

By investing in a purpose-built CMS, medical device companies can focus on what truly matters: delivering safe and effective devices to the market.

An UDI is a distinct numeric or alphanumeric code used to identify medical devices throughout healthcare supply chains. These codes are generated by product owners based on globally accepted standards for device identification.

The UDI code consists of two standard elements, which are:

• Device Identifier (DI): DI identifies the labeler and the model or version of a device. The DI is a required component and considered to be the static portion of the UDI, meaning that it is the same for all instances of the product model or version.
• Production Identifier (PI): PI identifies one or more variable characteristics, such as manufactured date, expiration date, lot number, or serial number. The PI is considered to be the dynamic portion of the UDI, meaning that the PI value changes according to the production controls.

The DI is always first and is followed by the PI if it has a value.

Unique Device Identifier (UDI) = Device Identifier (DI) + Production Identifier (PI)

There are different Issuing Agencies/ Entities for issuing an UDI for a medical device they are:

GS1: Global Standards 1 (GS1) are a nonprofit standards agency, GS1 sets international standards for supply chains, electronic data exchange, healthcare, and more. GTIN (Global Trade Item Number) and UPC (Universal Product Code) are GS1 standards, both are numeric only codes. GS1 provides a “GS1 Company Prefix” to a subscribing organization and reserves a range of “Item Reference” numbers for the organization to assign to their product portfolio. GS1 charges an initial fee and a lower annual renewal fee for the subscription. GS1 is used by the majority of medical device manufacturers.

HIBCC: Health Industry Business Communications Council (HIBCC) is a nonprofit organization focused on setting standards for the healthcare industry. The HIBC (Health Industry Bar Code) standard is managed by HIBCC and is an alphanumeric code. HIBCC provides a Labeler Identification Code (LIC) to an organization after paying a one-time subscription fee. The organization creates and assigns Product/Catalog Numbers (PCN) to their product portfolio without an additional charge.

ICCBBA: International Council for Commonality in Blood Banking Automation (ICCBBA) is a non-governmental organization. ICCBBA focuses exclusively on standards for medical products of human origin, such as blood products, tissues, and organs for transplant. It manages the ISBT 128 standard used in more than 75 countries. Only a few niche medical devices are identified using the ICCBBA standard.

Issuing Agency standards typically define a device identifier to encode a company, a product model, a package level, and a check character used to verify the accuracy of the code. 

UDI codes are included on the product and package labels and, in some cases, printed directly on the device itself. Regulations require the UDI be presented in both Automatic Identification and Data Capture (AIDC) and Human Readable Interpretation (HRI) formats.

The AIDC format is a one- or two-dimensional barcode. This format allows the product to be identified quickly and accurately by using barcode readers and scanner technologies. The HRI text format refers to easily readable text that allows the product to be identified by humans without the use of any scanning or barcode reader technology.

In the case of reused and reprocessed devices, such as a surgical scalpel, the UDI must be directly marked on the product, as the product packaging is discarded. There are different direct marking technologies such as laser etching, to mark the product for the life of the product.

Once the UDI is issued, the data must be securely stored in the manufacturer’s repository and submitted to the respective health authority’s Unique Device Identification Database (UDID).

In general, regulations require product UDI data to be reported to the UDID before the medical device is placed on the market. The UDI Device Identifier and numerous other data attributes need to be collected and submitted to the UDID.

An increasing number of health authorities are implementing UDI requirements to improve patient safety and the patient experience. Accurate, comprehensive product information gleaned from UDIDs is essential to ensure the correct and safe use of devices by all users, including patients, caregivers, healthcare providers, hospitals, and industry.

The primary goal of a UDI system is to ensure proper adverse event reporting among medical devices. UDI increases the accuracy of product traceability and enables medical device manufacturers, regulatory bodies, and other analysts to discover trends earlier and respond quicker in the event patient safety is at risk due to a certain device issue.

In order to effectively streamline UDI labeling and submissions for your medical devices, it is essential to have a thorough understanding of the entire process of development, validation, design, and submission of requirements. DDi offers a single Unique Device Identification (UDI) solution that meets compliance requirements across all countries.

In general, an eIFU is defined as a non-paper version of the instructions for use. Currently, the definition of an eIFU is not the same in each market.

In the EU, according to the Commission Implementing Regulation EU 2021/2226, which laid down rules for the application of Regulation (EU) 2017/745 of the European Parliament and of the Council in regards to electronic instructions for use of medical devices, instructions for use in electronic format means “instructions for use displayed in electronic form by the device, contained in portable electronic storage media supplied by the manufacturer together with the device, or made available through software or website.”

European eLabeling regulation 2021/2226 

The Medical Device Regulation (MDR) introduces a comprehensive framework that integrates multiple electronic instructions for use (eIFU) requirements, further supplemented by Implementing Regulation (EU) 2021/2226, the successor to Commission Regulation (EU) 207/2012.

Requirements for the use of electronic instructions for use as per regulation (EU) 2021/2226 

According to Implementing Regulation (EU) 2021/2226, instructions for use may be provided electronically (eIFU) instead of on paper if certain conditions are met:

1. The device should fall into a specific class, as mentioned below:
   • Implantable and active implantable medical devices and their accessories
   • Fixed installed medical devices and their accessories
   • Medical devices and their accessories fitted with a built-in system visually displaying the instructions for use (e.g., ultrasound equipment)
2. The devices and accessories are intended for exclusive use by professional users
3. The use by other  people is not reasonably foreseeable
4. For software, manufacturers may provide eIFUs within the software itself.

Manufacturers of Medical devices that provide instructions for use in electronic form to users instead of in paper form shall undertake a documented risk assessment which shall cover at least the following elements:

• Knowledge and experience of the intended users in particular regarding the use of the device and user needs;
• Characteristics of the environment in which the device will be used;
• knowledge and experience of the intended user of the hardware and software needed to display the instructions for use in electronic form;
• Access of the user to the reasonably foreseeable electronic resources needed at the time of use;
• Performance of safeguards to ensure that the electronic data and content are protected from tampering;
• Safety and backup mechanisms in the event of a hardware or software fault, particularly if the instructions for use in electronic form are integrated within the device;
• Foreseeable medical emergency situations requiring the provision of information in paper form;
• Impact caused by the temporary unavailability of the specific website, of the internet in general, or of their access in the healthcare institution, as well as the safety measures available to cope with such a situation;
• Evaluation of the period within which the instructions for use shall be provided in paper form at the user’s request;
• Assessment of the website’s compatibility with displaying the electronic instructions for use with different devices that could be used to display those instructions;
• Management of different versions of the instructions for use, where applicable

Factors to consider when switching to an electronic IFU for your medical device

1. Risk assessment

eIFU must maintain or improve the level of safety compared to providing a paper IFU. Your risk assessment needs to examine this carefully. For instance, if your device is sometimes used by nurses or doctors in rural locations where the internet may be spotty, what additional risks might that present? You will need to update your risk management procedures and forms to account for this.

2. Product packaging

The location of the eIFU must be indicated on the packaging for each unit or, in the case of fixed devices, on the device itself. For obvious reasons, you cannot simply place PDFs of your IFU on your website and assume professional users will know to look there. The Regulation makes it clear that your packaging must clearly specify that the IFU is in electronic format and where it can be found. Except for software and devices with screens, the IFU may reside on a website, and its location may be communicated via a website URL or QR code. If you choose the latter, make sure you document the pros and cons of using QR codes in your risk assessment and update your labeling work instructions as needed.

3. Validation

Ensure the user’s access is precise by having accurate product data in real-time and a solution for delivering the information in the user’s preferred language.

4. Method of delivery

If you make software as a medical device (SaMD) or a device with a larger display screen, the method of delivery may be the device itself. For all other devices, device manufacturers will most likely deliver IFUs via their website. This fulfills a key requirement that the information be provided in a universally available format (thumb drives and DVDs are no longer universal). The preamble of the new eIFU regulation says, “To ensure unconditional access to the instructions for use in electronic form and to facilitate the communication of updates, those instructions should be available on the website of the manufacturer in an official language of the Union determined by the Member State in which the device is made available to the user or patient.” This does not mean you cannot deliver your eIFU on a private YouTube channel, for example.

5. Paper version

There are professionals out there who prefer paper-based instructions, or (it is true) might not have reliable internet access. It is EU law to have paper IFUs, with the exception of some devices. If a paper-based option is required, you are obligated to provide a paper version within seven calendar days of the request at no cost. In cases where video or animation is not used, the eIFU may simply be a printed copy of the PDF you maintain online. Make sure to update your labeling SOP with this requirement.

6. Online security

Making your IFU available online is easy. Ensuring that it does not accidentally get removed or replaced is not possible. You will need to put procedures in place to ensure that your sales and marketing departments do not change the URL, delete old versions, or otherwise change the document. You should really think of the master IFU web page(s) as controlled documents, not just the IFU itself.

7. Archival procedures

For devices without a defined expiration date, your IFU needs to be maintained for 15 years after the last device has been placed on the market. For devices with an expiration date, this changes to 10 years. You also need to have a system for indicating when changes have been made (change control) and a way to inform each user if the change was made for safety reasons. Finally, all historical versions of the IFU must be made available on the website.

8. Privacy policy

Europe has one of the strictest online privacy laws in the world, known simply as the GDPR (General Data Protection Regulation 2016/679). If you will be asking the user to provide their name and/or email, or if your website has cookies enabled (most do), you will need to make sure you are following the GDPR.

Advantages of eIFU over paper-based instructions:

• Enhanced accessibility: considering the high internet coverage, electronic instructions can be accessed digitally and consulted anywhere, providing easier search and navigation and greater flexibility.
• Real-time updates: eIFU allows for immediate updates and revisions, ensuring that users always have the latest information about the product they are using. This is crucial for patient safety and optimal device utilization.
• User-friendly interfaces: Electronic formats enable the incorporation of multimedia elements, such as videos and interactive features, enhancing the clarity and effectiveness of instructions.
• Increased efficiency in MDR implementation: electronic formats facilitate the inclusion of multiple languages and therefore contribute to reducing the risk of shortages of medical devices and improving the overall availability of these devices, especially in a multilingual context like the European Union.
• Cost efficiency: Over time, the implementation of eIFU can lead to cost savings for both manufacturers and healthcare institutions, as the need for printing, distribution, storage, and waste management of paper IFU is significantly reduced.
• Environmentally sustainable: The transition to eIFU aligns with broader efforts to reduce paper usage, contributing to environmental sustainability and supporting the EU Green Deal.

Going forward, manufacturers seeking to sell their products in the European market must comply with the EU eIFU regulations. Adhering to these regulations will provide greater flexibility and reduce the risk of product recalls related to IFUs. If you are in the process of updating your device labels and preparing eIFUs, feel free to contact DDi for expert assistance.

• Computer Software Assurance is a risk-based approach to establish confidence in the automation used for production or quality systems, that software is fit for its intended use.
• CSA focus on preventing the introduction of defects into the software development process, identify & fit suitable additional rigor where it is required.
• Describe various methods and testing activities that may be applied to establish CSA and provide objective evidence to fulfill regulatory requirements (i.e Computer Software Validation requirements in 21CFR part 820).

Scope:

• This draft guidance to provide recommendations on Computer Software Assurance for computers and automated data processing systems used as part of medical device production or the quality system.
• This guidance provides additionally discusses specific risk considerations, acceptable testing methods, and efficient generation of objective evidence for production or quality system software.

Steps in CSA Approach:

The CSA risk framework focuses on four following steps:

• Identifying the intended use (use of the software feature or function)
• Determining the risk-based approach
• Determining the appropriate assurance activities
• Establishing the appropriate record

Identifying the Intended Use:

• 21 CFR 820.70(i) requires any software that is used as part of the production or quality system needs to be validated for its intended use
• In general, software can be categorized as:
  1. Direct Impact: Software being used for a production or quality system process. Ex: Software intended for automating production/quality processes, inspection, testing, or the Collection and processing of production/quality system data or maintaining a quality record under the regulation.
  2. Indirect Impact: software that supports a production or quality system process. Ex: Software intended for use as development tools that test or monitor software systems or that automate testing activities for the software used as part of production or the quality system, such as those used for developing and running scripts. And used for automating general record i.e not part of the quality record.
• Any category of Software may have one or more intended uses depending on the individual features, functions, and operations of that software. However, it is essential to thoroughly understand the features, functions, and operations of a software when determining the intended use.
• Based on complexity of software, and operations have different roles, they may produce different risks to product quality & Patient safety.
• FDA recommends that manufacturers examine the intended uses of the Individual features, functions, and operations to facilitate development of a risk-based assurance strategy with different assurance activities for individual features, functions, or operations. Ex: A commercial off-the-shelf (COTS) software is used to document time and temperature data for a curing process. Manufacturer may not need to perform additional assurance Activities beyond. These below mentioned are Sufficient to establish that the software is fit for its intended use.
• What the COTS software developer has already conducted in terms of validation
• Conducting a vendor assessment
• Software installation and configuration

Determining the Risk-based Approach:

• After determines that software intended use as part of production or the quality system, FDA recommends using a risk-based analysis to determine appropriate assurance activities.
• The CSA’s risk-based approach suggests classifying software as either “high process risk” and “not high process risk”.
  • High process risk:
    • When software does not perform as intended, it may result in a quality problem that may foreseeably compromise safety. meaning an increased medical device risk. Ex:Analyze acceptability of product without manual intervention.A software that can monitor and maintain temperature, pressure, or humidity in a sterile room and failure of which can impact product quality drastically.
  • Not high process risk:
    • Where software doesn’t perform as intended, would not result in a quality problem that foreseeably compromises safety. As well as situations where failure to perform as intended may result in a quality problem that may not foreseeably to compromise safety. Ex:
      • A software that is used as part the quality system for CAPA routing, automated logging/ tracking of complaints, automated change control management / automated procedure management.
      • Collect and record data from the process for monitoring and review purposes that do not have a direct impact on production or process performance and software used to support production or the quality system.
• Manufacturers can also choose to further categorize these software as “moderate”, “intermediate”, or “low” to determine assurance activities; however, FDA will consider them under “Not high process risk” category only.

Determining the Appropriate Assurance Activities:

• For high process risk software, FDA suggests perform scripted testing or limited scripted testing as appropriate.
  1. Scripted testing: In which the tester’s actions are prescribed by written instructions in a test case step by step with evidence. Scripted testing includes both robust and limited scripted testing.
  2. Robust scripted testing: Scripted testing efforts in which the risk of the computer System or automation includes evidence of repeatability, traceability to requirements, and auditability.
  3. Limited scripted testing: A hybrid approach of scripted and unscripted testing that is appropriately scaled according to the risk of the computer system or automation. This approach may apply scripted testing for high-risk features or operations and un scripted testing for low to medium-risk items as part of the same assurance effort.
• For not high-risk software, FDA suggests perform un-scripted testing. Testing methods such as ad-hoc testing, error-guessing, exploratory testing, or a combination of methods that is suitable for the risk of the intended use.
  1. Unscripted testing: Dynamic testing in which the tester’s actions are not prescribed by Written instructions step by step and no need to collect evidence. It includes:
  2. Ad-hoc testing: A concept derived from un scripted practice that focuses primarily on performing testing that does not follow on large amounts of documentation to execute (e.g., test Protocol) or documenting evidence.
  3. Error-guessing: A test design technique in which test cases are derived on the basis of the tester’s knowledge of past failures or general knowledge of failure modes.
  4. Exploratory testing: Experience- based testing in which the tester spontaneously designs and executes tests based on the tester’s existing relevant knowledge, prior exploration of the test item (including results from previous tests), and heuristic “rules of thumb” regarding common software behaviors and types of failure.
  5. Exploratory testing looks for hidden properties, including hidden, un anticipated user behaviors, or accidental use situations that could interfere with other software properties being tested and could pose a risk of software failure (towards patient safety).

Establishing the Appropriate Record:

• Sufficient document evidence required to demonstrate that the software feature, function, or operation was assessed and performs as intended. In general, the record should include the following:
  1. The intended use of the software feature, function, or operation;
  2. Risk-Based Analysis: The determination of risk of the software feature, function, or operation;
  3. Documentation of the assurance activities conducted: Includes description of the testing conducted based on the assurance activity (test steps, test results, tester details);
  4. Issues found (e.g., deviations, failures) and the disposition
  5. Conclusion statement declaring acceptability of the results
  6. The date of testing/assessment and the name of the person who conducted the testing/assessment
  7. Established review and approval when appropriate (e.g., when necessary, a signature and date of an individual with signatory authority)
• Documentation of assurance activities need not include more evidence than necessary to show that the software feature, function, or operation performs as intended for the risk identified. And FDA encourages the industry to use system- generated objective evidence such as system logs, audit trails rather than the traditional paper-based test scripts and screenshot evidence.