Search Results

RTHawk is an accessory to 1.5T and 3.0T whole-body magnetic devices (MRDD or MR). It is intended to operate alongside, and in parallel with, the existing MR console to acquire traditional, real-time and accelerated images. The Heart Vista Cardiac Package is a collection of RTHawk Apps designed to acquire, reconstruct and display cardiovascular MR (CMR) images.

RTHawk produces static and dynamic transverse, coronal, sagittal, and oblique cross-sectional images that display the internal structures and/or functions of the entire body. The images produced reflect the spatial distribution of nuclei exhibiting magnetic resonance. The magnetic resonance properties that determine image appearance are proton density, spin-lattice relaxation time (T1), spin-spin relaxation time (T2) and flow. When interpreted by a trained physician, these images provide information that may assist in the determination of a diagnosis.

RTHawk is intended for use as an accessory to the following MRI systems:

Manufacturer: GE Healthcare (GEHC) Field Strength: 1.5T and 3.0T Scanner Software Versions: 12, 15, 16, 23, 24, 25, 26

RTHawk is a software system designed from the ground up to provide a platform for efficient real-time MRI data acquisition, data transfer, image reconstruction, and interactive scan control and display of static and dynamic MR imaging data.

RTHawk is as an accessory to clinical 1.5T and 3.0T MR systems, operating alongside, and in parallel with, the MR scanner console with no permanent physical modifications to the MRI system required.

RTHawk is designed to run on a stand-alone linux-based computer workstation, color monitor, keyboard and mouse. It is designed to operate alongside, and in parallel with, the existing MR console with no hardware modifications required to be made to the MR system or console. This RTHawk Workstation is sourced by the Customer in conformance with HeartVista-provided specifications, and verified prior to installation.

A private ethernet network connects the RTHawk workstation to the MR scanner computer. When not in use, the RTHawk workstation may be detached from the MR scanner with no detrimental, residual impact upon MR scanner function, operation, or throughput.

The RTHawk application is written to run on top of the Linux operating system, much like application software for word processing, accounting, graphics, etc. Additional software is installed on the MR scanner computer, for receiving communications and control commands from RTHawk, and for directing MRI raw data to RTHawk for image reconstruction, display and processing.

RTHawk is an easy-to-use, yet fully functional, MR Operating System environment. The RTHawk operating system has been designed to provide a platform for the real-time acquisition, control, reconstruction, display, and storage of high-quality static and dynamic MRI images and data.

Data is continuously acquired and displayed. By user interaction or data feedback, fundamental scan parameters can be modified. Real-time and high-resolution image acquisition methods are used throughout RTHawk for scan plane localization, for tracking of patient motion, for detection of transient events, for on-the-fly, sub-second latency adjustment of image acquisition parameters (e.g., scan plane, flip angle, field-of-view, etc.) and for image visualization. Additional features are provided to automate and facilitate the set of tasks performed during a typical cardiac exam.

Conventional MR scanners queue an entire scan ahead of time and provide for little or no modification to a scan already in progress. Conversely, the RTHawk software prepares scan waveforms just as they are needed. RTHawk's efficient management of pulse sequence waveforms and instructions for modifying those pulse sequence waveforms uses the entire scanning interval for preparation of the next sequence. Scan parameters may be manipulated in real time, while providing all checks necessary to assure patient safety.

RTHawk makes extensive use of spiral image acquisition techniques to maximize scan efficiency. While conventional scans acquire data line-by-line in a Cartesian grid, RTHawk collects data more efficiently in a spiral pattern. Spiral-pattern raw data must be reformatted for correct reconstruction and display, requiring additional computing resources and image correction procedures to reduce image artifacts and distortions, ensuring high-quality reconstructed images.

RTHawk implements the conventional MRI concept of Protocols. Protocols are pre-set by HeartVista, but new protocols can be created and modified by the end user.

RTHawk Apps (Applications) are comprised of a pulse sequence, predefined fixed and adjustable parameters, reconstruction pipeline(s), and a tailored graphical user interface containing image visualization and scan control tools. RTHawk Apps may provide real-time interactive scanning, conventional) batch-mode scanning, accelerated scanning, or calibration functions, in which data acquired may be used to tune or optimize other Apps.

The HeartVista Cardiac Package is a collection of RTHawk APPs that enables the performance of a comprehensive cardiovascular MR (CMR) study in a clinically feasible amount of time. These APPs are designed and optimized to acquire, reconstruct, and display CMR images, with features including:

• On-the-fly, sub-second latency adjustment of image acquisition parameters (e.g., scan plane, flip angle, field-of-view, etc.)
• . Real-time imaging, enabling less reliance on ECG gating and artifact suppression techniques. Real-time imaging may be used for scan plane localization, instantaneous tracking of patient motion, and clinical user observation of transient events
• Scan automation tools including automatic pushbutton localization of standard cardiac . views, automatic determination of inversion time, automatic detection of artifacts, and automated myocardial segmentation
• High spatial resolution imaging, including single breath-hold, multi-slice high-resolution GRE app offering near total heart coverage
• Free-breathing, multi-slice SSFP and GRE apps that rapidly acquire high-quality images ● - potentially useful for patients who suffer from arrhythmia or who cannot hold their breath
• . Multi-slice dynamic SR GRE app with one heartbeat temporal resolution for time-course imaging.
• Continuous flow quantification

Here's a breakdown of the acceptance criteria and the study information derived from the provided text for the RTHawk, HeartVista Cardiac Package (K183274):

1. Table of Acceptance Criteria and Reported Device Performance

The provided document doesn't explicitly state quantitative acceptance criteria for device performance for the novel features introduced in K183274 compared to its predicate. Instead, it focuses on the device's adherence to regulatory standards and its functional equivalence/enhancements.

The "Performance Data - Discussion of Non-Clinical Tests" section (Page 7-8) lists the types of non-clinical tests performed, which essentially serve as verification that the device functions correctly and safely. The acceptance criteria for these would be compliance with the listed standards and satisfactory results for internal quality assurance measures.

Acceptance Criteria (Implied by Non-Clinical Tests & Compliance to Standards):

Note: The document only states "First level controlled" for SAR and dB/dt, implying compliance with safety limits but not giving specific numerical values. Similarly, for SNR and uniformity, it states "Compliant with," indicating favorable results without providing raw performance metrics.

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

The provided document does not explicitly describe a "test set" in terms of patient data for evaluating the clinical performance of the device's new features (like automated segmentation or new cardiac apps). The focus of the performance data discussion is on non-clinical engineering and software validation.

Therefore, information regarding:

• Sample size used for the test set: Not provided in terms of patient data.
• Data provenance (country of origin, retrospective/prospective): Not provided.

The "verification testing" mentioned on page 7 refers to internal software and system testing, not necessarily clinical validation with patient data.

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

Since the document does not detail a clinical study with patient data for algorithm performance, there is no information provided regarding:

• Number of experts used to establish ground truth: Not mentioned.
• Qualifications of those experts: Not mentioned.

Ground truth is only implicitly referred to in the context of a "trained physician" interpreting images to assist in diagnosis (page 2, Indications for Use).

4. Adjudication Method for the Test Set

As there is no specific clinical test set described, there is no information provided regarding an adjudication method.

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

The document does not mention or describe a Multi-Reader Multi-Case (MRMC) comparative effectiveness study. There is no information about human readers improving with AI assistance vs. without AI assistance. This submission focuses on the device's functional and safety equivalence and expanded features rather than its impact on physician performance.

6. Standalone (Algorithm Only) Performance Study

The information provided does not explicitly present a standalone performance study of the algorithm (e.g., for automated segmentation) with quantitative metrics. The new features like "Automated myocardial segmentation" are listed as enhancements but no performance data for these specific features in standalone mode is provided in this summary.

7. Type of Ground Truth Used for Performance Evaluation

Given the lack of a detailed clinical performance study in the provided text for the novel features, the type of ground truth used is not specified. The document leans heavily on compliance with engineering and safety standards, and functional equivalence to the predicate device. For potential future clinical performance assessments of features like "Automated myocardial segmentation," pathology or expert consensus would typically be used as ground truth, but this is not detailed here.

8. Sample Size for the Training Set

The document does not provide any information regarding the sample size for a training set. This K183274 submission is an update to a previously cleared device (K170090) and details software enhancements and new "Apps." While machine learning components (like the automated segmentation or artifact detection) would typically involve training data, this specific summary does not disclose those details.

9. How Ground Truth for the Training Set Was Established

Similar to point 8, since no training set information is provided, how the ground truth for any potential training set was established is also not detailed in this document.

Ask a specific question about this device