Cognition Corporation | Guided Compliance
Product Development & Compliance Solutions
The ability to reuse product data can dramatically reduce the time taken to design, gain regulatory approvals, and ultimately bring new medical devices to market.
[Read more…] about Reusability: Reliable Acceleration Of Medical Device Development
Key takeaway: The ability to reuse product data can dramatically reduce the time taken to design, gain regulatory approvals, and ultimately bring new medical devices to market.
Time equates to money in any business, and in the world of medical device design and manufacturing, that can mean BIG numbers!
Depending on the route taken, following FDA regulations, the average cost to bring a medical device to market through the Premarket Approval pathway is $94 million. The less intensive 510(k) process averages out at $31 million.
Taking shortcuts is not an option, not when rules and regulations are so stringent. But that doesn’t mean that device manufacturers need the same level of time and effort to satisfy regulatory demands when bringing a new product to market when they already have access to some of the product data needed.
It’s not just a simple case of “cut and paste,” though. A robust reusability technology framework is needed.
In the context of product design, reusability takes existing documentation, and data to create new and individual products, as well as products in the same family tree, or those that share similar features and functionalities.
Rather than re-entering existing information to design a new product or a variation of an existing product, it’s also possible to leverage previously created detailed information. Being able to do this can have a direct impact in terms of scaling a product line—or even an entire company.
Let’s look at how this works and at some of the other benefits.
Liability for defects, inconsistent quality, fluctuating supplier costs, increased globalization, and device regulations all pose challenges for the medical device industry. The margin of error approaches zero for medical devices being brought to market. But if defects are not discovered and corrected during development, companies could face patient injury or death, plus legal consequences.
That’s why data handling, and the documentation required to meet compliance and verify the production process, is so critical. It has to be done accurately and efficiently.
Regardless of how you approach the development process, any opportunity to save time is huge. But because of the nature of medical devices, considerations such as risk mitigation, the potential to cause harm, and regulatory compliance are paramount concerns; these need to be thoroughly addressed no matter how much time they take. Compliance is crucial to the pathway for clearance and approval by the US Food & Drug Administration (FDA) and Notified Bodies (and Competent Authorities) in the EU, with registration required in the UK through the Medicines and Healthcare products Regulatory Agency (MHRA). And again, the more accurate and clear your documentation is, the faster your device can move through the approval process.
It’s surprising how many companies rely on legacy tools such as Excel spreadsheets to manage their product development and compliance at every stage. This can be laborious at best, and at worst can result in erroneous data. This is particularly evident when it comes to trace tables, which can be a huge undertaking in a program like Excel.
Providing reports containing errors could derail product development and manufacturing, and manually building traces based on inaccurate data creates errors on top of errors that compromise the regulatory approval process
Device manufacturers need a system that truly unifies risk, requirement, and test management for a structured, automatically traceable, fully auditable, design control process. That’s why Cognition developed Compass. Powered by the Cockpit Platform, it’s the only solution that takes a templated, guided approach to device development and includes built-in, enforced processes for quality management and custom document generation functionality – meeting reporting and regulatory submission needs.
Compass is an ‘off-the-shelf, out-of-the-box system’ SaaS solution purpose-built to connect data across all functional areas of medical device product development and to automate a complex workflow between those interconnections.
It provides an adaptable set of templates for the entire product design control process: risk, requirement, and test management, from user needs to validation. It maintains documentation and supports submissions as well as provides automatic generation of the master trace matrices for the Design History File (DHF).
The key to the effectiveness of these solutions is the ability to create once, and in the case of Compass, use ready-made or created libraries and templates that allow parts of the project data to be reused. The advantage of reusability kicks in especially based on product variants, i.e., when a product line has different versions but much of the same functionality. The product team can retrace their steps using the various design stages and essentially duplicate the compliance steps up to a certain point, then adapt the plan only for the new or different parts of the product.
Take Personal Protective Equipment (PPE) as a use case, specifically disposable medical gloves. Although all gloves have the same attributes (5 fingers, entry for the hand, different sizes), the chemical composition may be different depending on how a medical glove is used, or they may even come in different colors. Using Compass, the user needs (such as “color”) can be easily altered at scale, using data from the product libraries’ data on the original product.
Additionally, users can create templates from existing designs, giving them a head start by using existing data. Take, for example, user needs and the design inputs that satisfy them. If the next product is an iteration of the existing product, the user needs and design inputs are probably similar, and the design inputs are not too different either. If you can identify the common data, you can kickstart a project from a library that contains all these items already.
Slight changes to some of the attributes of these items might need to be made, but the overall data structure is already there.
So, where is the big difference between Cognition’s solutions and Excel spreadsheets? Because the medical device industry is strictly governed by regulations, there is a need to extrapolate risk mitigation. If a user wants to implement a change in certain requirements in three different areas in Cockpit Enterprise, this is a simple task represented by a data point. If that data point is changed, it is not changed in just one place; it is automatically changed anywhere that it exists across the project.
Figure 1: Example of the reuse of a regulation across multiple projects.
By contrast in Excel, as the spreadsheets are built on cells, each cell needs the change to be typed in individually and there is no way to ensure it is changed in all places, no single source of truth. Yes, you could just cut and paste Excel data from one spreadsheet to another, but this adds even more complexity and potential for error.
If you multiply a given change across a hundred products, over thousands of requirements, you can easily lose the integrity of your data in Excel and necessitate hundreds of additional hours updating the previous requirements. But using a structured data environment, if you change one item, that change can be propagated wherever it is used.
Although in Excel you can build lookup tables, you can’t incorporate different process flows that can be enforced and verified. In Compass and Cockpit Enterprise, this process workflow can be built into the templates, meaning that access and editability depend on workflow state, user role, and ownership. No other tools on the market have this functionality.
Automated processes make it easy to apply quality best practices to ensure every change is accounted for and nothing falls through the cracks: a master map and single point of truth where all actions and their impacts across a product’s development lifecycle are recorded.
Essentially, we’re talking about structured data management. When users need only enter something once, they can then be sure that the data, no matter how many places it exists within a project, is always up-to-date and correct. If a change is made to the data, it changes wherever it exists across the project.
By contrast, with Excel, for example, there is always the danger that a reused bit of text is not exactly as it is elsewhere or has been overlooked when a change was made back in an earlier development stage. Manual processes and the lack of linkage or connection between all compliance data makes product development—and critical traceability—highly error-prone, time-intensive, expensive, and complex.
However, when technology and process meet to create and maintain connections between diverse data, products can get to market faster with less risk. That’s a huge benefit for any medical device company.
Countdown To Savings: Cost-Efficient Medical Device SafetyCognition has been a trusted resource for the largest and most prominent medical device and pharmaceutical companies for more than 20 years and pioneered Cognition Cockpit, an intuitive, web-based application empowering the Product Development Process (PDP). [Read more…] about Countdown To Savings: Cost-Efficient Medical Device Safety
Cognition is excited to announce the opportunity to join a 30 minute webinar on taking a structured data approach to risk management and design controls. [Read more…] about Cognition Launch ‘Lunch And Learn’ Webinar
Using unstructured tools such as Word and Excel when doing risk management for medical devices could result in harm to a patient. Why? Because many medical devices are complex, with hundreds to thousands of inter-related design inputs/outputs, testing, and risk management data. Managing that amount of data manually is nearly impossible when using tools like Word and Excel…
With unstructured data, it is difficult to author and maintain properly. It may be easy to type a value into the cell but often this data needs to be in multiple locations, leading to considerable copying and pasting. When that data needs to be changed, it must be changed in every location (Figure 1). Mistakes are made.
Traces need to be created from that data and now you must manually generate a trace-based on what is manually typed in hopes every change has been accounted for and every effect understood. Because of that manual approach, medium to large traces will never be accurate and you are going to have poor data integrity. The same happens with documents that will be generated from that data.
It’s not unusual for an FMEA or other risk management activity to have dozens of columns and hundreds of rows in a spreadsheet, so this gets complicated fast. The manual creation and the errors it can generate, and the time spent to verify those errors, results in a poor chain of evidence because you don’t always know who touched what and when. You also can’t have good controls or signatures on a spreadsheet. All of that is going to lead to delays in projects, delays in time to market, increased audit risk, and of course exposure to post-market inspectional observations or other problems down the road.
Traces are one of the most important artifacts, or deliverables, coming out of the product development process. Using a manual or unstructured approach to traces is going to have many of the same problems as using a manual or unstructured approach to creating the data items originally. To illustrate how quickly complexity can grow (Figure 2), say we have five levels of data items in the project. If there are five levels and five data items in each level, and each item has a link or trace to two other items, there would be 40 links to either create or verify.
Taking that same 5×5 configuration but instead, each item links to four other items, the number of links goes from 40 to 80 to verify, and in reality, it is much worse than that. In the typical device development project, there may be a spreadsheet with dozens of columns and hundreds of rows.
With an unstructured approach, it’s very difficult not only to generate a trace but also to verify it. The reality in device development is that changes will be made, and the effects of those changes can be at a scale that is unrealistic to manually verify, so errors (on top of errors) will occur. There will also be lots of time spent trying to find those errors and fix them.
Let’s use a Preliminary Hazard Analysis (PHA) as an example of why using a structured data approach makes more sense than an unstructured one. The process starts with a series of questions, likely based on the relevant standard. The questions are structured items, so if the standard changes your PHA project will get the update (Figure 3). With structured data hazards, hazardous situations, harms, mitigations, requirements, tests – everything involved in the development process – is a data item. So, you can always know who made a change and when; when it was approved; and, if changes were made, how they impact other items.
FMEA is a similar approach. There may be product families and product elements or components that tie into other development projects – that information can be saved and re-used and, when a change is made, it is made everywhere across every project. There may be individual requirements associated with a particular FMEA; those requirements may also be connected to other places in the project. The effect of every change is understood and tracked.
For Use Error Analysis (UEA), another common risk activity, the same approach applies. With structured data, each of the different items or steps in my UEA are connected to all of the other items and there can be an audit log and version tracking with approvals. It is very different than just typing information into a cell, each piece of information is a data item that is connected to the different components or pieces across the development project to which it is related.
With structured data, you can use libraries to re-use information – and achieve amazing increases in productivity and data integrity. For example, if hazards need to be identified for a project, and your company has already defined what the hazards are for that type of product or component, the engineer can draw all of that pre-approved information into their development project.
Another example is a simple trace with structured items (Figure 4). In the center of the trace is a requirement. It is automatically linked or traced to a mitigation it controls, to a variant mode it may have, to a test that may be operating on it, and other things – traces can easily have thousands of items. This type of reliable trace info is only possible, or can only be automatically created, using a structured approach.
With structured data, compliance deliverable documents can be automatically generated. There is no need to manually build submission documents, adding and replacing tables and values to ensure the correct information from your data items. The same issues outlined above, poor data integrity and productivity, will plague your submission deliverables if managed in Excel or other unstructured tools.
The entire concept of structured data is centered on improving data integrity, improving the chain of evidence, increasing compliance, regulatory preparedness, and an overall reduction of costs and resources. By using a structured data approach you’ll reduce the overall burden required for risk management activities and help eliminate manual data verification. It will help you in regulatory preparedness and consequently reduce time to market.
Should you want to see more of this, contact us here!
Cognition has been a trusted resource for the largest and most prominent medical device and pharmaceutical companies for more than 20 years and pioneered Cognition Cockpit, an intuitive, web-based application empowering the Product Development Process (PDP).
The company’s SaaS-based solutions – such as Compass – enable customers to structure their data and automate compliance proc
esses. This saves time and money and enables companies like Mediso to deliver their products to market faster with less risk – as demonstrated in our recent case study.
[Read more…] about Mediso Case Study: Consistency In A Changing Regulatory Environment
