KPIs are like scorecards for organizations, helping them track how well they’re doing and if they’re moving closer to their goals. In the world of ISO 13485 (Section 4.1.3 and Section 8.2.5), process KPIs are important to be compliant. They are the metrics by which the health of our processes is measured.

The perfect opportunity for a health check-up of your process is the Management Review pursuant to ISO 13485:2016 Section 5.6. Of course we also have a template for the Management Review SOP and the Management Review Report. In the Management Review you’ll look at every process and evaluate whether it performs well. To approach it systematically, you need a metric that shows if the process achieved what it is meant to do: those metrics are your KPIs.

You can either define the KPIs for every process in the respective SOPs themselves, and/or you can keep an overview of the KPIs in the template for the Management Review Report.

While the standard does not require a certain number of KPIs, a common number for startups would be to have one or two KPIs per process. But any number higher than 0 is acceptable. This is also depending on the maturity of your QMS. The KPIs will evolve in the course of the Management Reviews and over the years. When you deem some metrics to yield no insights, you are well advised to change them for the upcoming term.

In most cases, it makes sense to define a target for your KPIs (goal). That makes the assessment easier in the Management Review, as you can easily determine whether the outcome is acceptable or not.

In case you have no idea which KPIs you could use for your processes, here’s a list of examples:

CAP-SOP: Corrective and Preventive Action

1. Quick completion of root cause analysis and definition of action plan (goal: within 1 week)
2. Average time for completing action plans (goal: < 1 month)
3. Every process failure has resulted in a CAPA (goal: yes)

CERT-SOP: Product Certification and Registration

1. Unsuccessful attempts of Notified Body assessment due to incomplete documentation (goal: zero)
2. Non-Conforming Product Rate: The percentage of products that do not meet specified quality standards. (goal: <1)
3. The regulatory requirements for every relevant market are regularly monitored (goal: yes)

CEV-SOP: Clinical Evaluation

1. PMCF activities are conducted on time and as planned (goal: yes)
2. The Benefit-Risk profile improves (goal: yes)
3. New clinical data is incorporated, adverse events are monitored (goal: yes)
4. CER Update Timeliness: Time needed to update the CER when new clinical/regulatory data becomes available.

CHM-SOP: Change Management

1. No nonconformities due to incomplete change documentation or wrong change evaluation
2. Change Backlog: Number of pending change requests. For how long have they been pending already? (goal: < 6 months)
3. Have all changes been planned and assessed in advance? Has there been a change request for every change? (goal: yes)

CSV-SOP: Computerized System Validation

1. Nonconformities due to systems not validated prior to use (goal: zero)
2. All systems have been evaluated before use (goal: yes)
3. Validation Schedule Adherence: CSV activities are completed within the planned schedule. (goal: yes)
4. Validation Defect Rate: Number of defects or issues identified during system validation and their severity.

DPL-SOP: Deployment

1. Is always the correct software versions deployed and are obsolete versions not in use anymore? (goal: yes)
2. Is every deployment adequately documented as described in the process (goal: yes)
3. Regulatory Approval: Has every deployment been authorized by the PRRC? (goal: yes)

DRC-SOP: Document and Record Control

1. No minor nonconformities during audits related to this process (goal: zero)
2. Are employees adequately trained when documents change?
3. Time it takes for documents to be reviewed and approved (goal: < 2 days)
4. Are obsolete documents archived and retained according to their retention period? (goal: yes)

SWD-SOP: Integrated Software Development

includes Usability Evaluation and Risk Management

1. Development Cycle Time: Time from start to release (goal: < 1 month)
2. Defect Rate: Number of software defects or bugs identified during development and post-release. (goal: < 2)
3. User errors during usability testing (goal: < 3)
4. Integration of usability evaluation findings into the software development (goal: all findings implemented).
5. Non-conformities due to incomplete / insufficient risk management (goal: 0)
6. Effectiveness of risk mitigation measures in reducing or controlling identified risks (goal: no known risk leads to user complaints)
7. Adherence to the established Risk Management Plan (goal: all activities conducted on time)

FBM-SOP: Feedback Management

1. Short initial response time to feedback (goal: one day)
2. Swift initial action (i.e. initial documentation and classification; goal: 3d)
3. User Satisfaction: Collect feedback from users (goal: users are happy)
4. Trends in feedback reporting are monitored and forwarded to PMS (goal: yes)
5. Feedback data is effectively integrated into the risk management process (goal: yes)

HRA-SOP: Human Resources Administration

1. Regular evaluation of training need (goal: at least annually)
2. Timely implementation of planned training (goal: 100%)
3. CAPA issues that are caused by lack of training (goal: 0)

IAU-SOP: Internal Auditing

1. Number of non-conformities is decreasing over time (goal: yes)
2. Average Time to resolve non-conformities (goal: < 1 week)
3. Audit Program is executed as planned (goal: yes)

MGR-SOP: Management Review

1. Percentage of action items from previous management reviews that have been closed. (goal: 100%)
2. Percentage of improvement initiatives discussed during management reviews that have been implemented. (goal: 100%)
3. Assessment of communication effectiveness between top management and relevant stakeholders. (goal: employees are satisfied)
4. Effectiveness of resource allocation decisions discussed during the management review. (goal: no shortage of resources in the last year)

PCH-SOP: Purchasing

1. No purchases from critical suppliers for which no supplier evaluation has been conducted yet
2. Number of rejected products based on quality assessment (< 1)
3. Average Supplier Response Time to Requests (goal: < 1 workday)
4. Average time to evaluate a supplier (goal: < 1 week)

PMS-SOP: Post-Market Surveillance

1. Complaint Handling Timeliness: The time it takes to acknowledge, investigate, and resolve complaints.
2. Periodic Safety Update Report (PSUR) Timeliness (goal: before deadline)
3. Signal Detection Effectiveness: The ability of the PMS process to detect and investigate emerging safety signals or trends in adverse event data.
4. The risk management is updated based on post-market data. (goal: yes)

PRS-SOP: Problem Resolution

1. Quick completion of root cause analysis and decision (goal: within 2 work days)
2. Time from discovery to solution (goal: < 1 week)
3. Bug Fix Documentation is complete and correct (goal: yes)

URG-SOP: Update of Regulations

1. Identify and implement regulatory updates (goal: within three months of publication)
2. Regulatory updates are regularly assessed (goal: every month)
3. Applicable regulations in targeted markets are taken into account in strategic planning (goal: yes)

VIG-SOP: Vigilance

1. Every relevant event has been assessed acc. to the SOP
2. Average time from discovery of an incident to its reporting (goal: < 2 days)
3. Implemented measures to avoid harm were effective (goal: yes)

Conclusion

There is (almost) no right or wrong when it comes to KPIs. Especially when you’re setting up your QMS from scratch, you likely don’t know (yet) what’s the most important metric for your processes. The KPIs listed above give you a good headstart. Thoughout the years, you will look at these metrics at least once per year in the Management Review. Some of them will prove as helpful, some you might need to replace in order to measure the right things and to keep improving. The quality of your KPIs will be proportional to the maturity of your QMS (hopefully).

Keep in mind that KPIs should facilitate an assessment of the performance of the process. When we take the example of the CAPA process, you might think that measuring the number of CAPAs per year makes sense. However, it is not a good indicator for the process. A lot of CAPAs doesn’t mean that the process is bad while few CAPAs likewise doesn’t say anything. Maybe not all CAPAs are reported, maybe you’re opening a CAPA for too many minor issues. The goal of the KPI is to indicate whether the CAPA process does what it should do when you need it.

Likewise, the goal with KPIs is not to always achieve the goal that you’ve set yourself, but rather to actually paint a comprehensive picture of the quality of your products, services and organizational structure. You can always say you’ve achieved your goal if your goal is to “have a product”. It’s not valuable though. If you set out to have zero customer complaints, it’s way harder, but this metric will show you whether you’re on the right path.

In this regard, the 13485 requirement to measure your processes can actually be helpful for your business. So thanks for requiring this, 13485.