Search Results

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

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).

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

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).

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

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.

Ask a specific question about this device

The Enterprise Visual Medical System(TM) is classified as a picture archive and communications system. It is a software only solution developed by Emageon Inc., that utilizes off the shelf software, standard computer workstations and standard storage devices that allow authorized physicians and authorized healthcare professionals to acquire, access, visualize and store digital medical images, and data associated with the images, across the enterprise using advanced content management and clinical workflow through a graphical user interface.

Advanced Visualization (Image Viewing) includes: Full featured 2D imaging, 3D Volume Rendering, Multi-Planar Reformatting (MPR), Real-time oblique imaging, Integrated image fusion, JPEG2000-based Adaptive Bandwidth Streaming, DICOM Image Note export, Presentation States, Annotation and Measurement tools, Automated linking, Display protocols, Enterprise Worklist, prior study management, archiving of digital mammography images provided that systems cleared via a cleared 510(k) are used and that digitized secondary captures of those images are not viewed for assisting in diagnosis, utilization of third-party electronic templates, the display of Standard Uptake Value, recording of third party, plug-in software, and user configurable settings for viewing digital medical images and corresponding data.

Emageon Inc.'s EVMS™ software is integrated client-server software package comprised of features that were previously cleared in Vortex ™, 510(k): K012097, and Ultravisual™, 510(k) K042008. The main difference is that the software will now allow display Standard Uptake Value measurements, MPR on irregular data sets and in oblique planes, and automatic region growing, the naming conventions of the components have been modified, the design architecture and the overall design and development process in order to synchronize the existing compliance to the federal QSR 21 CFR, Part 820 with ISO 13485:2003 and ISO 14971:2000/Amd 1 .: 2003(E).

The provided 510(k) summary for Emageon Inc.'s EVMS™ Enterprise Visual Medical System software focuses on demonstrating substantial equivalence to previously cleared devices (Vortex™ and Ultravisual™) rather than presenting a standalone study with defined acceptance criteria and performance metrics for the EVMS™ itself.

The submission states that EVMS™ is an integrated client-server software package comprised of features previously cleared. The main differences are the addition of Standard Uptake Value measurements, MPR on irregular datasets and in oblique planes, automatic region growing, modified naming conventions, and updates to the design architecture and development process to align with ISO standards.

Based on the provided document, here's a breakdown of the information requested, with explicit notes where information is not available or implied by the substantial equivalence approach:

1. Table of Acceptance Criteria and Reported Device Performance:

No specific acceptance criteria or performance metrics (e.g., sensitivity, specificity, accuracy, precision) are defined for EVMS™. The submission relies on the substantial equivalence of its features to previously cleared devices. Therefore, a table for this device cannot be constructed as the data is not present in the document.

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

• Test Set Sample Size: Not specified.
• Data Provenance: Not specified. The submission refers to "Extensive testing... performed by programmers, non-programmers, quality assurance staff, potential customers, and contracted third parties," but does not detail a specific test set or its origins.

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

• Number of Experts: Not specified.
• Qualifications of Experts: Not specified. The document mentions "potential customers" testing, which might imply clinical users, but their specific qualifications for establishing ground truth are not detailed.

4. Adjudication Method for the Test Set:

• Adjudication Method: Not specified.

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

• MRMC Study: No. The document does not mention a MRMC comparative effectiveness study where human readers' performance with and without AI assistance was evaluated. The focus is on the software's functionality and equivalence to prior versions.
• Effect Size of Human Readers' Improvement with AI vs. Without AI Assistance: Not applicable, as no MRMC study was performed or reported.

6. If a Standalone (Algorithm Only Without Human-in-the-Loop Performance) Was Done:

• Standalone Performance Study: No. The document describes the software as an image processing system for display and analysis, intended for use by healthcare professionals. No standalone algorithm performance evaluation (e.g., for automated detection or diagnosis without human review) is reported.

7. The Type of Ground Truth Used:

• Type of Ground Truth: Not specified. Given the nature of the device (an image processing and PACS system), "ground truth" would likely relate to the accuracy of image display, measurements, and advanced visualization renderings compared to expected validated outputs or established clinical standards. However, no specific ground truth methodology is outlined.

8. The Sample Size for the Training Set:

• Training Set Sample Size: Not applicable/Not specified. The device is described as an image processing system, not a machine learning or AI algorithm that undergoes "training" in the traditional sense, as understood for predictive models. Its development involves standard software engineering practices.

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

• Ground Truth for Training Set: Not applicable/Not specified. As noted above, the concept of a "training set" and "ground truth" for it, as applied to machine learning, does not appear relevant to this submission. The development process refers to "design, developed, tested and validated according to written procedures" and compliance with QSR and ISO standards. The "ground truth" in this context would be the correct functioning of the software features as per specifications.

Ask a specific question about this device