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...
The Problem with Unstructured Data
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.
Figure 1: Managing Risk with Excel
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.
Structured Data, Complexity, and Traceability
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 5x5 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.
Figure 2: Scaling Rapidly Increases Complexity
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.
Structured Data and Risk Management
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.
Figure 3: Sample PHA Workflow Using Structured Data
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.
Structured Data, Libraries, and Trace Matrices
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.
Figure 4: Example of a Requirements Trace
Structured Data and Regulatory Submission Documents
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.
Want to Dig Deeper?
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.
Watch our video to learn more!
Complete the form below to access the video.
