GP-006 Non-conformity, Corrective and Preventive actions

Procedure flowchart

Purpose

In this procedure we describe how we manage and control non-conformities, as well as actions to prevent non-conformities or their repetition, or to minimize their consequences.

Scope

All the non-conformities regarding the specified requirements for all our products and processes.

Responsibilities

JD-001

To provide the organization with a set of appropriate documents and resources to guarantee the quality and non-conformities management.

JD-004

To identify, keep record, segregate and manage the non-conforming product or materials and to control the non-conformities and their corrective and preventive actions.

JD-005

To make the pertinent communications to the health authorities responsible in each case in the presence of serious incidents and/or modifications of the technical documentation, product, general safety and performance requirements and their intended purpose.

All team members

To notify the existence of non-conforming products or materials to the JD-004 for their correct identification, documentation, segregation, evaluation and control.

Inputs

• Communication or finding of non-conforming or potential non-conforming products.
• Communication or finding of non-conformities or potential non-conformities related to our activities or processes.
• Non-conformities or potential non-conformities related to subcontractors, providers, materials or components, etc.

Outputs

The following templates are used to manage non-conformities and CAPAs:

Template	Description	Location
T-006-001 Non-conformity report	Template for documenting individual NC details, analysis, and actions	Jira
T-006-002 List of non-conformities, CAPA, claims and communications	Consolidated list of all NCs, CAPAs, and their status	Jira
T-006-003 CAPA report	Template for documenting corrective and preventive actions	Jira
T-006-004 Stakeholder NC Notification Template	Template for tracing communications with stakeholders regarding NC opening and closure	QMS

Templates in Jira vs QMS

Templates T-006-001, T-006-002, and T-006-003 are implemented directly in Jira as issue types with predefined fields and workflows. This allows for real-time status tracking, digital signatures, and automatic linking between NCs and CAPAs.

Only T-006-004 Stakeholder NC Notification Template is maintained in the QMS, as it is used to document and trace external communications with customers, Notified Bodies, Competent Authorities, and other stakeholders.

Definitions

• Non-conformity (NC): unfulfillment of a system requirement. They can be non-conformities when detected, or potential non-conformities detected as observations or recomendations by the employees or auditors.
• Corrective action (CA): action taken to eliminate the cause of a potential or actual non-conformity or another undesirable situation, to prevent them from happening again.
• Preventive action (PA): action taken to eliminate the cause of a potential non-conformity or other potential undesirable situation, to prevent them from the possibility of happening.
• Incident: any malfunction or deterioration of the characteristics or performance of a device made available on the market, including use-error due to ergonomic features, as well as any inadequacy in the information supplied by the manufacturer and any undesirable side-effect.

Procedure

NC and CAPA Management in Jira

The entire lifecycle of non-conformities and CAPAs is managed through Jira, which serves as the central platform for:

• Registration and documentation of all NCs using the T-006-001 Non-conformity report template
• Tracking and listing all NCs and CAPAs in the T-006-002 List of non-conformities, CAPA, claims and communications
• CAPA management using the T-006-003 CAPA report template
• Status control through Jira labels and workflow states
• Linking NCs and CAPAs to maintain traceability between related issues
• Digital signatures for approval and closure of actions

Jira Workflow and Status Labels

The status of each NC and CAPA is tracked in Jira using workflow states. The main status transitions are:

NC Status Flow

For Non-conformities (T-006-001):

Status	Description
Open	NC has been registered and is pending initial evaluation
In Progress	Root cause analysis and investigation in progress
Immediate Action	Containment actions being implemented
Solved but waiting to close the CAPA	NC resolved but linked CAPA still in progress
Solved ✓ Done	NC fully resolved and closed

CAPA Status Flow

For CAPAs (T-006-003):

Status	Description
Open	CAPA has been created and is pending implementation
In Progress	CAPA actions being implemented
Efficacy Verification	Verifying effectiveness of implemented actions
Impact Verification	Verifying no adverse impact on safety/performance
Solved ✓ Done	CAPA completed and closed

NC and CAPA Closure Dependency

When a NC is linked to a CAPA, the NC cannot be fully closed until the associated CAPA has been completed and closed. This dependency is enforced through Jira, ensuring that:

1. The NC status shows "Solved but waiting to close the CAPA" while the CAPA is open
2. The CAPA must reach "Solved" status first
3. Effectiveness and impact verifications must be completed in the CAPA
4. Only then can the linked NC be moved to "Solved" status

Reception of Non-conformity

Non-conformities (or potential non-conformities) may be raised through a number of channels, ranging from telephone or email communications with customers, to critical findings or observations from external auditors, internal detection of an issue, among many other channels.

Initially, all communications coming from customers are registered in the tickets management form according to GP-014 Feedback and complaints procedure, and are considered external communications.

Definition: 'external communication'

An external communication is a customer inquiry or complaint related to the product, but not related to its performance and/or safety.

When an employee becomes aware of an issue, they communicate the issue to the JD-004, who receives and evaluates the information, and decides whether it corresponds to a non-conformity.

All non-conformities and observations that can lead to non-conformities will be investigated and registered in Jira using the T-006-001 Non-conformity report template, where all the data will be collected for subsequent evaluation.

If the problem is directly related to the device's specifications, performance, safety, software problem or if it requires actions to solve it, it will be considered as a non-conformity. The evaluation will also determine the need for actions and/or the need to apply the procedure GP-004 Vigilance system.

About customer support

Users of the device will find support forms in many points during the use of the device. These forms automatically create tickets in our tickets management tool (see GP-014 Feedback and complaints), wherein the user identification, description of the incident and the date will be automatically included. The tickets will be managed with a FIFO methodology with a maximum response time of 48 hours.

Non-conformity Analysis and Management in Jira

Each non-conformity will be analyzed individually and recorded in Jira using the T-006-001 Non-conformity issue type. The NC record in Jira includes the following fields:

Field	Description
Title	Date and descriptive title (e.g., "2025-03-13_R-006-001_BSI NC Pilot_CE Mark")
Description	Detailed description of the non-conformity
Source	How the NC was detected (Finding from audit, Internal, Customer complaint, etc.)
Origin	Specific origin (BSI Audit, Internal Development, Customer, Post-market surveillance, etc.)
Category	Product category (Legit.Health Plus (MDR), Legacy (MDD))
Impact	Safety, Performance, or both
Quality Manager	JD-004 responsible for the NC
Reporter	Person who registered the NC
Assignee	Person responsible for implementing actions
First assessment and immediate correction	Initial evaluation and containment actions
Immediate correction due date	Target date for immediate actions
Root cause analysis	Analysis using the 5 Whys technique
Customer communication	Yes/No - Whether customer notification is required
Linked CAPA	Link to associated CAPA issue (if applicable)

The non-conformity management starts with the analysis and investigation of the non-conforming product or from the non-conformity detected, and the analysis of its origin. The NC is classified in accordance to its origin (customer claim, internal NCs, supplier's claim or audit deviation, internal or external).

The JD-004 is responsible for executing the root cause analysis, together with the responsible department when needed, using the 5 whys technique: it is a technique that iteratively asks why from the NC itself until its origin is found.

NC Criticality Classification

The JD-004 shall evaluate the criticality of the non-conformity according to its effect on safety and performance.

The categories of criticality are as follows:

• High: nonconformities categorized as high impact represent the most critical failures in terms of safety and performance. These issues may result in misdiagnosis, delays in treatment and worsening of the patient's health status, impairment of the overall functionality of the software. High impact nonconformities could include failures that lead to incorrect diagnosis or treatment recommendations, compromised patient data security.
• Medium: nonconformities categorized as medium impact represent failures that have a notable but not immediate impact on safety and performance. While they may not pose an immediate risk of severe harm, they still require attention to prevent potential complications or adverse effects on patient outcomes. Medium impact nonconformities could include software bugs that result in inaccurate or incomplete information provided to the users.
• Low: nonconformities categorized as low impact represent minor failures that have minimal impact on safety and performance. While these issues may be undesirable and require correction, they are unlikely to cause significant harm to patients or impair the overall functionality of the software to a critical extent. Low impact nonconformities could include cosmetic issues, minor usability issues, or non-critical errors that do not affect the core functionality of the software or its ability to provide accurate diagnostic information.

Determining CAPA Requirement

The JD-004 is also responsible for supervising all the NCs that occur and deciding whether a corrective action is required. It is necessary to discriminate between:

• Immediate actions: Containment measures to address the immediate issue and allow the process to continue safely
• Corrective actions (CAPA): Actions that aim to eliminate the root cause and prevent recurrence of the same non-conformity

When a CAPA is required, the JD-004 will:

1. Create a new CAPA issue in Jira using the T-006-003 CAPA issue type
2. Link the CAPA to the originating NC in Jira using the "NC source" field, establishing a traceable relationship
3. The NC will show status "Solved but waiting to close the CAPA" until the CAPA is completed

All the conclusions and decisions will be reported to the JD-005, in case he/she finds some unacceptable hazard or uncontrolled risk.

Stakeholder Notification for Non-conformities

Customer Communication Decision Flow

Customer Communication Field in Jira

During the NC analysis in Jira, the JD-004 shall evaluate and determine whether customer communication is required by setting the "Customer communication" field (Yes/No) in the NC record. This decision is documented in Jira and is based on:

• Origin of the NC: Whether it was detected by a customer or internally
• Type of NC: Safety issues, performance issues, data integrity, etc.
• Impact on customers: Whether the NC affects customer operations or patient safety

The following rules apply:

NC Origin	Customer Communication Field	Notification Required
Customer-detected NC	Yes	Always - Both opening and closure notifications
Internal NC with safety/performance impact on customers	Yes	Always - Both opening and closure notifications
Internal NC without customer impact	No	Not required
Audit findings (e.g., BSI, internal audits)	As determined by JD-004	Based on customer impact assessment

When customer communication is required

Customer communication is required in two scenarios:

1. Customer-detected NCs: Non-conformities that are detected or reported by customers always require customer communication.

2. NCs with customer impact: Non-conformities detected internally (e.g., through internal audits, monitoring, development) that have an impact on customer safety, performance, or operations also require customer communication, even though the customer did not report the issue.

In both cases, the JD-004 shall set the "Customer communication" field to Yes in Jira, and the customer must be notified of:

• NC Opening: Acknowledgment that the issue has been identified and is being investigated
• NC Closure: Notification that the NC has been resolved, including a summary of actions taken

Connection with Technical Assistance Service (GP-017)

Customer communications related to NC notifications are managed in coordination with the GP-017 Technical Assistance Service procedure:

• Communication channels: Customer notifications are sent through the same channels established in GP-017: email, phone, or HubSpot
• Recording: All NC communications are recorded in HubSpot as part of the customer communication history, in addition to being traced in the T-006-004 Stakeholder NC Notification Template
• Responsibility: The JD-005 coordinates with the technical assistance team to ensure customer notifications are sent within the established timeframes
• Traceability: The communication date and method are recorded both in the NC record in Jira and in HubSpot

Integration with HubSpot

When customer communication is required (field set to "Yes" in Jira), the notification shall be:

1. Sent to the customer via email, phone, or HubSpot
2. Recorded in HubSpot as part of the customer's communication history
3. Documented using the T-006-004 Stakeholder NC Notification Template
4. The communication date recorded in the NC record in Jira

Notification Timeframes

Opening Notification Timeframes

When customer communication is required (either because the NC was customer-detected or because it has customer impact), the following timeframes apply for notifying the opening of the NC based on criticality:

NC Criticality	Opening Notification Timeframe	Examples
High	Within 24 hours of NC confirmation	Safety issues, data breaches, critical functionality failures, misdiagnosis risk
Medium	Within 72 hours (3 business days) of NC confirmation	Performance degradation, incomplete data, non-critical software bugs affecting user experience
Low	Within 5 business days of NC confirmation	Minor usability issues, cosmetic defects, documentation errors

Closure Notification

For all NCs where customer communication is required (both customer-detected and those with customer impact), the customer shall be notified of the NC closure within 5 business days after the NC status is changed to "Solved" in Jira. The closure notification shall include:

• Confirmation that the NC has been resolved
• Summary of root cause analysis findings
• Description of corrective actions implemented
• Any preventive measures taken to avoid recurrence

Communication Channels and Traceability

Customer notifications shall be sent through the channels established in GP-017 Technical Assistance Service:

Channel	Usage	Traceability
Email	Primary channel for formal notifications	Recorded in HubSpot
Phone	For urgent communications (High criticality NCs)	Call summary recorded in HubSpot
HubSpot	For tracking and managing all customer communications	Automatic record

All communications shall be:

1. Documented using the T-006-004 Stakeholder NC Notification Template (maintained in the QMS)
2. Recorded in HubSpot as part of the customer communication history (as per GP-017)
3. The communication date recorded in the NC record in Jira

Notified Body and Competent Authority Notifications

For Notified Bodies and Competent Authorities, notification timeframes shall comply with:

• MDR 2017/745 requirements (Articles 10, 83-86)
• QMS certification agreement terms with the Notified Body
• National regulations of applicable EU Member States
• Without undue delay for significant QMS or product non-conformities

The JD-005 shall coordinate with JD-004 to ensure regulatory notification requirements are met.

Notification Content Requirements

All stakeholder notifications shall include, at minimum:

• Description of the non-conformity and its potential impact
• Actions already taken and/or planned to resolve the issue
• Expected resolution date
• Contact information for questions or concerns
• Any interim measures or workarounds available

For Notified Bodies and Competent Authorities, notifications shall additionally include:

• Product identification (name, version, UDI-DI, EC Certificate reference)
• Risk assessment summary
• Root cause analysis summary
• Impact on Technical Documentation or QMS, if applicable

All notifications shall be documented using the T-006-004 Stakeholder NC Notification Template and tracked in the NC record in Jira with the communication date recorded.

Corrective and Preventive Actions (CAPA)

The corrective actions shall be taken without undue delay to avoid the recurrence of an already detected NC. On the other hand, the preventive action starts when activities that may become a NC are detected but have not occurred yet (possible sources of preventive actions can be improvement opportunities, recommendations from clients/auditors).

CAPA Management in Jira

Corrective and preventive actions are registered in Jira using the T-006-003 CAPA issue type. The CAPA record in Jira includes the following fields:

Field	Description
Type of CAPA	Corrective Action or Preventive Action
Source	Origin of the CAPA (Non-conformity, improvement opportunity, etc.)
NC source	Link to the originating NC (automatically creates traceability)
Description	Detailed description of the CAPA and actions to be taken
Category	Product category (e.g., Legit.Health Plus (MDR), Legacy (MDD))
Origin	Source of detection (e.g., BSI Audit, Internal Development)
Impact	Safety, Performance, or both
Assignee	Person responsible for implementing the CAPA
Due date	Target date for CAPA completion

NC and CAPA Linking

When a CAPA is created from a NC, the two issues are linked in Jira through the "NC source" field in the CAPA record. This linking ensures:

1. Traceability: Clear relationship between the NC and its corrective/preventive actions
2. Status dependency: The NC displays status "Solved but waiting to close the CAPA" until the linked CAPA is closed
3. Complete closure: The NC cannot be fully closed until all linked CAPAs are completed

CAPA Implementation Process

The JD-004, together with the responsible department when needed, will define a corrective (or preventive) actions plan by identifying:

• The actions to be taken to avoid recurrence of the same non-conformity (or potential non-conformity)
• Responsible person to implement the actions
• Due date for the corrective/preventive actions implementation
• Resources needed

After the implementation of the corrective/preventive actions, it shall be verified that the corrective/preventive action does not adversely affect the ability to comply with applicable regulatory requirements or the safety and performance of the medical device, as well as their effectiveness.

Actions before delivery

Actions in response to the non-conforming product detected before delivery

We must ensure that if we detect a non-conformity during the development process, that product is not put on the market until the non-conformity management process has been completed and the product complies with all general safety and performance requirements.

To do so, we manage non-conformities through one or more of the following ways:

• Taking actions to eliminate the detected non-conformities.
• Taking actions to prevent the use of the product.
• Authorizing the use of the product, but only under concession.

In the cases where we authorize the use of a non-conforming product under concession, we ensure that we provide justification, obtain approval and meet regulatory requirements. Records of the acceptance by concession and of the identity of the person authorizing the use are kept within the Design History File and following the process established in the procedure GP-011 Production and service provision.

Actions after delivery

Actions in response to the non-conforming product detected after delivery

When the non-conforming product is detected after delivery or when its use has already begun, we take the appropriate action depending on the effects, or potential effects, of the non-conformity. Records of the actions taken are kept in the T-006-001 Non-conformity report, considering the possible link to the Procedure GP-004 Vigilance system.

Verification of the efficacy of CAPAs

After the coorrective/preventive actions implementation, the JD-004 shall evaluate the effectiveness of the actions. The results and conclusions of this verification is recorded in the T-006-003 CAPA report.

This record contains, at least, the following points:

• Description of the non-conformity
• Source (Non-conformity, improvement opportunity, others)
• CAPA plan
• Resources needed that must be made available to the responsible for planning the action
• Due date for CAPA implementation
• Follow up on the status of CAPA implementation
• Date and signature of the responsible person for the execution of the actions, as acceptance of these actions
• Effectiveness verification plan
• Effectiveness verification (if the action adopted has not been effective, new actions should be studied and implemented, restarting the process until its satisfactory resolution)
• Impact verification to ensure that the implemented actions does not affect safety/performance of the device and compliance with regulatory requirements
• Closure of the action by the JD-004 when the effectiveness of the actions and the impact are verified by signing the closing action. When the JD-004was the responsible for the execution of the action, the closure of the action is verified by the JD-003.

A record of all the NCs and CAPA will be kept through the T-006-002 List of non-conformities, CAPA, claims and communications, where the status of each one will be managed and the planned closing date will be initially registered, as well as the definitive date.

Verification of the impact of CAPAs

When it is necessary to take preventive and/or corrective actions to accomplish all the aspects that are exposed in the previous points of this procedure, we establish the verification of impact documented in the T-006-003 CAPA report. This evaluation is carried out to verify that the corrective and/or preventive action does not adversely affect the ability to meet applicable regulatory requirements of the safety and performance of the medical devices that we manufacture.

Re-work

According to the very nature of our product, we have no need to perform re-work.

Connection with Other Processes

This procedure is connected to several other QMS processes. The following table summarizes the relationships and when each process applies:

Process	Relationship with GP-006	When it Applies
GP-004 Vigilance System	Mandatory reporting of serious incidents to regulatory authorities	When NC involves a serious incident, device malfunction affecting patient safety, or requires Field Safety Corrective Action (FSCA)
GP-007 Post-market Surveillance	Source of NC detection through market monitoring	NCs detected through PMS activities (complaints trends, literature review, etc.) are registered and managed through this procedure
GP-014 Feedback and Complaints	Initial reception of customer communications	Customer inquiries are first registered in the feedback system; if they relate to device safety/performance, they are escalated to NC
GP-017 Technical Assistance Service	Customer returns and technical support	When NC resolution involves customer returns or requires technical assistance activities
GP-011 Production and Service Provision	Release of non-conforming product under concession	When JD-005 authorizes use of NC product that does not represent danger
SP-004-001 Product Withdrawal	Removal of NC product from market	When NC product service must be stopped and removed from public access
T-030-005 NIS2 Incident Response Plan	Cybersecurity incident notifications	When NC involves cybersecurity incidents requiring NIS2 compliance notifications

Distinction from other notification processes

The stakeholder notification requirement in this procedure (using T-006-004) is separate from:

• GP-004 Vigilance System: For reporting serious incidents to regulatory authorities (mandatory incident reporting under MDR)
• GP-014 Feedback and complaints: For general customer support inquiries (48h response time)
• T-030-005 NIS2 Incident Response Plan: For cybersecurity incident notifications under NIS2 directive

Severe Incidents and Communications to Authorities

In cases where a NC could become an incident, the non-conformities will be managed by our vigilance system. As such, we will follow the procedure GP-004 Vigilance system.

In this case, we proceed as follows:

1. When a non-conformity is raised, the JD-004 will immediately inform the people involved, will collect all the information related to the fact and will prepare a NC record in Jira.
2. Then, the JD-004 will analyze all the information and will detect which process, product, batch, service, component or document has caused the issue, collecting all the information and conclusions in the NC record.
3. The non-conforming product service will be stopped, removing it from public access, according to the procedure SP-004-001 Product Withdrawal, until the required investigation is finished.
4. If a NC or claim is not investigated, it will be duly justified in the corresponding NC record.
5. With all the information and conclusions, the JD-004 decides which actions are necessary to tackle the non-conformity and its causes.
6. Then, the JD-004, alongside the corresponding department, designs the actions aimed at resolving the origin and consequences of the non-conformity. When required, the JD-005 will notify it in accordance with the procedure GP-004 Vigilance system.
7. If the JD-005, together with the responsible department, decides to authorize the use of a segregated product as non-conforming, provided that they do not represent any danger to their use, it will be released as a conforming product or material (GP-011 Production and service provision), stating the fact in the NC record by the JD-004.

Supplier Non-conformities

In cases where a supplier notifies a NC detected in the subcontracting process, their control, treatment and registration are responsibility of the external companies or subcontractors. These activities are described in their established procedures, being obliged to inform us of their causes, effects and consequences.

Customer Returns

Customer returns should be proposed by the JD-004 and/or JD-005 and authorized by the JD-001. All the information will be collected in the NC record in Jira. In these cases, the activities are involved within the technical assistance activities that are described in the Procedure GP-017 Technical Assistance Service.

Associated Records

Record	Description	Location
T-006-001 Non-conformity report	Template for documenting individual NC details	Jira
T-006-002 List of non-conformities, CAPA, claims and communications	Consolidated list and project space	Jira
T-006-003 CAPA report	Template for corrective and preventive actions	Jira
T-006-004 Stakeholder NC Notification Template	Template for external stakeholder communications	QMS

Related Procedures

• GP-004 Vigilance system
• GP-007 Post-market surveillance
• GP-011 Production and service provision
• GP-014 Feedback and complaints
• GP-017 Technical Assistance Service
• SP-004-001 Product Withdrawal

Signature meaning

The signatures for the approval process of this document can be found in the verified commits at the repository for the QMS. As a reference, the team members who are expected to participate in this document and their roles in the approval process, as defined in Annex I Responsibility Matrix of the GP-001, are:

• Author: Team members involved
• Reviewer: JD-003 Design & Development Manager, JD-004 Quality Manager & PRRC
• Approver: JD-001 General Manager