Essential Performance Requirements and How to Identify Them
The Essential Guide to Requirements Management and Traceability
Chapters
- 1. Requirements Management
- Overview
- 1 What is Requirements Management? A Complete Guide
- 2 Why do you need Requirements Management?
- 3 Four Stages of Requirements Management Processes
- 4 Adopting an Agile Approach to Requirements Management
- 5 Status Request Changes
- 6 Conquering the 5 Biggest Challenges of Requirements Management
- 7 Three Reasons You Need a Requirements Management Solution
- 8 Guide to Poor Requirements: Identify Causes, Repercussions, and How to Fix Them
- 9 What Is a Requirements Management Plan? A Practical Guide
- 2. Writing Requirements
- Overview
- 1 Functional requirements examples and templates
- 2 What Is a Product Requirements Document? A Complete PRD Guide
- 3 What Is a User Requirement Specification (URS)? How to Write and Manage One
- 4 Identifying and Measuring Requirements Quality
- 5 How to Write a System Requirements Specification (SRS) Document
- 6 The Fundamentals of Business Requirements: Examples of Business Requirements and the Importance of Excellence
- 7 What Is a Compliance Risk Assessment? Steps, Framework, and Examples
- 8 Adopting the EARS Notation to Improve Requirements Engineering
- 9 Jama Connect Advisor™
- 10 Frequently Asked Questions about the EARS Notation and Jama Connect Advisor™
- 11 How to Write an Effective Product Requirements Document (PRD)
- 12 Functional vs. Non-Functional Requirements
- 13 What Are Nonfunctional Requirements and How Do They Impact Product Development?
- 14 What Is a Software Design Specification? Key Components + Template
- 15 Characteristics of Effective Software Requirements and Software Requirements Specifications (SRS)
- 16 8 Do’s and Don’ts for Writing Requirements
- 17 Project Requirements: Types, Process, and Best Practices
- 3. Requirements Gathering and Management Processes
- Overview
- 1 Requirements Engineering
- 2 Requirements Analysis
- 3 A Guide to Requirements Elicitation for Product Teams
- 4 Requirements Gathering Techniques for Agile Product Teams
- 5 Requirements Gathering in Software Engineering: Process, Techniques, and Best Practices
- 6 Defining and Implementing a Requirements Baseline
- 7 Managing Project Scope — Why It Matters and Best Practices
- 8 Requirements Decomposition and How AI Supports It
- 9 How Long Do Requirements Take?
- 10 How to Reuse Requirements Across Multiple Products
- 11 Requirements Prioritization Techniques: 7 Methods for Engineers
- 4. Requirements Traceability
- Overview
- 1 What Is Traceability in Product Development? A Guide for Regulated Teams
- 2 Tracing Your Way to Success: The Crucial Role of Traceability in Modern Product and Systems Development
- 3 Bidirectional Traceability: What It Is and How to Implement It
- 4 Change Impact Analysis (CIA): A Short Guide for Effective Implementation
- 5 What is Engineering Change Management (ECM)? A Complete Guide
- 6 What is Meant by Version Control?
- 7 Key Traceability Challenges and Tips for Ensuring Accountability and Efficiency
- 8 The Role of a Data Thread in Product and Software Development
- 9 Unraveling the Digital Thread: Enhancing Connectivity and Efficiency
- 10 What is a Traceability Matrix? A Guide to Requirements Traceability
- 11 How to Create and Use a Requirements Traceability Matrix (RTM)
- 12 Requirements Traceability Matrix Pros and Cons: A Practical Guide
- 13 Live Traceability vs. After-the-Fact Traceability
- 14 Overcoming Barriers to Live Requirements Traceability™
- 15 Requirements Traceability, What Are You Missing?
- 16 Requirements Traceability: Links in the Chain
- 17 What Are the Benefits of End-to-End Traceability During Product Development?
- 18 Requirements Volatility: 7 Essential Management Strategies
- 19 FAQs About Requirements Traceability
- 20 What Is AI Traceability? How to Implement It
- 21 Product Traceability for Regulated Industries: A Complete Guide to Audit-Ready Compliance
- 22 What Is the Traceability Information Model?
- 5. Requirements Management Tools and Software
- Overview
- 1 Selecting the Right Requirements Management Tools and Software
- 2 Why Investing in Requirements Management Software Makes Business Sense During an Economic Downturn
- 3 Why Word and Excel Alone is Not Enough for Product, Software, and Systems Development
- 4 Can You Track Requirements in Excel?
- 5 What Is Application Lifecycle Management (ALM)?
- 6 Is There Life After DOORS®?
- 7 Can You Track Requirements in Jira?
- 8 Checklist: Selecting a Requirements Management Tool
- 6. Requirements Validation and Verification
- 7. Meeting Regulatory Compliance and Industry Standards
- Overview
- 1 Understanding ISO Standards
- 2 Understanding ISO/IEC 27001: A Guide to Information Security Management
- 3 What is DevSecOps? A Guide to Building Secure Software
- 4 Compliance Management
- 5 What Is Functional Safety (FuSa)? Standards, Lifecycle, and Where Programs Fail
- 6 Failure Mode and Effects Analysis (FMEA) Explained
- 7 TÜV SÜD: Ensuring Safety, Quality, and Sustainability Worldwide
- 8 What is IEC 62443? A Guide to Industrial Cybersecurity
- 9 DFARS Compliance: A Guide for Defense Contractors
- 10 CMMC vs FedRAMP: What’s Different and Which One Applies to You
- 11 Automotive SPICE (ASPICE) 4.0: A Complete Guide
- 12 Restriction of Hazardous Substances (RoHS) Compliance Guide
- 13 MISRA C and MISRA C++ Explained: Rules for Safer Embedded Code
- 14 REACH Compliance for Product Engineering Teams
- 8. Systems Engineering
- Overview
- 1 What is Systems Engineering? A Guide for Modern Engineering Teams
- 2 How Do Engineers Collaborate? A Guide to Streamlined Teamwork and Innovation
- 3 The Systems Engineering Body of Knowledge (SEBoK)
- 4 What Is MBSE? Model-Based Systems Engineering Explained
- 5 Digital Engineering Between Government and Contractors
- 6 Digital Engineering Tools: The Key to Driving Innovation and Efficiency in Complex Systems
- 7 What Is Bill of Materials (BOM) Management? A Guide to Controlling Product Data
- 9. Automotive Development
- Overview
- 1 Understanding IATF 16949: A Quick Guide to Automotive Quality Management
- 2 What Is ISO 21434? Automotive Cybersecurity Engineering Explained
- 3 What Is ISO 26262? A Guide to Functional Safety in Automotive
- 4 What Is ASIL? A Guide to Automotive Safety Integrity Levels in ISO 26262
- 5 What Is SOTIF? A Guide to ISO 21448 for ADAS Safety
- 10. Medical Device & Life Sciences Development
- Overview
- 1 The Importance of Benefit-Risk Analysis in Medical Device Development
- 2 Software as a Medical Device: Revolutionizing Healthcare
- 3 What’s a Design History File, and How Are DHFs Used by Product Teams?
- 4 Navigating the Risks of Software of Unknown Pedigree (SOUP) in the Medical Device & Life Sciences Industry
- 5 What Is ISO 13485? A Guide to Medical Device Quality Management Systems
- 6 What Is a Device Master Record (DMR)? Definition and FDA Requirements
- 7 What Is IEC 62304? A Guide to Medical Device Software
- 8 ISO 13485 vs ISO 9001: Understanding the Differences and Synergies
- 9 What You Need to Know: ANSI/AAMI SW96:2023 — Medical Device Security
- 10 Failure Modes, Effects, and Diagnostic Analysis (FMEDA) for Medical Devices: What You Need to Know
- 11 Embracing the Future of Healthcare: Exploring the Internet of Medical Things (IoMT)
- 12 What Is General Safety and Performance Requirements (GSPR)? What You Need To Know
- 13 What Is IEC 62366? A Guide to Medical Device Usability Engineering
- 14 What Is the Quality Management System Regulation (QMSR)?
- 15 510(k) vs PMA: Differences in FDA Device Approval and Clearance
- 16 EU MDR Compliance Requirements and Timeline
- 17 Essential Performance Requirements and How to Identify Them
- 11. Aerospace & Defense Development
- Overview
- 1 What is ITAR Compliance? What Engineering Teams Need to Know
- 2 What Is DO-278A? A Guide for Compliance Teams
- 3 What Is a Safety Integrity Level (SIL)? How to Calculate and Apply It
- 4 What Is ARP4754A? A Complete Guide to Civil Aircraft and Systems Development Assurance
- 5 Understanding ARP4761A: Guidelines for System Safety Assessment in Aerospace
- 6 What Is DO-254? A Complete Guide to Airborne Hardware Design Assurance
- 7 What Is DO-178C? A Guide to Airborne Software Certification
- 12. Architecture, Engineering, and Construction (AEC industry) Development
- 13. Industrial Manufacturing & Machinery, Automation & Robotics, Consumer Electronics, and Energy
- 14. Semiconductor Development
- 15. AI in Product Development
- Overview
- 1 What Is AI in Product Development? A Complete 2026 Guide
- 2 AI Test Case Generation: A Complete Guide for Regulated QA Teams
- 3 Using AI to Write Software Requirements: What Works and What Doesn’t
- 4 What Is the Model Context Protocol (MCP) for Requirements Management?
- 5 AI for Systems Engineering: Benefits, Risks, and How to Start
- 6 How to Automate Requirements Management
- 7 Artificial Intelligence in Requirements Management
- 16. Risk Management
- 17. Product Development Terms and Definitions
Chapter 10: Essential Performance Requirements and How to Identify Them
Chapters
- 1. Requirements Management
- Overview
- 1 What is Requirements Management? A Complete Guide
- 2 Why do you need Requirements Management?
- 3 Four Stages of Requirements Management Processes
- 4 Adopting an Agile Approach to Requirements Management
- 5 Status Request Changes
- 6 Conquering the 5 Biggest Challenges of Requirements Management
- 7 Three Reasons You Need a Requirements Management Solution
- 8 Guide to Poor Requirements: Identify Causes, Repercussions, and How to Fix Them
- 9 What Is a Requirements Management Plan? A Practical Guide
- 2. Writing Requirements
- Overview
- 1 Functional requirements examples and templates
- 2 What Is a Product Requirements Document? A Complete PRD Guide
- 3 What Is a User Requirement Specification (URS)? How to Write and Manage One
- 4 Identifying and Measuring Requirements Quality
- 5 How to Write a System Requirements Specification (SRS) Document
- 6 The Fundamentals of Business Requirements: Examples of Business Requirements and the Importance of Excellence
- 7 What Is a Compliance Risk Assessment? Steps, Framework, and Examples
- 8 Adopting the EARS Notation to Improve Requirements Engineering
- 9 Jama Connect Advisor™
- 10 Frequently Asked Questions about the EARS Notation and Jama Connect Advisor™
- 11 How to Write an Effective Product Requirements Document (PRD)
- 12 Functional vs. Non-Functional Requirements
- 13 What Are Nonfunctional Requirements and How Do They Impact Product Development?
- 14 What Is a Software Design Specification? Key Components + Template
- 15 Characteristics of Effective Software Requirements and Software Requirements Specifications (SRS)
- 16 8 Do’s and Don’ts for Writing Requirements
- 17 Project Requirements: Types, Process, and Best Practices
- 3. Requirements Gathering and Management Processes
- Overview
- 1 Requirements Engineering
- 2 Requirements Analysis
- 3 A Guide to Requirements Elicitation for Product Teams
- 4 Requirements Gathering Techniques for Agile Product Teams
- 5 Requirements Gathering in Software Engineering: Process, Techniques, and Best Practices
- 6 Defining and Implementing a Requirements Baseline
- 7 Managing Project Scope — Why It Matters and Best Practices
- 8 Requirements Decomposition and How AI Supports It
- 9 How Long Do Requirements Take?
- 10 How to Reuse Requirements Across Multiple Products
- 11 Requirements Prioritization Techniques: 7 Methods for Engineers
- 4. Requirements Traceability
- Overview
- 1 What Is Traceability in Product Development? A Guide for Regulated Teams
- 2 Tracing Your Way to Success: The Crucial Role of Traceability in Modern Product and Systems Development
- 3 Bidirectional Traceability: What It Is and How to Implement It
- 4 Change Impact Analysis (CIA): A Short Guide for Effective Implementation
- 5 What is Engineering Change Management (ECM)? A Complete Guide
- 6 What is Meant by Version Control?
- 7 Key Traceability Challenges and Tips for Ensuring Accountability and Efficiency
- 8 The Role of a Data Thread in Product and Software Development
- 9 Unraveling the Digital Thread: Enhancing Connectivity and Efficiency
- 10 What is a Traceability Matrix? A Guide to Requirements Traceability
- 11 How to Create and Use a Requirements Traceability Matrix (RTM)
- 12 Requirements Traceability Matrix Pros and Cons: A Practical Guide
- 13 Live Traceability vs. After-the-Fact Traceability
- 14 Overcoming Barriers to Live Requirements Traceability™
- 15 Requirements Traceability, What Are You Missing?
- 16 Requirements Traceability: Links in the Chain
- 17 What Are the Benefits of End-to-End Traceability During Product Development?
- 18 Requirements Volatility: 7 Essential Management Strategies
- 19 FAQs About Requirements Traceability
- 20 What Is AI Traceability? How to Implement It
- 21 Product Traceability for Regulated Industries: A Complete Guide to Audit-Ready Compliance
- 22 What Is the Traceability Information Model?
- 5. Requirements Management Tools and Software
- Overview
- 1 Selecting the Right Requirements Management Tools and Software
- 2 Why Investing in Requirements Management Software Makes Business Sense During an Economic Downturn
- 3 Why Word and Excel Alone is Not Enough for Product, Software, and Systems Development
- 4 Can You Track Requirements in Excel?
- 5 What Is Application Lifecycle Management (ALM)?
- 6 Is There Life After DOORS®?
- 7 Can You Track Requirements in Jira?
- 8 Checklist: Selecting a Requirements Management Tool
- 6. Requirements Validation and Verification
- 7. Meeting Regulatory Compliance and Industry Standards
- Overview
- 1 Understanding ISO Standards
- 2 Understanding ISO/IEC 27001: A Guide to Information Security Management
- 3 What is DevSecOps? A Guide to Building Secure Software
- 4 Compliance Management
- 5 What Is Functional Safety (FuSa)? Standards, Lifecycle, and Where Programs Fail
- 6 Failure Mode and Effects Analysis (FMEA) Explained
- 7 TÜV SÜD: Ensuring Safety, Quality, and Sustainability Worldwide
- 8 What is IEC 62443? A Guide to Industrial Cybersecurity
- 9 DFARS Compliance: A Guide for Defense Contractors
- 10 CMMC vs FedRAMP: What’s Different and Which One Applies to You
- 11 Automotive SPICE (ASPICE) 4.0: A Complete Guide
- 12 Restriction of Hazardous Substances (RoHS) Compliance Guide
- 13 MISRA C and MISRA C++ Explained: Rules for Safer Embedded Code
- 14 REACH Compliance for Product Engineering Teams
- 8. Systems Engineering
- Overview
- 1 What is Systems Engineering? A Guide for Modern Engineering Teams
- 2 How Do Engineers Collaborate? A Guide to Streamlined Teamwork and Innovation
- 3 The Systems Engineering Body of Knowledge (SEBoK)
- 4 What Is MBSE? Model-Based Systems Engineering Explained
- 5 Digital Engineering Between Government and Contractors
- 6 Digital Engineering Tools: The Key to Driving Innovation and Efficiency in Complex Systems
- 7 What Is Bill of Materials (BOM) Management? A Guide to Controlling Product Data
- 9. Automotive Development
- Overview
- 1 Understanding IATF 16949: A Quick Guide to Automotive Quality Management
- 2 What Is ISO 21434? Automotive Cybersecurity Engineering Explained
- 3 What Is ISO 26262? A Guide to Functional Safety in Automotive
- 4 What Is ASIL? A Guide to Automotive Safety Integrity Levels in ISO 26262
- 5 What Is SOTIF? A Guide to ISO 21448 for ADAS Safety
- 10. Medical Device & Life Sciences Development
- Overview
- 1 The Importance of Benefit-Risk Analysis in Medical Device Development
- 2 Software as a Medical Device: Revolutionizing Healthcare
- 3 What’s a Design History File, and How Are DHFs Used by Product Teams?
- 4 Navigating the Risks of Software of Unknown Pedigree (SOUP) in the Medical Device & Life Sciences Industry
- 5 What Is ISO 13485? A Guide to Medical Device Quality Management Systems
- 6 What Is a Device Master Record (DMR)? Definition and FDA Requirements
- 7 What Is IEC 62304? A Guide to Medical Device Software
- 8 ISO 13485 vs ISO 9001: Understanding the Differences and Synergies
- 9 What You Need to Know: ANSI/AAMI SW96:2023 — Medical Device Security
- 10 Failure Modes, Effects, and Diagnostic Analysis (FMEDA) for Medical Devices: What You Need to Know
- 11 Embracing the Future of Healthcare: Exploring the Internet of Medical Things (IoMT)
- 12 What Is General Safety and Performance Requirements (GSPR)? What You Need To Know
- 13 What Is IEC 62366? A Guide to Medical Device Usability Engineering
- 14 What Is the Quality Management System Regulation (QMSR)?
- 15 510(k) vs PMA: Differences in FDA Device Approval and Clearance
- 16 EU MDR Compliance Requirements and Timeline
- 17 Essential Performance Requirements and How to Identify Them
- 11. Aerospace & Defense Development
- Overview
- 1 What is ITAR Compliance? What Engineering Teams Need to Know
- 2 What Is DO-278A? A Guide for Compliance Teams
- 3 What Is a Safety Integrity Level (SIL)? How to Calculate and Apply It
- 4 What Is ARP4754A? A Complete Guide to Civil Aircraft and Systems Development Assurance
- 5 Understanding ARP4761A: Guidelines for System Safety Assessment in Aerospace
- 6 What Is DO-254? A Complete Guide to Airborne Hardware Design Assurance
- 7 What Is DO-178C? A Guide to Airborne Software Certification
- 12. Architecture, Engineering, and Construction (AEC industry) Development
- 13. Industrial Manufacturing & Machinery, Automation & Robotics, Consumer Electronics, and Energy
- 14. Semiconductor Development
- 15. AI in Product Development
- Overview
- 1 What Is AI in Product Development? A Complete 2026 Guide
- 2 AI Test Case Generation: A Complete Guide for Regulated QA Teams
- 3 Using AI to Write Software Requirements: What Works and What Doesn’t
- 4 What Is the Model Context Protocol (MCP) for Requirements Management?
- 5 AI for Systems Engineering: Benefits, Risks, and How to Start
- 6 How to Automate Requirements Management
- 7 Artificial Intelligence in Requirements Management
- 16. Risk Management
- 17. Product Development Terms and Definitions
Essential Performance Requirements and How to Identify Them
A patient hoist performs two clinical functions, raising a patient and lowering one. A risk analysis may accept a hoist’s failure to lift a patient while treating failure to lower the patient as unacceptable risk. In that analysis, only the lowering function qualifies as essential performance.
That asymmetry sits at the center of essential performance analysis. The manufacturer leads the risk-based determination. In some cases, the manufacturer may conclude the device has no essential performance. Essential performance analysis separates clinical function risk from basic safety risk and anchors the determination within ISO 14971 risk analysis.
This guide covers how essential performance differs from basic safety, how to identify it through risk analysis, and how to test, document, and maintain it as designs change.
What Is an Essential Performance Requirement?
IEC 60601-1 defines essential performance as the performance of a clinical function whose loss or degradation beyond the limits specified by the manufacturer results in an unacceptable risk. That definition gives teams a direct screening question. Would the function’s absence or degradation cross the manufacturer’s acceptable-risk threshold?
An essential performance requirement (EPR) is a documented requirement that captures the clinical function, its performance limits, and the conditions under which those limits apply. Essential performance became a compliance requirement through an amendment to IEC 60601-1. Manufacturers must establish specific performance limits, evaluate essential performance characteristics under abnormal or fault conditions, and declare specific essential performance criteria in the product’s technical description.
Those limits must sit between fully functional and total loss of the identified performance, under both normal and single-fault conditions. The standard notes that the limits can differ between the two conditions. The current Edition 3.2 was published in August 2020, and its requirements have been in effect for U.S. certification since December 17, 2023.
Essential Performance vs. Basic Safety and the Difference
Every requirement in IEC 60601-1 serves one or both of two objectives, basic safety and essential performance. The two concepts answer different questions about the same device.
How IEC 60601-1 Defines Basic Safety
Basic safety covers unacceptable risk directly caused by the device’s physical hazards under normal and single-fault conditions. The physical hazards inherent to the device are electric shock, thermal hazards, and mechanical hazards. Manufacturers typically address them through passive protective measures such as electrical insulation, thermal fuses, and fireproof casings.
Why Clinical Function Is the Dividing Line
Essential performance concerns whether the device delivers its intended clinical benefit. Above that threshold, the harm comes from the failure to treat, monitor, or diagnose. The device’s own physical hazards fall under basic safety. Clinical functions include therapeutic and patient-monitoring functions, along with diagnostic functions built into the equipment itself, such as imaging or waveform analysis. Standalone in vitro diagnostic devices fall outside this scope, as covered below. The split is easiest to see in devices that carry both dimensions at once.
| Dimension | Defibrillator | Infusion pump | Blood pressure monitor |
| Basic safety | Electrical safety of the discharge circuit | Enclosure and electrical insulation | Insulation and touch-current limits |
| Essential performance | Delivering the correct energy level to restart the heart | Dose delivery within specified accuracy limits | Accurate measurement and display of blood pressure |
Both dimensions must survive single fault condition testing. The tested failure differs. One protects against a physical hazard, the other confirms continued delivery of the clinical function.
How to Identify Essential Performance Requirements
Manufacturers identify essential performance through a risk management process that complies with ISO 14971. Essential performance identification must connect directly to risk management under IEC 60601-1.
Starting With a Risk-Based Assessment Under ISO 14971
Identification starts by enumerating every clinical function the device performs, then treating the loss or degradation of each as a potential source of harm. Manufacturers must identify and document known and foreseeable hazards based on the device’s safety characteristics across the intended use and reasonably foreseeable misuse, under both normal and fault conditions, as required by ISO 14971. A risk analysis limited to component failures will miss functions that drift out of specification during ordinary operation, so the normal-condition analysis has to be included.
Teams can use guidance questions from the companion technical report, ISO/TR 24971, to identify device characteristics that affect safety. Those questions help teams avoid narrowing the analysis too early.
Mapping Each Clinical Function to Its Risk
For each function, teams ask whether operation beyond specified performance levels would result in harm. The performance range at which harm occurs establishes the essential performance limits, and if variation in the function doesn’t result in injury, it isn’t essential performance. The manufacturer’s documented policy defines acceptable risk levels.
Teams should assess essential performance before applying risk control measures, because the essential performance they define determines those controls. Assessing after mitigation inverts the logic.
Common Tools for Essential Performance Risk Analysis
Manufacturers choose risk analysis techniques that fit the device and hazard profile. ISO/TR 24971 lists methods such as the following:
- Failure Mode and Effects Analysis (FMEA): A bottom-up method that starts from components and failure modes and works toward hazards. FMEA only identifies risks associated with fault conditions, so it can’t be the sole tool for an analysis that must also cover normal operation.
- Fault Tree Analysis (FTA): A top-down method that starts from a defined top event, such as loss of accurate drug delivery. It decomposes the event into contributing failure combinations with AND and OR gates. Minimal cut sets expose single points of failure threatening an essential performance function.
- Hazard and Operability Analysis: A guide-word technique that examines deviations from design intent. Guide words such as “more than,” “less than,” and “no flow” map directly onto loss or degradation of essential performance.
The directional differences explain why teams combine methods rather than pick one. Running both against the same function surfaces failure paths that a single technique alone would miss.
Deciding When a Device Has No Essential Performance
When the evidence supports no essential performance, the team still follows the same analysis as any other outcome. The same sequence applies when the team believes no essential performance exists:
- All functions of the device are listed.
- Non-clinical functions are removed.
- Functions outside the intended use are removed.
- Loss or degradation of each remaining function is assessed for unacceptable risk.
- Every function that fails that test is identified as essential performance.
Caution is warranted with backup-system arguments, because the risk analysis still needs to account for harm the primary system may cause before the backup engages. Auditors may scrutinize a bare no-essential-performance statement, so the supporting risk assessment must be retrievable when a test laboratory or regulator requests it.
How to Test and Document Essential Performance Requirements
Identifying an EPR creates testing and documentation obligations that follow the device through certification and beyond. Each requirement needs preplanned acceptance criteria, standards mapping, and traceability to verification evidence.
Setting Acceptance Criteria for Each EPR
Pass/fail criteria for immunity testing must be quantitative, specific to the medical device and its functions, observable, and documented in the electromagnetic compatibility (EMC) test plan before testing begins. Criteria defined after the fact invite challenge during regulatory review. Essential performance and basic safety must not be affected by electromagnetic disturbances under IEC 60601-1-2, the EMC collateral standard, and degradation that produces unacceptable risk isn’t allowed, even when an alarm accompanies it.
Measurable criteria can include the accuracy of a life-supporting function and the correct operation of an alarm whose failure would pose an unacceptable risk. Teams should make the required performance limit testable before laboratory work starts.
Mapping EPRs to Applicable Standards
For covered device types, particular standards name essential performance explicitly and are the first place to look. For infusion pumps, a later edition of IEC 60601-2-24 added a table of EPRs where an earlier edition had none. Defibrillator EPR areas include charging time, endurance, synchronizer function, and recovery of electrocardiogram (ECG) inputs after defibrillation, as identified in EN 60601-2-4.
A pulse oximeter’s essential performance is the accuracy of peripheral oxygen saturation (SpO2) and pulse rate, or an indication of abnormal operation, under ISO 80601-2-61. Where no particular standard applies, risk assessment and knowledge of predicate devices define essential performance. If a particular standard specifies no additional essential performance requirements, the manufacturer reverts to the general standard.
Recording Rationale for Audit and Regulatory Review
For audit and regulatory review, the risk management file should connect essential performance, failure modes, risk controls, and verification results. Each identified hazard must be traceable in accordance with ISO 14971. Reviewers evaluate the whole file for consistency, and non-conformities often cluster at document interfaces. The auditable chain needs to hold at each interface:
- Hazard to risk control: each identified hazard links to the risk control that mitigates it.
- Risk control to requirement: each risk control links to the requirement that implements it.
- Requirement-to-test result: each requirement links to the test protocol and the pass/fail result that verifies it.
The chain looks largely the same across U.S. Food and Drug Administration (FDA) and European Union Medical Device Regulation (EU MDR) reviews. Keeping those links current makes the rationale easier to defend.
Common Challenges When Defining Essential Performance
Teams that run the risk process correctly still stumble on recurring problems. Essential performance can sit in supporting functions, connected products, and later design changes.
Overlooking Secondary or Monitoring Functions
Alarm functions can be essential to the performance of devices such as patient monitors, neonatal warmers and incubators, anesthesia delivery systems, dialysis machines, infusion pumps, and ventilators. Raising visual and auditory alarms to alert caregivers is itself a clinical function whose loss can create unacceptable risk. Later editions of IEC 60601-1 expanded the scope to capture performance such as the accuracy of physiological monitoring equipment.
Identification has to cover supporting functions as well as the primary therapeutic one. Otherwise, teams can miss the function that distinguishes safe intervention from delayed response.
Added Complexity in Combination Products
Drug-device combination products can carry a second layer of analysis, because teams need to assess, characterize, and control interactions of the constituent parts in addition to the parts themselves. EPRs for combination products are design input requirements for safe and effective operation, and they’re usually a subset of Critical Quality Attributes (CQAs) in drug Quality by Design language.
Keeping EPRs Current Through Design Changes
Any change to a device’s intended use can change its essential performance, and a predicate device with essential performance can create the expectation that yours will need it too. Alarm system changes sit in the same trap, since teams must assess the significance of removing, adding, or modifying alarm handling. Teams that push alarm changes through routine engineering change orders without an essential performance impact assessment create a documented compliance gap.
Retroactive documentation of changes can become an audit finding. A living essential performance analysis makes those impacts easier to spot before the record falls behind the design.
How Jama Connect Supports Essential Performance Requirements
When EPR artifacts live in disconnected spreadsheets, Jama Connect® can support regulated teams by keeping risk activities such as FMEA and hazard analysis alongside the requirements they trace to. Its medical device framework is aligned to ISO 13485, IEC 62304, ISO 14971, and FDA design controls.
When designs change, Live Traceability™ helps keep requirements, risk records, design outputs, and test evidence connected. If an essential performance limit changes, suspect links flag linked test cases and risk assessments for review before the gap becomes a finding.
Keep Essential Performance Requirements Audit Ready
Changes to standards and design inputs can alter EPRs after release. Intended-use changes can do the same. Teams should keep the hazard-to-requirement-to-test rationale up to date as those inputs evolve.
If your team is still rebuilding traceability before each audit, Jama Connect helps keep requirements, risks, and tests connected in one place. You can see how connected requirements, risks, and tests work together with a free trial of Jama Connect.
Frequently Asked Questions About Essential Performance Requirements
What is the difference between essential performance and basic performance?
Essential performance covers clinical functions that cross the IEC 60601-1 unacceptable-risk threshold. Basic performance is what the device delivers per manufacturer specifications, labeling, public claims, or risk controls, and standardized performance covers requirements published in national or international standards. Teams can document those distinctions in design input requirements to avoid over-declaring or under-declaring EPRs.
Does essential performance apply to in vitro diagnostic devices or standalone software?
IEC 60601-1 does not apply to in vitro diagnostic (IVD) devices or standalone software. IEC 61010-1, its sister standard, is a safety-only standard that doesn’t address essential performance. Embedded software that controls or monitors a device, such as a heart-lung machine’s pump control, can still implement essential performance characteristics and needs linked test cases.
Can a manufacturer treat all functions as essential performance for immunity testing?
Yes. For immunity testing, manufacturers may either identify essential performance with guidance in Annex GGG or consider all functions essential under IEC 60601-1-2. The current edition also requires notifying end users about any expected loss of performance, even when the degradation doesn’t affect basic safety or essential performance.
This article was authored by Tom Rish and published on August 7, 2026.
Book a Demo
See Jama Connect in Action!
Our Jama Connect experts are ready to guide you through a personalized demo, answer your questions, and show you how Jama Connect can help you identify risks, improve cross-team collaboration, and drive faster time to market.