Search Results

Capsule Surveillance is a clinical decision support device that integrates, analyzes, and displays data from multiple sources including medical devices and healthcare information systems. It uses standardized rules that are based on customers approved clinical protocols, and policies to create clinically relevant alerts in health care facilities when used by clinical physicians or appropriate medical staff under the direction of physicians. It is not intended to replace clinicians' judgment, but rather to assist clinicians in making timely, informed, higher quality decisions. Capsule Surveillance may be configured for secondary monitoring and alerting intended to be relied upon in deciding to take immediate clinical action. Capsule Surveillance may also be configured for remote display of physiological data and alerts not intended to be relied upon in deciding to take immediate clinical action.

The Capsule Surveillance System is a clinical decision support device that integrates data from multiple sources including medical devices and healthcare information systems. The Capsule Surveillance Systems offers two methods of accessing the clinical application: . A workstation which is a dedicated desktop used exclusively to run the Capsule Surveillance System clinical application in kiosk mode. . The remote display which is any machine that accesses the Capsule Surveillance System via a web browser. Use of the Capsule Surveillance System allows for simultaneous monitoring of different patients in a clinical setting, providing information from integrated data sources that monitor physiological parameters such as, pulse, respiratory rate, SpO2, temperature, and blood pressure.

I am sorry, but the provided text does not contain specific details regarding acceptance criteria for a device, nor does it describe a study that proves a device meets those criteria with the requested information (table of acceptance criteria and reported performance, sample sizes, data provenance, expert ground truth establishment, adjudication methods, MRMC studies, standalone performance, type of ground truth, training set sample size, and ground truth establishment for the training set).

The document is a 510(k) premarket notification letter from the FDA, confirming the substantial equivalence of the "Capsule Surveillance System" to a predicate device. It primarily focuses on regulatory approval based on similarities to existing devices, harmonized standards compliance, and non-clinical bench testing.

Specifically:

• There is no table of acceptance criteria or reported device performance metrics in the provided text.
• The document states "No new issues of safety or effectiveness are introduced as a result of using this device" and "The Capsule Surveillance System, like the predicate device, did not require clinical trials." This indicates that a clinical study to prove performance against specific acceptance criteria, as in the context of an AI/ML device relying on diagnostic accuracy metrics, was not performed or required for this device's 510(k) clearance.
• The document mentions "Human factors and usability testing has been completed" and "verification and validation, software validation, usability validation, and risk management activities have taken place," but it does not provide the detailed results, sample sizes, or methodologies for these tests in the format requested.
• It does not discuss the use of experts for ground truth establishment, adjudication methods, MRMC studies, standalone algorithm performance, or details about training sets, as these are typically relevant for AI/ML-based diagnostic devices, which this system, described as a "clinical decision support device" and "physiological monitor," doesn't appear to be in the context of this submission. The device integrates, analyzes, and displays data from other medical devices and healthcare systems to create alerts, based on customer-approved clinical protocols, rather than autonomously diagnosing.

Ask a specific question about this device

The intended use of Critical Alert CommonPath Enterprise is to provide an interface with clinical systems to forward information associated to the particular event to the designated display device(s).

For medical, near real time alarms, Critical Alert CommonPath Enterprise is intended to serve as a parallel, redundant, forwarding mechanism to inform healthcare professionals of particular medical related events. Critical Alert CommonPath Enterprise does not alter the behavior of the primary medical devices and associated alarm annunciations. The display device provides a visual, and/or audible and/or vibrating mechanism upon receipt of the alert.

Critical Alert CommonPath Enterprise is intended for use as a secondary alert. It does not replace the alarm function on the primary device.

Critical Alert CommonPath Enterprise (CommonPath) is a software application installed on a Windows server environment capable of acquiring alarms, events, and parameters from clinical systems and intelligently forwarding this information as notifications to designated display devices provided by third-party mobile device companies.

Critical Alert CommonPath Enterprise is intended for use as a secondary alarm; it does not replace the alarm function on the primary device.

Users receive interactive, time-critical information from clinical systems directly via their display devices as text (visual) or alarms (audible) or data. Received attributes related to the presentation of alerts include text and tones (beeps) in addition to and in coordination with event priorities. CommonPath allows users to be aware of their patients' status and alarm conditions when they are away from the patient and patient monitoring system.

CommonPath connects to the information sources through wired ethernet connections which are part of the customer's infrastructure and acquires patient data from clinical systems. The user configures CommonPath to determine which information, including alarm notifications, is delivered to which users. CommonPath then formats the data for wireless delivery to the display devices through a messaging server.

The provided text describes a 510(k) premarket notification for a medical device called "Critical Alert CommonPath Enterprise." This documentation is primarily a regulatory submission aiming to demonstrate substantial equivalence to a legally marketed predicate device rather than presenting a performance study with detailed acceptance criteria and the results of a clinical trial or large-scale validation study in the way one might for an AI/ML diagnostic device.

The "acceptance criteria" and "device performance" in this context refer to the device meeting its specified functional requirements and regulatory standards rather than statistical performance metrics of an AI algorithm (e.g., sensitivity, specificity, AUC).

Here's an analysis based on the provided text:

1. Table of Acceptance Criteria and Reported Device Performance

The acceptance criteria are implied by the device's intended use and the regulatory standards it aims to comply with. The "performance" is stated as compliance with these standards and internal requirements.

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

This document does not describe a "test set" in the context of an AI/ML model where a specific number of cases are evaluated for accuracy. Instead, the testing appears to be functional and performance testing of a software system. The "sample size" would refer to the various configurations, alarm types, and system loads tested to ensure functionality and performance. Specific numbers of test scenarios or user types are not provided.

• Data Provenance: Not applicable in the context of clinical data for AI/ML validation. The "data" here are system events, alarms, and configurations generated or simulated during software testing. There is no mention of country of origin or retrospective/prospective clinical data for evaluation.

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

Not applicable. This is not an AI diagnostic device requiring expert interpretation for ground truth establishment. The ground truth for this device is its defined functional specifications and compliance with regulatory standards.

4. Adjudication Method for the Test Set

Not applicable. There's no subjective interpretation requiring adjudication.

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

Not applicable. This device is a communication and alarm forwarding system, not an image-based diagnostic AI. It does not involve human readers interpreting cases with or without AI assistance.

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

The device is inherently a "standalone" software system in that it processes and forwards information automatically. Its performance is evaluated on its ability to correctly interface, process, and forward alarms based on predefined rules, not on diagnostic accuracy of an AI algorithm. So, while it's "algorithm only" in its core function, it's not "standalone" in the typical AI diagnostic sense where it would produce a diagnostic output without human review. Its function is to inform humans.

7. The Type of Ground Truth Used

The "ground truth" for this device's validation is its functional specification, software requirements, and compliance with relevant medical device standards (e.g., IEC 60601-1-8 for alarm systems, IEC 62366-1 for usability). The testing verifies that the device adheres to these defined specifications and performance benchmarks (e.g., processing speed, number of supported connections, correct routing of alarms), and that these meet or exceed the predicate device's capabilities.

8. The Sample Size for the Training Set

Not applicable. This is not an AI/ML device that requires a "training set" of data to learn patterns or make predictions. It is a communication system with programmed logic and rules.

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

Not applicable, as there is no training set for an AI/ML model. The "ground truth" for its development would be its functional design specifications and clinical needs defined by engineers and medical professionals involved in its design.

Ask a specific question about this device

The intended use of the Digistat Smart Central is to provide an interface with clinical systems to forward information associated to the particular event from patient monitors, ventilators, and infusion pumps to the designated display device(s). For medical, near real time alarms, the Digistat Smart Central is intended to serve as a parallel, redundant, forwarding mechanism to inform healthcare professionals of particular medical related events. The Digistat Smart Central does not alter the behavior of the primary medical devices and associated alarm annunciations. The display device provides a visual, and/or audio and/or vibrating mechanism upon receipt of the alert.

The Digistat Smart Central is intended for use as a secondary alarm. It does not replace the primary alarm function on the medical devices.

Digistat Smart Central is an on-site integration solution which forwards medical device status and alarm information to the user via display devices provided by Ascom or third-party companies. Users receive, time-critical information from connected medical devices directly via their display devices as text, alarms or data. Digistat Smart Central allows users to be aware of their patients' status and alarm conditions when they are away from the patient and associated medical devices.

Digistat Smart Central connects to the information sources through wired ethernet connections which are part of the customer's infrastructure. Digistat Smart Central software acquires patient data and information through DIGISTAT Connect, a MDDS, from medical devices including patient monitors, ventilators, and infusion pumps. The user configures Digistat Smart Central to determine which information, including alarm notifications, is delivered to which users. Digistat Smart Central then formats the data for delivery to the display devices.

Digistat Smart Central is not in contact with the patient. It is intended to forward the information generated by the connected medical devices and systems and it does not generate patient related alarms. As such, the patient population and patient conditions are established by the medical devices and systems to which the product is connected.

This document, a 510(k) Premarket Notification for the Digistat Smart Central, primarily focuses on demonstrating substantial equivalence to predicate devices rather than proving a device meets specific performance acceptance criteria for an AI/ML algorithm. The product described is a medical device integration solution that forwards information and alarms, not an AI/ML diagnostic or predictive algorithm.

Therefore, many of the requested elements pertaining to AI/ML model validation (e.g., sample size for test/training sets, ground truth establishment by experts, MRMC studies, standalone performance) are not applicable or detailed in this document. The document outlines performance testing more generally related to software development, cybersecurity, and usability engineering, rather than clinical performance metrics typical for AI/ML algorithms.

Here's an attempt to answer the questions based on the provided text, highlighting where information is not present due to the nature of the device:

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

The document does not explicitly present a table of quantitative acceptance criteria for performance metrics (like sensitivity, specificity, accuracy) akin to AI/ML device validation. Instead, the "Summary of Performance Testing" section indicates that the device's software and benchmark performance were verified and validated against:

• Software Standards/Guidance:

  • FDA guidance: "The content of premarket submissions for software contained in medical devices, 11 May 05."
  • FDA guidance: "Off-the-shelf software use in medical devices, 09 Sep 99."
  • FDA guidance: "General principles of software validation; Final guidance for industry and FDA staff, 11 Jan 02."
  • FDA guidance: "Content of premarket submissions for management of cybersecurity in medical devices, 02 Oct 14."
  • "Cybersecurity for Networked Medical Devices Containing Off-The-Shelf (OTS) software, 14 Jan 05."
  • "Design Considerations and Premarket Submission Recommendations for Interoperable Medical Devices, 06 Sep 17."
  • IEC 62304: 2006, "Medical device software - Software life cycle processes."

• Performance Testing – Bench (Usability):

  • IEC 62366-1: 2015, "Medical devices – Application of usability engineering to medical devices."

Reported Device Performance:

The document states:

• "Test results indicate that the Digistat Smart Central software complies with its predetermined specifications and the applicable guidance documents."
• "Test results indicate that the Digistat Smart Central complies with its predetermined specifications and the applicable standards."
• "The results of these activities demonstrate that the Digistat Smart Central is performs as well as the predicate devices."

This indicates qualitative confirmation of meeting specifications and standards rather than specific quantitative performance numbers (e.g., latency, throughput, error rates) that would typically be associated with performance acceptance criteria for an AI/ML device. The "acceptance criteria" here are compliance with software and usability standards, and the "performance" is that it did comply.

2. Sample sizes 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. As the device is a data forwarding system and not an AI/ML diagnostic tool, there's no mention of "test sets" in the context of patient data or clinical images/signals for AI/ML model evaluation. The "tests" mentioned are verification and validation of software and usability, which don't typically involve "sample sizes" of clinical data to the same extent an AI/ML model would.

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 applicable/provided. The device does not generate diagnostic interpretations or predictions that would require expert-established ground truth for performance evaluation in the context of AI/ML.

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

This information is not applicable/provided. Adjudication methods are used in studies involving human interpretation or uncertain ground truth, which is not the primary focus for a data forwarding device like Digistat Smart Central.

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 information is not applicable/provided. MRMC studies are typically done for AI/ML devices that assist human interpretation (e.g., radiologists reading scans with vs. without AI assistance). The Digistat Smart Central is a messaging system, not an AI-assisted diagnostic tool.

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

This information is not applicable/provided. The device is a "Smart Central" system that forwards information; its "performance" is its ability to reliably forward data and alarms, not to make a standalone diagnosis or prediction.

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

This information is not applicable/provided. Ground truth, in the AI/ML sense, is not relevant for the type of device (data forwarding system) described in this document. The "truth" for this device would be whether the data was forwarded accurately and in a timely manner, which would be verified through system testing rather than clinical ground truth labels.

8. The sample size for the training set

This information is not applicable/provided. The Digistat Smart Central is not described as an AI/ML algorithm that requires a training set. Its "software" is rigorously engineered and verified/validated against specifications and standards, not "trained" on a dataset.

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

This information is not applicable/provided. As the device is not an AI/ML algorithm requiring a training set, the concept of "ground truth for the training set" does not apply.

Ask a specific question about this device

The Intelesens Aingeal Activity is used to monitor and transmit physiological data to a remote application for display or analysis by a clinician. The device can be worn by ambulatory or non-ambulatory adult patients in a healthcare environment to support clinical staff when they are carrying out their routine observations or when a patient would otherwise be in an unmonitored or unobserved situation.

This re-usable device is intended to be used on the patient for short term periods only. The device is intended to be used on adult patients for monitoring of ECG, respiration, heart rate, skin temperature and activity levels in a healthcare setting.

The device can be used where information on ECG, respiration, heart rate, skin temperature, and activity levels would be useful.

The device uses on-board ECG arrhythmia detection algorithms to automatically record and send ECG data if the user is suspected to be experiencing an arrhythmia event. The device also detects and records respiration, skin temperature and activity. The device transmits the data to the remote application at user defined intervals or upon the detection of an arrhythmia event (arrhythmia or threshold breach).

The Aingeal Activity System is a modification of the Intelesens Aingeal (VS200) 510(k) cleared under 510(k) K110015. Details of the modifications can be found in Section 11.

The Aingeal Activity system includes the following components:

• Aingeal Activity Monitor a wireless (Wi-Fi) monitoring device with a rechargeable lithium polymer battery
• Adherent electrode array
• Battery charger
• Compatible monitoring software such as CPC Bernoulli (FDA 510(k) clearance # K130208)

The Aingeal Activity device is battery powered. The battery is removed from the device prior to charging in the standalone battery charger station. Charging does not occur when the Aingeal Activity device is connected to a patient. Aingeal Activity is a reusable, nonsterile device to be used with a single use disposable electrode.

The battery is charged in a separate charger, charging does not / cannot occur when the Aingeal Activity Device is connected to a patient

The Aingeal Activity monitor clips on the adherent electrode array and is worn on-body. In conjunction with the array it collects, stores and transmits user physiological data. The electrode array and device, when enabled and applied to the user's torso will measure ECG, heart rate, respiration rate, skin temperature and activity levels with on board software algorithms. This data is transmitted periodically to the compatible third party server for display such as the CPC Bernoulli software (server). ECG signals recorded by the electrode array and device will also be transmitted on a heart rate trigger basis with thresholds adjustable by the user, or arrhythmia. Respiration signals recorded by the electrode array and device will also be transmitted on a respiration rate trigger basis with thresholds adjustable by the user. Skin temperature is recorded by the electrode array and device will also be transmitted on a temperature level trigger basis with thresholds adjustable by the user. The ECG, respiration signals, skin temperature value and activity metrics are also transmitted periodically and can be displayed via the server.

The device also contains on-board ECG arrhythmia recognition to automatically record and send ECG data on detection of one or more of the following arrhythmias:

• 1. asystole,
• 2. ventricular fibrillation, (VF)
• 3. bradycardia
• tachycardia (Ventricular or Supraventricular 4.

The provided text describes the Intelesens Aingeal Activity System, which is a physiological patient monitor, and its 510(k) submission to the FDA. The document primarily focuses on establishing substantial equivalence to a predicate device (Intelesens Aingeal (VS-200) K110015).

Based on the provided information, the device is considered a physiological patient monitor with on-board ECG arrhythmia detection algorithms. However, the document does not contain the detailed acceptance criteria for the arrhythmia detection algorithm's performance, nor does it present the study results for proving these criteria.

Instead, the document emphasizes bench testing and compliance with various electrical safety and performance standards. It explicitly states:

• "No human clinical testing was performed" (page 10).
• "No animal testing was performed" (page 10).

Therefore, I cannot fulfill the request to provide a table of acceptance criteria and reported device performance for the arrhythmia detection algorithm's accuracy, as this specific information is not present in the provided text. The document focuses on regulatory compliance and substantial equivalence based on design, technology, and general performance specifications, not on a detailed clinical performance study of the arrhythmia detection itself.

Here's an analysis of what can be extracted and what is missing:

Information Present:

• Device Name: Aingeal Activity System
• Intended Use: Monitoring and transmitting physiological data (ECG, respiration, heart rate, skin temperature, activity levels) to a remote application for display or analysis by a clinician. It has on-board ECG arrhythmia detection algorithms to automatically record and send ECG data if arrhythmia is suspected.
• Detected Arrhythmias (on-board): Asystole, ventricular fibrillation (VF), bradycardia, tachycardia (Ventricular or Supraventricular).
• Predicate Device: Intelesens Aingeal (VS-200) K110015.
• Type of Testing: Bench testing for compliance with various standards (e.g., AAMI/ANSI ES60601-1, IEC 60601-2-27, AAMI EC 57 for cardiac rhythm and ST-segment measurement algorithms).
• Ground Truth for Manufacturing/Bench Testing: Compliance with standards indicates that the device was tested against simulated or standardized signals with known characteristics.
• Test Set Data Provenance (for bench): Not explicitly stated, but implied to be generated in a lab setting to meet standard requirements.
• Training Set Sample Size/Ground Truth: Not mentioned.

Information NOT Present (and thus, cannot be provided as requested):

1. A table of acceptance criteria and the reported device performance for arrhythmia detection: The document lists standards like AAMI EC 57:2012 ("Testing and reporting performance results of cardiac rhythm and ST-segment measurement algorithms"), indicating that performance aspects related to arrhythmia detection were considered during bench testing. However, the specific quantitative acceptance criteria (e.g., sensitivity, specificity, accuracy for each arrhythmia type) and the actual numerical results achieved by the device are not provided in this summary.
2. Sample size used for the test set and data provenance (e.g., country of origin of the data, retrospective or prospective) for arrhythmia detection: Since no human clinical testing was performed, there's no clinical test set in the traditional sense for arrhythmia detection performance. Bench testing would use test signals/databases, but their size and origin are not detailed.
3. Number of experts used to establish the ground truth for the test set and their qualifications: Not applicable, as no human clinical testing or expert ground-truthing on a patient test set was conducted for algorithm performance.
4. Adjudication method: Not applicable.
5. MRMC comparative effectiveness study: Not conducted or reported.
6. Stand-alone (algorithm only without human-in-the-loop performance) study: While the device has on-board algorithms, the document does not detail a specific study demonstrating the performance metrics of these algorithms against defined ground truth, beyond stating compliance with standards.
7. The type of ground truth used (expert consensus, pathology, outcomes data, etc.) for assessing arrhythmia detection: For the "on-board ECG arrhythmia detection algorithms," the ground truth for the bench testing would likely be standardized ECG waveforms or databases that include known arrhythmias, used to verify compliance with standards like AAMI EC 57. However, no details on such a dataset are provided.
8. The sample size for the training set: Not mentioned in this document.
9. How the ground truth for the training set was established: Not mentioned in this document.

In summary, this 510(k) pertains to a device whose arrhythmia detection capabilities are primarily validated through bench testing against recognized industry standards (e.g., AAMI EC 57), rather than through a human clinical performance study with defined performance metrics for arrhythmia detection. The document asserts "substantial equivalence" based on design, technology, specifications, and compliance with various safety and performance standards for medical electrical equipment.

Ask a specific question about this device