(60 days)
The UHI-4 instrument is intended to insufflate the abdominal cavity, and provides automatic suction and smoke evacuation to facilitate laparoscopic observation, diagnosis and treatment.
This instrument is intended for controlled CO2 insufflation to create a cavity along the saphenous vein and/or radial artery to facilitate observation during an endoscopic vessel harvesting procedure.
This instrument is used to insufflate the colon to facilitate endoscopic observation, diagnosis and treatment.
The subject device, UHI-4, is intended to insufflate the abdominal cavity, and provides automatic suction and smoke evacuation to facilitate laparoscopic observation, diagnosis and treatment, and for controlled CO2 insufflation to create a cavity along the saphenous vein and/or radial artery to facilitate observation during an endoscopic vessel harvesting procedure. The subject device is also used to insufflate the colon to facilitate endoscopic observation, diagnosis and treatment.
The subject UHI-4 has the following system functions which are existing features/functions of the predicate device and are not new feature/function.
- Cavity mode
- Adjustment of the cavity pressure
- Adjustment of the gas flow rate
- Display mode
- Relief mode
- Smoke evacuation
- Automatic smoke evacuation
- Pressure sensor failure detection
- Excessive pressure alarm & alarm delay setting
The subject device has the same technological characteristics and design as the applicable predicate devices. There have been no modifications to the device hardware design including performance specifications and physical design requirements, materials, sterilization, shelf life, reprocessing, or packaging.
The only difference between the subject device and the predicate device is the device software, and there are modifications for two existing software functions: "Pressure sensor failure detection" and "Alarm delay setting".
This document is a 510(k) summary for the Olympus High Flow Insufflation Unit (UHI-4), seeking clearance for a software change. It is primarily a comparative analysis against a predicate device (K122180) and does not present a traditional study proving the device meets acceptance criteria through clinical or large-scale performance testing as one might expect for a novel AI/ML-based diagnostic device.
Therefore, many of the specific questions about acceptance criteria (in terms of performance metrics like sensitivity/specificity), sample size for test sets, expert involvement, and ground truth establishment are not applicable to this type of submission. The focus here is on demonstrating substantial equivalence, especially concerning a minor software modification, rather than a de novo performance validation study.
However, I can extract the information relevant to this specific K243527 submission based on the provided text, while indicating where information is not available or not applicable.
Acceptance Criteria and Device Performance (Based on Substantial Equivalence and Bench Testing)
Since this is a 510(k) for a software change to an existing device, the "acceptance criteria" here are primarily demonstrated through showing the new device maintains the same performance and safety characteristics as the predicate device, validated by bench testing focused on the changed functions.
Table of Acceptance Criteria and Reported Device Performance
| Feature/Test | Acceptance Criteria (Implied by Predicate Equivalence and Safety Focus) | Reported Device Performance (UHI-4 with software changes) |
|---|---|---|
| Indications for Use | Must be identical to the predicate device to maintain substantial equivalence. | Identical: For insufflating the abdominal cavity for laparoscopic observation, diagnosis, and treatment; controlled CO2 insufflation for endoscopic vessel harvesting; and insufflating the colon for endoscopic observation, diagnosis, and treatment. |
| Device Hardware Design | Must be identical to the predicate device. | Identical: No modifications to hardware, performance specifications, physical design, materials, sterilization, shelf life, or packaging. |
| Technological Characteristics | Must be substantially equivalent to the predicate. | Same as predicate: UHI-4 has existing features/functions of the predicate (Cavity mode, pressure/flow adjustment, display mode, relief mode, smoke evacuation, pressure sensor failure detection, excessive pressure alarm & delay setting). The only difference is software modification for "Pressure sensor failure detection" and "Alarm delay setting." |
| Overpressure Protection | Device must withstand pressure beyond its intended operating range without failure and maintain structural integrity. | Passed "Overpressure Testing": Confirmed ability to withstand pressure beyond intended range without failure, maintaining structural integrity, and posing no risks. |
| Tube Obstruction Management | Device must detect and appropriately manage blockages in the tubing system to prevent adverse events. | Passed "Tube Obstruction Testing": Verified ability to identify obstructions and respond appropriately to prevent adverse events like inadequate suction/gas flow. |
| CO2 Suction Control Accuracy/Reliability | Device must accurately and reliably regulate CO2 removal to maintain clinical effectiveness, reduce overpressures, and prevent complications. | Passed "CO2 Suction Control Testing": Validated accuracy and reliability of the CO2 suction control mechanism, ensuring appropriate CO2 removal. |
| Hardware Abnormality Response/Safety | Device must respond appropriately to hardware faults (component failures, power disruptions) with safety mechanisms to detect and mitigate failures. | Passed "Hardware Abnormality Testing": Assessed response to hardware faults, confirming safety mechanisms are in place to detect and mitigate failures. |
| Failure Communication | Device must effectively communicate failure conditions/malfunctions to the user through clear and accurate error messages or alarms, enabling prompt corrective action. | Passed "Communication of Failure Detail Testing": Verified effective communication of failure conditions through appropriate error messages/alarms, ensuring users are aware of issues for prompt corrective action. |
| Software Performance & Validation | Software must meet performance requirements, operate as intended under normal and abnormal conditions, and adhere to FDA guidance for software validation, ensuring reliability and no impact on patient safety. Specific to the changed functions ("Pressure sensor failure detection" and "Alarm delay setting") it must prove they do not cause over-insufflation. | Passed "Software Testing": Validated that the software meets performance requirements, operates as intended, and adheres to FDA guidance. Confirmed reliability and no errors impacting patient safety. The software change specifically addresses the prevention of over-insufflation. |
| Cybersecurity | Device must be resilient to cyber threats, including protection against unauthorized access, data tampering, and system vulnerabilities, in compliance with relevant standards. | Passed "Cybersecurity Testing": Evaluated resilience to cyber threats, including risk assessments, secure update mechanisms, and compliance with standards (e.g., CVSS framework), ensuring secure operation and safeguarding patient information/functions. |
Here's a breakdown of the other requested information:
-
A table of acceptance criteria and the reported device performance: This is provided above.
-
Sample sized used for the test set and the data provenance (e.g. country of origin of the data, retrospective or prospective):
- Sample Size: Not applicable in the context of a clinical test set with patient data for this submission. The tests performed ("Overpressure Testing," "Tube Obstruction Testing," "CO2 Suction Control Testing," "Hardware Abnormality Testing," "Communication of Failure Detail Testing," "Software Testing," and "Cybersecurity Testing") were bench tests. These tests typically involve a specific number of units/simulations/iterations as defined by internal validation protocols, but not a "sample size" in the sense of a patient cohort. The document does not specify the number of units tested or the number of test runs for each bench test.
- Data Provenance: Not applicable as there is no patient data or clinical data for this specific submission. The tests were laboratory/bench-based. The submitter is Olympus Medical Systems Corporation, located in Tokyo, Japan.
-
Number of experts used to establish the ground truth for the test set and the qualifications of those experts:
- Not applicable. No external experts were used to establish a ground truth for a test set in the conventional sense (e.g., diagnosis of images). The "ground truth" for these bench tests is defined by engineering specifications, safety standards, and the expected functional behavior of the device described by the manufacturer. The tests confirm the device meets these pre-defined engineering criteria.
-
Adjudication method (e.g. 2+1, 3+1, none) for the test set:
- Not applicable. Adjudication methods are typically used in clinical studies involving human interpretation or subjective assessments. Bench testing does not involve such methods; results are typically derived from automated measurements or predefined pass/fail criteria.
-
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, not done. This device is an insufflation unit, not an AI-assisted diagnostic or imaging device. Therefore, MRMC studies are not relevant to its clearance.
-
If a standalone (i.e. algorithm only without human-in-the-loop performance) was done:
- Not applicable. This is a hardware device with embedded software controlling its functions, not a standalone algorithm. The "software testing" assessed the embedded software's performance within the device.
-
The type of ground truth used (expert consensus, pathology, outcomes data, etc):
- Engineering Specifications and Safety Standards. The ground truth for the performance of this device is defined by its intended function, the engineering specifications it must meet (e.g., pressure output, flow rate, alarm thresholds), and established safety standards for medical devices of this class. The "truth" is whether the device performs within its defined parameters and safety limits when subjected to various conditions (normal operation, overpressure, obstruction, hardware faults).
-
The sample size for the training set:
- Not applicable. This is not an AI/ML device that requires a "training set" in the machine learning sense. The software modifications enhance existing functions and were presumably developed and verified through standard software development life cycle (SDLC) processes, including unit testing, integration testing, and system testing. The document refers to "Software Testing" and "Cybersecurity Testing" which are validation steps for the finished software, not a training phase for a learning algorithm.
-
How the ground truth for the training set was established:
- Not applicable. See point 8.
§ 884.1730 Laparoscopic insufflator.
(a)
Identification. A laparoscopic insufflator is a device used to facilitate the use of the laparoscope by filling the peritoneal cavity with gas to distend it.(b)
Classification. (1) Class II (performance standards).(2) Class I for tubing and tubing/filter kits which include accessory instruments that are not used to effect intra-abdominal insufflation (pneumoperitoneum). The devices subject to this paragraph (b)(2) are exempt from the premarket notification procedures in subpart E of part 807 of this chapter, subject to the limitations in § 884.9.