Search Results

The MedApps /Alere Connect 2.0 Remote Patient Monitoring System is not intended for diagnosis or as a substitute for medical care, nor is it intended to provide real-time / time-critical data. The device is contraindicated for patients requiring direct medical supervision or emergency intervention.

The MedApps 2.0 - Remote Patient Monitoring System consists of:

• HealthPAL hardware: (1) The physical component of the 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 module. LED lights to indicate activity, timer button to assist patients with their reading schedule (i.e. remind them to take their reading in X minutes), last reading button, volume up and down buttons. The HealthPAL Model 105 contains a GSM cellular module while the HealthPAL Model 106 contains a CDMA cellular module.
• HealthHUB hardware / software: (2) The HealthHUB hardware is an extension of the HealthPAL functionality. HealthHUB acts as a "docking" station for the HealthPAL in order to act as a conduit for the AC power adaptor connecting the electrical wall outlet to the HealthPAL providing power and battery charging capability. The Hubs also provide additional connections to off the shelf Glucose Meters, Scales, Blood Pressure Monitors and Pulse Oximeters, via smart cables (per validated in HealthPAL software). The HealthHUB model MA200 allows for multiple wired connections for accessory devices. HealthHUB Model 205 is specific for the HealthPAL MA105, and the HealthHUB 206 is specific for the HealthPAL MA 106 with both Hubs having one wired connector.
• HealthPAL firmware / software: (3) The firmware captures data from commercially available health monitors, and stores and transmits the information to the HealthCOM server, via the embedded communication chip / platform. The firmware allows HealthPAL to receive information via wire or via embedded wireless module from accessory medical devices that are compatibly wireless enabled, which have been paired to the MedApps HealthPAL. The firmware has many additional functions including: Download of user profiles from the server to configure HealthPAL remotely. HealthPAL has audio capability to deliver verbal announcement of readings and acknowledgment of data transmission from all connected accessory medical devices, time settings, volume control, educational content and reminders, in any language that is loaded to the device. Timer capability, activated by the user to provide assistance with adhering to a reading schedule (reminders to take readings within a set timeframe). OLED screen displays information regarding the HealthPAL's status including battery level, volume level, data transmission status, transmission pending indicator, activity icons / messages and other information to provide ease of use and promote patient adherence; as well as information received from accessory medical devices, such as the type of device, measurement, date and time of the last reading collected. Battery charging, isolation circuits, and interfaces to individual accessory medical devices / protocols via the smart cable.
• MobileLink hardware / software: (4) AC020 MobileLink is a modified MA105 HealthPAL device. The physical component of the MobileLink is an electronic device contained in a plastic enclosure with built-in M2M cellular chip, speaker, standard USB cable and USB Smart Cable connection, OLED screen to review the reading, and LED lights to indicate activity regarding the receiving and transmitting of collected data. Like the HealthPAL, MobileLink's firmware / software captures, data from commercially available retail health monitors, and transmits information. to the HealthCOM server, via the embedded communication chip / platform. The firmware allows MobileLink to receive information via wire, either standard USB or with a customized USB Smart Cable, from accessory medical devices. The firmware has many additional functions including: Download of user profiles from the server to configure MobileLink remotely. MobileLink's Audio feature uses audio tones to indicate acknowledgment of collected readings from all connected accessory medical devices as well as reading transmission via the cellular network. MobileLink's visual user interface utilizes an OLED display to display collected readings from attached accessory medical devices as well as reading transmission acknowledgements. MobileLink's visual interface also contains a LED light to show power and provide reading request indication capability.
• HomeLink hardware / software: (5) AC200 HomeLink is a modified MA105 HealthPAL device. The physical component of the HomeLink is an electronic device contained in a plastic enclosure with built-in M2M cellular chip, speaker, standard USB cable and USB Smart Cable connection, touch screen to review the reading and allow patients with ability to have "IVR" (questions and answers) functionality that was formally part of the HealthCOM IVR section, and wireless module. Like the HealthPAL or MobileLink, HomeLink's firmware / software captures biometric data from FDA cleared commercially available accessory devices, and stores and transmits information to the HealthCOM server, via the embedded communication chip / piatform. The firmware allows HomeLink to receive information via wire or via embedded wireless module from accessory medical devices that are compatibly wireless enabled, which have been paired to the HomeLink device. The firmware has many additional functions including: Download of user profiles from the server to configure HomeLink remotely. HomeLink's has audio capability to deliver verbal announcement of readings and acknowledgment of data transmission from all connected accessory medical devices, volume control, user feedback, in any language that is loaded to the device. HomeLink's visual user interface utilizes a touch screen display to display collected readings from attached accessory medical devices as well as other user interactions. One such patient HomeLink user interface includes the MedApps 2.0 System IVR functionality, which originally was executed from the HealthCOM webportal by professionals to patient's phones. The updated version allows end users (patients) to provide answers on the HomeLink device based on professional predefined questions that are reviewed in HealthCOM. This allows an improved user interaction of the previous IVR procedure. HomeLink screen also displays information regarding the device's status including volume level, data transmission status, preferred language, transmission pending indicator, activity icons / messages and other information to provide ease of use and promote patient adherence; as well as information received from accessory medical devices, such as the type of device, measurement, date and time of the last reading collected.
• MedApps HealthCOM software application: (6) The HealthCOM software application allows caregivers access to review patient data collected from accessory medical devices using MedApps hardware on the secure HealthCOM website. HealthCOM software allows professional caregivers to set patient readings. 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 or Medical Record (EHR or EMR),
• MedApps IVR software application from HealthCOM: (7) The IVR (Interactive Voice Response) software application provides the ability to contact the patient remotely, by phone (designated in the user profile), and executes an pre-approved ("canned") scripts to deliver pre-approved ("canned") 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"), educational content and gather survey information. In addition, the MedApps IVR application will send out Email, SMS / Text Messages, Paging, IM and other forms of communications in order to contact patients or caregivers. This will include reminders and alerts, based on clinically defined parameters / thresholds established in HealthCOM by the professional care provider. The original IVR system has moved to the HomeLink device for easier interaction with the patient compared to the need for the patient to receive an IVR phone call on their personal phone, which includes professionally defined questions that the patient can answer and both the questions and answers will be recorded in the HealthCOM system for professional review.
• Accessory Device Descriptions: (8)

The document describes the MedApps 2.0 - Remote Patient Monitoring System and states that its conformity to FDA's recognized consensus standards demonstrates its safety and efficacy. No specific acceptance criteria or a dedicated study proving device performance against such criteria are explicitly provided. Instead, the submission focuses on demonstrating substantial equivalence to predicate devices through a comparison of technological characteristics and non-clinical testing.

Here's a breakdown of the requested information based on the provided text:

1. Table of Acceptance Criteria and Reported Device Performance

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

The document does not specify a sample size for a "test set" in the context of clinical performance evaluation. The testing described is primarily non-clinical performance data testing and review, focused on design control verification and validation. The data provenance is internal to MedApps' development process, likely involving various test environments and scenarios, rather than patient data from a specific country or collected retrospectively/prospectively from a clinical trial.

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

This information is not provided in the document. The testing described appears to be engineering and software verification/validation, not a study requiring expert-established ground truth on patient data.

4. Adjudication Method for the Test Set

This information is not provided as the described testing is not an adjudication process involving multiple reviewers for clinical outcomes.

5. Multi-Reader Multi-Case (MRMC) Comparative Effectiveness Study

No, a Multi-Reader Multi-Case (MRMC) comparative effectiveness study was not done. The document explicitly states: "The MedApps 2.0 Remote Patient Monitoring System does not rely on an assessment of clinical performance data."

6. Standalone (Algorithm Only Without Human-in-the-Loop Performance) Study

The device is a "Remote Patient Monitoring System" that facilitates the collection and transmission of data from accessory medical devices for review by healthcare professionals. While the system operates without direct human intervention during data collection and transmission, its overall function is designed to support human monitoring. The described testing is primarily about the reliability and functionality of data collection and transmission, not a standalone diagnostic or interpretive algorithm's performance in a clinical sense. Therefore, a standalone study evaluating an "algorithm only" performance in the typical sense (e.g., diagnostic accuracy of an AI model) does not appear to have been done or is not relevant to the described device's function as a data transmission hub.

7. Type of Ground Truth Used

For the non-clinical performance testing described, the "ground truth" would be the expected functional behavior and compliance with design specifications and regulatory standards. This is established through the device's design requirements, engineering specifications, and validated test procedures, rather than expert consensus on clinical cases, pathology, or outcomes data.

8. Sample Size for the Training Set

This information is not applicable/not provided. The MedApps 2.0 System is a hardware and software system for data collection and transmission, not a machine learning or AI algorithm that requires a "training set" in the conventional sense for clinical interpretation or prediction.

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

This information is not applicable/not provided for the same reasons as #8.

Ask a specific question about this device

The MedApps (Alere Connect) 2.0 - Remote Patient Monitoring System consists of 1) a cellular communication hub (MedApps' HealthPAL or MobileLink) an over-the-counter device that resides with the end-user (patient), which connects to commercially available FDA cleared accessory devices, specifically glucose meters, scales, blood pressure monitors, pulse oximeters, and PT/INR monitors and 2) web-based health data management application (MedApps' HealthCOM), that provides access to collected data stored on a secure host server system.

MedApps Inc., DBA Alere Connect Remote Patient Monitoring devices receive and store measurements collected from the described accessory devices, either wirelessly using short-range radio protocols (e.g. Bluetooth, Zigbee, WiFi, Bluetooth Low Energy (BLE), Fitlinxx Radios) or tethered via cable (e.g. USB, serial, etc). Regardless of connectivity mode, the MedApps / Alere Connect monitoring devices do not alter the indications for use of the described peripheral accessory health devices.

MedApps / Alere Connect devices indicate successful or failed data reception and transmission with visual and audio feedback using a combination of any of the following: OLED Display, LED Lights, verbal messages, and / or audio tones / chimes. MedApps / Alere Connect devices store collected data and forward / transmit to server for access in HealthCOM via commercially available, FCC compliant, wireless telecommunication protocols (including but not limited to cellular GSM, CDMA and WiMax).

Healthcare professionals, clinicians and other authorized personnel can review the transmitted information within the MedApps HealthCOM system, where they can review collected readings, establish parameters to Indicate readings exceptions to set thresholds, or trigger Interactive Voice Response (IVR) messages to the patient remotely to issue Information such as reminders (e.g. "We haven't received readings from you today, please take and send your readings") or possibly educational information for conditions such as diabetes, hypertension, CHF, etc. Additionally, HealthCOM can port collected data to the healthcare providers' clinical back-end system(s) of choice.

The MedApps 2.0 (Alere Connect) - Remote Patient Monitoring System is not intended for diagnosis or as a substitute for medical care, nor is it intended to provide real-time / time-critical data. The device is contraindicated for patients requiring direct medical supervision or emergency intervention.

The MedApps 2.0 - Remote Patient Monitoring System consists of:

• (1) HealthPAL hardware: The physical component of the 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 module, LED lights to indicate activity, timer button to assist patients with their reading schedule (i.e. remind them to take their reading in X minutes), last reading button, volume up and down buttons. The HealthPAL Model 105 contains a GSM cellular module while the HealthPAL Model 106 contains a CDMA cellular module.
• (2) HealthHUB hardware / software: The HealthHUB hardware is an extension of the HealthPAL functionality. HealthHUB acts as a "docking" station for the HealthPAL in order to act as a conduit for the AC power adaptor connecting the electrical wall outlet to the HealthPAL providing power and battery charging capability. The Hubs also provide additional connections to off the shelf Glucose Meters, Scales, Blood Pressure Monitors and Pulse Oximeters, via smart cables (per validated in HealthPAL software). The HealthHUB model MA200 allows for multiple wired connections for accessory devices. HealthHUB Model 205 is specific for the HealthPAL MA105, and the HealthHUB 206 is specific for the HealthPAL MA 106 with both Hubs having one wired connector.
• (3) HealthPAL firmware / software: The firmware captures data from commercially available health monitors, and stores and transmits the information to the HealthCOM server, via the embedded communication chip / platform. The firmware allows HealthPAL to receive information via wire or via embedded wireless module from accessory medical devices that are compatibly wireless enabled, which have been paired to the MedApps HealthPAL. The firmware has many additional functions including: Download of user profiles from the server to configure HealthPAL remotely, Audio capability to deliver verbal announcement of readings and acknowledgment of data transmission, Timer capability, OLED screen displays information regarding the HealthPAL's status, Battery charging, isolation circuits, and interfaces to individual accessory medical devices / protocols via the smart cable.
• (4) MobileLink (formally HealthAIR) hardware / software: AC020 MobileLink is a modified MA105 HealthPAL device. The physical component of the MobileLink is an electronic device contained in a plastic enclosure with built-in M2M cellular chip, speaker, standard USB cable and USB Smart Cable connection, OLED screen to review the reading, and LED lights to indicate activity regarding the receiving and transmitting of collected data. Like the HealthPAL, MobileLink's firmware / software captures, data from commercially available retail health monitors, and stores and transmits information to the HealthCOM server, via the embedded communication chip / platform. The firmware allows MobileLink to receive information via wire, either standard USB or with a customized USB Smart Cable, from accessory medical devices. The firmware has many additional functions including: Download of user profiles from the server to configure MobileLink remotely, MobileLink's Audio feature uses audio tones to indicate acknowledgment of collected readings, MobileLink's visual user interface utilizes an OLED display to display collected readings.
• (5) MedApps HealthCOM software application: The HealthCOM software application allows caregivers access to review patient data collected from accessory medical devices using MedApps hardware on the secure HealthCOM website. HealthCOM software allows professional caregivers to set patient readings. 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 or Medical Record (EHR or EMR).
• (6) MedApps IVR software application: The IVR (Interactive Voice Response) software application provides the ability to contact the patient remotely, by phone (designated in the user profile), and executes an pre-approved ("canned") scripts to deliver preapproved ("canned") reminder messages, educational content and gather survey information. In addition, the MedApps IVR application will send out Email, SMS / Text Messages, Paging, IM and other forms of communications in order to contact patients or caregivers. This will include reminders and alerts, based on clinically defined parameters / thresholds established in HealthCOM by the professional care provider.

The provided text describes the MedApps 2.0 - Remote Patient Monitoring System and its substantial equivalence to predicate devices, but it does not contain acceptance criteria or details of a study that proves the device meets specific acceptance criteria in the way you've outlined for clinical performance studies.

This document is a 510(k) Premarket Notification summary, which typically focuses on demonstrating "substantial equivalence" to a legally marketed predicate device rather than conducting new clinical performance studies to establish efficacy against a set of predetermined acceptance criteria.

The key statement is found in section "G. SAFETY AND EFFICACY":
"The MedApps 2.0 Remote Patient Monitoring System 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 does not introduce any new questions concerning the safety or efficacy and is, therefore, substantially equivalent to the predicate devices."

Therefore, I cannot populate most of the requested fields because the information is not present in the provided document.

Here's what can be extracted based on the document:

Acceptance Criteria and Device Performance Study Details

1. Table of Acceptance Criteria and Reported Device Performance:

2. Sample size used for the test set and data provenance:
Not applicable. No clinical test set or patient data for performance evaluation is described. The relevant testing is "design control verification and validation testing" and "certification testing."

3. Number of experts used to establish the ground truth for the test set and their qualifications:
Not applicable. No clinical test set with ground truth established by experts is described.

4. Adjudication method (e.g., 2+1, 3+1, none) for the test set:
Not applicable. No clinical test set with adjudication is described.

5. If a multi-reader multi-case (MRMC) comparative effectiveness study was done, and its effect size:
No. The document explicitly states that the device does not rely on clinical performance data.

6. If a standalone (i.e., algorithm only without human-in-the-loop performance) was done:
Not applicable. The device is a "Remote Patient Monitoring System," which involves collecting and transmitting patient data from accessory devices to healthcare professionals. Its performance is related to accurate data transmission and system functionality, not a standalone diagnostic algorithm.

7. The type of ground truth used (expert consensus, pathology, outcomes data, etc.):
Not applicable for clinical performance. For system validation, the "ground truth" would be the expected functional behavior and data integrity as per design specifications and accessory medical device readings.

8. The sample size for the training set:
Not applicable. The document does not describe a machine learning model or "training set" in the context of clinical performance.

9. How the ground truth for the training set was established:
Not applicable.

Summary of Device Verification & Validation (Non-Clinical):

The document mentions the following non-clinical testing:

• MedApps' design control verification and validation testing: This included testing all executable code and functionality, and confirming that identified risks were addressed by software functionality, the user interface, documentation, or user SOP.
• MedApps Product Verification and Release Plan execution: Ensured both HealthPAL and MobileLink medical devices work with each type of user accessory medical device (glucose, blood pressure monitor, scale, pulse oximeter, and PT/INR) as part of the MedApps 2.0 System, including integration to the HealthCOM backend software application.
• Certification testing: EMC (60601-1-2) and Safety (60601-1) as described in MedApps' Declaration of Conformity.

These activities confirm that the system meets its requirements and design specifications but do not constitute a clinical performance study with defined acceptance criteria for diagnostic or prognostic accuracy.

Ask a specific question about this device

The MedApps 2.0 - Remote Patient Monitoring System consists of a patient device, MedApps HealthPAL, a mobile over-the-counter wireless communication hub, or MedApps HealthAIR, a portable over-the-counter wireless communication hub, which connects to commercially available glucose meters, scales, blood pressure monitors and pulse oximeters and HealthCOM, MedApps' secure host server system.

MedApps Remote Patient Monitoring devices receive and store measurements collected from the described monitors, either wirelessly (HealthPAL) or tethered (HealthPAL or HealthAIR). MedApps devices do not alter the indicated use of the peripheral monitors that they integrate with. MedApps devices indicate successful or failed reception and transmission of data with visual and audio cues (HealthPAL via OLED display screen, verbal message and audio tones; HealthAIR via LED lights and audio tones). MedApps devices store collected data and transmit to HealthCOM using commercially available, FCC compliant, wireless telecommunication protocols (including but not limited to cellular 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.

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 module, LED lights to indicate activity, timer button to assist patients with their reading schedule (i.e. remind them to take their reading in X minutes), last reading button, volume up and down buttons.
(2) MedApps HealthPAL firmware / software:
The firmware captures data from commercially available health monitors, and stores and transmits the information to the MedApps HealthCOM server, via the embedded communication chip / platform.
The firmware allows HealthPAL to receive information via wire or via embedded wireless module from accessory medical devices that are compatibly wireless enabled, which have been paired to the MedApps HealthPAL.
The firmware has many additional functions including:
Download of user profiles from the server to configure HealthPAL remotely.
HealthPAL has audio capability to deliver verbal announcement of readings and acknowledgment of data transmission from all connected accessory medical devices, time settings, volume control, educational content and reminders, in any language that is loaded to the device.
Timer capability, activated by the user to provide assistance with adhering to a reading schedule (reminders to take readings within a set timeframe).
OLED screen displays information regarding the HealthPAL's status including battery level, volume level, data transmission status, transmission pending indicator, activity icons / messages and other information to provide ease of use and promote patient adherence; as well as information received from accessory medical devices, such as the type of device, measurement, date and time of the last reading collected.
Battery charging, isolation circuits, and interfaces to individual accessory medical devices / protocols via the smart cable.
(3) MedApps HealthAIR hardware / software:
MA020 HealthAIR is a modified MA105 HealthPAL device. The physical component of the MedApps HealthAIR is an electronic device contained in a plastic enclosure with built-in M2M cellular chip, speaker, standard USB cable and USB Smart Cable connection, and LED lights to indicate activity regarding the receiving and transmitting of collected data.
Like the HealthPAL, HealthAIR's firmware / software captures, data from commercially available retail health monitors, and stores and transmits information to the MedApps HealthCOM server, via the embedded communication chip / platform.
The firmware allows HealthAIR to receive information via wire, either standard USB or with a MedApps USB Smart Cable, from accessory medical devices.
The firmware has many additional functions including:
Download of user profiles from the server to configure HealthAIR remotely.
HealthAIR's Audio feature uses audio tones to indicate acknowledgment of collected readings from all connected accessory medical devices as well as reading transmission via the cellular network.
HealthAIR's visual user interface utilizes LED lights of collected readings from all attached medical devices as well as reading transmission acknowledgements (via).
(5) MedApps HealthCOM software application:
The HealthCOM software application allows caregivers access to review patient data collected from accessory medical devices using MedApps hardware on the secure HealthCOM website. HealthCOM software allows professional caregivers to set patient readings.
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 or Medical Record (EHR or EMR).
(6) MedApps IVR software application:
The IVR (Interactive Voice Response) software application provides the ability to contact the patient remotely, by phone (designated in the user profile), and executes an pre-approved ("canned") scripts to deliver preapproved ("canned") 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"), educational content and gather survey information.
In addition, the MedApps IVR application will send out Email, SMS / Text Messages, Paging, IM and other forms of communications in order to contact patients or caregivers. This will include reminders and alerts, based on clinically defined parameters / thresholds established in HealthCOM by the professional care provider.

1. Table of Acceptance Criteria and Reported Device Performance:

Study Proving Device Meets Acceptance Criteria:

The document describes a "Non-Clinical Performance Data Testing and Review" study.

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

The document does not explicitly state a specific sample size for a "test set" in terms of number of patients or readings. Instead, it refers to:

• "testing of all executable code and functionality"
• "testing of all Design Specifications (Design Control Inputs)"
• "Product Verification and Release Plan execution on both HealthPAL and HealthAIR" with "each type of user accessory medical device (glucose, blood pressure monitor, scale, and pulse oximeter)"

This suggests that the testing was comprehensive across the device's functional aspects and integrated accessories rather than focused on a specific patient data set.

The data provenance is not specified as country of origin or retrospective/prospective, as the testing described appears to be internal device verification and validation rather than a clinical trial 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 study focuses on design control verification and validation of electrical, software, and communication functionalities, not on the interpretation of medical data by experts.

4. Adjudication Method for the Test Set:

This information is not provided. Given the nature of the non-clinical testing described, an adjudication method in the context of expert review of medical data would not be applicable.

5. If a Multi Reader Multi Case (MRMC) Comparative Effectiveness Study was done:

No, an MRMC comparative effectiveness study was not done. The document states, "The MedApps 2.0 Remote Patient Monitoring System does not rely on an assessment of clinical performance data."

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

While the device has software and firmware that perform functions autonomously (collecting, storing, and transmitting data, setting thresholds), the overall system is designed for "Remote Patient Monitoring" with "Healthcare professionals" reviewing the transmitted information in HealthCOM. There isn't a standalone algorithm-only performance evaluation in a diagnostic context described. The focus is on the reliable functionality of the device as a data collection and transmission hub.

7. The Type of Ground Truth Used:

The "ground truth" used for this non-clinical testing would be the design specifications and requirements for the device's functionality, safety, and electromagnetic compatibility. The testing aimed to confirm that the device met these predefined technical and regulatory standards. It was not based on expert consensus, pathology, or outcomes data, as it was not a clinical performance study.

8. The Sample Size for the Training Set:

This information is not applicable and not provided. The device described is a remote patient monitoring system that collects and transmits data from other medical devices. It is not an AI/ML algorithm that requires a "training set" in the context of learning patterns from data to make predictions or diagnoses.

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

This information is not applicable and not provided since there is no mention of a "training set" for an AI/ML algorithm.

Ask a specific question about this device

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.

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 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.

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.

Ask a specific question about this device

The MedApps Wellness System is intended for use in non-clinical settings to collect and transmit historical data to healthcare professionals to help support effective management of patients.

The System is not intended to provide automated treatment decisions, nor is it to be used as a substitute for a professional healthcare judgment. All patient medical diagnosis and treatment are performed under the supervision and oversight of an appropriate healthcare professional.

The MedApps Wellness System model D-PAL acts as an accessory to FDA cleared devices, which collects and transmits stored patient data via wireless connections from medical devices to a cellular phone (Hub) and forwards to a central server for review of historical data about a patient over time to benefit the Healthcare Practitioner.

The following medical devices and measuring systems are fully validated for this intended use at this time:

• . LifeScan OneTouch ® Ultra® Blood Glucose Monitoring System (K024194 / K043197)
• . Polytel PWR-08-03 Remote Module (K070559 pending clearance)

The MedApps Wellness System is not intended to provide automated treatment decisions or to be used as a substitute for professional healthcare judgment. All patient medical diagnoses and treatment are to be performed under the supervision and oversight of an appropriate healthcare professional.

The MedApps Wellness System is not intended for emergency calls, and may not be used for transmission or indication of any real-time alarms or time-critical data.

Clinical judgment and experience are required to check and interpret the measurements collected and transmitted.

This device is not for use in systems which substitute for medical care.

This device is not intended for patients requiring direct medical supervision or emergency intervention.

The MedApps Wellness System ("System") is designed to be used by patients to send their data from the LifeScan OneTouch Ultra glucometer to a central server for subsequent storage and display.

The System is comprised of a "Hub" (cell phone software) and the MedApps Engine, which runs on a central server.

The Hub is a software program that runs on a cell phone and takes in data from the OneTouch Ultra and then transmits it to the central server for storage and processing.

The MedApps Engine is a software program that runs on a common Web / Internet secure server platform. The MedApps Engine picks up the stored data sent to it by the Hub and through a set of business rules set by the healthcare providers, determines if a follow-up Interactive Voice Response (IVR) call is required to be made to the patient to collect additional Behavioral information from the patient.

Once all the data is collected, then it is stored in a repository for access by the healthcare provider,

The Hub will utilize the OneTouch Ultra integrated Short-range low power wireless transmission (Bluetooth V1.2) or a FDA approved accessory to the medical devices that to transmits the medical device data via Bluetooth to a compatible cellular telephone, such as the Nokia 6620, or other /compatible cellular phones.

The provided 510(k) summary for the MedApps™ Remote Patient Monitoring System does not contain the specific details about "acceptance criteria" for performance metrics like sensitivity, specificity, or image quality, nor does it detail a clinical study with such explicit criteria and outcomes for direct comparison.

However, based on the non-clinical performance data testing and review, and the nature of the device as a data transmission system, we can infer the acceptance criteria and the study's approach to proving substantial equivalence.

Here's an interpretation of the requested information, drawing inferences where explicit details are not present.

Acceptance Criteria and Device Performance

Since the MedApps system is primarily a data collection and transmission device, its performance criteria are centered on its ability to accurately and reliably transfer data. The document does not provide quantitative metrics for accuracy, latency, or data integrity in the form of a table. However, the section on "Non-Clinical Performance Data Testing and Review" implies that the acceptance criteria were based on meeting Software Design Specifications (SDS) and demonstrating functional equivalence to predicate devices.

Inferred Acceptance Criteria Table:

Study Details:

1. A table of acceptance criteria and the reported device performance:

   • (Provided above)

2. Sample size used for the test set and the data provenance (e.g. country of origin of the data, retrospective or prospective):

   • Sample Size: Not explicitly stated. The document refers to "exhaustive validation scripts" and a "complete record of those executed scripts as operational performance data." This suggests a comprehensive test suite rather than a traditional "sample size" in clinical study terms.
   • Data Provenance: Not specified. Given the nature of the device as a software system for data transmission, the "data" being tested would be synthetic or simulated data generated during the validation process to represent real-world glucometer readings. The testing appears to be prospective in the sense that the validation scripts were executed to test the device's functionality. There is no indication of patient-derived data or geographical origin.

3. Number of experts used to establish the ground truth for the test set and the qualifications of those experts (e.g. radiologist with 10 years of experience):

   • This question is not applicable in the traditional sense. The "ground truth" for a data transmission system is the source data itself. The validation tests would verify that the transmitted data perfectly matches the input data. There is no 언급 of external experts or clinical judgment being used to establish a "ground truth" for the test set, as is common in diagnostic device studies. The "ground truth" here is the expected behavior and output based on the device's design specifications.

4. Adjudication method (e.g. 2+1, 3+1, none) for the test set:

   • Not applicable. Adjudication methods like 2+1 (two readers agree, third is tie-breaker) are used in studies involving human interpretation (e.g., radiology reads). For a software device that transmits data, the "test set" verification would involve automated or direct comparison of transmitted data against source data, or verification of functional execution against design specifications. No human adjudication is mentioned or implied.

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:

   • No MRMC comparative effectiveness study was done or is applicable. This device is a data transmission system, not an AI-powered diagnostic tool that assists human readers. Its purpose is to present historical data to healthcare professionals, not to interpret or augment human diagnostic capabilities with AI.

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

   • Yes, implicitly. The "Alpha validation testing" and "exhaustive validation scripts" evaluated the MedApps Wellness System (software algorithm) in isolation to ensure it met its "required requirements and design specifications." This testing focuses on the system's ability to accurately collect, transmit, store, and process data according to its programmed logic, without direct human intervention in the data flow or processing steps. The output data is then presented for human review, but the performance of the transmission system itself is standalone.

7. The type of ground truth used (expert consensus, pathology, outcomes data, etc):

   • The "ground truth" for this device's performance testing was its Software Design Specifications (SDS) and the source data (simulated glucometer readings). The validation aimed to confirm that the device accurately processed and transmitted the input data according to its predefined functional requirements and met all specified design parameters.

8. The sample size for the training set:

   • Not applicable. The MedApps Wellness System is not an AI/ML device that requires a "training set" to learn or optimize its performance. It is a rule-based software system that performs predefined tasks (data collection, transmission, storage, and IVR triggering).

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

   • Not applicable, as there is no training set for this type of device.

Ask a specific question about this device