(216 days)
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:
| Acceptance Criteria | Reported Device Performance |
|---|---|
| Not specified in the document. The submission relies on substantial equivalence to predicate devices and conformity to recognized consensus standards, rather than specific clinical performance acceptance criteria. | Not applicable. The document explicitly states, "The MedApps 2.0 Remote Patient Monitoring System does not rely on an assessment of clinical performance data." |
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.
§ 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).