Search Results

The Avalon CL Fetal & Maternal (F&M) Pod & Patch is a device indicated for use by healthcare professionals in a clinical setting for non-invasive monitoring of maternal heart rate (aHR), fetal heart rate (aFHR), and uterine activity (aToco) in women who are at >36 completed weeks, in labor, with singleton pregnancy, using surface electrodes on the maternal abdomen.

The Avalon CL Fetal & Maternal (F&M) Pod and the Avalon CL Fetal & Maternal (F&M) Patch is a beltless battery-powered maternal-fetal monitoring system that non-invasively measures abdominal fetal heart rate (aFHR), abdominal uterine activity (aToco), and abdominal maternal heart rate (aHR). The Avalon CL Fetal & Maternal (F&M) Patch is a single-use disposable adhesive electrode patch designed to be affixed to the maternal abdomen. The Avalon CL Fetal & Maternal (F&M) Pod is a reusable device which, when connected to the Avalon CL Fetal & Maternal (F&M) Patch, picks up electrical signals and converts it to Short Range Radio (SRR). The Avalon CL Fetal & Maternal Pod communicates the data measurement values to the Avalon CL Base Station using Short-Range Radio (SRR). The Avalon CL Base Station in turn relays the information to the connected Philips Fetal-Maternal (FM) Monitor (i.e., FM20, FM30, FM40, and FM50).

The provided FDA 510(k) summary for the Philips Avalon CL Fetal & Maternal (F&M) Pod & Patch focuses heavily on demonstrating substantial equivalence to a predicate device through non-clinical testing and comparison of technical characteristics rather than a detailed clinical study report with specific acceptance criteria and performance metrics for the device's accuracy in monitoring FHR, MHR, and UA.

Therefore, much of the requested information regarding "acceptance criteria and the study that proves the device meets the acceptance criteria" in terms of clinical performance (e.g., accuracy, sensitivity, specificity, agreement with ground truth for FHR, MHR, and UA) is not explicitly detailed in this document. The document primarily discusses non-clinical tests for safety, electrical performance, and biocompatibility.

However, based on the information provided, here's what can be extracted and inferred:

1. Table of Acceptance Criteria and Reported Device Performance

The document does not provide a table with specific clinical performance acceptance criteria (e.g., accuracy ranges for FHR) and reported device performance from an effectiveness standpoint. Instead, it details non-clinical technical acceptance criteria related to safety, electrical performance, and biocompatibility, which the device met.

Regarding MHR/FHR/UA accuracy, the document states for "Performance Bench" that "MHR/FHR/UA accuracy after stored in room (23℃), high (32℃) and low (2-8℃) temperature" were conducted and "met the acceptance criteria as defined in the test requirements." However, the specific numerical acceptance criteria for accuracy (e.g., mean absolute difference, percentage agreement, etc.) and the reported numerical performance regarding MHR/FHR/UA accuracy are not provided in this summary. This suggests that these accuracy tests were likely bench tests under controlled conditions, not a clinical trial comparing device readings to a clinical ground truth.

2. Sample Size for Test Set and Data Provenance

The document does not explicitly mention a "test set" in the context of a clinical performance study with human subjects to evaluate the accuracy of FHR, MHR, and UA measurements. The in-vivo testing mentioned under "Performance Bench" refers only to "integrity, detachment/reattachment, and performance (impedance, noise level, MHR, conductivity) after shower and usage (8 hours/32 hours) for the patch (Novii Patch)." This does not sound like a large-scale clinical accuracy study.

Therefore, based on the provided text alone:

• Sample size for the test set: Not explicitly stated for clinical performance as commonly understood for device accuracy. The "in vivo testing" details are too limited to determine sample size or its direct relation to device accuracy claims.
• Data provenance: Not explicitly stated. The type of testing suggests it might be internal company testing rather than an independent clinical trial.

3. Number of Experts and Qualifications for Ground Truth

Given the lack of a detailed clinical performance study report, there is no information provided regarding the number or qualifications of experts used to establish ground truth for a clinical test set for FHR, MHR, or UA.

4. Adjudication Method

Again, due to the absence of a detailed clinical performance study, there is no information provided on any adjudication method (e.g., 2+1, 3+1) for a clinical test set.

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

No. The document does not mention a multi-reader multi-case (MRMC) comparative effectiveness study, nor does it discuss human readers or AI assistance in this context. This device appears to be a monitoring system for physiological parameters, not an AI-assisted diagnostic imaging or interpretation tool.

6. Standalone Performance

The device itself is a "standalone" monitoring system in the sense that it performs its measurements (aHR, aFHR, aToco) via its electrodes and pod, then relays this data to a Philips Fetal-Maternal (FM) Monitor for display. The performance tests ("Performance Bench") assess the device's ability to measure these parameters. However, the exact "standalone" clinical accuracy metrics (e.g., sensitivity, specificity, accuracy vs. a gold standard) are not provided. The phrase "standalone performance" is generally associated with diagnostic algorithms, which doesn't seem to be the primary claim here.

7. Type of Ground Truth Used

For the non-clinical performance "MHR/FHR/UA accuracy after stored in room (23℃), high (32℃) and low (2-8℃) temperature," the type of ground truth used is not specified. It likely refers to controlled laboratory measurements against calibrated reference standards, rather than clinical ground truth like pathology, expert consensus, or outcomes data. For clinical performance data (which is not detailed), common ground truths for FHR, MHR, and UA would be internal fetal monitoring (IUPC for UA, fetal scalp electrode for FHR) or expert interpretation of existing monitoring tracings (though this isn't mentioned).

8. Sample Size for the Training Set

No information is provided about a "training set." This term is typically associated with machine learning or AI algorithm development. While the device uses signal processing (template matching, filtering, confidence tagging) to identify fECG and mECG complexes, the document does not describe the development or training of such algorithms or any associated data sets used for this purpose.

9. How Ground Truth for the Training Set Was Established

As no training set is discussed, there is no information provided on how ground truth for a training set was established.

In summary, the provided FDA summary focuses on demonstrating substantial equivalence through technical and non-clinical performance and safety testing. It lacks detailed clinical performance data (e.g., accuracy, sensitivity, specificity) against a clinical ground truth, specific sample sizes for clinical evaluations, or information about expert consensus or adjudication methods for such clinical data, which are typically found in clinical study reports for devices claiming diagnostic or interpretative capabilities.

Ask a specific question about this device

The intended use of the MX40 is to:

The device is intended for monitoring and recording of and to generate alarms for, multiple physiological parameters of adults and pediatrics in a hospital environment and during patient transport inside hospitals. Not intended for home use. Intended for use by health care professionals.

Indications for Use

Indicated for use by health care professionals whenever there is a need for monitoring the physiological parameters of patients. Intended for monitoring and recording of, and to generate alarms for, multiple physiological parameters of adults and pediatrics in hospital environments and during transport inside hospitals.

Rx only.

The MX40 is a multi-parameter, battery operated patient monitor that is small enough to be worn by the patient. Its multi-radio design enables device operation within existing Philips telemetry networks while providing compatibility to the IntelliVue Information Center solutions. Along with infrastructure radios, the MX40 integrates a short-range radio (SRR), enabling wireless connectivity to the litelliVue family of monitors. Acquired physiological data, along with physiological alarms and technical alert information are provided to multiple monitoring systems (local, bedsides and /or information systems).

Previously cleared compatible Accessories are still in use, compatibility to additional Massimo accessories are documented in this filing. The MX40 is compatible with the legally marketed Philips CL SpO2 Pod and CL NBP Pod (K101600, K111905). The CL SpO2/NBP Pods are small battery powered devices that measure oxygen saturation, pulse rate and blood pressure, pulse rate, respectively. A list of all accessories is available in the Instructions for Use.

The provided text is a 510(k) summary for the Philips MX40 Release C.01, a physiological patient monitor. It describes the device, its intended use, and a comparison with a predicate device (Philips IntelliVue MX40 Release B.07).

However, this document does not contain the specific information required to answer your request regarding acceptance criteria and the study proving the device meets them.

The document states:

• "No performance standards have been issued under the authority of Section 514."
• "The MX40 Release C.01 was tested in accordance with Philips verification and validation processes."
• "Clinical Performance testing for MX40 Release C.01 was not performed, as there were no new clinical applications that had hazards or risk mitigations that required a clinical performance testing to support equivalence."
• "Verification, validation, and testing activities, where required to establish the performance, functionality, and reliability characteristics of the new device with respect to the predicate are performed. Testing involved system level tests, performance tests, and safety testing from hazard analysis. Pass/Fail criteria were based on the specifications cleared for the predicate device and test results showed substantial equivalence."

This indicates that the submission relies on demonstrating substantial equivalence to a predicate device through non-clinical testing (system level tests, performance tests, and safety testing based on hazard analysis) and adherence to Philips' internal verification and validation processes, rather than conducting a new clinical study with specific acceptance criteria as one might expect for a novel device or a device with new clinical applications.

Therefore, I cannot provide the requested information from this document for the following reasons:

1. A table of acceptance criteria and reported device performance: This document explicitly states that "No performance standards have been issued." While it mentions "Pass/Fail criteria were based on the specifications cleared for the predicate device," these specific criteria and the detailed performance results are not provided in this summary.
2. Sample size used for the test set and data provenance: The document mentions "non-clinical performance testing" and "system level tests, performance tests, and safety testing," but does not specify sample sizes or data provenance (e.g., number of patients, records, or the nature of the test data).
3. Number of experts used to establish ground truth and qualifications: This information would typically be relevant for clinical studies or studies establishing ground truth, which were not performed for this 510(k) as per the document.
4. Adjudication method for the test set: Not applicable as a clinical study for establishing ground truth was not performed.
5. Multi-reader multi-case (MRMC) comparative effectiveness study: The document clearly states, "Clinical Production testing for MX40 Release C.01 was not performed." Therefore, no MRMC study was conducted.
6. Standalone (algorithm only without human-in-the-loop performance) study: This would typically refer to AI/ML device performance. The MX40 is a physiological monitor, not an AI/ML algorithm in the context typically discussed for standalone performance. Its functions are monitoring and alarm generation for vital parameters. The document focuses on hardware, software, and accessory changes.
7. Type of ground truth used: Not explicitly stated, as clinical performance testing was not performed. The "ground truth" for the non-clinical testing would be the established specifications and expected performance of the predicate device.
8. Sample size for the training set: Not applicable, as this is not an AI/ML device requiring a training set in the typical sense.
9. How the ground truth for the training set was established: Not applicable.

In summary, the provided 510(k) pertains to a modification of an existing physiological monitor, and its acceptance criteria and proof of performance are based on demonstrating substantial equivalence through non-clinical verification and validation against the predicate device's established specifications, rather than a new clinical study with the type of data points you are requesting.

Ask a specific question about this device

The intended use of the MX40 is to: The device is intended for monitoring and recording of and to generate alarms for, multiple physiological parameters of adults and pediatrics in a hospital environment and during patient transport inside hospitals. Not intended for home use. Intended for use by health care professionals.

Indications for Use: Indicated for use by health care professionals whenever there is a need for monitoring the physiological parameters of patients. Intended for monitoring and recording of, and to generate alarms for, multiple physiological parameters of adults and pediatrics in hospital environments and during transport inside hospitals. Rx only.

The MX40 is a multi-parameter, battery operated patient monitor that is small enough to be worn by the patient. Its multi-radio design enables device operation within existing Philips telemetry networks while providing compatibility to the IntelliVue Information Center solutions. Along with infrastructure radios, the MX40 integrates a short-range radio (SRR), enabling wireless connectivity to the IntelliVue family of monitors. Acquired physiological data, along with physiological alarms and technical alert information are provided to multiple monitoring systems (local, bedsides and /or information systems).

The provided document is a 510(k) summary for the Philips MX40 Release B.07, a physiological patient monitor. It focuses on demonstrating substantial equivalence to a predicate device rather than presenting a study of its own performance against pre-defined acceptance criteria for a novel AI/software component within the device.

Therefore, many of the requested details about acceptance criteria, specific studies proving performance, sample sizes, ground truth establishment, expert involvement, and MRMC studies are not present in this document as it pertains to a modification of an existing device rather than a new device with new clinical claims. Manufacturers typically demonstrate substantial equivalence through verification and validation testing, often against established standards and internal specifications, rather than large-scale clinical trials for minor modifications.

Here's an attempt to answer the questions based on the available information:

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

The document does not provide a table of specific acceptance criteria (e.g., sensitivity, specificity thresholds) or quantitative device performance metrics. Instead, it states:

• Acceptance Criteria (Implied): "Pass/Fail criteria were based on the specifications cleared for the predicate device." (Page 8)
• Reported Device Performance: "test results showed substantial equivalence." (Page 8) and "The MX40 Release B.07 meets all defined reliability requirements and performance claims." (Page 8)

The document lists changes to functionalities, such as:

• Heart Rate Alarm from Pulse, requiring PIC IX version C.01 or higher.
• Auto report battery inop (Technical Alert) when Standby is in low battery state.
• Support CI (Connection Indication) message transport using Unicast protocol for WLAN.
• Malfunc Inop for software license failure - Added self-test to MX40 to allow for confirmation of Software License version to assist users to identify compatibility to other systems.
• Claim IEC60601-1 3rd edition update IFU and Product Labeling appropriately.
• AAMI screen - A new portrait screen 1-wave and 2 numerics to support AAMI EC13 display, local control only & cannot default to this screen from PIC-iX.
• MCS PigTail and Block Adapter hardware to support Respiration measurements.

The "reported device performance" is broadly stated as meeting the specifications of the predicate device.

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

This information is not provided in the document. The document refers to "system level tests, performance tests, and safety testing from hazard analysis" (Page 8), but does not specify sample sizes or data provenance for these non-clinical tests.

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 document, as clinical performance testing, which would typically involve expert ground truth, was not performed.

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

This information is not provided in the document.

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 mentioned or performed, as the device is a physiological monitor and not an AI-assisted diagnostic tool.

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

The document states that "Clinical Performance testing for MX40 Release B.07 was not performed, as there were no new clinical applications that had hazards or risk mitigations that required a clinical performance testing to support equivalence." (Page 8). Therefore, no standalone clinical performance study was done for this particular submission. The device itself is a standalone physiological monitor, but the nature of the submission (modifications to an existing device) did not necessitate a new standalone performance study against clinical ground truth.

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

For the non-clinical testing performed, the ground truth would have been based on established specifications, standards, and expected performance characteristics of the predicate device and the new functionalities, rather than clinical ground truth like pathology or expert consensus. The changes relate to hardware and software updates, not new diagnostic algorithms requiring clinical validation.

8. The sample size for the training set

This information is not applicable as the document does not describe the development or testing of an AI/machine learning algorithm with a training set. The device is a physiological monitor with specified functionalities.

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

This information is not applicable as there is no mention of an AI/machine learning component or a training set.

Ask a specific question about this device

IntelliVue Guardian Software:
The IntelliVue Guardian Software is indicated for use by healthcare providers whenever there is a need for generation of a patient record.
The IntelliVue Guardian Software is intended for use in the collection, storage and management of data from IntelliVue Cableless Measurements and IntelliVue Patient Monitors that are connected through networks.

IntelliVue CL SpO2 Pod:
The IntelliVue CL SpO2 Pod is indicated for use by health care professionals whenever there is a need for acquisition or monitoring of physiological patient parameters Sp02 and pulse rate wirelessly.
The intended use of the IntelliVue CL SpO2 Pod when used together with a patient monitor or with a telemetry system transceiver is for monitoring, recording, and alarming of arterial oxygen saturation and pulse rate of adult and pediatric patients.
The IntelliVue CL SpO2 Pod is also intended for acquisition of arterial oxyger saturation and pulse rate data of adult and pediatric patients for a clinical information management system.
The IntelliVue CL SpO2 Pod is intended for use by health care professionals inside hospitals. It is not intended for home use. It is not a therapeutic device.

IntelliVue CL NBP Pod:
The IntelliVue CL NBP Pod is indicated for use by health care professionals whenever there is a need for acquisition or monitoring of physiological patient parameters non-invasive blood pressure and pulse rate wirelessly.
The intended use of the IntelliVue CL NBP Pod when used together with a patient monitor or with a telemetry system transceiver is for monitoring, recording, and alarming of systolic, diastvlir, and mean pressure and pulse rate of adult and pediatric, patients.
The IntelliVue CL NBP Pod is also intended for acquisition of systolic, diastolic, and mean pressure and pulse rate data of adult and pediatric patients for a clinical information management system.
The IntelliVue CL NBP Pod is intended for use by health care professionals inside hospitals. It is not intended for home use. It is not a therapeutic device.

New IntelliVue Guardian Software:
The new IntelliVue Guardian Software is a Clinical Information Management System. It collects and manages vital signs data acquired from the IntelliVue Cableless Measurements and IntelliVue patient monitors. The Guardian Software provides trending, review, reporting, notification, clinical documentation, calculations, clinical advisories including EWS deterioration status, remote viewing and operating, interfacing, storage, and printing.
The IntelliVue Guardian Software is software only product intended to be installed on a customer supplied PC or Server.

Modified IntelliVue CL SpO2 Pod:
The IntelliVue CL SpO2 Pod is a small, battery powered, wrist worn pulse oximeter device. It contains Philips FAST-Sp02 (Fourier Artifact Suppression Technology) to provide reliable saturation values under various artifact conditions including motion and low perfusion. It provides continuous cperating mode and intermittent operating mode with configurable measuring me intervals. Integrated monochrome LCD display shows measured values, measurement signal quality, battery state, and RF signal strength. It has three hardkeys for basic operation and navigation. It supports specialized Philips reusable and disposable SpO2 sensors.
The IntelliVue CL Sp02 Pod remains unchanged as it is. The modification, which is subject of this Premarket Notification, is solely limited to the labeling change in order to indicate the usage of this device together with the new Philips IntelliVue Guardian Software.

Modified IntelliVue CL NBP Pod:
The IntelliVue CL NBP Pod is a small, battery powered, noninvasive blood pressure and pulse rate measurement device. It uses oscillometric method for measuring NBP. It produces numerics for systolic, diastolic and mean blood pressure values and pulse rate. Integrated monochrome LCD Display shows measured values, battery state, and RF signal strength. It has three hardkeys for basic operation and navigation. It supports specialized Philips reusable and disposable NBP cuffs.
The IntelliVue CL NBP Pod remains unchanged as it is. The modification, which is subject of this Premarket Notification, is limited to the labeling change in order to indicate the usage of this device together with the new Philips IntelliVue Guardian Software.

The provided 510(k) summary describes the IntelliVue Guardian Software and modified IntelliVue CL SpO2 Pod and CL NBP Pod. However, it does not contain the specific details required to fully address all aspects of your request regarding acceptance criteria and a detailed study proving the device meets those criteria.

Here's an analysis based on the available information:

1. Table of Acceptance Criteria and Reported Device Performance

The document broadly states that the device successfully met its specifications and performed reliably. Specific, quantifiable acceptance criteria (e.g., specific accuracy metrics for data collection, thresholds for system response times) and their corresponding reported performance values are not explicitly provided in this summary. The "performance" is described in general terms of functionality and clinical usefulness.

2. Sample Size for the Test Set and Data Provenance

The summary does not specify a sample size for any test set (e.g., number of patients, number of data points, or number of simulated scenarios).

Regarding data provenance:

• Country of Origin: Not specified.
• Retrospective/Prospective: Not specified for the performance tests, but the "Clinical Evaluation" implies prospective use in a clinical setting to assess usefulness and acceptance by users.

3. Number of Experts and Qualifications for Ground Truth

The summary mentions "clinical users" in the context of the "Clinical Evaluation" for user acceptance. However, it does not specify the number of experts, their qualifications (e.g., radiologists with X years of experience), or their role in establishing ground truth for any performance metrics. The ground truth for this device appears to be primarily related to system functionality and user acceptance, rather than a diagnostic output requiring expert consensus.

4. Adjudication Method

The summary does not mention any adjudication method (e.g., 2+1, 3+1, none) for the test set or for establishing ground truth.

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

The document does not indicate that a Multi-Reader Multi-Case (MRMC) comparative effectiveness study was done. The device is a Clinical Information Management System and cableless measurement pods, which are generally not subject to MRMC studies in the same way an AI-powered diagnostic tool would be. The focus is on data collection, management, and display.

6. Standalone Performance Study

The summary mentions "Non-Clinical Performance Tests (bench testing)" and "Functionality testing on the new IntelliVue Guardian Software," which imply standalone or algorithm-only evaluation of the software and its components. However, it does not provide specific metrics or results from such a standalone study beyond a general statement of "confirmed static and dynamic performance... according to the specifications."

7. Type of Ground Truth Used

The "ground truth" for the various tests appears to be established as follows:

• Non-Clinical Performance Tests: Adherence to "specifications" for static and dynamic performance. This likely refers to predefined technical requirements and expected system behavior.
• Clinical Evaluation: "Clinical usefulness" and "acceptance by the clinical users." This suggests a qualitative assessment based on user feedback and observation in a clinical setting.
• Functionality Testing: Verification against expected functional behavior of the software and hardware components.

There is no mention of pathology, expert consensus on diagnostic outcomes, or long-term outcomes data as ground truth, as these would typically apply to diagnostic or prognostic devices.

8. Sample Size for the Training Set

This document describes a clinical information management system and monitoring devices. It does not explicitly mention a training set in the context of machine learning or AI. The product is not presented as an AI/ML device that requires a training set in the conventional sense. The "IntelliVue Guardian Software" is described as a "Software only product," and its features like "Early Warning Scoring capability" sound like rules-based algorithms rather than learned models.

9. How Ground Truth for the Training Set Was Established

As no training set is explicitly mentioned for an AI/ML model, the question of how its ground truth was established is not applicable based on the provided text.

Ask a specific question about this device