(163 days)
The intended use of the ADMS software application is to:
Receive, aggregate, process, distribute and display physiologic waves, parameters, alarms and events at locations other than at the patient, for multiple patients.
Display visual alarm conditions as generated by a connected monitor.
Display of patient information can be real-time or historical record review.
Provide review and trend application data, designed to the screening of patient condition. All information or visual indications provided are intended to support the judgement of a medical professional and are not intended to be the sole source of information for decision making.
Provide connection to other systems not associated with active patient monitoring, such as information systems. The software performs the action to transfer, store, convert from one format to another according to preset specifications, or to display medical device data.
ADMS is intended for use in professional healthcare facilities, emergency medical applications, during transport, and other healthcare environments by trained healthcare professionals. ADMS Software is not intended for home use.
Indicated for use for specific patient populations (adult, pediatric, infant/neonate) depends on the indicated labeling of medical device(s) connected to ADMS providing the data.
The Athena GTX Device Management Suite (ADMS) is a software only device that manages patient data from compatible monitoring devices.
The Athena GTX Device Management Suite (ADMS) receives, distributes and displays physiologic waves, parameters and visual alarms at locations other than at the patient, for multiple patients. Data is generate by compatible connected devices and can be real-time or historical review.
The Athena GTX Device Management Suite provides a method of controlling ADMS compatible devices and viewing the device's data on Android devices (smartphones and tablets), iOS devices (smartphones and tablets) and on PCs running Windows OS.
The ADMS software receives data using Wi-Fi (802.11) from any Athena device within range. Whenever a device comes within range of ADMS, it will start receiving data from the device automatically. Commands to devices is transmitted via Wi-Fi (802.11) to the device. Each platform running ADMS can support viewing up to twenty (20) devices at one time.
The Athena GTX Device Management Suite (ADMS) consists of software only applications that do not come into physical contact with patients.
The Athena GTX Device Management Suite (ADMS) is a software-only device. The provided text, an FDA 510(k) summary, details the device's characteristics, comparison to predicate devices, and software verification and validation activities rather than a clinical study evaluating specific performance metrics against acceptance criteria. Therefore, several of the requested sections (sample size, data provenance, expert adjudication, MRMC study, ground truth, training set information) are not directly applicable or available in the provided document.
Here's an overview based on the available information:
1. A table of acceptance criteria and the reported device performance
The document does not explicitly present a table of quantitative acceptance criteria for device performance. Instead, it relies on demonstrating substantial equivalence to predicate devices through comparisons of technological characteristics and successful software verification and validation. The "reported device performance" is described qualitatively as meeting the intended use and being safe and effective due to these comparisons and testing.
| Acceptance Criteria (Inferred from Substantial Equivalence and V&V) | Reported Device Performance |
|---|---|
| Functional Equivalence to Predicates: | |
| Receive, aggregate, process, distribute, and display physiologic waves, parameters, alarms, and events. | ADMS performs these functions. |
| Display visual alarm conditions generated by connected monitors. | ADMS displays visual alarms. |
| Display real-time or historical patient information. | ADMS displays both. |
| Provide review and trend application data. | ADMS provides this. |
| Connect to other systems (e.g., information systems) for data transfer, storage, conversion, or display. | ADMS performs these actions, including HL7 interface to EMR. |
| Bi-directional communication with connected monitors (configuration, alarm limits, start/stop BP, find command). | ADMS supports this. |
| Safety and Effectiveness: | |
| Complies with FDA's Guidance for "moderate" level of concern software. | Software verification and validation testing were conducted and documentation provided as recommended. |
| Device functions as intended without unreasonable risks. | Results of safety, compliance, and non-clinical performance testing demonstrate substantial equivalence. |
| Not raising different questions of safety and effectiveness compared to predicates. | Differences from predicates (e.g., lack of ECG waveform analysis, visual-only alarms, PHI encryption) are presented as not raising new safety/effectiveness concerns or enhancing security. |
2. Sample size 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 "Software verification and validation testing," which typically involves various forms of testing (unit, integration, system, regression) but does not specify a "test set" in the context of clinical or performance data with associated sample sizes or data provenance.
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. The study described is not a clinical or performance study that would typically involve a ground truth established by medical experts.
4. Adjudication method (e.g. 2+1, 3+1, none) for the test set
This information is not provided in the document. As there is no clinical test set described requiring expert ground truth, adjudication methods are irrelevant here.
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, an MRMC comparative effectiveness study was not done. The document explicitly states: "Clinical Study Data [807.92(b)(2)]: None."
6. If a standalone (i.e. algorithm only without human-in-the-loop performance) was done
The document describes the "Athena GTX Device Management Suite (ADMS)" as a "software only device" that "receives, aggregates, processes, distributes and displays physiologic waves, parameters, alarms and events." It also states, "All information or visual indications provided are intended to support the judgement of a medical professional and are not intended to be the sole source of information for decision making." This indicates that ADMS is designed to operate as a standalone algorithm in terms of data processing and display, but its output is intended for human-in-the-loop evaluation. However, the "standalone performance" in the context of diagnostic accuracy (which is not the primary function of this device) was not explicitly tested or reported in the context of classifying patient conditions. The core function is data management and display.
7. The type of ground truth used (expert consensus, pathology, outcomes data, etc.)
Given that no clinical validation study is described, no ground truth from "expert consensus, pathology, outcomes data" was used. The ground truth for the software verification and validation would be based on expected system behavior and output specifications.
8. The sample size for the training set
This information is not provided in the document. This device is a data management and display software, not an AI/ML algorithm that typically requires a 'training set' in the traditional sense for diagnostic or predictive tasks. The software is developed based on specifications and programming logic.
9. How the ground truth for the training set was established
This information is not provided in the document. As mentioned, the concept of a 'training set' for this type of software is not applicable in the context of AI/ML model training described here. The "ground truth" for software development and testing would be defined by the design specifications and functional requirements.
§ 870.2300 Cardiac monitor (including cardiotachometer and rate alarm).
(a)
Identification. A cardiac monitor (including cardiotachometer and rate alarm) is a device used to measure the heart rate from an analog signal produced by an electrocardiograph, vectorcardiograph, or blood pressure monitor. This device may sound an alarm when the heart rate falls outside preset upper and lower limits.(b)
Classification. Class II (performance standards).