Search Filters

Search Results

Found 2 results

510(k) Data Aggregation

    K Number
    K103142
    Date Cleared
    2011-03-03

    (129 days)

    Product Code
    Regulation Number
    870.1025
    Reference & Predicate Devices
    Why did this record match?
    Reference Devices :

    K050605

    AI/MLSaMDIVD (In Vitro Diagnostic)TherapeuticDiagnosticis PCCP AuthorizedThirdpartyExpeditedreview
    Intended Use

    The Spacelabs Multi-parameter Module is intended for use with the Patient Care Management System (PCMS) to acquire, monitor, and process various clinical parameters from an adult or neonate/infant populations in any type of clinical environment other than home use.

    Physiological parameters that may be monitored include ECG with arrhythmia detection, respiration, invasive and noninvasive blood pressure, temperature, oxygen saturation (SpO2) and cardiac output. Acquired data may then be communicated to an information network for display, recording, editing and analysis.

    Device Description

    The Spacelabs Multi-parameter Module provides monitoring capability for the following parameters: ECG with arrhythmia detection, respiration, invasive and noninvasive blood pressure, temperature, oxygen saturation (SpO2) and cardiac output. It is a "plug-in" module that is used in conjunction with a Spacelabs Monitoring Station such as the Model 91387.

    The patient is connected to the Spacelabs Multi-parameter Module via parameter-specific cables/sensors which provide the monitor with the patient's physiological data. The physiological data for each active parameter is accumulated by the Spacelabs Multi-parameter Module, and sent to the monitor which performs any necessary analysis and provides both waveform data and numeric values for display on the monitor screen. The monitor provides the display and printing capabilities for the care provider.

    Setting of alarm limits, enabling or disabling alarm monitoring, and definition of alarm responses are determined on a parameter-byparameter basis, and can be defined by the user for each parameter. In general, alarm limits can be set to provide the user with both audible and visible indications of the alarm condition. Each parameter provides a hierarchy of menu structures and keys that are activated through controls of the monitor by touching the monitor screen.

    Each parameter provides the capability to output recordings of selected information to a variety of recording devices. Recordings are available using the Spacelabs Monitor internal printer, network printers, and the Intesys Clinical Suite Print Manager Model 91881. Recordings can be automatically generated by each of the parameter's alarm managers or manually generated.

    The Spacelabs Multi-parameter Module utilizes the same technology for each parameter as utilized by the predicate device.

    AI/ML Overview

    Here's an analysis of the provided 510(k) summary regarding the acceptance criteria and the study proving the device meets them:

    1. A table of acceptance criteria and the reported device performance:

    Acceptance Criteria CategoryReported Device PerformanceComments
    Sterilization & Shelf-LifeNot applicableDevice is not sterilized or sterilizable by the user. Software modifications did not affect accessories that are.
    BiocompatibilityNot applicableDevice is not intended for direct or indirect patient contact. Software modifications did not affect accessories that are.
    Software TestingComplies with predetermined specificationsDesigned and developed according to a robust software development process; rigorously verified and validated. Complies with FDA guidance for software in medical devices.
    Electrical Safety & Electromagnetic CompatibilityNot applicableSoftware modifications did not affect these aspects; no hardware modifications were made.
    Performance Testing - BenchPerformance equal to or better than the predicate deviceTested in accordance with ANSI/AAMI EC57: 1998 / (R) 2003, in addition to software verification and validation.
    Performance Testing - AnimalNot applicableNot necessary to demonstrate safety and effectiveness.
    Performance Testing - ClinicalNot applicableNot necessary to demonstrate safety and effectiveness.

    2. Sample size used for the test set and the data provenance:

    • The document does not specify a numerical sample size for a dedicated "test set" in the context of clinical or large-scale data evaluation.
    • The performance testing primarily focuses on software verification and validation and bench testing against a standard (ANSI/AAMI EC57: 1998 / (R) 2003) and comparison to a predicate device. This suggests internal testing and adherence to engineering standards rather than external data-driven validation.
    • Data provenance is not explicitly mentioned as no clinical or animal performance testing was deemed necessary. The evaluation seems to be based on engineering benchmarks and comparisons to the predicate device's established performance.

    3. Number of experts used to establish the ground truth for the test set and the qualifications of those experts (e.g., radiologist with 10 years of experience):

    • This information is not provided in the submission. Given that clinical and animal testing were deemed not applicable, and the focus was on software and bench testing, expert review for ground truth on patient data (such as for arrhythmia detection accuracy) is not described.

    4. Adjudication method (e.g., 2+1, 3+1, none) for the test set:

    • This information is not provided. As clinical and animal testing were not performed, and no external expert review of patient cases is described, an adjudication method for a test set is not detailed.

    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:

    • No MRMC comparative effectiveness study was performed or described. The device is a multi-parameter module that includes arrhythmia detection, which is typically an algorithmic function, not a human-in-the-loop AI assistance tool that would necessitate an MRMC study. The comparison is between the modified device and its predicate, based on technical performance.

    6. If a standalone (i.e. algorithm only without human-in-the-loop performance) was done:

    • Yes, in essence. The "Software Testing" and "Performance Testing - Bench" sections evaluate the device's inherent performance. The arrhythmia detection component would inherently be a standalone algorithmic function within the module. The document states:
      • "Test results indicate that the Spacelabs Multi-parameter Module complies with its predetermined specification." (Software Testing)
      • "Test results demonstrate performance equal to or better than the predicate device." (Performance Testing - Bench, which includes testing in accordance with ANSI/AAMI EC57 for ECG/arrhythmia).
    • These statements imply that the algorithm's performance was evaluated in isolation to ensure it met its defined specifications and performed comparably to the predicate device.

    7. The type of ground truth used (expert consensus, pathology, outcomes data, etc.):

    • For the software and bench testing, the "ground truth" would be the expected output or reference standard defined by the product's specifications and the requirements of standards like ANSI/AAMI EC57. For instance, in arrhythmia detection, this would involve synthetic ECG signals with known arrhythmias, or recorded physiological data where arrhythmias have been definitively identified by established methods (though specifics of how this ground truth was established for the test data are not detailed in this summary). The comparison to the predicate device also implies its established performance serves as a benchmark for "ground truth."

    8. The sample size for the training set:

    • This information is not provided. The submission details modifications to an existing device rather than the development of a novel algorithm that would typically involve a distinct "training set." The software development process mentioned implies iterative testing and refinement, but specifics of data used for internal training are not disclosed.

    9. How the ground truth for the training set was established:

    • As a "training set" is not explicitly mentioned, the method for establishing its ground truth is not described. For an algorithmic component like arrhythmia detection, initial development (training) would likely involve a combination of expert-annotated ECG waveforms (synthetic or recorded) and adherence to physiological principles. However, the 510(k) focuses on the modifications' verification and validation against existing standards and the predicate, not the original algorithm's development.
    Ask a Question

    Ask a specific question about this device

    K Number
    K102422
    Date Cleared
    2010-12-07

    (104 days)

    Product Code
    Regulation Number
    870.1025
    Why did this record match?
    AI/MLSaMDIVD (In Vitro Diagnostic)TherapeuticDiagnosticis PCCP AuthorizedThirdpartyExpeditedreview
    Intended Use

    Spacelabs Healthcare patient monitors, functioning as either bedside or central monitors; passively display data generated by Spacelabs Healthcare parameter modules, Flexports interfaces, and other SDLC based products in the form of waveform and numeric displays, trends and alarms. Key monitored parameters available on the model 91367, 91369, 91370 and 91387, when employing the Spacelabs Command Module, consist of ECG, respiration, invasive and noninvasive blood pressure, SpO2, temperature and cardiac output. Additional parameters and interfaces to other systems are also available depending on the parameter modules employed.

    Spacelabs Healthcare patient monitors are intended to alert the user to alarm conditions that are reported by Spacelabs Healthcare parameter modules and/or other physiologic monitors via Flexport interfaces. These determine a) when an alarm condition is violated; b) the alarm priority (i.e. high, medium or low); c) alarm limits; and d) when to initiate and terminate alarm notifications. The patient monitors are also capable of displaying alarm conditions on other monitors that are on the network through the Alarm Watch feature.

    Spacelabs Healthcare patient monitors may also function as a generic display or computer terminal. As a generic display or terminal, the patient monitors allow networkbased applications to open windows and display information on other networked monitors.

    Spacelabs Healthcare patient monitors are also designed to communicate with a variety of external devices such as displays, network devices, serial devices, user input devices, audio systems, and local/remote recorders.

    Spacelabs Healthcare patient monitors are intended for use under the direct supervision of a licensed healthcare practitioner, or by personnel trained in proper use of the equipment in a hospital environment.

    Device Description

    The Spacelabs Medical Patient Monitors are a component of the Spacelabs Medical Patient Monitoring System. The four (4) monitor models 91367, 91369 and 91370 and the stationary monitor model 91387; are all similar in that they are all employ the same software and all accept inputs from the family of Spacelabs Parameter Modules. The monitors accept and display parameter information, waveform and numeric data, and alarm conditions including arrhythmia information received from the same family of modules modules.

    The portable monitors are capable of operating independent of or connected to the Spacelabs Patient monitoring Network. As independent, portable monitors these devices operate from either AC or battery power. All alarm information received from the parameter modules is visually and audibly available at each monitor. When networked, either physically or wirelessly, these monitors are able to share their information with a central station or with other monitors on the network according to conditions establish by the user/system administrator. They are also able to connect, via the healthcare institution's network, through Dynamic Network Access (DNA) to other applications available on the network.

    The stationary monitor, model 91387, can be configured at installation as either a bedside or central station. As an independent bedside monitor the device operates from AC and. presents waveform, numeric data, and alarm conditions, including arrhythmia information, received from parameter modules. When physically networked these monitors are able to share their information with a central station or with other monitors on the network according to conditions establish by the user/system administrator. They are also able to connect, via the healthcare institution's network, through Dynamic Network Access (DNA) to other applications available on the newt6work.

    The model 91387 central station monitor provides full monitoring control of remote parameters, including displays and alarms with both visual and audible annunciation for up to 16 patients. All waveform and current numeric data, arrhythmia, ST segment, and trends are available are available at the central station.

    AI/ML Overview

    The provided text describes the Spacelabs Patient Monitors (models 91367, 91369, 91370, and 91387) and their substantial equivalence to predicate devices. However, it does not contain specific acceptance criteria or a detailed study report with performance metrics in the format usually associated with a medical device's performance evaluation against predefined criteria.

    Instead, the document states that the devices were validated through "rigorous testing" to ensure compliance with standards and accurate presentation of parameter data, but it does not quantify this performance or present it in a table of acceptance criteria vs. reported performance.

    Therefore, for aspects like "Table of acceptance criteria and reported device performance," "Sample sized used for the test set," etc., the information is not present in the provided text.

    Here's an analysis based on the information available in the text:

    1. Table of Acceptance Criteria and Reported Device Performance

    Acceptance CriteriaReported Device Performance
    Specific Performance Metrics for accuracy, sensitivity, specificity, etc.Not provided in the document. The document states "Test programs verified that parameter data provided by parameter modules...to the Patient Monitors could be accurately presented and that the interface supported the intended clinical work flows and met the user's clinical needs." However, no quantifiable performance metrics, thresholds, or pass/fail criteria are given.
    Compliance with relevant standards (unspecified, but mentioned in "Software section")The device was subject to "rigorous testing that, in part, support the compliance of the software to the Standards mentioned in the Software section of this submission." No specific standards or results against them are detailed.
    Support intended clinical workflows and meet user's clinical needs"Test programs verified that...the interface supported the intended clinical work flows and met the user's clinical needs." No specific details on how this was verified or what criteria were met.
    Software developed following a robust software development process"the Spacelabs Patient Monitors' software was developed following a robust software development process that was fully specified and validated." No details about the process or validation.

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

    • Sample Size: Not specified. The document mentions "test programs" but does not give the number of cases, patients, or data points used.
    • Data Provenance: Not specified (e.g., country of origin, retrospective or prospective).

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

    • Number of Experts: Not specified.
    • Qualifications of Experts: Not specified.

    4. Adjudication Method for the Test Set

    • Adjudication Method: Not specified.

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

    • Was an MRMC study done? No. The document describes patient monitors that display data from other modules and communicate alarm conditions. It does not involve human readers interpreting data that could be assisted by AI.
    • Effect size of human readers with vs. without AI assistance: Not applicable, as no MRMC study or AI assistance is mentioned in this context.

    6. Standalone (Algorithm Only Without Human-in-the-Loop Performance) Study

    • Was a standalone study done? The device itself (the monitor) is not an "algorithm" in the sense of making diagnostic interpretations. It's a display and communication device for physiological parameters. The "rigorous testing" mentioned was for the monitor's ability to accurately present data and interface. This aligns more with functional and system integration testing rather than an AI algorithm's standalone performance. No specific standalone performance metrics for an algorithm are provided.

    7. Type of Ground Truth Used

    • Type of Ground Truth: Not explicitly stated for specific performance metrics. The phrasing "parameter data provided by parameter modules...could be accurately presented" suggests that the ground truth for "accuracy" would be the direct output from the source parameter modules or a reference standard for those parameters. For clinical workflow, the "ground truth" would be the subjective assessment of meeting user needs.

    8. Sample Size for the Training Set

    • Sample Size: Not applicable. This device is a patient monitor displaying data, not an AI/ML algorithm that is "trained" on a dataset.

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

    • How Ground Truth Established: Not applicable. This device is a patient monitor displaying data, not an AI/ML algorithm that is "trained" on a dataset.

    Summary of Device and Study Information:

    This 510(k) submission is for patient monitors that display and communicate physiological data and alarms from other external modules. The "study" described is a general validation of the monitors' ability to accurately present data, support clinical workflows, and comply with unspecified software standards. There are no detailed performance metrics, test set sizes, expert qualifications, or AI-related study components typically found in submissions for AI/ML-driven devices. The focus is on the functional equivalence and safety of the monitors as display and communication interfaces.

    Ask a Question

    Ask a specific question about this device

    Page 1 of 1