Irregular Rhythm Notification Feature (IRNF)
Apple Inc. • Cardiovascular • 07/21/2023
Device Purpose
Apple's Irregular Rhythm Notification Feature (IRNF) 2.0 is an over-the-counter software application that utilizes Apple Watch's photoplethysmography sensor and proprietary algorithms to analyze pulse rate data for rhythms suggestive of atrial fibrillation, providing opportunistic notifications to users. This iteration of the device incorporates a Predetermined Change Control Plan, allowing for specified future software modifications to its tachogram classification and confirmation cycle algorithms within a controlled framework that includes robust verification and validation to ensure ongoing safety and effectiveness.
Summary
Apple's Irregular Rhythm Notification Feature (IRNF) 2.0 is a software-only mobile medical application designed for use with Apple Watch and iPhone. It employs photoplethysmography (PPG) sensors on the Apple Watch to collect pulse rate data, which is then analyzed by algorithms (tachogram classification and confirmation cycle) to identify episodes of irregular heart rhythms suggestive of atrial fibrillation (AFib). If potential AFib is detected, the system provides an over-the-counter (OTC) notification to the user. This feature is intended for opportunistic screening, capturing data only when the user is still and sufficient data are available, to supplement AFib screening decisions alongside user risk factors. It is explicitly not a replacement for traditional diagnostic methods or treatment, and is not intended for individuals under 22 years of age or those previously diagnosed with AFib. The IRNF 2.0 system comprises an application on the Apple Watch, which handles data analysis using its tachogram classification and confirmation cycle algorithms and generates AFib notifications, and a companion Health App on the iPhone. The iPhone app facilitates user onboarding, provides educational materials, and displays a history of AFib notifications, including details of irregular tachograms. A key aspect of this iteration of IRNF 2.0 is the implementation of a Predetermined Change Control Plan (PCCP). This plan outlines specific, anticipated modifications to the software's algorithms, such as adjusting numerical thresholds for AFib classification or retraining algorithms with new datasets, and changes to the confirmation cycle parameters. These modifications are governed by a rigorous protocol that includes impact assessments, data management practices, and specified verification and validation activities (including demographic requirements for test data like age, sex, race, and skin tone) to ensure the device remains as safe and effective, with updates communicated to users.
AI Regulatory Concerns
Powered by
Jev reads the full FDA letter and returns calibrated concern probabilities per regulatory category. These are AI estimates, not regulatory advice.
Keywords
Device Metadata
Relevant Clinical Questions
- Q1. How does the tachogram classification algorithm differentiate between AFib-suggestive irregular rhythms and other types of arrhythmias or artifacts, especially during periods of user stillness?; What are the specific sensitivity, specificity, and positive predictive value targets for the IRNF 2.0 in identifying AFib, and how do these compare to traditional AFib screening methods in the intended OTC population?; Considering the opportunistic nature of data capture (only when still and sufficient data are available), what is the potential impact on missing AFib episodes, and how is this risk effectively communicated to users?; What are the minimum criteria (e.g., duration, number of irregular tachograms) for the confirmation cycle algorithm to trigger a notification, and how were these thresholds validated to balance detection rates against false positives?; Regarding the Predetermined Change Control Plan (PCCP), what are the specific boundaries or limits for algorithm modifications (e.g., threshold adjustments, dataset characteristics for retraining) that ensure changes remain within the established safety and effectiveness profile without necessitating a new regulatory submission?
Risk Classification
ESL AnalysisFDA Class II via 510(k) pathway; IEC 62304 Class C (software safety classification); Authorized before §524B enforcement
Learn how Parasoft automates IEC 62304 compliance testing →Cybersecurity Evidence
Powered by SBOMator™Based on AI-generated device summaries, not the full FDA submission. Items not detected here may still be present in the complete submission package.
Supply Chain BOM Evidence
Based on the CycloneDX / OWASP ECMA-424 xBOM ecosystem. Detection is from the AI-generated summary.
Analysis:
• Analysis is based on the AI-generated device summary, not the full FDA submission package. Click "Analyze Full FDA PDF" below to scan the actual submission document.
• Evidence of ML-BOM, HBOM detected in AI-generated device summary.
• This device was authorized before §524B took effect. Cybersecurity evidence requirements were less prescriptive at the time.
• Not detected in AI-generated device summary: SBOM, SaaSBOM, CBOM, VDR/VEX, OBOM. These may be present in the full FDA submission.
Preparing a similar submission?
ESL takes complete ownership of your software evidence work - SBOM & CVE remediation with SBOMator™, static analysis & unit testing with Parasoft, traceability, and full IEC 62304 lifecycle support.
Assess Your Readiness →Or contact ESL directly