Search Results

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

The Glucose Pilot Blood Glucose monitoring System is intended for the quantitative measurement of glucose in fresh capillary whole blood from a finger stick, for the lay-user. It is also intended for the professional use, which include fresh capillary whole blood. It is intended for use outside the body (in vitro diagnostic use) by people with diabetes mellitus at home as an aid in monitoring the effectiveness of a diabetes control program. It is not intended for the diagnosis of or screening for diabetes mellitus, and is not intended for use on neonates.

The Glucose Pilot Glucose monitoring System consists of a hand-held blood glucose meter, test strips, lancing device, lancets, and two levels of control solution. The test strip has a lot - specific calibration information and the meter reads automatically. The meter is turned on by inserting the strip, the user supplies the capillary blood or control solution, the meter makes an audible tone and starts the assay, which completes in five seconds. The meter's software converts the results read off the test strip into a plasma glucose concentration and displays the value on the meter's display. The provided instructions and illustrations explaining that the blood drop will be pulled into the strip sample entry by capillary action. Results are stored in the meter's memory for tracking purposes.

Here's an analysis of the provided text to extract the requested information about acceptance criteria and the device study:

Important Note: The provided document is a 510(k) summary for a blood glucose monitoring system. These typically focus on demonstrating substantial equivalence to a predicate device rather than presenting a full clinical study with detailed performance metrics against defined acceptance criteria in the same way a novel high-risk device might. Consequently, some of the requested information (especially regarding expert adjudication, MRMC studies, explicit acceptance criteria with pre-defined ground truth for this specific device's performance claims) is not explicitly stated in this type of document. I will extract what is available and highlight where information is absent due to the nature of the submission.

Acceptance Criteria and Device Performance

The document doesn't explicitly list a table of acceptance criteria with corresponding device performance metrics in the format you requested for a complex diagnostic device. Instead, it focuses on demonstrating substantial equivalence to an existing predicate device (Ultra One Touch Glucose Monitoring System). The "acceptance criteria" in this context are implicitly that the new device performs similarly or equivalently to the predicate device across various characteristics and specifications.

However, based on the Comparison to Predicate Device(s) table, we can infer performance specifications that the new device aims to meet or match.

1. Table of Acceptance Criteria and the Reported Device Performance

Since explicit "acceptance criteria" are not given, I will present the key performance specifications listed for the new device as its "reported device performance" and the corresponding values from the predicate device as an indication of the expected or "accepted" range for similar devices.

Study Details

The document mentions "The information provided in this pre-market notification demonstrates that Glucose Plot [Pilot] Monitoring System is substantially equivalent to Ultra One Touch Blood Glucose Monitoring System. Substantial Equivalence was established through comparison of intended use and physical properties to the commercialized predicate devices. The information supplied in this pro-marketing notification provides reasonable assurance that the Glucose Pilot Blood Glucose Monitoring System is safe and effective for its stated intended use."

This indicates that the "study" demonstrating equivalence primarily involved analytical and performance testing to show the new device meets the same specifications and analytical performance characteristics as the predicate device. Details of a formal "clinical study" in the sense of a large-scale patient trial with statistical comparison of diagnostic accuracy against a gold standard are not provided in this summary.

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

• Sample size used for the test set: Not explicitly stated in this 510(k) summary. For glucose meters, accuracy studies typically involve a certain number of subjects across different glucose ranges.
• Data provenance: Not explicitly stated. For a 510(k) submission from a Chinese manufacturer, the testing could be done in China (country of origin for manufacturing) or potentially through contract labs elsewhere. The submission itself is dated from China with a US contact. It's safe to assume it's retrospective analytical performance 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 in the 510(k) summary. For blood glucose meters, the "ground truth" for comparative studies is typically established by laboratory reference methods (e.g., YSI analyzer) rather than expert consensus on diagnostic images.

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

• This information is not applicable/provided as the ground truth for blood glucose measurements is generally established by a laboratory reference instrument, not by human expert adjudication in the context of image interpretation.

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 Blood Glucose Monitoring System, which is an in vitro diagnostic device for quantitative measurement, not an AI-powered diagnostic imaging system requiring human reader performance analysis.

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

• Yes, implicitly. The "standalone" performance for a blood glucose meter refers to its analytical accuracy and precision in measuring glucose concentrations, independent of human interpretation of a complex output. The specifications (measurement range, test time, sample volume, etc.) are characteristics of the device itself.

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

• For blood glucose monitoring systems, the ground truth is typically established using a laboratory reference method (e.g., a YSI STAT PLUS Glucose & Lactate Analyzer, hexokinase method, or similar highly accurate laboratory method) on plasma or whole blood samples. This document does not explicitly state the specific reference method used, but it would be a standard part of analytical performance testing.

8. The sample size for the training set

• This information is not applicable/provided in the context of this traditional electrochemical biosensor device. Blood glucose meters are not typically "trained" using machine learning algorithms in the same way an AI-driven image analysis system would be. Their performance is based on the chemical and electrochemical properties of the test strips and the meter's calibration algorithms.

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

• This information is not applicable/provided for the reasons stated in point 8.

Ask a specific question about this device

The MedStar System is indicated for Out-of-Hospital Use with any patient requiring Out-of-Hospital monitoring. The associated Collection Server is intended for use in a Disease Management Center, Hospital or Hospital-Type facility, Medical Clinic or Physician's Office.

The MedStar Monitoring System II comprises the MedStar Unit and the associated Collection Server. The MedStar Unit is a portable, battery-operated unit for controlling the transmission of data from a range of compatible patient monitors or measurement devices to a remote monitoring center. Data is transmitted via telephone lines to the associated data collection server at the remote site. The MedStar Unit is contained in a small plastic enclosure with an LCD screen mounted into the top of the case. The case is made of a strong impact resistant plastic material. A User push button control is located adjacent to the display. Four serial communication ports are located at the side of the unit for connection to the serial data ports of specific patient monitors. Two standard phone jacks are also located at the side of the unit for connection to standard phone outlets. Two recessed programming buttons are included on the opposite side of the enclosure to the phone jacks. The Collection Server comprises a Personal Computer-type Processor Unit incorporating an additional electronics board to control phone line transmission to and from the MedStar Unit.

The provided text lacks the detailed study information required to complete the table and answer all questions comprehensively. The document is a 510(k) summary, which focuses on demonstrating substantial equivalence to predicate devices rather than presenting a detailed performance study with acceptance criteria and specific statistical results.

Here's an attempt to extract the available information and highlight what is missing:

1. Table of Acceptance Criteria and Reported Device Performance:

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

• Test Set Sample Size: Not specified.
• Data Provenance: Not specified, but the "bench testing" mentioned suggests internal testing, not necessarily human patient data.

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

• Not applicable. The device's function is data transfer, not diagnostic interpretation requiring expert ground truth.

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

• Not applicable. The device's function is data transfer, not diagnostic interpretation.

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:

• Not applicable. The MedStar System II is a data transfer device, not an AI-powered diagnostic tool used by human readers.

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

• Yes, implicitly. The "bench testing" mentioned would be a standalone evaluation of the device's technical performance (e.g., successful data transmission, accuracy of data transfer) without human intervention in its core function. However, specific results are not provided.

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

• For a data transfer device, the 'ground truth' would likely involve verifying the integrity and accuracy of the transmitted data against the original source data (e.g., verifying that a blood glucose reading of 'X' from the monitor is correctly received as 'X' by the server). The document does not specify the method used for this verification.

8. The sample size for the training set:

• Not applicable. This device is not described as using machine learning or AI that would require a training set.

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

• Not applicable, as there's no mention of a training set.

Ask a specific question about this device

The Well@Home System is indicated for use for patients who need home-based health care from professional clinicians. The system provides benefits for patients who need periodic remote monitoring of their vital signs (such as noninvasive blood pressure, oxygen saturation, pulse rate, temperature, respiration rate, weight, blood glucose level, heart rate, or ECG) or self-reported symptoms, who need reminders to take prescribed medications, or who need training about how to manage their illness.

The Well@Home System consists of the home-based "Well@Home Monitor" and the office-based "Well@Home Clinician Application". Using the Well@Home System, clinicians can monitor theised at home or in another remote health care facility. The use model is "daily checkups", rather them continuous monitoring.

The Well@Home Monitor collects vital signs and symptom information on a periodic basis via a patientfriendly user interface. The user interface guides the patient through a schedule of activities using voice promots, instructional diagrams and large, easy-to-read buttons. The scheduled of doutinities can'nclude reminders to take medications or to take vital signs measurements. The schedule for these activities can be customized by the clinician according to the patient's medical condition. The user interface also provides opportunities for the patient to report symbons at any time, and to review training ontent related to managing the patient's illness.

The Well@Home monitor measures noninvasive blood pressure, oxygen saturation, pulse rate, temperation | President rate, heart rate, and ECG. The Well@Home Monitor is designed to interface to Other Medical Devices (OMD's) for the purpose of gathering physiological data from those devices. The interface is through the monitor's three OMD serial ports. These serial ports are electrically isoated from each other and from the monitor's own physiological front-end. The list of supported OMD's is as follows:

• . Fairbanks Digital Scale (private labeled and device listed as a Zoe Medical accessory)
• Lifescan One Touch Ultra Blood Glucose Meter (or compatible BGM from Lifescan) .

The OMD interface mechanism is designed to be expandable. Future OMD's may include a Spirometer or a PT/INR measurement device.

The Well@Home Monitor transmits the gathered information to a clinician over the patient's existing telephone line. This information is received and stored by the Well(@Home Clinican Application.

The Well@Home Clinician Application is essentially a patient data management and record keeping program that includes an interface to the Well@Home Monitor. The Well@Home Clinician Application stores information that is gathered from multiple Well@Home Monitors and allows a clinician to review a given patient's information. It also allows the clinician to make adjustments to a patient's schedule of activities as needed. These adjustments are sent back to the patient's Well@Home Monitor over the same telephone link.

The Well@Home Clinician Application software was developed by Patient Care Technologies (PtCT) of Atlanta, Georgia, and is designed to run on standard Windows-based PC's. These PC's are typically installed at the office of a home care agency, and are referred to in this 510(k) as "Agency Servers". The Agency Servers may run other information management software developed by PtCT that is not part of the Well@Home System. The Well@Home System is product-branded to tie into PtCT's information management software product line.

Because of the remote-monitoring and spot check nature of the Well@Home System, there are no realtime "alarms" as in a hospital-style monitor. Rather, the clinician defines "alerts" that are to be generated (e.g., when a vital sign parameter exceeds set limits or when a particular symptom is reported). These alerts are part of the information package that is sent from the Well@Home Monitor to the Well@Home Clinician Application. The alerts are then visually highlighted when the clinician reviews the patient's information.

The provided text describes the Zoe Medical Well@Home System, which is a noninvasive blood pressure measurement system for remote patient monitoring. However, it does not include detailed acceptance criteria or a specific study proving the device meets those criteria in the way a modern medical device submission typically would.

Instead, the document focuses on demonstrating substantial equivalence to existing predicate devices through:

1. Technological Characteristics Comparison: Showing that the Well@Home System's design, functions, and principles of operation are similar to previously cleared devices.
2. Performance Testing: Stating that internal engineering tests were conducted to verify performance against functional requirements and to show substantial equivalence.

Given this, I will extract the information available and note where specific details (like numerical acceptance criteria, sample sizes for test sets, expert qualifications, etc.) are absent.

Acceptance Criteria and Device Performance (as inferred from the document)

Detailed Study Information (Based on Available Text):

1. 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 specified. The document states "internal engineering tests" and "bench tests using simulators" were conducted, but no numerical sample sizes for these tests are provided for either human subjects or simulated data points.
   • Data Provenance: Not specified. The tests were "internal engineering tests," implying they were conducted by the manufacturer, Zoe Medical, but details on location or whether they involved human subjects are absent.
   • Retrospective or Prospective: Not specified. The nature of "internal engineering tests" and "bench tests using simulators" suggests they were likely prospective tests conducted on the device hardware and software.

2. 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):

   • Not applicable/Not specified. The "ground truth" for the vital signs measurements appears to be established by the predicate devices themselves (Nightingale PPM and One Touch Ultra) and, for overall system functionality, by functional requirements. There is no mention of independent experts establishing ground truth for a test set in the context of clinical accuracy or interpretation that would require such expertise. "Bench tests using simulators" imply comparison against known simulator outputs.

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

   • Not applicable/Not specified. The document does not describe a clinical study design that would involve expert adjudication of results. The testing described is primarily technical and functional equivalence vs. predicate devices or simulators.

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

   • Not applicable. This device is not an AI-assisted diagnostic tool for human readers. It is a remote monitoring system that collects and transmits vital signs and symptom data. Therefore, an MRMC study or AI-assistance effect size is not relevant to this submission.

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

   • Yes, implicitly. The "internal engineering tests" and "bench tests using simulators" for vital signs measurement evaluate the device's capability to measure data and display it correctly. For the blood glucose meter, the BGM's performance is explicitly stated as "no different when it is connected to the Well@Home Monitor as when it functions as a standalone device," indicating a standalone performance assessment of the BGM component. The Well@Home System functions as an "information transfer technology" for the BGM.

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

   • For vital signs measurement (Nightingale PPM comparison): The ground truth was presumably the known accurate outputs from physiological simulators or the validated measurements from the predicate Nightingale PPM itself.
   • For blood glucose measurement (One Touch Ultra comparison): The ground truth was the measurements provided by the standalone, predicate Lifescan One Touch Ultra Blood Glucose Meter.
   • For overall system functionality (HANC Network comparison): The ground truth was likely defined by functional requirements derived from the predicate HANC Network's capabilities.

7. The sample size for the training set:

   • Not applicable/Not specified. This document is for a medical device submission focused on substantial equivalence through hardware and software design, and functional testing. It does not describe a machine learning or AI model that would require a "training set" in the conventional sense. The software algorithms for vital signs measurement are stated to be "the same software algorithms" as the predicate Nightingale PPM, implying they were developed and validated previously, not newly trained for this specific application.

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

   • Not applicable. As there is no described training set for an AI/ML model, this question is not relevant to the provided information.

Ask a specific question about this device