FDA 510(k) Search - By Innolitics (SaMD and AI Experts)

The Monitoring System is for the monitoring of vital parameters including ECG, SpO2, invasive blood pressure, temperature, NIBP and CO2, and for the evaluation of resting ECG, arrhythmias, ST-segments and cardiac output. Some systems are built and designed to measure End Tidal CO2.

The system comprises the Patient Data Module and the HeartSuite Hemodynamics Hemo Monitor PC. The two units are connected via a serial interface.

All vital parameters and evaluations are registered and calculated in the Patient Data Module. This data is then transmitted to the HeartSuite Hemodynamics Hemo Monitor PC via the serial interface. All data can be shown and monitored on the HeartSuite Hemodynamics Hemo Monitor PC.

The Patient Data Module uses an internal battery charged from an external power input (RS 232/12V). The power supply, like the data transmission, is completely isolated from the visualization unit. The HeartSuite Hemodynamics Hemo Monitor PC is powered via the normal mains connection 230V/110V.

The system is intended for use in hospital cardiac catheterization laboratories.

The Monitoring System (comprising the Patient Data Module and the HeartSuite Hemodynamics Hemo Monitor PC) is a medical product of the Class IIa (RL 93/42/EWG, Appendix IX).

Device Description

HeartSuite Hemodynamics monitors, measures, and records physiologic data from a human patient undergoing a cardiac catheterization procedure.

The system comprises the Patient Data Module and the HeartSuite Hemodynamics Hemo Monitor PC. The two units are connected via a serial interface.

The system is intended for use in hospital cardiac catheterization laboratories.

The Monitoring System (comprising the Patient Data Module and the HeartSuite Hemodynamics Hemo Monitor PC) is a medical product of the Class IIa (RL 93/42/EWG, Appendix IX).

AI/ML Overview

The HeartSuite Hemodynamics device is a system that monitors, measures, and records physiological data from patients during cardiac catheterization procedures. The provided documentation does not explicitly list acceptance criteria in a quantitative format, but rather describes the types of tests conducted to ensure the software performs safely and efficiently.

Here's an attempt to structure the information based on the provided text, recognizing that specific numerical acceptance criteria are not detailed.

1. Table of Acceptance Criteria and Reported Device Performance

Acceptance Criteria (Implied)	Reported Device Performance
Accurate R-Wave detection for rate meter and timing measurements related to pressure analysis.	Software responded appropriately to validation using various ECG aberrations, rates, amplitudes, and deviations for R-Wave detection and timing measurements.
Accurate pressure and valve analyses.	Software responded appropriately to validation using multiple simulated pressures under various conditions for pressure and valve analyses.
Accurate hemodynamic calculations based on oxygen saturation.	Software responded appropriately to validation using multiple oxygen saturations for hemodynamic calculations.
Accurate End Tidal CO2 measurements.	End Tidal CO2 was validated through Schiller and verified through tests run using SimMan, with appropriate responses.
Robust data entry restrictions.	Software responded appropriately to validation using multiple erroneous and/or incongruous entries in data entry locations.
Data integrity during export.	Software responded appropriately to validation by creating and exporting multiple cases.
Appropriate response of all command buttons.	All command buttons were tested, and the software responded appropriately.
Correct report generation.	Multiple reports were generated, and the software responded appropriately, validating the report generation functions.
Patient isolation and leakage current within specifications.	These tests are to be performed on each unit after assembly and prior to shipment. (Implied successful completion for market release).
Device functions safely and efficiently.	In addition to functional testing, a risk analysis, requirements review, and design review were performed. The software responded appropriately in all described tests, ensuring safe and efficient performance. No new safety or effectiveness issues were raised compared to the predicate device.

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

The documentation does not provide specific numerical sample sizes for the test sets (e.g., number of ECG waveforms, pressure simulations, or cases). The descriptions use terms like "various types of ECG aberrations," "multiple pressures," "multiple oxygen saturations," and "multiple erroneous and/or incongruous entries," and "multiple cases."

The data provenance is from simulated physiologic data, not actual patient data. The tests were conducted using "physiologic simulators," "Schiller," and "SimMan." This indicates that the data was not obtained retrospectively or prospectively from human patients, nor does it specify a country of origin.

3. Number of Experts Used to Establish the Ground Truth for the Test Set and Qualifications of Those Experts

The document does not mention the use of human experts to establish ground truth for the test set. The validation seems to rely on the known parameters of the "physiologic simulators," "Schiller," and "SimMan," which inherently provide the "ground truth" for the simulated scenarios.

4. Adjudication Method for the Test Set

Not applicable, as no human experts were used for establishing ground truth for the test set. The device's output was compared against the known parameters of the simulators.

5. If a Multi-Reader Multi-Case (MRMC) Comparative Effectiveness Study Was Done

No, a multi-reader multi-case (MRMC) comparative effectiveness study was not done. The documentation explicitly states, "No clinical performance data has been used to support the substantial equivalence claim." The testing focused on the device's functional performance against simulated data, not on its impact on human reader performance.

6. If a Standalone (i.e., algorithm only without human-in-the-loop performance) Was Done

Yes, the described testing is exclusively a standalone performance evaluation. The device (HeartSuite Hemodynamics software) was "tested using physiologic simulators" to assess its ability to monitor, measure, and record data and perform calculations independently. There is no mention of a "human-in-the-loop" component in the described performance testing.

7. The Type of Ground Truth Used

The ground truth used was based on the known, predefined parameters and outputs of physiologic simulators (including Schiller and SimMan). This is akin to a "synthetic ground truth" or a "simulated ground truth."

8. The Sample Size for the Training Set

The document does not mention a training set or any machine learning/AI components that would require one. The system appears to be based on pre-programmed logic for monitoring, measuring, and calculating physiological data, rather than a learning algorithm.

9. How the Ground Truth for the Training Set Was Established

Not applicable, as no training set is mentioned or implied by the device's description and testing methodology.

Summary

Regulation Number and Section

§ 870.1425 Programmable diagnostic computer.

(a)
Identification. A programmable diagnostic computer is a device that can be programmed to compute various physiologic or blood flow parameters based on the output from one or more electrodes, transducers, or measuring devices; this device includes any associated commercially supplied programs.(b)
Classification. Class II (performance standards).