Cockpit is a product development compliance and commercialization platform used to aid in the development of medical devices, pharmaceuticals, and combination products. The powerful database allows teams to trace the product development process from concept through commercialization and into postmarket.
Cognition provides sets of pre-defined online templates that allow for a simple, guided environment to complete exercises required for regulatory submissions. The templates live inside the Cockpit Platform, which is the engine powering them. Templates are updated from time to time by Cognition to maintain consistency with updated standards and regulations.
All content created within the template is captured, stored, and managed in the secure underlying database, allowing content to later feed into other templates that are part of the development process. This progression through the guided templates builds a set of deliverables suitable for both FDA and EU Notified Body submissions.
Learn more about our current templates:
Cognition’s Template for PHA Exercises
Preliminary Hazard Analysis is a commonly available method of risk management defined as “a tool of analysis based on applying prior experience or knowledge of a hazard or failure to identify future hazards, hazardous situations, and events that might cause harm, as well as to estimate their probability of occurrence for a given activity…” – Section 1.7, Annex I: Risk Management Method and Tools, Q9 Quality Risk Management
The PHA template allows teams to create a PHA using pre-defined lists of perspectives, questions proposed by the guiding ISO and IEC standards, and pre-populated Harm and Hazard libraries. These libraries provide generic harms and hazards commonly encountered in development.
Cockpit’s out-of-the-box PHA template is designed to comply with the following regulations:
It promotes “inherent safety by design” by guiding users through detailed risk analysis early in the design phase of the system. It reduces development costs and time to market by minimizing system redesigns in the later stages of product development.
The template comes preconfigured with perspectives (User, Maintainer, Patient), but more may be added as required.
The template comes preconfigured with the hazards identified in Annex E of ISO 14971:2012, split into four categories. Additional hazards and categories may be added as required.
The template comes preconfigured with harms and associated severities. Additional harms may be identified and severities assigned as required.
GUIDED Q&A: APPLICATION OF RISK MANAGEMENT TO THE MEDICAL DEVICE
The template comes preconfigured with a non-exhaustive list of questions identified in Annex C of ISO 14971:2012 to assist with “identifying the characteristics of the medical device that could affect safety”. Additional questions may be added as required.
AUTO GENERATE PHA TABLE
The template automatically inserts the hazards identified as a part of answering the risk management and usability questions into the PHA table. The user is then prompted to identify hazardous situations, sequences of events, harms, and risk (severity and occurrence) for each hazard, before defining mitigations and residual risk for each overall risk.
GUIDED Q&A: APPLICATION OF USABILITY TO THE MEDICAL DEVICE
The template comes preconfigured with a non-exhaustive list of questions identified in Annex E of IEC 62366:2008 to assist with “identifying the usability characteristics of the medical device that could affect safety”. Additional questions may be added as required.
COMPLETE THE RISK CONTROL MATRIX
The template automatically inserts the mitigations identified in the PHA table into the risk control trace matrix. The user is then prompted to link mitigations to existing requirements.
Cognition’s Template for Design Controls
21 CFR 820.30 outlines the regulations for Design Control of medical devices. The regulation is broken up into ten subsections detailing the tasks necessary to be compliant. The guidance is written in a way that leaves it open for interpretation. The Cognition Design Control template combines FDA best practices with the standard itself, leaving little room for error in the design process.
This template was created to give teams an easy way to start creating and capturing requirements, validation tests, and verification tests in accordance with 21 CFR 820.30.
Each manufacturer of any class III or class II device, and [some] class I devices…Read More…
820.30(B): DESIGN AND DEVELOPMENT PLANNING
Each manufacturer shall establish and maintain plans that describe or reference the design and development activities and define responsibility for implementation. The plans shall…
820.30(C): DESIGN INPUT
Each manufacturer shall establish and maintain procedures to ensure that the design requirements relating to a device are appropriate and address the intended use of the device, including…
820.30(D): DESIGN OUTPUT
Each manufacturer shall establish and maintain procedures for defining and documenting design output in terms that allow an adequate evaluation of conformance to design input requirements. Design output…Read More…
820.30(E): DESIGN REVIEW
Each manufacturer shall establish and maintain procedures to ensure that formal documented reviews of the design results are planned and conducted at appropriate stages of the device’s design development…Read More…
820.30(F): DESIGN VERIFICATION
Each manufacturer shall establish and maintain procedures for verifying the device design. Design verification shall confirm that the design output meets the design input requirements. The results…Read More…
820.30(G): DESIGN VALIDATION
Each manufacturer shall establish and maintain procedures for validating the device design. Design validation shall be performed under defined operating conditions on initial production units, lots, or batches, or their equivalents. Design validation shall…Read More…
820.30(H): DESIGN TRANSFER
Each manufacturer shall establish and maintain procedures to ensure that the device design is correctly translated into production specifications…Read More…
820.30(I): DESIGN CHANGES
Each manufacturer shall establish and maintain procedures for the identification, documentation, validation or where appropriate verification…Read More…
820.30(J): DESIGN HISTORY FILE
Each manufacturer shall establish and maintain a DHF for each type of device. The DHF shall contain or reference the records necessary to demonstrate…Read More…
Cognition’s Templates for FMEA Exercises
Failure Modes Effect Analysis (FMEA) “… provides for an evaluation of potential failure modes for processes and their likely effect on outcomes and/or product performance” – Section I.2, Annex I: Risk Management Method and Tools, Q9 Quality Risk Management. Risk mitigation through FMEA exercises reduces or controls potential failures by breaking down risk analysis for complex systems into manageable steps. It is an effective tool for identifying important failure modes, contributing factors/causes, failure consequences, and mitigations.
The FMEA templates guide teams through completion of FMEA exercises for uFMEA, dFMEA, and pFMEA. . Cockpit allows teams to configure risk score calculations using either simple scoring thresholds or user-defined color lookup matrices. Cockpit FMEA templates also support risk libraries commonly used in product development and postmarket surveillance.
Cockpit’s FMEA templates are configurable to meet regulations/standards, including:
Product development teams can set and define scores and ranges for risk severity, probability of occurrence, and detectability. Matrices or straight threshold calculations can be configured to reflect scores.
Cockpit includes several pre-populated risk libraries to guide teams through FMEA exercises. Set up your own risk libraries or modify pre-configured ones within Cockpit. The platform support libraries for failures, hazards, harms, complaints, etc.
SUPPORTED FMEA TEMPLATES
- uFMEA — Identify use-related risks and work out all possible use scenarios leading to failure and potential failure consequence
- dFMEA — Apply FMEA method specifically to device or product design
- pFMEA — Identify and evaluate potential process failures
Develop multiple risk exercises for use cases and human factors, functional studies including connections to system BOM and mapping out app process definitions to predict risk of failure and identify appropriate mitigations.
TYING RISKS TO REQUIREMENTS AND TESTS
Implement mitigations by designating controlling requirements to show interactions between risks and requirements; verify implementation through Cockpit’s testing features. Out of box templates empower dynamic connections between all design controlled documents, meaning risks can be tied back to requirements in a real-time, dynamic environment.
Field complaints can be fed back into FMEA templates as actual occurrences of a failure to help support postmarket surveillance and the Corrective and Preventive Action (CAPA) process. Templates support both pre-and post-mitigation scoring algorithms.
Cognition’s Template for Human Factors
Understand the context of use for the device you are creating. What type of person is going to be using it? What environment will it be used in? What are your tasks to proceed?
Understand what could possibly go wrong. Take what you have learned from your contextual inquiry and dissect the harms and hazardous situations that lead to those harms. Use common risk management techniques to ensure total coverage over all scenarios.
USER INTERFACE SPECIFICATION
What are your acceptance criteria for knowing you have a successful design? This is where you spell it out. Does your device meet the expectation of the user? During this phase, define what the user is expecting to ensure the device is designed as specified.
Create a rapid prototype or wireframe of your device. Early usability testing also occurs at this phase of the Human Factors Engineering lifecycle.
Formative and Summative testing is done to ensure that your device is on the right track. Formative testing is done early in the process. It is used to identify key areas that may change the overall design of the device, among other things. Summative testing, also called Validation Usability testing, is done to prove the final design performs as desired/intended.