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

The Remote Presence System 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 may also be used in conjunction with 510(k)-cleared devices that transmit patient biometric data including vital signs information. The Remote Presence System transmits and receives information over a high speed connection between patients, health professionals and critical transport teams. The Remote Presence System can be used in communications for active patient monitoring in . high acuity clinical environments where immediate clinical action may be required, e.g., pre-, perioperative 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 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 consists of a Control Station ("CS"), (i.e., desktop or laptop computer) and an end point, which may be controlled by an input device (i.e., mouse or joystick) that the operator uses to control the movement of the end point in the remote location (e.g., RP-70), or manually located by the user (e.g., RP-Lite®, KSEA VisitOR1 Cart, RP-Vantage®, or RP-Xpress™), or used in a restricted clinical environment, such as an operating room, where it is boom mounted (e.g., BoomBot (aka RP-B and KSEA VisitOR1)). The end point and CS are each equipped with various combinations of cameras, displays, microphones and speakers, depending upon the specific device, which facilitate two-wav audio-video communication. Optional accessories include Class II devices, including an integrated electronic stethoscope, which are used for the same purpose for which they received 510(k) clearance. Communication between the CS and the end-point is established wia broadband Internet and an 802.11 wireless network or a broadband cellular connection.

The provided text does not describe the acceptance criteria or the study that proves the device meets the acceptance criteria. Instead, it contains a 510(k) summary for a general-purpose telemedicine system (Remote Presence System- RP-7i® etc.).

Here's what can be extracted from the document, and what cannot:

Information that can be extracted from the provided text:

• Device Description and Intended Use: The Remote Presence System is a telecommunications platform for real-time videoconferencing and clinical communications, transmitting, receiving, and storing real-time audio and video, and patient data. It can also be used in conjunction with 510(k)-cleared devices that transmit patient biometric data. It is intended for use in high acuity clinical environments for active patient monitoring, assessments, and examinations.
• Predicate Device: The legally marketed predicate device is the InTouch Remote Presence Robotic System, Model RP-7 (K073710).
• Comparison to Predicate Device: The new device expands on the predicate by introducing new cart-based and hand-held models, providing improved system flexibility and adapting to additional clinical environments (e.g., operating rooms, emergency departments, intensive care units, patient transport). It also broadens the connectivity options (wired or wireless broadband, USB, Bluetooth®), communication protocols (Session Initiation Protocol), and types of devices that can be interfaced.
• Validation Testing: The document states, "The effectiveness of these improvements was demonstrated by the validation testing performed on the system." and "The performance data discussed in this 510(k) application demonstrate that the Remote Presence System is as safe and effective, and performs as well as or better than the predicate device."

Information that cannot be extracted from the provided text (and why):

The document is a 510(k) summary for a telemedicine system. It describes the device's function, its predicate, and differences. It does not present clinical study data or acceptance criteria related to a specific AI/ML medical device's performance for diagnosis or prognostication. Therefore, the specific details requested regarding acceptance criteria, study design, sample sizes for test/training sets, expert qualifications, ground truth establishment, MRMC studies, or standalone performance are not present in this document.

The "validation testing" mentioned is general and typically refers to engineering verification and validation testing for functionality, safety, and effectiveness in a broader sense for a communication system, not clinical performance metrics for an AI-powered diagnostic tool.

To answer your request, if this were an AI/ML device submission, here's what would typically be expected, and why the provided text doesn't contain it:

1. A table of acceptance criteria and the reported device performance: This would list specific metrics (e.g., sensitivity, specificity, AUC) and the agreed-upon thresholds (acceptance criteria) along with the actual performance achieved by the device in testing. Not present.
2. Sample sized used for the test set and the data provenance: Details on the number of cases/samples in the test set, and whether the data was retrospective/prospective, and its geographical origin. Not present.
3. Number of experts used to establish the ground truth for the test set and the qualifications of those experts: Information about the raters/readers who established the truth label for the test data. Not present.
4. Adjudication method for the test set: How disagreements among experts were resolved (e.g., 2 majority vote, 3+1 with a tie-breaker). Not present.
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: Details of studies comparing human performance with and without AI, including an effect size. Not present.
6. If a standalone (i.e. algorithm only without human-in-the-loop performance) was done: Metrics for the algorithm's performance without any human intervention. Not present.
7. The type of ground truth used: Whether the truth was derived from expert consensus, pathology, long-term outcomes, etc. Not present.
8. The sample size for the training set: The number of samples used to train the AI model. Not present.
9. How the ground truth for the training set was established: The methodology for creating the reference labels for the training data. Not present.

In summary, the provided document describes a communication device, not an AI/ML diagnostic or predictive device, and therefore does not contain the specific performance study details you are asking for.

Ask a specific question about this device