Search Results

The Remote Presence System, Model RP-VITA™ is a clinical communications tool that provides a means of transmitting, receiving, and storing real-time audio and video, and patient data. The Remote Presence System, Model RP-VITA™ may also be used in conjunction with 510(k)-cleared devices that transmit patient biometric data including vital signs information. The Remote Presence System, Model RP-VITA™ transmits and receives information over a high speed connection between patients, and health professionals. The Remote Presence System, Model RP-VITA™ can be used in communications for active patient monitoring in high acuity clinical environments where immediate clinical action may be required, e.g., pre-, peri-operative and post-surgical, cardiovascular, neurological, pre-natal, psychological and critical care assessments and examinations. Clinical judgment and experience are required to review and interpret the information transmitted.

The Remote Presence System, Model RP-VITA™ is a telecommunications platform that enables real-time videoconferencing and clinical communications, and provides a means for transmitting, receiving, and storing real-time audio and video, and patient data. The Remote Presence System, Model RP-VITA™ consists of a Control Station ("CS") (i.e., desktop or laptop computer) and the RP-VITA™ end point that is controlled by an input device (e.g., mouse or joystick) that the operator uses to control the movement of the RP-VITA™ from a remote location. The RP-VITA™ and CS are each equipped with various combinations of cameras, displays, microphones, and speakers, depending upon the specific CS used, which facilitate two-way audio-video communication. One accessory is a Class II, integrated electronic stethoscope, which is used for the same purpose for which it received 510(k) clearance. Communication between the CS and the RP-VITA™ end point is established via a wired broadband Internet connection or an 802.11 wireless broadband network connection.

Expanding on the predicate device, the Remote Presence System, Model RP-VITA™ is available with an optional autonomous navigation system ("autonavigation"), providing the ability to autonomously navigate and position the RP-VITA™ end point to a pre-determined location. Developed in partnership with iRobot, the RP-VITA™ contains similar Auto Drive technology that is already being used successfully by the defense and public safety communities (e.q., PackBot bomb disposal robots), as well as by consumers in household environments (e.g., Roomba vacuum cleaners). With a single click or tap, a bedside nurse or a remote clinician will be able to send the RP-VITA™ to the target destination. The RP-VITA™ features mapping and Obstacle Detection Obstacle Avoidance ("ODOA") technologies that support safe, fast, and highly flexible navigation in a clinical environment. As the technology name suggests, the ODOA system allows the RP-VITA™ to steer clear of obstacles in its path and maneuver around them. The RP-VITA's™ mapping technology creates and stores a digital map of a clinical environment that it can access in the future, labeling rooms, controlling device speed in certain areas, and marking areas where the RP-VITA™ should not travel.

This document describes the Intouch Health Remote Presence System, Model RP-VITA™, a telemedicine platform. The information provided heavily emphasizes the safety and effectiveness of the device through verification and validation testing, rather than a traditional comparative clinical study with acceptance criteria for performance metrics like sensitivity or specificity. This is typical for devices where the primary function is communication and remote control, and the "performance" is more about reliable operation and safety rather than diagnostic accuracy.

Here's an breakdown based on your request:

1. Acceptance Criteria and Reported Device Performance

The document describes functional and safety acceptance criteria for the new "autonavigation" feature and general device operation. The "reported device performance" is framed as successful verification and validation against these criteria, demonstrating the design outputs meet input requirements.

2. Sample Size and Data Provenance for the Test Set

The document does not explicitly state the sample size of a "test set" in terms of patient data or case numbers. The testing described is primarily engineering verification and validation testing of the device's hardware and software functionalities (e.g., autonavigation, obstacle detection, communication). This type of testing typically involves:

• Engineering test scenarios: Creating specific situations to evaluate the device's response (e.g., placing obstacles, simulating component failures).
• Controlled environments: Testing the device within a facility or a simulated clinical environment.

Therefore, there isn't data provenance in the traditional sense of "country of origin of the data, retrospective or prospective," as this wasn't a clinical study gathering patient data. The provenance for this type of testing is typically the manufacturer's own internal testing laboratories and facilities.

3. Number of Experts and Qualifications for Ground Truth

Not applicable. For this type of device, ground truth for operational and safety features is established against defined functional requirements and engineering specifications (e.g., "device should halt if component fails"). It does not involve expert consensus on clinical findings or diagnoses.

4. Adjudication Method

Not applicable. Adjudication methods like 2+1 or 3+1 are used in clinical studies where multiple human readers interpret data, and their disagreements need resolution to establish ground truth. This document describes engineering verification and validation testing against predetermined functional specifications.

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

No, a Multi-Reader Multi-Case (MRMC) comparative effectiveness study was not done. The study described is not a clinical study comparing human reader performance with or without AI assistance. The "AI" component is the autonomous navigation system, and the testing focuses on its safe and effective operation, not its impact on human diagnostic accuracy or efficiency.

6. Standalone Performance Study (Algorithm Only)

Yes, a form of "standalone" evaluation was done for the algorithm features, specifically the autonavigation system. The verification and validation testing described focused on the functionality and safety of the RP-VITA™'s autonomous navigation, obstacle detection, and collision avoidance systems operating independently (albeit within the integrated device). For example, tests confirmed the device would slow down in narrow spaces or when un-mapped obstacles were detected. This demonstrates the algorithm's direct operational performance.

7. Type of Ground Truth Used

The ground truth used for this device's testing is primarily functional and safety engineering specifications and requirements. These are established by the device's design inputs, industry standards, and risk analysis. For instance:

• "The device should halt if a critical component fails."
• "The device should slow down in narrow spaces."
• "The communication channel should be safe and effective."

This is based on engineered design expectations rather than expert consensus on clinical interpretations, pathology findings, or patient outcomes data.

8. Sample Size for the Training Set

Not applicable. The document describes a medical device clearance based on engineering verification and validation, not a machine learning model that requires a "training set" of data in the typical sense for classification or prediction tasks. The autonavigation system uses built-in mapping and ODOA technologies, which would have been developed and "trained" (or more accurately, engineered and calibrated) by iRobot (the partner) using their proprietary methods and data. This specific regulatory submission does not detail the internal training of the underlying robotics algorithms.

9. How Ground Truth for the Training Set Was Established

Not applicable, as there's no mention of a traditional machine learning training set within the provided text for this cleared device. If the autonavigation system uses machine learning, the establishment of ground truth for its internal development would have been part of iRobot's engineering process, likely involving:

• Mapping real-world environments.
• Annotating obstacles.
• Simulating various navigation scenarios.
• Testing robot responses against ideal or desired behaviors.

However, these details are not part of this 510(k) submission. The submission focuses on the verification and validation of the final integrated product against safety and performance requirements.

Ask a specific question about this device