Search Results

The myAir app is indicated for patients:

• prescribed with a compatible ResMed Air11 platform device to simulate therapy prior to using their device with their prescribed settings, and to configure their settings to support therapy. It is an optional software accessory to allow patients to acclimate to and operate their therapy device.
• prescribed a NightOwl wearable device to provide the user interface to operate the connected device and aid in the home sleep testing process.

The device is intended for home and hospital use for:

• new and existing patients of ResMed Air10 and Air11 PAP therapy devices and
• new users who are prescribed a compatible NightOwl home sleep test (HST).

myAir is a companion mobile medical application ("app") that serves as a patient self-monitoring, therapy usage tracking, and engagement platform for patients prescribed with compatible ResMed PAP therapy devices and the NightOwl home sleep test (HST) sensors. The app allows the patient to connect via Bluetooth to a compatible hardware device for control of their prescribed PAP or HST device and to allow self-tracking of device usage data. myAir can also be used as a communication pathway using the Bluetooth connection with the compatible device in order to send or receive data. Analysis of patient diagnostic data or display of diagnostic results are not in scope of myAir features.

The myAir subject device for this premarket submission adds device software functions related to starting and stopping therapy, and control of comfort settings (collectively referred to as "device control"). The addition of these device software functions within the myAir subject device is a modification to the K241216 myAir predicate device, in addition to sustaining previously cleared medical device functions.

It appears the provided document is an FDA Clearance Letter for the "myAir" device, specifically a 510(k) summary. This type of document primarily focuses on establishing substantial equivalence to a predicate device, rather than detailing the full scope of acceptance criteria and the comprehensive study results typically found in a clinical study report or a more detailed technical submission.

Based on the provided text, the device "myAir" is a companion mobile medical application. The submission is for a modified device, adding "device software functions related to starting and stopping therapy, and control of comfort settings (collectively referred to as 'device control')".

Therefore, the study detailed is primarily non-clinical verification and validation testing of software functions introduced with these modifications. The document states:

"Non-clinical verification and validation testing completed for device software functions under review introduced with the modifications to the myAir app demonstrated that the device met all intended performance requirements. Testing included:

• Software verification and validation, including non-functional requirements and end-to-end functional testing."

Given this, I cannot provide detailed information about acceptance criteria and study results for clinical performance or human-in-the-loop studies (MRMC, effect size, etc.), as such studies are not described in this 510(k) summary for a software modification. The focus is on the software's functional performance and adherence to guidance documents for software and cybersecurity.

Here's what can be extracted from the provided text according to your request, with a clear indication where information is not available in the document:

Acceptance Criteria and Device Performance for "myAir" (K250624)

The "myAir" device is a mobile application that received FDA 510(k) clearance (K250624) as a modified device, primarily adding "device control functions" (starting/stopping therapy, controlling comfort settings) for compatible ResMed Air11 platform devices. The acceptance criteria and performance detailed below pertain specifically to the non-clinical verification and validation of these new software functions.

1. Table of Acceptance Criteria and Reported Device Performance

2. Sample Size Used for the Test Set and Data Provenance

• Sample Size for Test Set: Not specified. The document mentions "Software verification and validation, including non-functional requirements and end-to-end functional testing." This typically involves a range of test cases, but the specific number is not disclosed in this summary.
• Data Provenance: The document describes "non-clinical verification and validation testing." This implies internal testing conducted by the manufacturer (ResMed Corp, USA). It does not involve patient data or clinical datasets. Therefore, provenance (country, retrospective/prospective) is not applicable in the typical sense of a clinical study.

3. Number of Experts Used to Establish the Ground Truth for the Test Set and Their Qualifications

• Not Applicable/Not specified. For non-clinical software verification and validation, "ground truth" is typically defined by functional requirements specifications and design documents. The testing validates that the software performs according to these pre-defined specifications. Expert human readers or adjudicators are not typically involved in establishing ground truth for this type of testing.

4. Adjudication Method for the Test Set

• Not Applicable/None stated. As the testing is non-clinical software verification, adjudication methods like 2+1 or 3+1 (common in image interpretation studies) are not relevant here. The success or failure of a test case is determined by whether the software performs as specified.

5. If a Multi-Reader Multi-Case (MRMC) Comparative Effectiveness Study Was Done

• No. An MRMC study was not conducted as part of this submission, based on the provided document. The submission pertains to software functionality and its substantial equivalence, not to comparative effectiveness for human readers.
• Effect Size of Human Readers Improvement with AI vs. Without AI Assistance: Not applicable, as no MRMC study or human reader performance evaluation was described. The "myAir" app is an accessory for device control and patient engagement, not an AI diagnostic tool assisting human readers.

6. If a Standalone (i.e., Algorithm Only Without Human-in-the-Loop Performance) Was Done

• Yes, implicitly. The "non-clinical verification and validation testing" is a form of standalone testing for the software's functional performance. The software is tested to operate its intended device control functions (starting/stopping therapy, comfort settings) without direct human intervention in the execution of those specific software commands once initiated. However, this is not "standalone performance" in the sense of a diagnostic algorithm's accuracy, sensitivity, or specificity. It's about the software performing its programmed tasks correctly.

7. The Type of Ground Truth Used

• Functional Requirements and Design Specifications. For this type of software verification, the "ground truth" is established by the detailed specifications of how the software functions are designed to operate. Test cases are then executed to confirm that the actual software behavior matches these expected behaviors. No clinical ground truth (e.g., pathology, outcomes data, expert consensus on patient conditions) is mentioned as being used for the specific software modifications under review.

8. The Sample Size for the Training Set

• Not Applicable/Not disclosed. Since this is software functional verification and validation for a non-AI/ML application (it controls a medical device and provides user interface), there is no "training set" in the sense of data used to train a machine learning model. The software's logic is developed through traditional programming methods, not data training.

9. How the Ground Truth for the Training Set Was Established

• Not Applicable. See point 8. No training set for an AI/ML model is indicated, so no ground truth establishment process for a training set is relevant or described.

Ask a specific question about this device

The myAir app is indicated for patients:
• prescribed with a compatible ResMed Air11 platform device to simulate therapy prior to using their device with their prescribed settings. It is an optional software accessory to allow patients to acclimate to their therapy device.
• prescribed a NightOwl wearable device to provide the user interface to operate the connected device and aid in the home sleep testing process.
The device is intended for home and hospital use for:
• new and existing patients of ResMed Air11 PAP therapy devices and
• new users who are prescribed a compatible NightOwl home sleep test (HST).

myAir is a companion mobile medical application ("app") for self-monitoring use of the compatible devices that serve as a patient Home Sleep Test (HST), pre-therapy, and engagement platform for positive airway pressure (PAP) therapy. The app allows the patient to connect via Bluetooth to a compatible hardware device for temporary control of their prescribed HST or PAP device and to allow self-tracking of device usage data. myAir can also be used as a communication pathway using the Bluetooth connection with the compatible device in order to send or receive data. Analysis of patient diagnostic data or display of diagnostic results are not in scope of myAir features.
The subject device modifies the predicate device by adding interoperability with the NightOwl HST (Stella functions) in addition to sustaining previously cleared medical device function of connecting to the Air 1 platform.

The provided text does not contain detailed information about specific acceptance criteria or a dedicated study proving the device meets those criteria. The document is primarily a 510(k) summary for the myAir app, outlining its substantial equivalence to a predicate device and a reference device. It mentions "non-clinical verification and validation testing" but does not elaborate on the specific tests, acceptance criteria, or results.

Therefore, I cannot provide the requested table or detailed information regarding the study.

However, I can extract the available relevant information:

Acceptance Criteria and Device Performance:

The document states: "Non-clinical verification and validation testing completed for NightOwl HST interoperable (Stella) functions introduced with the modifications to the myAir app demonstrated that the device met all intended performance requirements."

This is a general statement that the device met its intended performance requirements, but no specific acceptance criteria (e.g., accuracy metrics, thresholds for errors) or reported device performance data (e.g., a measured accuracy of X%) are provided in the text.

Regarding the study (based on limited information):

• Sample size used for the test set and data provenance: Not specified. The document only mentions "non-clinical verification and validation testing," implying a test set was used, but details on its size or provenance (country of origin, retrospective/prospective) are absent.
• Number of experts used to establish the ground truth for the test set and their qualifications: Not specified. The information provided is about software testing, not clinical performance evaluation that would typically involve expert ground truth.
• Adjudication method: Not applicable/specified. This type of method is typically used in clinical studies with human assessors, which is not described here.
• Multi-reader multi-case (MRMC) comparative effectiveness study: Not mentioned. The document focuses on software interoperability and functional testing, not comparative clinical effectiveness with human readers.
• Standalone (i.e., algorithm only without human-in-the-loop performance) study: The "non-clinical verification and validation testing" likely includes standalone software testing, but specific details or results are not provided. The myAir app acts as a user interface and data transfer mechanism, not an algorithm for diagnostic analysis or interpretation.
• Type of ground truth used: Not specified. For software functional testing, ground truth would typically be defined by expected system behavior and output under various conditions.
• Sample size for the training set: Not applicable and not specified. The myAir app described here is a companion mobile medical application for control and data transfer, not one that employs machine learning models requiring a training set for diagnostic purposes.
• How the ground truth for the training set was established: Not applicable and not specified.

Summary of what is available from the text:

The document concerns the ResMed myAir app (K241216). It states that non-clinical verification and validation testing was performed for the NightOwl HST interoperable (Stella) functions. This testing "demonstrated that the device met all intended performance requirements." The testing followed FDA guidance documents: "Content of Premarket Submissions for Device Software Functions: June 2023" and "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions: September 2023."

The core of the submission is to establish Substantial Equivalence because:

• The subject device (myAir) and predicate device (Galapagos, K200565) have the same intended use.
• They have similar technological characteristics and operating principles.
• The subject device adds interoperability with the NightOwl HST (Stella functions) to its existing cleared function of connecting to the Air11 platform.
• The differences do not raise any new questions of safety or effectiveness.
• It is as safe and effective as the predicate devices.

Ask a specific question about this device