(351 days)
The CHM Device is a remote monitoring software solution intended to collect and store biometric data from physiological measurement devices intended for use in the home. The CHM Device also allows for the automated transmission of the biometric data to a remote secure server via existing mobile telecommunications and/or Internet infrastructure.
The stored biometric data is accessible by clinicians for analysis and intervention. Patients can also review the stored biometric data and receive educational content from clinicians.
The CHM Device can be used as a standalone device or in conjunction with supported patient monitoring devices, such as a glucometer, weight scale, pulse oximeter, and blood pressure monitor.
The CHM Device is not intended for use in surgical rooms, intensive care units, intermediate or stepdown units or emergency vehicles. It is not interpretive, nor is it intended for diagnosis or as a replacement for the oversight of healthcare professionals. It does not provide real-time or emergency monitoring.
The CHM Device is a software platform for the collection and display of biometric data, primarily from externally supported patient monitoring devices, both to the clinician. The CHM Device may also be used as a standalone device. The CHM Device uses existing Internet and telecommunications architecture (cellphones and computers) for the automated transmission of medical data to a remote server from where it can be viewed remotely by clinicians and patients for the purposes of storage and basic analysis. The CHM Device also provides educational and motivational functionalities allowing the clinician to send tasks, recommendations, surveys, and educational and motivational messages to patients.
The Verizon Wireless Converged Health Management Device (K122458) is a software solution for remote monitoring, not an AI/ML diagnostic tool. Therefore, many of the typical acceptance criteria and study components requested for AI/ML devices, such as performance metrics (e.g., sensitivity, specificity), ground truth establishment by experts, and MRMC studies, are not applicable.
The submission focuses on software verification and validation, demonstrating that the device functions as intended and safely transmits data.
Here's a breakdown of the relevant information from the provided text:
1. Table of Acceptance Criteria and Reported Device Performance
| Acceptance Criteria | Reported Device Performance |
|---|---|
| Software Functionality: The CHM Device performs appropriately per defined specifications. | Software verification and validation testing, including usability validation, was performed successfully, demonstrating that the CHM Device performs appropriately per defined specifications. |
| Input Requirements: The CHM Device meets all input requirements. | Software verification and validation testing... demonstrating that the CHM Device... meets all input requirements. |
| Intended Use: The CHM Device fulfills the device's intended use. | Software verification and validation testing... demonstrating that the CHM Device... fulfills the device's intended use. |
| Safety Mitigations: The CHM Device correctly incorporates all required safety mitigations. | Software verification and validation testing... demonstrating that the CHM Device... correctly incorporates all required safety mitigations. |
2. Sample size used for the test set and the data provenance
Not applicable for this type of software device. The "test set" would primarily involve internal software testing and validation rather than a clinical dataset of 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 ground truth for this device is its adherence to software specifications and functional requirements, which are typically established by software engineers and quality assurance personnel, not medical experts.
4. Adjudication method for the test set
Not applicable. Software testing for functionality does not typically involve an adjudication method by medical experts in the way an AI diagnostic tool would.
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. This device is a data collection and transmission platform, not an interpretive or diagnostic AI. Therefore, an MRMC study related to human reader improvement with AI assistance is not relevant.
6. If a standalone (i.e. algorithm only without human-in-the-loop performance) was done
Yes, the software verification and validation described is a standalone assessment of the algorithmic/software performance. It focuses on the device's ability to collect, store, and transmit data accurately and according to specifications, independent of human interpretation of that data.
7. The type of ground truth used
The ground truth used for this device's performance validation is its defined software specifications and functional requirements. The testing confirmed that the software behaved as designed and intended.
8. The sample size for the training set
Not applicable. This is not an AI/ML algorithm that requires a training set of data.
9. How the ground truth for the training set was established
Not applicable. As this device is not an AI/ML algorithm requiring training data, this question is not relevant.
§ 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).