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