Medical device and equipment companies are challenged with controlling, managing, and distributing product information in a structured and secure environment. This is particularly true when a company keeps all records on paper. A product life-cycle management (PLM) system that stores and tracks digital records makes the job a lot easier, with a range of plusses. But going from paper to digital operations is not an overnight transformation. The challenge must be approached with special attention to risk so the business is not adversely disrupted by an audit. To minimize risk, an incremental roll-out of the PLM program can let a company hit business and engineering goals while staying compliant with FDA regulations.

The Plan

The best rollout plan pays attention to threatening transition periods where it's critical to be audit ready. Consider implementing in three broad steps:

  • Getting digital and remaining compliant

  • Getting automated and remaining compliant, and

  • Getting global and remaining compliant

The challenges to FDA compliance pertaining to PLM are found in 21 CFR Part 11 on Electronic Records and Electronic Signatures, and in 21 CFR Part 820 on Quality System Regulations (QSR) and Good Manufacturing Practices (GMP). Despite an electronic infrastructure in most companies, medical-device manufacturers still depend on some paper-based processes.

For example, one mid-western medical device manufacturer designs its products completely in 3D CAD yet processes all related Engineering Changes and Corrective Action Reports through a manual paper-based procedure and approval process.

Fully electronic based systems are worthy goals because their efficiency leads to greater growth and profitability than would be possible with a paper or hybrid system. But companies must perform a balancing act when technology, processes, and people are brought together in an implementation plan that is aggressive enough to keep momentum yet slow and methodical enough to not risk the success of the business.

Getting Digital

Most companies already keep the better part of their data in electronic formats, but it's probably scattered around the company on dozens of computers. So capturing the complete digital-model definition of a product presents a challenge.

The first step is to electronically capture product models, drawings, bills of material, schematics, and the tooling designs that will make the product. Most companies have done so. What they haven't done sufficiently is install a product-data management capability that traces every development step from specification through design and on to manufacturing.

This is where the risk of noncompliance to federal regulations emerges. PLM's job is to track, maintain, and reach back anywhere in a product development cycle to show decision points, changes, and authorizations. Collecting this data and providing it in a single view or report is key to delivering elements of the Design History File (DHF). The DHF is a favorite FDA audit request. It contains all records and documentation of the product specification from the time it emerged in R&D through the time it matured into a production offering.

Elements of 21 CFR Part 11 for control of electronic records and the record's authorized modification are important throughout early product development. The tracking of process workflows and associated authorization are compliance elements key to 21 CFR Part 820 conformance.

The Device Master Record (DMR) is also facilitated by having control and access over the digital product definition, but to a deeper level inclusive of material source, component origin, and production processes. The DMR is a deeper and broader data collection than that of the DHF. Due to this requirement's reach into manufacturing and supply chain information, it might best be implemented in later phases of the PLM roll-out.

To manage risk during the transition from paper-based records to an electronic format, capabilities for printing emerge as temporary yet critical. Every company will have this need, so a reporting capability that collects product-data content, change, and authorization records into collated representations is a requirement of the PLM system not to be taken lightly.

Getting Automated

This phase lays the ground work for a capability that generally has positive effect on the success of the business and even more so as the implementation scales to manage global operations. Automated distribution, tracking, reporting, and collecting of product data requires a separate step because of complexities that exist for engineering change management and product configuration management. While change management focuses on the process by which modifications to the product are recorded, configuration management focuses on the manner in which changes will be implemented. Recording and documenting a product change, although tedious, can be executed relatively easily. Decision support and mechanisms for implementing changes to the product involve disciplines that can span the company from R&D to customer support and everything in between.

Describing a process for product-change management is relatively easy, but automating the process and capturing all relevant data for compliance with 21 CFR Part 11 becomes a technology challenge. That's because what may seem a simple ad hoc decision, approval, or change, is actually held to a much higher standard in a regulated environment.

Configuration management, on the other hand, is always challenging and therefore draws on the PLM technologies to offer automated solutions that can cover a vast array of part-list structures, manufacturing-planning scenarios, and inventory dispositions. That's no small task.

The product-change management process does not necessarily provide a competitive advantage to a company, although automating it might. Most medical-device companies use standard product-change processes as part of their Corrective and Preventative Action (CAPA) procedures. These can affect many departments involved in product development, manufacturing, delivery, and support.

Still, it's wise to limit automation to a manageable group in this phase. Staying behind the firewall for an automated change process is a good place to start. Depending on an organization's size, Getting Automated might even best be limited to a simple geography or single business unit. A later phase, Getting Global, considers the worldwide organization, supply chain, and customers.

Industry-standard product change processes suggested by QSR and Good Manufacturing Practices for CAPA must be established within a dependable workflow where associated reference material for decision support is easily found through hyper-links and documentation attachments.

Because all process steps can't be automated at once, it makes sense to temporarily put a manual task or a paper-based task in the workflow to remain compliant during the implementation. Doing so mitigates risk to the business from threatening audits.

Automating configuration management is more difficult than change management because it must allow for creating many related bill of materials or part lists, known as product structures. And if one representation of the product structure changes, they all might have to change. It's difficult to meet these requirements with most PLM systems.

Incremental steps toward configuration management are possible. However, a critical success factor of a long-term compliant solution lies in a system's ability to easily compile and maintain the Device History Record. The history and master records (data collections) are bi-products of robust configuration management, because product structure is intended as the mechanism to relate all product data. The best solution for both product-change management and configuration management is one that is part of the PLM system.

The automation phase of a PLM implementation would be incomplete without considering elements of other enterprise systems that must be brought into the process. Swapping data with ERP, CRM, and MES is usually needed, and integrations can be developed successfully when done so between systems designed to interoperate and equipped with underlying business logic.

Planning for these integrations early, long before they're required, insures steady progress toward production milestones that include the release of product data to manufacturing from the new operating model.

Getting Global

Taking a working PLM system that has been optimized locally and deploying it globally is not without risks to security, intellectual-property protection, successful collaboration environments, and effective project management. Far away business units, suppliers, and customers throughout the world daily use many systems and applications. A common element among them is that they all probably use the Internet. So ideally, the architecture of the PLM system should be entirely Internet based and built on standard Web protocol.

A company's IT plans usually decide its security and how users will access company data. Those decisions and rules fall mostly outside the function of a PLM system. But collaboration with suppliers calls for a capability to protect the company's intellectual property. This is a function of the PLM system and serious risks are taken without it. To mitigate security risks, departments should consider the types of data, collaborative roles, processes, and the vehicle used for collaboration. Aspects of collaboration are typically controlled within the framework of project management. Visibility to the most up-to-date product data and activity status on a real-time basis by project participants provides for the successful management and execution of a project. Project management and execution components of the PLM system should be able to mitigate project management risks through dashboards and reporting capabilities that support the program function as well as the audit request originating internally or by the FDA.