Search Results

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