Search Results

The Spacelabs Healthcare Qube Compact Monitor (91390), functioning as either bedside or central monitors; passively displays data generated by Spacelabs Heatthcare 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 91390 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.

The Qube is 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 devices 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.

The Qube 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.

The Qube is 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.

The Qube is 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.

The Spacelabs Spacelabs Healthcare Qube Compact Monitor (91390) (Qube) is a component of the Spacelabs Medical Patient Monitoring System. The monitor accepts and displays parameter information, waveform and numeric data, and alarm conditions including arrhythmia information received from the same family of modules as its predicate, the Spacelabs Medical Model 91370 Patient Monitor.

The Spacelabs Healthcare Qube Compact Monitor (91390), functioning as either bedside or central monitors; passively displays data generated by Spacelabs Heatthcare 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 91390 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.

The Qube is 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 devices 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.

The Qube 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.

The Qube is 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.

The Qube is 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.

The provided text describes the Spacelabs Healthcare Qube Compact Monitor (91390) and its 510(k) premarket notification. However, it does not describe acceptance criteria or a study proving the device meets those criteria in the context of an Artificial Intelligence (AI) or machine learning algorithm. The document pertains to a medical device (patient monitor) and its regulatory clearance based on substantial equivalence to a predicate device. The performance testing outlined focuses on electrical safety, electromagnetic compatibility, software validation, usability, and alarm systems, which are standard for such medical devices, not for AI algorithm performance.

Therefore, for aspects related to AI/ML specific criteria (like ground truth, expert consensus, MRMC studies, sample sizes for training/test sets for an algorithm, and improvement with AI assistance), the information is not present in the provided document.

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

Acceptance Criteria and Device Performance (Based on available information)

• IEC 60601-1-6: 2010 (Usability)
• IEC 60601-1-8: 2006 (Alarm systems)
• IEC 62366: 2007 (Application of usability engineering)
• ISTA Procedure 1A (Packaged-products under 150 lb (68 kg) non-simulation integrity performance test procedure) | "Test results indicated that the Qube complies with its predetermined specification and with the applicable Standards." |
  | Conclusion/Overall | Safe and effective when used in accordance with intended use and labeling, and substantially equivalent to predicate device. | "Verification and validation activities were conducted to establish the performance and safety characteristics of the device modifications made to the Qube. The results of these activities demonstrate that the Qube is safe and effective when used in accordance with its intended use and labeling. Therefore, the Qube is considered substantially equivalent to the predicate device." |

Study Details (Based on available information for a medical device, not an AI algorithm)

The document describes performance testing for a medical device (patient monitor), not a study for an AI/ML algorithm. Therefore, many of the requested AI/ML-specific details are not applicable or not present.

1. A table of acceptance criteria and the reported device performance: (Provided above)

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

   • The document does not specify sample sizes for any of the performance tests (e.g., number of units tested, duration of tests, or amount of data used for software validation).
   • Data provenance is not mentioned. These are typical engineering and regulatory compliance tests performed on the device itself.

3. Number of experts used to establish the ground truth for the test set and the qualifications of those experts:

   • This concept of "ground truth" and "experts" as in AI/ML is not applicable to the type of device testing described. The tests are against established engineering standards and internal specifications, not a clinical "ground truth" adjudicated by medical experts.

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

   • Not applicable as this is not a study assessing human or AI interpretation against a clinical ground truth.

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 study was conducted or mentioned, as this device is a patient monitor, not an AI-assisted diagnostic tool.

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

   • Not applicable. The device itself is the system; there is no separate "algorithm only" performance reported in the context of an AI.

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

   • Not applicable in the AI/ML sense. The "ground truth" for the device's performance is adherence to established engineering and medical device safety standards (e.g., IEC standards, internal specifications).

8. The sample size for the training set:

   • Not applicable. This document is for a medical monitor, not an AI/ML algorithm that requires a training set.

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

   • Not applicable.

In summary, the provided K120616 document is a 510(k) summary for a patient monitoring device, demonstrating its substantial equivalence to a predicate device through adherence to recognized performance, safety, and electromagnetic compatibility standards. It does not involve artificial intelligence or machine learning algorithms and therefore does not contain information on "acceptance criteria" or "study" as one would expect for an AI/ML-based medical device.

Ask a specific question about this device

The Spacelabs Healthcare Xprezzon Bedside Monitor passively displays data generated by Spacelabs parameter modules, Flexport interfaces, and other Spacelabs SDLC based products as waveform and numeric displays, trends and alarms. Key monitored parameters available on the model 91393, when employing the Spacelabs Command Module, consist of ECG, respiration, invasive and noninvasive blood pressure, Sp02, temperature and cardiac output. Additional parameters and interfaces to other systems are also available depending on the parameter modules employed.

The Spacelabs Healthcare Xprezzon Bedside Monitor is intended to alert the user to alarm conditions that are reported by Spacelabs Healthcare parameter modules and/or other devices via Flexport interfaces. The patient monitors are also capable of displaying alarm conditions on other monitors that are on the network through the Alarm Watch feature.

The Spacelabs Healthcare Xprezzon Bedside Monitor may also function as a generic display or computer terminal. As a generic display or terminal, the patient monitor allows network based applications to open windows and display information the Xprezzon and other networked monitors.

The Spacelabs Healthcare Xprezzon Bedside Monitor is 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.

The Xprezzon Bedside Monitors is 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.

The Spacelabs Healthcare Xprezzon Bedside Monitor, Model 91393, is a component of the Spacelabs Healthcare Patient Monitoring System. The Xprezzon Bedside Monitor accepts inputs from the family of Spacelabs Parameter Modules. The monitor accept and displays parameter information, waveform and numeric data, and alarm conditions including arrhythmia information received from the same family of modules.

The Xprezzon Bedside monitor, model 91393, is configured at installation to operate independent of or connected to the Spacelabs Patient monitoring Network. 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 network.

Here's an analysis of the provided 510(k) summary regarding the Spacelabs Healthcare Xprezzon Bedside Monitor, focusing on acceptance criteria and supporting studies.

Important Note: The provided 510(k) summary focuses heavily on demonstrating substantial equivalence to a predicate device and does not detail specific, quantitative clinical performance metrics or studies in the way a typical AI/software as a medical device (SaMD) submission would. The "acceptance criteria" discussed below are inferred from the document's claims of functional equivalence and compliance with standards, rather than explicitly stated performance targets for a novel algorithm.

Acceptance Criteria and Reported Device Performance

This 510(k) summary does not present a table of quantitative acceptance criteria with corresponding performance metrics like sensitivity, specificity, or accuracy. Instead, it asserts that the device meets acceptance criteria through validation that supports compliance with standards and verifies accurate data presentation, intended clinical workflows, and user needs, based on functional equivalence to a predicate device.

Given the nature of the device (a bedside monitor displaying data from other modules), the "acceptance criteria" are implicitly tied to the proper functioning of the display and interface, and its ability to accurately present information and alarms generated by external parameter modules.

Study Details

The provided document describes the validation of the device, but it is not a clinical study in the typical sense of evaluating the performance of a diagnostic or predictive algorithm against ground truth with specific metrics (e.g., sensitivity, specificity). Instead, it is a device validation focused on engineering and software verification.

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

   • The document does not specify a "test set" in terms of patient data or clinical cases. The validation appears to be primarily laboratory-based and functional testing of the monitor's ability to display data.
   • Given the nature of the device (a display monitor), data provenance from specific countries or retrospective/prospective collection is not applicable in the context of this summary.

2. Number of experts used to establish the ground truth for the test set and the qualifications of those experts:

   • This information is not provided and is likely not relevant as "ground truth" for clinical performance metrics (like those for an arrhythmia detection algorithm) is not part of this specific 510(k) for the bedside monitor itself. The monitor displays ground truth as provided by separate parameter modules.
   • The document mentions "user's clinical needs," implying input from healthcare professionals, but specific details on their number or qualifications for establishing ground truth are absent.

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

   • This is not applicable/not provided. The validation described is not a clinical adjudication study for diagnostic accuracy.

4. 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 study was done. This device is a bedside monitor displaying data from other devices, not an AI-powered diagnostic or interpretive tool that assists human readers.

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

   • The "algorithm" here refers to the software controlling the display and networking of the monitor. A "standalone" performance evaluation in the context of a diagnostic algorithm is not applicable. The device's performance is inherently tied to its function as an interface and display. Its "standalone" performance would be its ability to correctly process and display inputs, which was part of the "rigorous testing" mentioned.

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

   • The document does not specify a type of ground truth in the context of clinical outcomes or pathology. For a bedside monitor, "ground truth" for validation would likely involve:
     • Reference signals/simulations: Using calibrated signal generators to simulate physiological data and ensure the monitor accurately displays it.
     • Predicate device comparison: Ensuring the Xprezzon displays data consistent with the predicate device.
     • Functional requirements testing: Verifying that different modules integrate correctly and that alarm conditions are triggered and displayed as expected according to predefined functional specifications.

7. The sample size for the training set:

   • This device is not an AI/machine learning model that requires a "training set" of data. Therefore, this information is not applicable/not provided. The software development process mentioned follows standard software engineering practices, not AI model training.

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

   • As there is no "training set" for an AI model, this question is not applicable.

Summary of the Study:

The "study" described is a developmental and verification/validation engineering process rather than a clinical trial. It involved:

• Rigorous testing to support compliance of software to standards.
• Validation that the software was developed following a robust software development process.
• Test programs to verify:
  • Accurate presentation of parameter data from external modules.
  • Support for intended clinical workflows.
  • Meeting user's clinical needs.

The entire submission hinges on demonstrating substantial equivalence to the predicate device (Spacelabs Medical Ultraview SL Patient Monitors, Model 91387), despite minor hardware and software updates, concluding that the new device is "as safe and effective." No novel claims of diagnostic or predictive accuracy are being made by the monitor itself; it acts as a display and interface for information generated by other cleared devices.

Ask a specific question about this device

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.

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.

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

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 specific question about this device

The Spacelabs élance Vital Signs Monitor and élance Central Station is indicated for use in patient populations for:

• Adult
• Pediatric

The Spacelabs élance Vital Signs Monitor and élance Central Station facilitates the monitoring of:

• ECG with arrhythmia detection
• Respiration
• Non-invasive blood pressures
• Invasive blood pressures
• Body temperature
• Functional arterial oxygen saturation, and
• End tidal CO2.

The Spacelabs élance Vital Signs Monitor and élance Central Station is a prescription device intended to be used by healthcare professionals in all areas of a healthcare facility.

The Spacelabs Medical, Inc. (Spacelabs) élance Vital Signs Monitor is a family of portable patient monitors intended to be used by clinicians and medical qualified personnel for monitoring ECG, respiration, NIBP, temperature, SPO2, invasive blood pressure and EtCO2. Models within the Spacelabs élance family come in two different sized viewing areas (10.2" and 12.1"), two different housing colors (white and black) and offer selected monitoring features.

The Spacelabs Medical, Inc. élance Central Station software package is available for use with a customer acquired computer based on specifications provided by Spacelabs Medical. This package allows monitoring of the élance Vital Signs Monitor at a central workstation.

The provided text describes a 510(k) submission for the Spacelabs Medical élance Vital Signs Monitor and élance Central Station. This type of submission focuses on demonstrating substantial equivalence to a predicate device rather than providing detailed clinical trial data with specific acceptance criteria and performance metrics typically seen in studies for novel technologies.

Therefore, for many of your requested points, the information is not available in the provided document, as it is not a study report designed to evaluate the device's performance against specific clinical acceptance criteria. Instead, it highlights verification that modifications were implemented correctly and that the device complies with predetermined specifications.

Here's an analysis based on the available information:

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

This information is not provided in the document. The document states that "Verification results indicated that the élance Vital Signs Monitor and élance Central Station complies with predetermined specifications," but it does not list those specifications or report numerical performance data against them.

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

This information is not provided. The submission refers to "verification results" but does not detail a specific test set, its size, or data provenance.

3. Number of experts used to establish the ground truth for the test set and the qualifications of those experts

This information is not provided. As it's a 510(k) for a monitoring device, ground truth for patient physiological parameters would typically involve highly accurate reference measurements from other medical devices, not expert human agreement in the same way it would for image interpretation. However, the document does not specify any details about how reference data was obtained or validated.

4. Adjudication method for the test set

This information is not provided.

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

There is no indication of an MRMC comparative effectiveness study in the provided text. This device is a physiological monitor, not an AI-assisted diagnostic tool for human readers, so such a study would not typically be applicable in this context.

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

The document states, "The élance Vital Signs Monitor and élance Central Station utilize the same technology for each parameter as utilized by the predicate device." While there's a "central station," the primary function is monitoring, and the "arrhythmia detection" is likely an algorithmic function. However, the document does not detail specific standalone algorithm performance metrics or any studies conducted on the algorithm alone without considering the human user. The focus is on the device as a whole and its substantial equivalence to a predicate.

7. The type of ground truth used

This information is not explicitly stated. For a vital signs monitor, the ground truth for parameters like ECG, respiration, blood pressure, temperature, SpO2, and EtCO2 would typically be established by highly accurate reference devices or invasive measurements (e.g., arterial line for invasive blood pressure, capnography for EtCO2). However, the document does not elaborate on how ground truth was established for the "predetermined specifications" against which the device was verified.

8. The sample size for the training set

This information is not provided. The submission is not for a device developed using machine learning that would typically involve a "training set" in the sense of AI model development. The verification is against "predetermined specifications," suggesting a more traditional engineering validation approach.

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

This information is not provided, as the concept of a "training set" in the context of AI model development does not appear to apply to this submission.

Ask a specific question about this device

The Spacelabs Medical, mCare 300, Model 91220, Vital Signs Monitor is indicated for use in adult, pediatric and neonate patient populations wherever there is a need for the monitoring of ECG, respiration, invasive or noninvasive blood pressures, body temperature, functional arterial oxygen saturation, or expired or minimum inspire CO2.
The Spacelabs Medical, mCare 300, Model 91220, Vital Signs Monitor is a prescription device intended to be used by healthcare professionals in all areas of a healthcare facility.

The Spacelabs Medical mCare 300 Vital Signs Monitor Model 91220 (mCare 300), is a portable patient monitoring device intended to be used by clinicians and medically qualified personnel for monitoring physiological parameters; ECG, respiration, noninvasive and invasive blood pressure, body temperature, SpO2, or End tidal CO2 or ETCO2; in neonatal, of pediatric and adult patients.
This device is designed to be used in all general hospital and alternate care environments. This device is available for sale only upon the order of a physician or licensed health care professional.

The provided text describes a 510(k) submission for the Spacelabs Medical mCare 300 Vital Signs Monitor, Model 91220. The submission is primarily focused on a change in the Non-Invasive Blood Pressure (NIBP) module from a Welch Allyn module to an Omron M3200 NIBP module.

Based on the information provided, here's a breakdown regarding acceptance criteria, performance, and study details:

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

The document does not explicitly state specific quantitative acceptance criteria (e.g., accuracy ranges for blood pressure readings) in the provided text. It mentions that the NIBP module revision was "validated through rigorous testing that, in part, supports the compliance of the mCare 300 to the various standards identified in this submission." However, the exact standards or performance metrics are not detailed.

Acceptance Criteria and Reported Device Performance

2. Sample size used for the test set and the data provenance (e.g. country of origin of the data, retrospective or prospective)

The document does not provide details on the sample size used for the test set or the data provenance. It only broadly refers to "rigorous testing."

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)

No information is provided regarding experts, their number, or qualifications for establishing ground truth. The testing mentioned appears to be related to technical validation of the NIBP module's performance against standards, rather than expert-driven clinical evaluation for diagnostic accuracy.

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

No information is provided regarding any adjudication methods.

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

This is not applicable. The device is a vital signs monitor, not an AI-assisted diagnostic tool for human readers. Therefore, an MRMC comparative effectiveness study involving AI assistance would not be relevant.

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

This is not applicable in the context of an NIBP module in a vital signs monitor. The performance of the NIBP module itself is typically assessed in isolation (i.e., its accuracy in measuring blood pressure) through technical and physiological testing. The document states "The NIBP module revision to the mCare 300 was validated through rigorous testing," implying standalone validation of the module's performance.

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

The document does not explicitly state the type of ground truth. For NIBP measurements, the "ground truth" would typically involve invasive arterial pressure measurements or highly accurate non-invasive reference methods to compare against the device's readings as part of its validation against relevant performance standards. The general statement "supports the compliance of the mCare 300 to the various standards identified in this submission" suggests that the ground truth would be defined by the requirements of those standards (e.g., ISO, AAMI standards for NIBP accuracy).

8. The sample size for the training set

This is not applicable. The device is a vital signs monitor, and the submission concerns a hardware module change and associated software validation, not a machine learning model that requires a training set.

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

This is not applicable, as there is no training set for a machine learning model.

Ask a specific question about this device

The Spacelabs Medical Full Disclosure System is indicated for use in clinical situations where there is a need for review of physiological waveform information and alarm events up to 72 hours after the fact. The Full Disclosure System is also indicated in those situations where a retrospective analysis of monitoring patients' ECG waveform data, that can be annotated and edited, is desired. The intended use of the Spacelabs Medical Full Disclosure System is to interface with the Spacelabs monitoring network in order to provide the user with a means of recalling waveform information and retrospectively analyzing up to 72 hours of monitoring patient's most recent ECG waveform data.

The Spacelabs Medical Full Disclosure System (FD), model 91810, is a software application intended to be installed on an Off-The-Shelf (OTS) computer system utilizing a Microsoft operating system. The primary purpose of the FD system is to review, up to 72 hours of monitored patients' historical physiological waveform and alarm event information. The system also provides for a Retrospective Analysis of the stored ECG waveform data. The Full Disclosure system is a software application that provides fulldisclosure functionality for Spacelabs Medical bedside monitors. Depending on options purchased, a maximum of 72 hours of patient waveform history can be viewed for patients connected to the monitoring network. The system supports the following waveform channels: ECG Primary and secondary, Arterial pressure, Pulmonary artery pressure, Central venous pressure, Right atrial pressure, Intracranial pressure, Left atrial pressure, General pressure, Umbilical artery pressure, Pulse oximetry, Umbilical venous pressure, Adult or neonatal ventilator Flexport, Carbon dioxide / multigas Flexport or module, Sp02/ET02 Flexport and Respiration. The Full Disclosure application allows the user to view and print the full array of waveform information collected from Spacelabs Medical bedside monitors connected to the Spacelabs Medical patient monitoring network. The Alarm events, 12 Lead Reports and waveform information is available to the user for up to 72 hours after the information is stored in the network's database. In addition, the system incorporates a shape-based, Retrospective Algorithm that may be applied to the ECG waveform data, if desired. This Retrospective Algorithm can identify clinically significant ECG events and make them available for viewing and printing. When ECG analysis is performed, the results are stored locally, not in the database. Preference information, such as display and report options, is saved on the local machine, not in the database.

The provided text describes a 510(k) premarket notification for the Spacelabs Medical Full Disclosure System, Model 91810. The notification focuses on establishing substantial equivalence to a predicate device rather than presenting a detailed clinical study with specific acceptance criteria in terms of analytical performance metrics or human reader comparisons.

Here's a breakdown of the requested information based on the provided text:

1. Table of Acceptance Criteria and Reported Device Performance

The document does not specify quantitative acceptance criteria in terms of performance metrics (e.g., sensitivity, specificity, accuracy) for the new device. Instead, the "acceptance criteria" appear to be tied to demonstrating substantial equivalence to a predicate device and adherence to software development processes and standards.

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

The provided text does not specify a sample size for a test set in terms of patient data or ECG recordings. The testing appears to be focused on software validation and verification rather than a clinical performance study using a defined patient cohort.

The data provenance is not explicitly stated. Given it's a software application for reviewing patient physiological data, it would logically involve existing patient data, but whether this was retrospective or prospective, or from a specific country, is not detailed.

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

The document does not mention the use of experts to establish a ground truth for a test set. This type of evaluation is common in AI/ML performance studies, but this 510(k) submission describes a software system for data review and a retrospective analysis algorithm, not a diagnostic AI system requiring expert-adjudicated ground truth for its primary claims.

4. Adjudication Method for the Test Set

Since no specific test set requiring expert ground truth establishment is described, there is no mention of an adjudication method (e.g., 2+1, 3+1).

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

No, an MRMC comparative effectiveness study was not done according to the provided information. The submission focuses on the functionality and substantial equivalence of the software system and its retrospective analysis algorithm, not on improving human reader performance with AI assistance.

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

The document states that the system incorporates a "shape-based, Retrospective Algorithm that may be applied to the ECG waveform data." It also mentions "The test program verified... that the Retrospective Analysis performed as expected." This implies some form of standalone evaluation of the algorithm's performance in identifying ECG events. However, the details of this "standalone" evaluation (e.g., specific metrics used, data size, ground truth for that specific algorithm's performance) are not provided. The overall substantial equivalence claim is for the system rather than just the algorithm in isolation.

7. The Type of Ground Truth Used

For the retrospective analysis algorithm, the type of ground truth used to evaluate its performance is not explicitly stated. In the context of ECG event identification, this would ideally involve physician-adjudicated annotations of ECG waveforms, but the document does not elaborate on this. For the general system's ability to recall data, the ground truth would inherently be the original monitored data itself.

8. The Sample Size for the Training Set

The document does not mention a training set sample size. This is not a typical requirement for a system whose primary purpose is data review and a shape-based retrospective algorithm, especially if it's not a deep learning or complex AI model that requires extensive training data. The focus is on functionality and existing standards.

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

Since a training set is not mentioned, the method for establishing its ground truth is also not described.

Ask a specific question about this device

The Spacelabs Medical mCARE 300, Model 91220, Vital Signs Monitor is indicated for use in adult, pediatric and neonate patient populations wherever there is a need for the monitoring of ECG, respiration, invasive or noninvasive blood pressures, body temperature, functional arterial oxygen saturation, or expired or minimum inspire CO2.

The Spacelabs Medical mCARE 300, Model 91220, Vital Signs Monitor is a prescription device intended to be used by healthcare professionals in all areas of a healthcare facility.

The Spacelabs Medical mCARE 300 Vital Signs Monitor, Model 91220, is a portable patient monitoring device intended to be used by clinicians and medically qualified personnel for monitoring physiological parameters; ECG, respiration, noninvasive and invasive blood pressure, body temperature, Sp02, or End tidal C02 or ETC02; in neonatal, of pediatric and adult patients.

This device is designed to be used in all general hospital and alternate care environments. This device is available for sale only upon the order of a physician or licensed health care professional.

The provided text is a 510(k) Summary of Safety and Effectiveness for the Spacelabs Medical mCARE 300 Vital Signs Monitor. It does not contain the specific acceptance criteria, reported device performance data, or details of a study that would allow for a complete answer to your request.

The document primarily focuses on establishing substantial equivalence to predicate devices and adherence to special controls and standards. It mentions that the device "successfully underwent testing to demonstrate conformance to the Special Controls established for 21CFR 807.1025, 'Class II Special Controls Guidance Document: Arrhythmia Detector and Alarm'" and "was validated through rigorous testing that, in part, support the compliance... to the Standards mentioned in Section 9.0 of this submission." However, it does not provide the results of these tests or the acceptance criteria used.

Therefore, I cannot populate the table or answer most of your detailed questions based solely on the provided text.

Here's what I can infer or state based on the given information:

• Device Type: Vital Signs Monitor (ECG, respiration, noninvasive and invasive blood pressure, body temperature, SpO2, EtCO2).
• Classification: Class II, with special controls: "Class II Special Controls Guidance Document: Arrhythmia Detector and Alarm."
• Intended Use: Adult, pediatric, and neonate patient populations in all areas of a healthcare facility, for monitoring the listed physiological parameters.
• Regulatory Pathway: 510(k) Premarket Notification, establishing substantial equivalence to predicate devices.

Missing Information:

The document lacks critical details such as:

• Specific numerical acceptance criteria for any of the physiological parameters.
• Detailed performance data (e.g., accuracy, precision, sensitivity, specificity) against those criteria.
• The specifics of any clinical or bench studies conducted (sample size, data provenance, ground truth establishment, expert qualifications, adjudication methods, details of training sets, etc.).
• Any mention of MRMC comparative effectiveness studies or standalone algorithm performance.

To answer your questions fully, you would typically need to consult the full 510(k) submission and associated test reports, which are not included in this summary.

Ask a specific question about this device

The intended use of the Spacelabs Medical Clinical Event Interface is to interface with the Spacelabs monitoring network in order to provide a secondary means of annunciating and displaying patient alarm information to mobile healthcare providers. The device is indicated for use in real-time monitoring of routine patient status and alarm events. The pager is intended to serve as a parallel, redundant mechanism to inform the clinical staff of patient events. The Clinical Event Interface System is intended for use as a secondary alarm in any hospital environment currently using or intending to use a Spacelabs patient monitoring network. The Clinical Event Interface supplements the primary patient-monitoring system by providing a forwarding mechanism for annunciating and displaying patient alarm events and the critical information associated with the events - including parameter values and waveforms, typically within 4 - 8 seconds of an alarm event on the patient monitor. The pager provides an audio or vibrating alert along with a series of displays showing patient identification, alarm parameters, and up to a 12-second waveform snapshot.

The Spacelabs Medical Clinical Event Interface is a secondary alarm. It does not replace the primary alarm function on the monitor.

The Spacelabs Medical Clinical Event Interface (CEI), model 91847, is a software module intended to be installed on an Off-The-Shelf (OTS) computer system utilizing a Microsoft operating system. The primarv purpose of the CEI is to forward patient monitor alarm event information, originating from a Spacelabs Patient Monitoring network, to a messaging and notification system for delivery to the healthcare provider via wireless pagers. The system is also capable of providing vital signs updates at regular intervals. CEI allows nurses to be aware of their patients' alarm conditions when they are away from the patient and the monitoring system.

CEI is an open design utilizing an OTS messaging system that is compatible with the Motorola CP1250 paging systems. The Clinical Event Interface includes a software module, created by Spacelabs Medical, that accesses patient data acquired from a Spacelabs Medical Patient Monitoring System. The monitoring system forwards the data to a database. The Spacelabs Medical software module recognizes when new information has become available. It accesses and formats that data for delivery to the Emergin Integrated Messaging System, an OTS software package. The Emergin software accepts input from the Spacelabs program, reformats it and passes it on to the paging encoder, an OTS component of the system. The paging encoder formats the data for the Motorola CP1250 pager and forwards it to the pager base station for transmission to the pager. The Spacelabs Medical CEI provides a complete, end-to-end solution for paging and incorporates all of these components in a single offering.

The CEI messaging system provides for the sending patient information in a text only or text and graphic format to the Motorola CP1250 pager. The CEI system is designed to forward alarm information as the alarms are recognized by the patient monitoring network. The system is also cable of being set up to periodically forward a patient's physiological data at predetermined intervals.

The Spacelabs Medical ICS Clinical Event Interface (CEI), model 91847, system is a secondary alarm notification system. It does not replace the primary alarm function of the bedside monitor.

The provided text describes the Spacelabs Medical Clinical Event Interface (CEI), Model 91847, a software module designed to forward patient monitor alarm event information to a messaging and notification system for delivery to healthcare providers via wireless pagers.

Here's an analysis of the acceptance criteria and study information, based solely on the provided text:

1. Table of Acceptance Criteria and Reported Device Performance

The document does not explicitly state specific, quantifiable acceptance criteria (e.g., "alarm delivery must occur within X seconds with Y% reliability") or a table comparing them to reported device performance. It only mentions the expected typical performance.

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

The document does inform that the device "was validated through rigorous testing." However, it does not specify:

• The exact sample size used for the test set.
• The data provenance (e.g., country of origin of the data, retrospective or prospective).

3. Number of experts used to establish the ground truth for the test set and the qualifications of those experts

The document does not provide information on:

• The number of experts used to establish the ground truth for the test set.
• The qualifications of those experts.

4. Adjudication method for the test set

The document does not describe any adjudication method (e.g., 2+1, 3+1, none) used for the test set. The validation focused on the technical performance of the system in forwarding alarms.

5. Multi-reader multi-case (MRMC) comparative effectiveness study

The document does not mention a multi-reader multi-case (MRMC) comparative effectiveness study. The device is a "secondary alarm notification system" designed primarily for technical function (forwarding alarms to pagers), not for interpretation by human readers in a diagnostic setting that would typically involve MRMC studies.

6. Standalone (algorithm only without human-in-the-loop performance) study

A standalone study was conducted, focusing on the technical performance of the CEI software module and its interaction with off-the-shelf (OTS) components. The text states: "CEI was validated through rigorous testing that, in part, support the compliance of the CEI software module and its OTS components... The test program included all of the components of the system and verified that as data became available to CEI it was acquired and forwarded through to the pager." This indicates a focus on the automated system's performance in transmitting alarms.

7. The type of ground truth used

The "ground truth" in this context is the actual occurrence of an alarm event on the primary patient monitoring network and the subsequent successful and timely transmission of that information through the CEI system to the pager. The testing verified the system's ability to "acquire[] and forward[] through to the pager" data that "became available to CEI" from the patient monitoring network. This is essentially a functional verification against the real-time events generated by the patient monitors.

8. The sample size for the training set

The document does not specify a training set size. The CEI is a software module for forwarding existing alarm data, rather than a machine learning model that would typically require a training set. The validation described is more akin to system integration and functional testing.

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

As the CEI is not a machine learning model, the concept of a "training set" and establishing ground truth for it in the traditional sense is not applicable. The validation focused on the functional performance of the system in a controlled testing environment, where the "ground truth" would be the known and controlled generation of alarm events from the Spacelabs Patient Monitoring network.

Ask a specific question about this device

The Spacelabs Medical Bispectral Index (BISx) Analysis Module 91482 is intended for use under the direct supervision of a licensed healthcare practitioner or by personnel trained in its proper use. It is intended for use on adult and pediatric patients within a hospital or medical facility providing patient care to monitor the state of the brain by data acquisition of EEG signals.

The Spacelabs Medical Bispectral Index (BISx) Analysis Module 91482 may be used as an aid in monitoring the effects of certain anesthetic agents. Use of BIS monitoring to help guide anesthetic administration may be associated with the reduction of the incidence of awareness with recall in adults during general anesthesia and sedation.

The Spacelabs Medical Bispectral Index (BISx) Analysis Module 91482 (BISx Module 91482) is an easy-to-use, slim, single module in the Spacelabs Medical family of Spacelabs Medical Ultraview System (Ultraview) modules. The BISx Module 91482 is a microprocessor based, two-channel EEG unit designed for use on adult and pediatric patients within a hospital or medical facility. Its system configuration includes the BISx Module 91482 with connectors for external serial data connections, a BISx pod, a patient interface cable, disposable sensors, and printer options. The BISx pod, patient interface cable and disposable sensors are manufactured by Aspect Medical Systems, and distributed by Spacelabs Medical for use with the BISx Module 91482, The Spacelabs Medical Ultraview monitor provides the display capabilities for the care provider.

The provided text describes the Spacelabs Medical Bispectral Index (BISx) Analysis Module 91482, but it does not contain information about acceptance criteria or a study proving the device meets specific performance criteria.

The document is a 510(k) Premarket Notification summary focusing on the general safety and effectiveness, device description, and indications for use as part of the FDA approval process. It confirms substantial equivalence to existing devices but does not detail device performance studies or their results.

Therefore, I cannot populate the requested table or answer the specific questions about the study that proves the device meets acceptance criteria based solely on the provided text. The requested information, such as sample sizes, ground truth establishment, expert qualifications, and specific performance metrics, is not present in this document.

Ask a specific question about this device

The Spacelabs Medical Multigas Analyzer Module 91518 (Module 91518) is intended to provide a means of monitoring a variety of gas concentrations and to alert clinical personnel when the concentration of anesthetic agent, oxygen, carbon dioxide or nitrous oxide falls outside of user defined limits. The Module 91518 is capable of automatically identifying which anesthetic agent(s) is being administered.
The Module 91518 is intended to be used with, and is controlled by, any Spacelabs Medical monitor, except the SLP100.
The Module 91518 is intended for use monitoring all hospitalized patients under the direction of qualified medical personnel.
Although the Module 91518 alarms when the duration between breaths exceeds user defined limits, it is not intended to be a primary diagnostic apnea monitor and/or recording device.

The Spacelabs Medical Multigas Analyzer Module 91518 (Module 91518) is an easy-to-use modular unit in the Spacelabs Medical product family. The Module 91518 is a multigas sidestream analyzer intended to provide a measurement of the following parameters;

• CO2 produced by the patient;
• . O2 and N2O administered to the patient;
• Anesthetic agents administered to the patient which includes: .
  • Desflurane;
  • O Enflurane:
  • Halothane; O
  • lsoflurane; and O
  • Sevorflur-ane.
• . Respiratory rate of the patient; and
• Calculated MAC and age-dependent MAC values. .
  The Module 91518 automatically identifies which anesthetic agent or mixture of anesthetic agents is present, and measures the concentration of the identified agent(s). An alarm is issued if a mixture of more than two anesthetic agents is dctected.
  The Module 91518 interfaces with all Spacelabs Medical monitors, except the SLP100. The monitor provides a numeric display for the gas concentrations and respiratory rate, and a waveform display for O2 and CO2. The Module 91518 is intended to be used for monitoring all hospitalized patients under the direction of qualified medical personnel.

Here's an analysis of the provided text regarding the Spacelabs Medical Multigas Analyzer Module 91518 and its acceptance criteria and supporting study information:

Based on the provided text, the documentation does not contain the detailed information typically found in a clinical study report or a robust performance validation study with specific acceptance criteria and reported device performance metrics in a quantitative manner. Instead, this is a 510(k) Premarket Notification summary, which focuses on demonstrating substantial equivalence to predicate devices.

Therefore, many of the requested sections (1-9) cannot be fully answered with the provided information. I will provide the information that is available and highlight what is missing.

Description of Acceptance Criteria and Study to Prove Device Meets Acceptance Criteria

The provided K053599 510(k) Premarket Notification for the Spacelabs Medical Multigas Analyzer Module 91518 primarily establishes substantial equivalence to predicate devices rather than presenting a standalone validation study with explicit acceptance criteria and corresponding reported performance in a tabular format.

Key Finding: The submission relies on demonstrating that the Module 91518 is "substantially equivalent in design concepts, technologies and materials" to the predicate devices (Spacelabs Medical Module 90518 (K954962) and Date-Ohmeda Compact Airway Module E-CAIOVX (K051092)). The validation is described as "rigorous testing that, in part, support the compliance of the Module 91518 to the Standards mentioned in Section 6.1 of this submission." However, the details of these rigorous tests, the specific acceptance criteria (e.g., accuracy ranges for gas measurements, response times), and the numerical results are not included in this summary document.

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

Explanation: The document states that "rigorous testing" validated the device and supported compliance with "Standards mentioned in Section 6.1." Without access to Section 6.1 or the full submission, the specific acceptance criteria (e.g., accuracy, precision, response time for each gas) and the detailed results are not available in this summary. The primary "acceptance" from the FDA's perspective in a 510(k) is the determination of substantial equivalence.

2. Sample size used for the test set and the data provenance (e.g. country of origin of the data, retrospective or prospective)

• Sample Size for Test Set: Not specified in this summary document.
• Data Provenance: Not specified in this summary document. Given this is a device for measuring gas concentrations, the "test set" would likely refer to specific gas mixtures or simulated breath patterns used for calibration and validation testing in a laboratory or engineering environment, rather than human patient data in the context of a clinical trial. The testing is described as occurring during the "validation" phase, implying a prospective testing approach against known standards.

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)

• Number of Experts: Not applicable or not specified.
• Qualifications of Experts: Not applicable or not specified.

Explanation: For a multigas analyzer, the "ground truth" for gas concentrations would be established by validated scientific methods and calibrated reference instruments (e.g., mass spectrometers, certified gas mixtures). This is not typically an expert-driven "ground truth" like in imaging or diagnostic pathology.

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

• Adjudication Method: Not applicable or not specified.

Explanation: Adjudication methods are typically used when subjective interpretations are involved (e.g., by human readers in a clinical trial). For a performance test of a gas analyzer, results are compared against a known, objectively measured "ground truth" from reference equipment.

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

• MRMC Study: No.
• Effect Size: Not applicable.

Explanation: This device is a measurement instrument, not an AI-assisted diagnostic tool that would involve human readers interpreting results in an MRMC study.

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

• Standalone Performance: Yes, the device itself provides standalone measurements and alarms.

Explanation: The Module 91518 is a diagnostic/monitoring device that continuously measures gas concentrations and respiratory rate and identifies anesthetic agents. Its performance validation would inherently be a "standalone" assessment of its accuracy, precision, and response time in these measurements. It operates without direct human-in-the-loop interpretation of its core measurement functions, though clinical personnel use and interpret the displayed values and alarms.

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

• Type of Ground Truth: Calibrated reference gas mixtures and/or reference instruments.

Explanation: For a device measuring gas concentrations, ground truth is established using highly accurate and calibrated reference techniques and known, certified gas concentrations.

8. The sample size for the training set

• Sample Size for Training Set: Not applicable or not specified.

Explanation: This device is not described as using machine learning or AI in a way that would require a "training set" in the conventional sense (e.g., image data for AI model training). Its function is based on established physical and chemical principles of gas analysis. The "software" referred to in the summary would be traditional embedded software, not a machine learning model.

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

• How Ground Truth for Training Set was Established: Not applicable.

Explanation: As mentioned above, a "training set" as understood in machine learning is not implied by the provided summary. If any internal calibration or characterization data (sometimes loosely referred to as "training" in a broad engineering sense) was used, its ground truth would have been established through highly precise laboratory measurements using reference standards.

Ask a specific question about this device