FDA 510(k) Search - By Innolitics (SaMD and AI Experts)

The MedApps 2.0 - Remote Patient Monitoring System consists of a patient device, MedApps HealthPAL, which is a mobile Over-The-Counter wireless communication hub that connects to commercially available wireless and tethered Glucose Meters, Scales, Blood Pressure Monitors and Pulse Oximeters. The HealthPAL stores and displays the information on the OLED screen, and transmits the information to the MedApps secure host server called "HealthCOM" using off the shelf FCC approved wireless / cellular connectivity (including, but not limited to GSM, CDMA and WiMax). Healthcare professionals can review the transmitted information within the MedApps HealthCOM system, set thresholds to flag readings based on specific thresholds being exceeded. In addition, the MedApps Interactive Voice Response (IVR) has the ability to contact the patient remotely and use pre-approved ("canned") educational or reminder messages. ("Your nurse would like to talk to you, can I connect you now", "We haven't received a reading from you today, please send us your readings").

The MedApps 2.0 - Remote Patient Monitoring System is not intended for diagnosis or as a substitute for medical care, and it is not intended to provide real time data. The data is made available to the patients when time-critical care is not required. The device is contraindicated for patients requiring direct medical supervision or emergency intervention.

Device Description

The MedApps 2.0 - Remote Patient Monitoring System uses MedApps Accessories that help the patient in usability of the product, including HealthLINK which docks the HealthPAL, and HealthPOD which connects to off the shelf medical devices via their data port to transmit data via wireless or RF technology (including, but not limited to bluetooth, zigbee, ANT, ULP, etc.).

The MedApps 2.0 - Remote Patient Monitoring System consists of:
(1) MedApps HealthPAL hardware:
The physical component of the MedApps HealthPAL is an electronic device contained in a plastic enclosure with an OLED screen, built-in M2M cellular chip, speaker, smart cable connection, smart cables, wireless, LED Lights to indicate activity, timer button to remind the patient to take their reading in X minutes, last reading button, volume up and down buttons.
(2) MedApps HealthPAL software application:
The software application captures, stores and transmits information to the MedApps HealthCOM server, via the embedded communication chip / platform.
The software application takes in additional information via the embedded wireless module from other medical devices that are wireless enabled, and that have been paired to the MedApps HealthPAL.
The software application has many additional functions including:

Download of the users profile from the server to configure the HealthPAL remotely.
Ability to "talk" to the patient with verbal acknowledgments of readings from all attached medical devices, time settings, volume control, educational content and reminders, in any language that is loaded to the device.
Timer set that was activated by the user at a set timeframe to do whatever they wanted to be reminded to do.
Control the OLED screen to show certain information including, battery status, volume level, transmission status, message waiting indicator, medical device last reading, activity icons / messages and more as it pertains to provide ease of use and easier adoption for the patient.
Battery charging, isolation circuits, and interfaces to individual medical devices / protocols via the smart cables.
(3) MedApps HealthLINK hardware / software:
The HealthLINK hardware / software plugs into off the shelf Glucose Meters, Scales, Blood Pressure Monitors and Pulse Oximeters, and transmit the data via wireless to a receiver that it is already paired with.
(4) MedApps HealthPOD hardware / software:
The HealthPOD hardware / software is an extension of the HealthPAL functionality that is outlined in this submission. HealthPOD acts as a "docking" station for the HealthPAL in order to recharge batteries, take in additional connections to off the shelf Glucose Meters, Scales, Blood Pressure Monitors and Pulse Oximeters, via smart cables (per validated in HealthPAL software), add a backup communication method via phone line (POTS line), and communicate via wireless to HealthPAL or additional HealthPODs.
(5) MedApps HealthCOM software application:
The software application allows caregivers to set thresholds and review patient data on the secure HealthCOM website.
The HealthCOM software also allows the patient to establish an account and to direct / authorize their data to be directed to an outside, validated Personal Health Record (PHR), Electronic Health Record (EHR or EMR).
(6) MedApps IVR software application:
The software application calls the patient on any phone that is designated in their user profile, and executes an approved ("canned") script to gather information. ("Your nurse would like to talk to you, can I connect you now", "We haven't received a reading from you today, please send us your readings").
In addition, the MedApps IVR application will send out Email, SMS / Text Messages, Paging, IM and many other forms of communications in order to contact patients or caregivers. This will include reminders and alerts, based on parameters / thresholds set in the HealthCOM system.

AI/ML Overview

The provided document is a 510(k) summary for the MedApps 2.0 - Remote Patient Monitoring System. It describes the device, its intended use, and compares it to predicate devices. However, this document does not contain acceptance criteria, nor does it describe a study proving the device meets specific performance criteria related to diagnostic accuracy or clinical effectiveness.

Instead, the document focuses on demonstrating substantial equivalence to previously cleared predicate devices based on technological characteristics and functional similarities. The "performance data" mentioned refers to non-clinical verification and validation testing, ensuring the system functions as designed and meets its requirements.

Therefore, for many of your requested points, the information is not available in the provided text.

Here's a breakdown based on the information that is available:

1. Table of Acceptance Criteria and Reported Device Performance

This information is not provided in the document. The document primarily focuses on demonstrating substantial equivalence based on technological characteristics rather than specific performance metrics (e.g., sensitivity, specificity, accuracy) against a set of predefined acceptance criteria in a clinical context.

2. Sample size used for the test set and the data provenance

This information is not provided in the document. The "Alpha validation testing" involved "testing of all executable code and functionality" and "exhaustive validation scripts of all Detail Design Specifications (DDS)." This refers to system and software testing, not a clinical test set with patient data.

3. Number of experts used to establish the ground truth for the test set and the qualifications of those experts

This information is not provided. The testing described is non-clinical verification and validation of software functionality and system requirements.

4. Adjudication method for the test set

This information is not provided.

5. If a multi-reader multi-case (MRMC) comparative effectiveness study was done, if so, what was the effect size of how much human readers improve with AI vs without AI assistance

This information is not applicable/provided. The device is a remote patient monitoring system for collecting and transmitting physiological data, not an AI-powered diagnostic tool requiring MRMC studies for human reader improvement. The document explicitly states: "The MedApps 2.0 - Remote Patient Monitoring System is not intended for diagnosis or as a substitute for medical care, and it is not intended to provide real time data."

6. If a standalone (i.e. algorithm only without human-in-the-loop performance) was done

A standalone performance in the sense of diagnostic accuracy is not applicable. The "performance data" described refers to the non-clinical verification and validation of the system's ability to capture, store, transmit, and display data, and to execute functions as per its design specifications. It's a functional performance assessment, not a clinical performance assessment of an algorithm's diagnostic capability. The document states:

"Alpha validation testing included testing of all executable code and functionality and confirmation that all identified hazards have been adequately addressed by software functionality, the user interface, documentation or user SOP."
"Alpha validation activities included exhaustive validation scripts of all Detail Design Specifications (DDS)..."
"The output of these two performance data records documents that MedApps 2.0 - Remote Patient Monitoring System met its required requirements and design specifications as intended."

7. The type of ground truth used

For the non-clinical testing, the "ground truth" was essentially the design specifications and requirements (Detail Design Specifications (DDS) and System Requirements Specifications (FDA-SRS-8009)). The testing confirmed that the device met these predefined functional and technical requirements.

8. The sample size for the training set

This information is not provided and is not applicable, as this device does not describe an AI/ML algorithm that requires a training set in the conventional sense for diagnostic tasks.

9. How the ground truth for the training set was established

This information is not provided and is not applicable, as this device does not describe an AI/ML algorithm that requires a training set in the conventional sense for diagnostic tasks.

Summary of available information regarding claimed "study":

The "study" referenced in the document is a non-clinical verification and validation testing process, not a clinical trial or comparative effectiveness study.

Acceptance Criteria (Implied): The device met its "required requirements and design specifications as intended" during specific Alpha validation activities. These requirements and specifications (detailed in Exhibit 08 - System Requirements Specifications (FDA-SRS-8009) which is not provided but referenced) served as the implicit acceptance criteria for functional performance.
Reported Device Performance: The "output of these two performance data records documents that MedApps 2.0 - Remote Patient Monitoring System met its required requirements and design specifications as intended."
Study Design/Methodology:
- Non-Clinical Testing: "significant verification and validation testing, Alpha validation testing included testing of all executable code and functionality and confirmation that all identified hazards have been adequately addressed by software functionality, the user interface, documentation or user SOP."
- Alpha Validation Activities: "exhaustive validation scripts of all Detail Design Specifications (DDS), which was summarized and discussed to provide a preliminary record of performance data. Additionally, the submitter duplicated the operational environment of a sophisticated user and provided the complete record of those executed scripts as operational performance data."
Conclusion: The device "does not rely on an assessment of clinical performance data. The device conforms to FDA's recognized consensus standards and relies on its conformity to demonstrate its safety and efficacy. The device introduces no new questions concering the safety or efficacy and is, therefore, substantially equivalent to the predicate devices."

The document clearly states that "The MedApps 2.0 - Remote Patient Monitoring System does not rely on an assessment of clinical performance data." This means it did not undergo studies focused on clinical outcomes or diagnostic accuracy against a ground truth from patient data. Its clearance was based on demonstrating substantial equivalence to predicate devices through technical comparisons and non-clinical functional testing.

Summary

Regulation Number and Section

§ 870.2910 Radiofrequency physiological signal transmitter and receiver.

(a)
Identification. A radiofrequency physiological signal transmitter and receiver is a device used to condition a physiological signal so that it can be transmitted via radiofrequency from one location to another, e.g., a central monitoring station. The received signal is reconditioned by the device into its original format so that it can be displayed.(b)
Classification. Class II (performance standards).