(139 days)
Vista Solution 2.1 is a software user intended for use by healthcare professionals to display physiological data collected by the VitalConnect Platform wireless remote monitoring system in home and healthcare settings. Vista Solution is a secondary, adjunct patient monitor and is not intended to replace existing standard-of-care patient monitoring practices.
The VitalConnect Platform, Vista Solution is a wireless remote monitoring system consisting of the VitalPatch biosensor (K190916) and the VistaCenter and VistaPoint software (formally branded as VitalWatch in K170973). This submission is a catch-up 510(k) for changes made to the software since K170973 was cleared. The principles of operation, mechanism of action, and proposed environment of use are unchanged from the predicate device (K170973).
This document pertains to the Vista Solution 2.1, a software user interface for displaying physiological data collected by the VitalConnect Platform wireless remote monitoring system. The submission is a "catch-up 510(k)" for changes made to the software since its predicate (K170973) was cleared.
Here's the breakdown of the requested information:
1. Table of acceptance criteria and the reported device performance
The document does not explicitly state "acceptance criteria" in a quantitative performance metric table directly comparable to the predicate for all features. However, it implicitly demonstrates substantial equivalence by highlighting the similarities and changes made. The core "acceptance criteria" appear to be focused on ensuring that the modified software performs its intended function (displaying physiological data) without raising new questions of safety and effectiveness, and that new functionalities meet established standards or are extensions of existing ones.
| Feature | Acceptance Criteria (Implied) | Reported Device Performance |
|---|---|---|
| Primary Functionality | Display physiological data from the VitalConnect Platform. | Displays heart rate, ECG, heart rate variability, R-R interval, respiratory rate, body temperature, activity, and posture. |
| New Physiological Data Monitored | Accurately display data from supported third-party devices (SpO2, Blood Pressure, Weight) and body temperature, and calculate NEWS score correctly. | Supports display of data from pulse oximeter, blood pressure, and weight via 3rd party devices. Supports body temperature, 30-degree supine posture calibration, and NEWS score calculation (with observer input for consciousness and supplemental oxygen). |
| Data Management | Enable data management by patient (multiple patches/devices for one patient). | Supports data management by patient instead of patch. |
| VitalPatch 3.0 Features | Support new features of VitalPatch 3.0. | Supports VitalPatch 3.0 features including body temperature, 30-degree calibration, and LED blinking. |
| User Interface Equivalence | User interface of VistaTablet 2.0 should be substantially equivalent to VistaTablet 1.0, with additions. | VistaTablet user interface is substantially equivalent to previously commercialized VistaTablet 1.0 with specified major additions and extended functionalities (manual data entry, notifications on 3rd party devices, body temperature, universal notifications). |
| Software Life Cycle Compliance | Software must be developed and validated according to recognized standards. | Software validation was performed in accordance with IEC 62304. |
| Usability | Usability should meet recognized standards. | Usability testing was performed in accordance with IEC 62366. |
| Electrical Safety & EMC | Not applicable as a standalone software, but implicitly, it should not introduce new electrical safety or EMC risks through its interface with wirelessly transmitted physiological data. | Stated as "Not Applicable (Standalone Software)". |
| Safety and Effectiveness | The modifications should not raise different questions of safety and effectiveness compared to the predicate device. | The conclusion states: "The Proposed Vista Solution Software User Interface is substantially equivalent to the predicate device. The modifications described in this 510(k) do not raise different questions of safety and effectiveness." This is the ultimate "performance" metric for a 510(k) submission. |
2. Sample size used for the test set and the data provenance (e.g. country of origin of the data, retrospective or prospective)
The document focuses on software changes and equivalency. There is no specific mention of a "test set" in terms of patient data for evaluating clinical performance. The evaluation was done through software verification and validation, and benchtop usability testing. Therefore, details regarding sample size, country of origin, or retrospective/prospective nature of a clinical test set are not provided.
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)
Not applicable. The submission did not involve a clinical test set requiring expert ground truth establishment in the traditional sense. The evaluation was primarily against software requirements, functional specifications, and usability standards.
4. Adjudication method (e.g. 2+1, 3+1, none) for the test set
Not applicable. There was no clinical test set requiring adjudication.
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. This was not an AI-assisted diagnostic or interpretive device, nor was it a study comparing human performance with and without AI. It is a software user interface for displaying physiological data.
6. If a standalone (i.e. algorithm only without human-in-the-loop performance) was done
The entire submission is for a "standalone software user interface" that displays data. The performance evaluation primarily involved software verification and validation testing (IEC 62304) and benchtop usability testing (IEC 62366). These are assessments of the algorithm/software itself in meeting its specifications and being usable, rather than a clinical performance study. The device is intended for "human-in-the-loop" (healthcare professionals) to interpret the displayed data.
7. The type of ground truth used (expert consensus, pathology, outcomes data, etc)
For the software validation, the "ground truth" would be the software requirements specifications and functional specifications. For usability testing, the "ground truth" would be adherence to usability standards and user task success criteria. No pathology, outcomes data, or expert consensus on clinical data was used to establish ground truth for this software submission.
8. The sample size for the training set
Not applicable. This is not a machine learning or artificial intelligence device that requires a "training set" in the context of model development.
9. How the ground truth for the training set was established
Not applicable, as there was no training set.
§ 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).