(90 days)
The HyperVue Software is intended to be used only with compatible HyperVue Imaging Systems and Starlight Imaging Catheter.
The HyperVue Imaging System is intended for the imaging of coronary arteries and is indicated in patients who are candidates for transluminal interventional procedures.
The Starlight Imaging Catheter is intended for use in vessels 2.0 to 5.2 mm in diameter.
The Starlight Imaging Catheter is not intended for use in a target vessel which has undergone a previous bypass procedure.
The NIRS capability of the HyperVue Imaging System is intended for the detection of lipid core containing plaques of interest.
The NIRS capability of the HyperVue Imaging System is intended for the assessment of coronary artery lipid core burden.
The NIRS capability of the HyperVue Imaging System is intended for the identification of patients and plaques at increased risk of major adverse cardiac events.
The HyperVue Software (2.0) is resident on the HyperVue Imaging System (K230691) and is used with the Starlight Imaging Catheter (K243016). The HyperVue Software provides a user interface for executing clinical workflows, acquiring and processing OCT-NIRS data, and exporting patient data. The software update introduces the ability to connect to hospital PACS servers for data export.
The provided FDA 510(k) clearance letter for the HyperVue™ Software primarily focuses on demonstrating substantial equivalence to a predicate device based on technological characteristics and general software verification and validation. It does not contain detailed information regarding clinical performance studies (e.g., MRMC studies, standalone performance), specific acceptance criteria, or the methodology for establishing ground truth for medical image analysis tasks, especially related to the NIRS capabilities like plaque assessment.
The text states that the software update "introduces the ability to connect to hospital PACS servers for data export" and discusses "historical software and algorithm changes." However, it does not provide specifics on how these "historical algorithm changes" were validated in terms of clinical performance metrics that would typically be included in an AI/ML medical device submission.
Based on the provided document, here's what can be extracted and what is missing:
Acceptance Criteria and Device Performance
The document does not provide a specific table of acceptance criteria for clinical performance (e.g., sensitivity, specificity, accuracy) or reported device performance metrics related to diagnostic tasks (like lipid core detection or plaque assessment). The performance data section focuses on software engineering aspects (verification, validation, cybersecurity, and adherence to design controls) rather than clinical accuracy or effectiveness.
Table of Acceptance Criteria and Reported Device Performance (Based only on available information)
| Acceptance Criteria Category | Specific Criteria (Expected but not found in document) | Reported Device Performance (Not quantified in document) |
|---|---|---|
| Software Functionality | All functions performed by the software are evaluated and passed. | Passed all pre-determined acceptance criteria identified in the test plan. |
| Design Control Compliance | Verification and validation testing completed per company's Design Control process (21 CFR Part 820.30) and FDA guidance for software. | Verification and validation testing completed in accordance with the company's Design Control process in compliance with 21 CFR Part 820.30 and FDA "Guidance on Software Contained in Medical Devices". |
| Cybersecurity | Static Code Analysis, Vulnerability Scanning, Penetration Testing, Security Controls verified, Interoperability Assessment, Risk Analysis & Mitigation. | Performed as per FDA guidance "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions." Risks analyzed and satisfactorily mitigated. |
| Clinical Performance (e.g., for NIRS capability) | Not specified in the document (e.g., sensitivity, specificity, AUC for lipid core detection) | Not reported in the document. |
Study Details (Based only on available information, with many points missing)
-
Sample sizes used for the test set and data provenance:
- Test Set Sample Size: Not specified. The document mentions "an established test plan that fully evaluated all functions performed by the software," but it does not specify the number of cases or patients used for performance testing, especially not for clinical performance.
- Data Provenance: Not specified. There is no mention of the country of origin of data or whether it was retrospective or prospective. The testing described appears to be primarily software-level functional and cybersecurity testing rather than a clinical performance study.
-
Number of experts used to establish the ground truth for the test set and the qualifications of those experts:
- Not specified. The document does not describe the establishment of a clinical ground truth, suggesting that the primary validation for this 510(k) was based on software engineering and safety, not on a new clinical performance claim requiring expert ground truth.
-
Adjudication method (e.g., 2+1, 3+1, none) for the test set:
- Not specified. Since a clinical performance study with expert ground truth establishment is not detailed, adjudication methods are not mentioned.
-
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 is mentioned or implied. The submission emphasizes substantial equivalence based on technological characteristics and software updates rather than a new clinical claim supported by a reader study.
-
If a standalone (i.e., algorithm only without human-in-the-loop performance) was done:
- Not explicitly stated in terms of clinical performance metrics. The document claims that the software "processes reflected optical signals to construct images" and makes "mathematical comparisons of image data." However, it does not provide standalone performance metrics (e.g., sensitivity/specificity for lipid plaque detection) for these algorithmic functions. The clearance is for the software (2.0) that is resident on the imaging system, implying it's part of the overall system that assists physicians, but no specific standalone diagnostic performance is reported.
-
The type of ground truth used (expert consensus, pathology, outcomes data, etc.):
- Not specified for clinical claims. For the "software functions," ground truth would likely be based on technical specifications and expected software behavior. For the NIRS capabilities (lipid core detection, plaque assessment), the method for establishing ground truth for performance evaluation is not described in this document. This suggests that the current 510(k) submission did not hinge on a new clinical efficacy claim for these NIRS functionalities that would require a new, robust clinical study with defined ground truth. Instead, it seems to rely on the predicate device's existing clearance for these capabilities.
-
The sample size for the training set:
- Not specified. The document does not discuss any machine learning model training or associated training sets. The primary focus of this 510(k) is a software update (version 2.0) mainly involving PACS connectivity and "historical" algorithm changes, which doesn't necessarily imply retraining a new ML model that would require a dedicated training set description in this context.
-
How the ground truth for the training set was established:
- Not applicable/Not specified. Since a training set is not mentioned, the method for establishing its ground truth is also not.
Summary of Gaps:
The provided FDA 510(k) clearance letter is for a software update (HyperVue™ Software 2.0) that appears to be primarily a software modification/upgrade (PACS connectivity, historical algorithm changes) to an existing cleared device. As such, the submission focuses heavily on software engineering verification and validation, cybersecurity, and demonstrating substantial equivalence to the predicate device based on technological characteristics and intended use.
It does not contain the detailed clinical performance study information (e.g., specific acceptance criteria for diagnostic performance, quantitative performance metrics, sample sizes for clinical test sets, expert qualifications, ground truth methodology for clinical data) that would typically be seen for a novel AI/ML device making new clinical claims or demonstrating significantly improved diagnostic performance. The NIRS capabilities listed appear to be carried over from the predicate device's clearance.
Therefore, for aspects related to clinical accuracy and effectiveness of features like "detection of lipid core containing plaques," this document does not provide the specific study details you requested.
§ 892.1560 Ultrasonic pulsed echo imaging system.
(a)
Identification. An ultrasonic pulsed echo imaging system is a device intended to project a pulsed sound beam into body tissue to determine the depth or location of the tissue interfaces and to measure the duration of an acoustic pulse from the transmitter to the tissue interface and back to the receiver. This generic type of device may include signal analysis and display equipment, patient and equipment supports, component parts, and accessories.(b)
Classification. Class II (special controls). A biopsy needle guide kit intended for use with an ultrasonic pulsed echo imaging system only is exempt from the premarket notification procedures in subpart E of part 807 of this chapter subject to the limitations in § 892.9.