Company Spotlight: Cosmo AI GI Genius Module 300 - Multitasking in Endoscopy

Maya: We are looking at a gastrointestinal AI device that just got FDA clearance not for detecting polyps better, but for essentially learning how to multitask, allowing background health IT software to run during live endoscopy.

Sam: That is our focus today as we unpack the FDA 510(k) summary K261369 for the GI Genius Module 300 and ColonPRO US software, published by the U.S. Food and Drug Administration on May 29, 2026.

Maya: Before we dive in, a quick reminder that our voices are AI-generated, and this episode is a summary of a publicly available FDA 510(k) document, not company marketing material.

Sam: Maya, gastrointestinal endoscopy is obviously a massive procedural space. To start us off, who is the company behind this specific submission, and what exactly is the device's regulatory classification?

Maya: The 510(k) owner and submitter is Cosmo Artificial Intelligence - AI Ltd, located in Dublin, Ireland. The document also lists a specification developer named Linkverse Srl based in Rome, Italy. As for the classification, the FDA designates this as a Class II device under Regulation Number 21 CFR 876.1520.

Sam: And the official FDA classification name?

Maya: The classification name is Gastrointestinal lesion software detection system, and it falls under the Gastroenterology and Urology panel with the product code QNP.

Sam: Okay, so we know exactly where it sits in the regulatory framework. What is its primary job in the procedure room according to the indications for use?

Maya: The document defines the GI Genius system as a computer-assisted reading tool. It is designed to aid endoscopists in detecting colonic mucosal lesions, such as polyps and adenomas, in real time. It is specifically limited for use with standard white-light endoscopy imaging only during screening and surveillance evaluations.

Sam: And the summary mentions both hardware and software components, right? The Module 300 and the ColonPRO US software. How does that hardware actually integrate into the endoscopy equipment a hospital already owns?

Maya: The summary explains that this hardware module is connected right between the video processor and the endoscopic display monitor. It lists some very specific compatibility standards too. It works with Video Processors featuring SDI, HD-SDI, and 3G/SDI output ports, and it is also compatible with the 4K UHD standard.

Sam: It intercepts the live video feed and overlays its findings. What does the physician actually see on the screen while they are actively navigating the colon?

Maya: According to the summary, when it is first switched on, the endoscopic field of view gets four corner markers and a blinking green square indicator to show the system is ready. Then, during the live video streaming, if the algorithm detects a polyp or other lesion of interest, it generates superimposed green square markers accompanied by a short sound.

Sam: Green squares and a sound. Very straightforward. Now, I want to clarify something based on our editor's angle for today. Is this software characterizing the lesions in real time? Is it telling the doctor if a polyp is benign or malignant?

Maya: That is a crucial distinction. The summary is very clear about its limits. The indications for use specifically state it is a computer-assisted detection device and that this device is not intended to replace clinical decision making. The word characterization does not appear anywhere in this clearance document.

Sam: Got it. Strict detection, no characterization claims here. So if the core medical function is just detecting lesions, why did the company submit this new Special 510(k) application? What exactly changed from their previous version?

Maya: This is where it gets really interesting for health-system IT leaders. The core medical algorithm has not changed at all. The predicate device is the GI Genius Module 300 with ColonPRO 4.0, which was FDA-cleared under K241887 on July 25, 2024. This new submission, which updates the software to version 4.0.3-S, is all about Two design changes related to software architecture and connectivity.

Sam: Let us break those Two design changes down. What is the first one?

Maya: The first change introduces what the document calls multicontainer management functionality. Basically, the device can now allow the use of background non-medical software in separate software containers at the exact same time as the medical lesion detection software.

Sam: Wait, really? So while the AI is actively looking for polyps in the live video feed and putting up green squares, the exact same hardware box is running other non-medical applications in the background?

Maya: Exactly. The summary notes this qualifies it as a multiple function device product. The goal is to allow the user to operate non-medical device software in real time to support daily manual operations. The document explicitly lists clinical management, reporting, and health IT functions as examples of what might run in the background to ease user workload.

Sam: That sounds incredibly useful for hospital workflow, but my immediate thought is about system lag. If I am running heavy reporting software in the background, does it slow down the live polyp detection? In a live procedure, even a tiny delay could mean missing a lesion.

Maya: That is exactly the risk the FDA requires them to mitigate. The summary details specific verification and validation activities for this. They had to prove that resources management controls ensure the background software does not impact the performance, timing, image processing, or output generation of the ColonPRO US software.

Sam: How do they guarantee that technically inside the box?

Maya: The document states that the foreground medical software container is always executed with prioritized system resources and with exclusive control of the foreground execution environment. It also verified that a failure or malfunction of a background software container cannot directly or indirectly alter the medical function.

Sam: Okay, that makes sense. Prioritize the medical function at the operating system level. You mentioned a second major design change. What is that?

Maya: The second change is about how users actually interact with those background applications. The unmodified device already had connectivity functionalities, specifically LAN, USB, and QSFP ports. But previously, those were only used by the manufacturer for service activities. Now, they are being made available to users.

Sam: So a hospital IT department or a clinician can actually plug into those local ports or connect remotely now?

Maya: Yes. The summary says the proposed change allows use of the current device connectivity features, both local and remote, to allow the user to interact with the background software containers on external devices and exchange and transfer data in real time.

Sam: Opening up local and remote data ports on a live medical device immediately brings up cybersecurity concerns. If I am transferring reporting data out, what stops someone from hacking in and messing with the polyp detection algorithm?

Maya: The summary explicitly addresses cybersecurity of activated communication and data transmission. They verified and validated that external connections do not permit control of, modification to, or interaction with the foreground medical software container.

Sam: Did they do specific tests for the software container architecture itself?

Maya: They did. The summary lists verification for container isolation failure, resource contention, and container coexistence, stating all of these are addressed through software architecture controls, access limitations, and security monitoring measures.

Sam: It really sounds like they are turning this single-purpose AI box into a secure, hospital-connected platform. But I want to pivot back to the core medical function. Even though the algorithm itself did not change, the summary includes a substantial equivalence table with all the original performance numbers. Let us look at those, because anyone buying this needs to know exactly how well it detects lesions.

Maya: Absolutely. The medical performance data is clearly laid out in the predicate device comparison table. Let us start with the top-line metric. The lesion-based sensitivity is reported as exactly 88.07%.

Sam: 88.07%. What kind of dataset was that validated on?

Maya: The frame level performance was evaluated on a dataset of 150 videos containing 338 polyps.

Sam: 150 videos and 338 polyps. That gives us a sense of the scale. What about the frame-by-frame breakdown? Video AI analyzes dozens of frames per second, so the sheer volume of data must be massive.

Maya: It is massive. They report 277,738 true positive frames and 5,248,406 true negative frames. On the flip side, there were 95,391 false positive frames and 184,052 false negative frames.

Sam: 5,248,406 true negative frames. That is an incredible volume of video data. But let us look at those false positives. 95,391 false positive frames sounds like a lot until you compare it to the total. Did they calculate a rate for that?

Maya: Yes, the document states the mean false positive rate per frame is 1.79%. Meanwhile, the mean true positive rate per frame is 60.14%, and the percentage of polyps detected is listed at 100%. They also report a Frame-Based ROC curve AOC of 0.826.

Sam: So a 1.79% false positive rate per frame. But in the clinic, a false positive frame is not just a math problem, it is a green square flashing on the screen when there is no polyp. Does the document talk about how often those false alarms happen in actual clusters during a procedure?

Maya: It does. They break down false positive clusters per patient. For clusters lasting less than 500 ms, there were 97. For clusters lasting greater than 500 ms, there were 10.

Sam: That is a really helpful metric for clinicians. A cluster under 500 ms is basically a half-second flicker on the screen. 97 of those per patient. But only 10 instances per patient where the false alarm stays on screen for longer than half a second. That speaks directly to the distraction factor on the ward.

Maya: Exactly. And speaking of timing, we talked earlier about the risk of system lag from the new background apps. The comparison table confirms the video delay from signal in to signal out is just 29 μs.

Sam: 29 μs. That is incredibly fast.

Maya: It is. The table notes that the limit is less than 5.75 ms, so 29 μs is well within the safety margin. It confirms that the multicontainer architecture is not slowing down the video feed.

Sam: For the engineers building AI products listening to this, the level of software verification required here is intense. Does the summary give any numbers on the scope of their internal testing for these changes?

Maya: It mentions verification of the software at the system level. They tested 37 Units and 25 Items, encompassing 206 software requirements. They also carried out validation of the software at the user level.

Sam: I want to shift gears and look at the clearance letter at the beginning of this document. It includes standard regulatory boilerplate, but it outlines the ongoing requirements for any company after they get a 510(k). What does the FDA emphasize?

Maya: The letter reminds the company that clearance is subject to the general controls provisions of the Federal Food, Drug, and Cosmetic Act. That includes annual registration, listing of devices, good manufacturing practice, and prohibitions against misbranding and adulteration.

Sam: It also mentions something about combination products. Is this considered one?

Maya: The letter includes a standard warning that some cleared products may instead be combination products, but based on the rest of the summary, this is strictly classified as a medical device. However, the FDA is very specific about the Quality Management System Regulation, or QMSR.

Sam: What specific quality standards do they have to maintain for a software product like this?

Maya: The FDA explicitly calls out compliance with 21 CFR Part 820. It lists specific ISO 13485 clauses they must follow for design controls, nonconforming product, corrective action, and preventative action.

Sam: So basically, if they find a bug or a nonconforming output in the field, they need a rigorous, documented process to correct and prevent it.

Maya: Correct. And they note that regardless of whether a future change requires premarket review, the manufacturer must review and approve changes to device design and production, and document them in the Medical Device File as required by ISO 13485.

Sam: The letter also brings up the Unique Device Identification System rule. How does that apply here?

Maya: The UDI Rule requires that a device bear a unique device identifier on its label and package under 21 CFR 801.20(a), and that certain information be submitted to the Global Unique Device Identification Database under 21 CFR Part 830 Subpart E.

Sam: It is a good reminder for anyone in MedTech that getting the 510(k) clearance letter is really just the beginning of the compliance journey. But we also have to point out the limitations of what this specific 510(k) summary actually tells us about the GI Genius. What is not in this document?

Maya: The most important limitation to remember is the regulatory pathway itself. This is a Special 510(k) based entirely on substantial equivalence. The document clearly states that the baseline clinical validation for the subject device was conducted and reviewed in an older De Novo submission, specifically DEN200055.

Sam: Right, so this summary does not give us any new prospective clinical trial data or real-world patient outcomes from the ward. It relies entirely on the fact that the underlying medical algorithm is technically identical to the predicate device cleared in 2024.

Maya: Exactly. As the FDA letter points out, issuance of a substantial equivalence determination does not mean the FDA has made a determination that the device complies with other federal statutes or contract liability warranties. The FDA explicitly states they do not evaluate information related to contract liability warranties.

Sam: We also do not know from this summary what specific third-party health IT applications are actually going to be run in those new background containers, just that the device is now capable of hosting them securely. The document states that availability of any software container remains under the exclusive control of the manufacturer.

Maya: That is a great point. The hardware is ready, the ports are open, and the FDA has cleared the architecture, but the manufacturer still holds the keys to what actually gets installed and executed in those background containers.

Sam: Maya, when you look at this from both the clinical and business perspectives, what is the one memorable takeaway from this clearance?

Maya: For me, it is the shift from single-purpose AI to modular AI platforms. The GI Genius is maintaining its 88.07% sensitivity for detecting polyps, but by proving to the FDA that they can safely run background applications without lagging the medical feed, Cosmo AI is turning a detection tool into a broader digital hub for the endoscopy suite.

Sam: It is a fascinating look at where medical device architecture is heading. To recap, we have been looking at the FDA 510(k) summary K261369 for the GI Genius Module 300 and ColonPRO US software. The device aids in detecting colonic lesions and has now been cleared to run non-medical health IT software in separate background containers using newly activated connectivity ports.

Maya: As always, you can find a link to the full FDA summary document in our show notes. And a final reminder: this podcast is for informational purposes only and is not medical advice.