Search Results

The Proteus® Digital Health Feedback Device consists of a miniaturized, wearable sensor for ambulatory recording of physiological and behavioral metrics such as heart rate, activity, body angle relative to gravity (body position), and time-stamped patient-logged events, including events signaled by the co-incidence with, or co-ingestion with, the ingestible sensor accessory. When the ingestible sensor is ingested, the Proteus Digital Health Feedback Device is intended to log, track and trend intake times. When co-ingested with medication, the tracking and trending of intake times may be used as an aid to measure medication adherence. The Proteus Digital Health Feedback Device may be used in any instance where quantifiable analysis of event-associated physiological and behavioral metrics is desirable, and enables unattended data collection for clinical and research applications.

The Proteus Digital Health Feedback Device consists of a wearable sensor, an ingestible sensor, and a software application.

The Proteus wearable sensor is a body-worn sensor that collects physiological and behavioral metrics such as heart rate, activity, body angle relative to gravity (body position), skin temperature, and time-stamped user-logged events signaled by the co-incidence with, or coingestion with, the Proteus ingestible sensor. The display application of the Proteus Digital Health Feedback Device may be used to analyze circadian rhythms and patterns.

The ingestible sensor is embedded inside an inactive tablet. (the Proteus Pill or sensorenabled pill) for ease of handling and swallowing. After the ingestible sensor reaches the stomach, it activates and communicates its presence with a unique identifier to the wearable sensor. When the ingestible sensor is co-ingested with medication, the Proteus device is intended to log, track, and trend medicine intake times as an aid to measure medication adherence.

The software application receives the data from the wearable sensor for further processing and analysis of the physiological and behavioral metrics. The processed data is then sent to the user interface (UI) for display as well as to Proteus databases for storage and sharing.

Here's an analysis of the provided text, focusing on the acceptance criteria and study information for the Proteus Digital Health Feedback Device:

Based on the provided text, a comprehensive study proving the device meets acceptance criteria, including specific quantifiable acceptance criteria and detailed study results, is not present. The document is a 510(k) summary for FDA clearance, which focuses on demonstrating substantial equivalence to a predicate device rather than presenting a detailed clinical study report with acceptance criteria.

However, we can extract information regarding non-clinical performance data and the general approach to validating different aspects of the device.

1. Table of Acceptance Criteria and Reported Device Performance

As noted above, explicit acceptance criteria with specific thresholds are not provided in this document. The text describes how different parameters were validated or quantified, rather than defining performance targets.

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

• Test Set Sample Size: Not specified. The document mentions "tested using selected guidelines" or "validated against," but does not provide details on the number of subjects or samples used in these non-clinical evaluations.
• Data Provenance: The document does not specify the country of origin. It indicates that the data are from "Non-Clinical Performance Data" and implies laboratory or controlled test environments. The data is retrospective in the sense that it was collected prior to this submission for FDA clearance.

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

• Not Applicable / Not Specified. The evaluations described are primarily technical performance tests of sensors and algorithms, not evaluations against human expert ground truth for diagnostic purposes. For example, the accelerometer was "validated against a known acceleration," which implies a controlled physical standard rather than expert consensus. Similarly, heart rate was tested against "selected guidelines set forth in the ANSI/AAMI EC 13 standard," which refers to industry standards, not human interpreters.

4. Adjudication Method for the Test Set

• Not Applicable / Not Specified. Since there is no mention of human experts establishing ground truth or making judgments, there is no adjudication method described.

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, an MRMC comparative effectiveness study was not done or described. This device focuses on objective physiological and behavioral data collection, not on aiding human interpretation of complex medical images or data that typically require MRMC studies.

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

• Yes, standalone non-clinical performance data was done for individual device components. The section "Summary of Non-Clinical Performance Data" describes evaluating the accelerometer, biopotential low-frequency amplifier (for heart rate), thermistor, and ingestible sensor activation/lifetime independently. For example, "The three-axis accelerometer provided motion and angle relative to gravity (body position) data and was validated against a known acceleration applied against each of its three axes." This indicates direct evaluation of the device's technical output.

7. The Type of Ground Truth Used (expert consensus, pathology, outcomes data, etc.)

• The ground truth used was primarily controlled physical inputs, laboratory standards, and industry guidelines.
  • For the accelerometer: "known acceleration."
  • For heart rate: "selected guidelines set forth in the ANSI/AAMI EC 13 standard."
  • For skin temperature: "compared to a reference resistor" (implying a controlled reference temperature/voltage).
  • For ingestible sensor: Testing "activation time and lifetime" implies comparison against internal specifications or direct observation.

8. The Sample Size for the Training Set

• Not specified. The document does not provide details on a separate training set for any algorithms. It describes a "proprietary algorithm" for heart rate, but does not detail its development or training data. Given the context of a 510(k) for a sensor device, emphasis would be on device performance rather than complex machine learning algorithm training.

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

• Not specified, as no training set details are provided.

Ask a specific question about this device

The Proteus Patch is a miniaturized, wearable data-logger for ambulatory recording of physiological and behavioral metrics such as heart rate, activity, body angle relative to gravity, and time-stamped, patient-logged events, including events signaled by swallowing the Ingestible Sensor accessory. The Proteus Patch enables unattended data collection for clinical and research applications. The Proteus Patch may be used in any instance where quantifiable analysis of event-associated physiological and behavioral metrics is desirable.

The Proteus Patch is a body-worn sensor that collects physiological and behavioral metrics such as heart tate, activity, body angle relative to gravity, and time-stamped user-logged events generated by swallowing the Proteus Ingestible Sensor. The Ingestible Sensor is embedded inside an inactive tablet (the Pill) for ease of handling and swallowing. Once the Ingestible Sensor reaches the stomach, it activates and communicates its presence and unique identifier to the Patch stores and wirelessly sends the physiological, behavioral, event, and ingestion data to a general computing device for display.

Here's an analysis of the acceptance criteria and study information provided in the document:

1. Table of Acceptance Criteria and Reported Device Performance

The provided summary does not explicitly state formal "acceptance criteria" with specific thresholds for performance. Instead, it describes general methods for validation and testing. Therefore, the table below interprets the "acceptance criteria" as the method of validation itself rather than a numerical threshold, and the "reported device performance" as the statement of successful validation.

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

The document does not provide specific sample sizes for test sets used for the individual performance validations. It mentions testing methods but not the number of subjects or items tested.
The data provenance is not specified (e.g., country of origin, retrospective/prospective). This is a non-clinical evaluation, so "patients" might not have been involved in all tests.

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

This document describes technical device validation against standards or known inputs (e.g., "known acceleration"). It does not involve human expert interpretation of data to establish ground truth in the way a diagnostic AI system would. Therefore, this information is not applicable or provided.

4. Adjudication Method for the Test Set

Not applicable, as this is a technical validation against established standards and known physical inputs, not a subjective interpretation requiring expert adjudication.

5. If a Multi-Reader Multi-Case (MRMC) Comparative Effectiveness Study Was Done, and Effect Size

No, an MRMC comparative effectiveness study was not done. The document states: "No additional clinical data were required to confirm substantial equivalence to predicate device." This indicates the device was cleared based on non-clinical performance and technological characteristics in comparison to a predicate, not through a study involving human readers or AI assistance.

6. If a Standalone (Algorithm Only Without Human-in-the-Loop Performance) Was Done

The performance data described (heart rate algorithm, accelerometer validation, ingestion sensor testing) are inherently "standalone" in the sense that they are assessing the device's technical capabilities without a human-in-the-loop for the primary validation. The device's overall intended use does involve data collection for clinical and research applications, implying potential future human interpretation, but the core performance described here is the device's ability to accurately log these metrics.

7. The Type of Ground Truth Used

The ground truth used for validation was primarily:

• Established industry standards: For heart rate, "guidelines set forth in the ANSI/AAMI EC 13 standard."
• Known physical inputs: For activity/body angle, "a known acceleration applied against each of its three axes."
• Device-specific measurements/specifications: For the ingestion sensor, "activation time and lifetime after activation" would be measured against the sensor's designed parameters.

8. The Sample Size for the Training Set

The document does not mention any "training set" in the context of machine learning. The device utilizes algorithms (e.g., modified Hamilton-Tompkins for R-wave frequency) that would have been developed and potentially trained previously, but the details of such training (including sample size) are not provided or relevant to this 510(k) summary, which focuses on validation rather than algorithm development.

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

As no training set is discussed, this information is not provided.

Ask a specific question about this device

The Proteus® Patch is a miniaturized, wearable data-logger for ambulatory recording of physiological and behavioral metrics such as heart rate, activity, body angle relative to gravity, and time-stamped, patient-logged events, including events signaled by swallowing the Ingestible Sensor accessory. The Proteus Patch enables unattended data collection for clinical and research applications. The Proteus Patch may be used in any instance where quantifiable analysis of event-associated physiological and behavioral metrics is desirable.

The Proteus Patch is a body-worn sensor that collects physiological and behavioral metrics such as heart rate, activity, body angle relative to gravity, and time-stamped user-logged events generated by swallowing the Proteus Ingestible Sensor. The Ingestible Sensor is embedded inside an inactive tablet (the Pill) for ease of handling and swallowing. Once the Ingestible Sensor reaches the stomach, it activates and communicates its presence and unique identifier to the Patch. The Patch stores and wirelessly sends the physiological, behavioral, event, and ingestion data to a general computing device for display.

Here's a breakdown of the acceptance criteria and the study information based on the provided text:

1. Table of Acceptance Criteria and Reported Device Performance

The provided text does not explicitly state quantitative "acceptance criteria" in the traditional sense (e.g., minimum sensitivity, specificity, or accuracy percentages). Instead, it focuses on validating the functionality of different components. Therefore, the table below reflects the validation methods and what was "proven" or "tested."

2. Sample Size for the Test Set and Data Provenance

The document does not explicitly state the sample size used for the test set for each validation. It also does not provide details on data provenance (e.g., country of origin, retrospective or prospective nature of the data). The validation efforts appear to be laboratory-based rather than real-world patient data in some cases.

• Accelerometer: "validated against a known acceleration applied against each of its three axes." This suggests controlled laboratory testing.
• Heart Rate: "tested using guidelines set forth in the ANSI/AAMI EC 13 standard." This standard typically involves using databases or simulators for testing, but details are not provided.
• Ingestion Sensor: "tested for activation time and lifetime after activation." This would likely be laboratory testing of the ingestible sensor units.

3. Number of Experts Used to Establish Ground Truth and Qualifications

The document does not mention the use of human experts to establish ground truth for the device's performance. The validation appears to be against established physical standards, known inputs, or existing guidelines (like ANSI/AAMI EC 13).

4. Adjudication Method for the Test Set

No adjudication method is mentioned. Given the nature of the "testing" described (validation against known physical inputs and standards), an adjudication process among human experts would not be applicable.

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

No MRMC comparative effectiveness study was done or mentioned. The device, the Proteus Patch Including Ingestible Sensor, is a data-logger and sensor, not an interpretive AI system that assists human readers. Therefore, the concept of human readers improving with or without AI assistance is not applicable to this device.

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

The described performance evaluation is a standalone (algorithm only) evaluation. The validation tests were conducted on the device's sensors and algorithms directly (e.g., accelerometer output, R-wave frequency detection, sensor activation). There is no human-in-the-loop component mentioned in these performance assessments.

7. Type of Ground Truth Used

The ground truth used in the validation studies appears to be:

• Known physical inputs/standards: For the accelerometer, "known acceleration applied against each of its three axes."
• Standardized guidelines/algorithms: For heart rate, "guidelines set forth in the ANSI/AAMI EC 13 standard" and a "modified Hamilton-Tompkins algorithm."
• Intrinsic device characteristics/specifications: For the ingestion sensor, "activation time and lifetime after activation" refers to its expected functional behavior.

There is no mention of expert consensus, pathology, or outcomes data being used as ground truth for these specific performance validations.

8. Sample Size for the Training Set

The document does not specify a "training set" or its sample size. This device is described as a "data-logger" and sensor system. While it contains algorithms (e.g., for R-wave detection), there is no indication that these algorithms were developed using a machine learning approach that would typically involve a distinct training set. The focus is on validation against established engineering and physiological standards.

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

Since no training set and corresponding machine learning approach are explicitly described, the method for establishing ground truth for a training set is not provided.

Ask a specific question about this device

The Proteus® Patch, also called the Patch, is a miniaturized, wearable data-logger for ambulatory recording of physiological and behavioral metrics such as heart rate, activity, body angle relative to gravity, and time-stamped, patient-logged events, including events signaled by swallowing the Ingestible Sensor accessory. The Proteus Patch enables unattended data collection for clinical and research applications. The Proteus Patch may be used in any instance where quantifiable analysis of event-associated physiological and behavioral heart rate, activity, and body position is desirable.

Like the Proteus Personal Monitor (K113070), the Proteus Patch is a body-worn sensor that collects physiological and behavioral metrics including heart rate, activity, body angle, and time-stamped user-logged events generated by swallowing the Proteus Ingestible Sensor. The Ingestible Sensor is embedded inside an inactive tablet (the Pill) for ease of handling and swallowing. Once the Ingestible Sensor reaches the stomach, it activates and communicates its presence and unique identifier to the Patch. The Patch stores and wirelessly sends the physiologic, event, accelerometry, and Ingestible Sensor data to a general computing device for display.

Here's a breakdown of the acceptance criteria and study information for the Proteus Patch including Ingestible Sensor, based on the provided document:

1. Table of Acceptance Criteria and Reported Device Performance

The document provides functional descriptions and validation methods for different parameters, but does not present explicit, quantitative acceptance criteria in a table format. However, based on the Summary of Non-Clinical Performance Data, we can infer the tested characteristics and the type of validation performed.

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

The summary states:

• "No additional clinical data were required to confirm substantial equivalence to predicate devices."
• The "Summary of Non-Clinical Performance Data" describes laboratory testing.

Therefore, there appears to be no distinct clinical test set used for this 510(k) submission as no additional clinical data was required. The "testing" mentioned refers to non-clinical, laboratory-based validation.

• Sample Size for Test Set: Not applicable for clinical data. For non-clinical validation, specific sample sizes for the accelerometer and Ingestible Sensor tests are not provided in this summary.
• Data Provenance: Not applicable for clinical data. The non-clinical testing would have been performed by the manufacturer, Proteus Digital Health, Inc.

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

Not applicable, as no additional clinical test set was used, and ground truth in this context would likely refer to clinical expert consensus. For the non-clinical tests:

• For the accelerometer, ground truth was "known acceleration."
• For the heart rate, the ANSI/AAMI EC 13 standard provides the reference for accurate ECG measurement.
• For the ingestible sensor, activation time and lifetime would be objectively measured, not requiring expert consensus for ground truth.

4. Adjudication Method for the Test Set

Not applicable, as no clinical test set requiring human adjudication was utilized for this submission based on the provided information.

5. If a Multi-Reader Multi-Case (MRMC) Comparative Effectiveness Study Was Done

No, a Multi-Reader Multi-Case (MRMC) comparative effectiveness study was not performed or submitted as part of this 510(k). The document explicitly states "No additional clinical data were required." Therefore, there is no effect size reported for human readers improving with or without AI assistance.

6. If a Standalone (i.e. algorithm only without human-in-the-loop performance) Study Was Done

This device does not involve an "algorithm only" or "AI" in the sense of image interpretation or diagnostic assistance. It's a data logger and sensor. The "non-clinical performance data" describes the validation of the device's sensing capabilities (accelerometer, heart rate measurement algorithm, ingestible sensor activation). These are standalone functional tests of the device components.

• Heart Rate Algorithm Standalone Performance: The biopotential low-frequency amplifier and its accompanying algorithm (modified Hamilton-Tompkins) were "tested using guidelines set forth in the ANSI/AAMI EC 13 standard." This indicates a standalone validation of the algorithm's performance against a known standard.

7. The Type of Ground Truth Used

• Accelerometer: "Known acceleration applied against each of its three axes." (Physics-based objective measurement)
• Heart Rate: Adherence to "ANSI/AAMI EC 13 standard" which provides criteria for accurate ECG measurement, implying a reference standard for ground truth.
• Ingestible Event Marker: Objective measurement of "activation time and lifetime after activation."

8. The Sample Size for the Training Set

The document does not mention any "training set." This type of device (data logger, physiological sensor, ingestible event marker) typically undergoes engineering verification and validation, not machine learning model training.

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

Not applicable, as there is no mention of a training set for machine learning.

Ask a specific question about this device