Siemens offers circuit breakers for air- and gas-insulated switchgear for up to 800 kV. The routine test is performed on the assembled circuit breaker. The specification requirements are automatically imported into the computer-aided routine test plan during order processing. This is how we check that all customer requirements are. Simulation & Test. To successfully combine mechanical functions with electronics, software and controls, you’ll need a development approach that overcomes the shortcomings of traditional processes, such as the separate workflows for simulation and testing, and the recurrent physical prototyping. A digital twin will help you be way more effective.

Medical device product development work is a highly integrated, and regulated process. Implementation of a requirements tracking solution requires attention to a variety of nuanced topics. In this 3-part series, we present a practical approach derived from real-world experience developing medical devices using Polarion solutions. In this second installment, we look into traceability, Design V&V and Risk Management. Continued from Traceability Matrix Design V&V The first task of any product development process is generally to discover, define and link the items of interest for that product. This is typically done in a logic Flow Diagram, and is the basis for developing the Design V&V test plan.

In today’s complex development environments, it can be a daunting task. The good news is that templates for typical setups have been completed and made available for use. One example of such a diagram is the SwanVMC comprehensive traceability table (shown below). Manufacturing The flow chart is intended to represent the design, manufacturing, and risk management relationships typical in a medical device product development process. It also integrates concepts used in the development process such as Standards integration (FDA guidance, ISO, ASTM, etc.), images, text justifications, essential requirements, and standard glossary definitions. Other Artifacts One of the most powerful leverage points in the use of Polarion is the way ancillary artifacts are referenced throughout the design history file (DHF). One example is the medical device intended use statement.

It is convenient to define the text once for approval, and then reference the tagged work item wherever it is used. This ensures consistency in the text, and the ability to establish every point where the standard text is used, which is critical to determine the full impact of a change, and assures the change is properly propagated to all relevant documents. Risk Management Conceptually, risk management is not difficult to describe and understand.

We have hazards that lead to harms. These hazards should be documented and mitigated to control an outcome to make the use of a device predictable and safe. However, the implementation of such a system is complicated. This is due to a variety of factors including the number of variables needed to describe the relationships between the various system components, options for whether to make these concepts unique and reusable, many-to-many database relationships, and sometimes vague or confusing regulatory expectations. For this reason, the following is offered as exploration on how these various components of the system can be organized. First, the data should be organized by how it will be reviewed. After release of a product to the field post market, surveillance will evaluate the product on the basis of the user harm, the user hazard, and the number or percentage of field occurrences.

Our data fields should directly mirror the data returned for easy comparison and response to issues identified in the field. We should be able to see the occurrence of a harm in the field and directly compare it with the risk management process. This will allow us to immediately evaluate whether the factor used to determine how often the hazardous situation results in a harm is correct, or whether the probability of the hazardous situation occurring has been improperly assessed. Second, the data fields should represent common terminology. The regulatory bodies have defined what is meant by a hazard, or hazardous situation. We should build the regulated terminology into our model to provide a system that helps auditors better understand our intent without additional explanation.