Everything Outside the Binary Is a Guess. Stop Submitting Guesses.

The FDA cleared a Class II AI device, K232613, on February 28, 2024, whose indications for use define the regulated device as a command line software application running on Ubuntu 20.04.5 LTS via Docker container that takes CT studies as input and outputs PDF and JSON reports, with no viewer, web app, cloud platform, or login. Regulatory consultant Innolitics argues the premarket device boundary should contain only what is certain to exist postmarket, because wrapping development infrastructure such as cloud accounts, identity providers, and message queues into the submission creates documentation debt when health systems later demand on-premises deployment. The cleared device's predicate, a chest X-ray cardiothoracic ratio tool, is described as software designed to be installed on a computer with specific system requirements.

On February 28, 2024, FDA cleared a Class II AI device whose indications for use begin with a sentence most regulatory consultants would have edited out. "CT Cardiomegaly is a command line software application intended to be run on its own or as part of another medical device." No viewer. No web app. No cloud. It has no login screen, either. The cleared device K232613 https://fda.innolitics.com/device/K232613 is, per its public summary, a Docker container on Ubuntu that takes in CT studies and puts out PDF and JSON reports. Everything else in the hospital sits outside the regulated boundary, including the PACS, the router, the computer the container runs on, and whatever displays the report. Over the last two years I have watched clients learn the same lesson. This month I wrote it down as a rule for myself: the premarket device boundary may contain only what you know for certain will exist in the postmarket. Everything else is an assumption, and assumptions inside the boundary become permanent documentation debt. The public 510 k summary for K232613 scopes the device boundary down very tightly. It is "a command line software application intended to be run on its own or as part of another medical device." Its inputs are CT image studies and its outputs are PDF and JSON reports. The software "runs on Ubuntu 20.04.5 LTS via Docker container." The predicate, a chest X-ray cardiothoracic ratio tool, is described as software "designed to be installed on the computer with specific system requirements." Neither summary mentions a viewer, a web application, a cloud platform, or a login. That shape changes the review. Every connected imaging AI device gets the same four cybersecurity questions, and I have written about them before in my survey of common FDA cybersecurity deficiencies https://innolitics.com/articles/common-cybersecurity-fda-ainn-letter-objections/ . How does the device behave on the hospital network? Does it implement layered authorization for different user roles? What security testing covered the end-to-end system? How does it detect, log, and recover from compromise? Each question assumes the usual shape of an imaging AI product: a listener on the network with a web viewer somewhere behind it. A container that takes files in and puts files out has a short answer to each. The network-connected machine belongs to the hospital. The device's only interface is a command line and the files it reads and writes, which the site's IT staff can wire to any router, share, or gateway they already run. I have called this pattern command line as a medical device https://innolitics.com/articles/command-line-as-a-medical-device-clamd/ before; this article is a deeper dive on the topic. I often see a startup wrap its algorithm in the infrastructure it used for development and testing: a cloud account, an identity provider, a web front end, a message queue. The team submits all of it as the device because that is what the architecture diagram happened to show at the time. FDA clears the system. Then the first sales contract from a health system arrives, and all that architecture needs to change overnight. Unless you have a crystal ball, premarket deployment infrastructure is an assumption or reference implementation. I once worked with a team that was certain it needed a multi-tenant cloud. The engineers and the pitch deck agreed, so the software requirements dutifully listed the queue, the object store, the identity provider, and the VPC as software items. Then the company landed its first big customer, a health system that wanted the software on its own hardware, behind its own network, with its own logging and its own identity provider. Every one of those documented items was now wrong, and so were the threat model and the penetration test built on them. I have watched the same thing happen to triage devices and remote-monitoring platforms. The waste lands in the premarket, when money is tightest, and it buys nothing: the pen test that matters is the one run against the network the future customer actually has. Do that one just in time, in the postmarket, when the configuration is known. Premarket architecture work is capital spent on a guess. A per-deployment pen test is a cost of goods sold, paid when a customer pays you. Companies are glad to make that trade, and it is the trade FDA should want too. A pen test against a real network, repeated as deployments change, is ongoing diligence. A pen test against a guessed network, done once before clearance, is just a one-and-done checkbox. The customer's deployment requirements do not care what the 510 k said. When the cloud account, identity provider, and web tier are software items inside the boundary, a deployment that differs from the cleared configuration is a design change to a cleared device. Best case, each change gets a letter to file: a documented assessment that no new 510 k is needed. Worst case, you owe a new submission. And the cost is not the FDA's $26,067 filing fee. It is the team you pull off the product to redo the requirements, risk assessments, testing, and submission. In , I priced the in-house team for a first AI SaMD submission at $1.07M to $1.72M a year in salaries and benefits alone , before contractors. A repeat submission does not start from zero, but it consumes that same expensive team's time that they could be spending improving the device. I now teach everyone on my engineering, regulatory, and cybersecurity teams to examine every system item, meaning each box on the architecture chart. An item inside the device must be specified, verified, threat-modeled, and kept under change control. For an external system item, you write the interface requirement it must satisfy and verify your side of that interface. Software engineers call this dependency inversion or a service provider interface. In plain English: tell the hospital what your software needs, not which vendor to buy from. The device publishes an interface contract: give me a folder of DICOM files that meet these criteria, and I will give you a report. Whoever satisfies that contract, a PACS router today or a cloud gateway next year, stays outside the device boundary. The concrete implementation belongs in the device history record for that installation, not in the design history file for the product. You will need at least one implementation of the contract during V&V to verify that the device fulfills its side. That implementation is V&V scaffolding, not a permanent part of your device. For example, your device requires an authentication server supporting OpenID Connect. You test against Okta during V&V to verify token and claims handling, but the requirement is the interface contract, not Okta. When a hospital uses Entra ID instead, you verify that deployment against the same contract rather than redesigning the device. Okta is scaffolding you used to test with. I searched every AI SaMD FDA clearance summary in FDA Device Explorer for language about where the software runs and identified 104 clearances worth highlighting. The 104 clearances in the figure below are a low-water mark, not an exhaustive list. I found them two ways. A keyword search of every FDA summary for phrases like "command line," "container," "no user interface," and "library" returned 625 hits, which we classified one by one; 63 described a device that stops at the code. Then I ran every AI-enabled SaMD summary through a language-model classifier, and it found 41 more. The result is 44 binaries, containers, or folder watchers, and 60 libraries or SDKs that another product calls. Sponsors outside the AI cohort who drew the boundary this way without the keywords are still not counted, and not all sponsors who utilize this approach say so publicly in the 510 k summary, so the real number is higher. | 510 k | Year | Device | Company | Shape | How the public summary describes it | |---|---|---|---|---|---| | K141069 https://fda.innolitics.com/device/K141069 | 2014 | Lung Density Analysis | Imbio, LLC | Binary / container | Operates as command-line executable; runs via command-line or scripting. | | K172534 https://fda.innolitics.com/device/K172534 | 2017 | LINACwatch, LinacView | Qualiformed Sarl | Binary / container | Standalone software analyzing linear accelerator LINAC performance via machine-generated log files. Outputs: real-time alerts via email for non-compliant parameters. | | K173821 https://fda.innolitics.com/device/K173821 | 2018 | LungQ Software | Thirona Corporation | Binary / container | LungQ is a standalone command-line software tool for processing thoracic CT scans. | | K191688 https://fda.innolitics.com/device/K191688 | 2019 | SubtleMR | Subtle Medical, Inc. | Binary / container | The software operates on DICOM files on a file system; it has no user interface. | | K200750 https://fda.innolitics.com/device/K200750 | 2020 | Neuro.AI http://neuro.ai/ Algorithm | TeraRecon, Inc. | Binary / container | The Neuro.AI http://neuro.ai/ Algorithm is a standalone image processing software device that can be deployed as a Microsoft Windows executable on off-the-shelf hardware or as a containerized application e.g., a Docker container . | | K200422 https://fda.innolitics.com/device/K200422 | 2020 | Image Quality Analyzer IQA | VisionQuest Biomedical, Inc. | Binary / container | IQA does not modify the image and only moves the image from the input folder to either the Save or Discard folder. | | K203182 https://fda.innolitics.com/device/K203182 | 2021 | SubtleMR | Subtle Medical, Inc. | Binary / container | The device has no user interface; it operates on DICOM files within clinical workflows. | | K203256 https://fda.innolitics.com/device/K203256 | 2021 | Imbio RV/LV Software | Imbio, LLC | Binary / container | The software operates as a command-line executable, typically integrated into radiological workflows at PACS workstations. | | K212550 https://fda.innolitics.com/device/K212550 | 2021 | Hura CTP v1.0 | Hura Imaging, Inc. | Binary / container | Bench testing including verification tests on: DICOM image import and export, command line functions, image denoising and contrast enhancement. | | K220349 https://fda.innolitics.com/device/K220349 | 2022 | TeraRecon Neuro | TeraRecon, Inc. | Binary / container | The TeraRecon Neuro Algorithm is a standalone image processing software device that can be deployed as a Microsoft Windows executable on off-the-shelf hardware or as a containerized application e.g., a Docker container . | | K222076 https://fda.innolitics.com/device/K222076 | 2022 | EFAI ChestSuite XR Pleural Effusion Assessment System | Ever Fortune.AI http://fortune.ai/ Co., Ltd. | Binary / container | Software-only device; operates on specialized servers physical or virtual . Deployed as a Docker container. | | K223396 https://fda.innolitics.com/device/K223396 | 2023 | Rapid RV/LV | iSchemaView, Inc. | Binary / container | Interface: Command Line. | | K223623 https://fda.innolitics.com/device/K223623 | 2023 | SubtleMR 2.3.x | Subtle Medical, Inc. | Binary / container | As it only processes images for the end user, the device has no user interface. | | K230112 https://fda.innolitics.com/device/K230112 | 2023 | CAC Software | Imbio, Inc. | Binary / container | The Imbio CAC Software is a single command-line executable program that may be run directly from the command line. | | K231570 https://fda.innolitics.com/device/K231570 | 2023 | StrokeViewer Perfusion | Nico-Lab B.V. | Binary / container | The software is packed as a Docker container allowing installation on a standard off-the-shelf computer or a virtual platform. | | K232412 https://fda.innolitics.com/device/K232412 | 2024 | LungQ v3.0.0 | Thirona BV | Binary / container | Stand-alone command-line software running on Linux. | | K232613 https://fda.innolitics.com/device/K232613 | 2024 | CT Cardiomegaly | Innolitics, LLC | Binary / container | CT Cardiomegaly is a command line software application intended to be run on its own or as part of another medical device. | | K241329 https://fda.innolitics.com/device/K241329 | 2024 | SubtleSYNTH 1.x | Subtle Medical, Inc. | Binary / container | The device functions in the background without a user interface; it receives DICOM images from a compatible medical device data system MDDS after MRI acquisition. | | K240290 https://fda.innolitics.com/device/K240290 | 2024 | AiMIFY 1.x | Subtle Medical, Inc. | Binary / container | The software operates in the background without a user interface, typically within a hospital or clinic network. | | K241847 https://fda.innolitics.com/device/K241847 | 2024 | Imbio PHA 4.0.0 | Imbio, Inc. | Binary / container | The software operates as a command-line executable, typically integrated into radiological workflows at PACS workstations. | | K241312 https://fda.innolitics.com/device/K241312 | 2024 | TeraRecon Cardiac.Chambers.MR http://cardiac.chambers.mr/ 1.0.0 | TeraRecon, Inc. | Binary / container | Deployed as a containerized application e.g., Docker , it processes MR inputs to produce segmentation outputs. | | K243158 https://fda.innolitics.com/device/K243158 | 2025 | TeraRecon Aorta.CT 1.1.0 | TeraRecon, Inc. | Binary / container | TeraRecon Aorta.CT is a software as a medical device SaMD deployed as a containerized application. | | K243250 https://fda.innolitics.com/device/K243250 | 2025 | SubtleHD 1.x | Subtle Medical, Inc. | Binary / container | The software operates on virtual machines Linux/PC/Mac without a user interface. | | K243378 https://fda.innolitics.com/device/K243378 | 2025 | Rapid MLS | iSchemaView, Inc. | Binary / container | Comparison table row: Interface: Command Line. | | K243859 https://fda.innolitics.com/device/K243859 | 2025 | PRAEVAorta 2 | Nurea | Binary / container | Software environment: Ubuntu, Docker. Connectivity: API-based, cloud or on-premises server. | | K250766 https://fda.innolitics.com/device/K250766 | 2025 | LungQ 4 | Thirona BV | Binary / container | LungQ is a docker image with a standalone command-line software which must be run from a command-line interpreter and does not have a graphical user interface. | | K250288 https://fda.innolitics.com/device/K250288 | 2025 | TeraRecon Cardiovascular.Calcification.CT | TeraRecon, Inc. | Binary / container | TeraRecon Cardiovascular.Calcification.CT is a software as a medical device SaMD deployed as a containerized application. | | K251474 https://fda.innolitics.com/device/K251474 | 2026 | Median LCS / eyonis LCS 1.0 | Median Technologies | Binary / container | Software-only SaMD; containerized architecture Kubernetes ; DICOM-based input and output; supports DICOMweb and HL7. | | K254013 https://fda.innolitics.com/device/K254013 | 2026 | SubtleHD-PET 1.x | Subtle Medical, Inc. | Binary / container | As it only processes images for the end user, the device has no user interface. | | K254120 https://fda.innolitics.com/device/K254120 | 2026 | SubtleHD-CT 1.x | Subtle Medical, Inc. | Binary / container | It operates as background software without a user interface, processing DICOM images received from a compatible medical device data system MDDS after acquisition. | | K253192 https://fda.innolitics.com/device/K253192 | 2026 | DeepXray Spina | Alpha Intelligence Manifolds, Inc. | Binary / container | Operates as an add-on to the DeepXray system K223621 within institutional Linux server / Docker containers. | | K141811 https://fda.innolitics.com/device/K141811 | 2014 | Mortara Monitoring Waveform Viewer | Mortara Instrument, Inc. | Library / SDK | The Monitoring Waveform Viewer is a software component intended to be utilized within another software application. | | K142693 https://fda.innolitics.com/device/K142693 | 2015 | ZywieAI Software Library | Zywie, Inc. | Library / SDK | The ZywieAI Software Library is an object library callable functions for automated ECG analysis. | | K150069 https://fda.innolitics.com/device/K150069 | 2015 | Fine Structure Analysis fineSA | Acuitas Medical, Ltd. | Library / SDK | fineSA software processes designated MR images using the 2-D pulse sequence incorporated on Siemens 3T MAGNETOM systems running syngo MR software. | | K161465 https://fda.innolitics.com/device/K161465 | 2016 | CardioConfirm | Mortara Instrument, Inc. | Library / SDK | CardioConfirm is a software component DLL or executable embedded in host applications e.g., EMR to manage diagnostic cardiology reports. | | K172329 https://fda.innolitics.com/device/K172329 | 2018 | Patient Status Engine | Isansys Lifecare, Ltd. | Library / SDK | The Software Library is run in third party devices. | | K180234 https://fda.innolitics.com/device/K180234 | 2018 | physIQ Heart Rhythm Module | physIQ, Inc. | Library / SDK | Computerized software library Python for automated analysis of single-lead ECG signals; integrates into customer-developed end-to-end remote monitoring systems via API. | | K182093 https://fda.innolitics.com/device/K182093 | 2019 | ZOLL ECG Analysis Software | Zoll Manufacturing Corporation | Library / SDK | The ECG Analysis Software is intended for use with ECG management software through an electronic interface. | | K181823 https://fda.innolitics.com/device/K181823 | 2019 | KardiaAI | AliveCor, Inc. | Library / SDK | The library is intended to be integrated into other device software. | | K183322 https://fda.innolitics.com/device/K183322 | 2019 | physIQ Heart Rhythm and Respiratory Module | physIQ, Inc. | Library / SDK | No primary display; integrates via API. | | K201985 https://fda.innolitics.com/device/K201985 | 2020 | KardiaAI | AliveCor, Inc. | Library / SDK | The library is intended to be integrated into other device software. | | K200884 https://fda.innolitics.com/device/K200884 | 2020 | B-Secur HeartKey Software Library | B-Secur, Ltd. | Library / SDK | The library is intended to be integrated into other device software. | | K220624 https://fda.innolitics.com/device/K220624 | 2022 | AI4CMR v1.0 | AI4MedImaging Medical Solutions S.A. | Library / SDK | Interface: 3rd party viewer as a plug-in. | | K223622 https://fda.innolitics.com/device/K223622 | 2023 | FaceHeart Vitals Software Development Kit FH Vitals SDK | FaceHeart Corp. | Library / SDK | A software development kit for integration into third-party applications; not intended for use in patients with known or suspected heart arrhythmias. | | K232699 https://fda.innolitics.com/device/K232699 | 2023 | Low Ejection Fraction AI-ECG Algorithm | Anumana, Inc. | Library / SDK | No GUI; relies on third-party display systems. | | K231068 https://fda.innolitics.com/device/K231068 | 2024 | autoSCORE | Holberg EEG AS | Library / SDK | autoSCORE does not have a user interface. autoSCORE sends this information to the host EEG software. | | K233580 https://fda.innolitics.com/device/K233580 | 2024 | A Breathing System ABS | DeepWell DTx, Inc. | Library / SDK | A Breathing System ABS is a software development kit SDK for Android 6.0+ apps; provides biofeedback to induce relaxation. | | K233755 https://fda.innolitics.com/device/K233755 | 2024 | HeartKey Rhythm | B-Secur Limited | Library / SDK | HeartKey Rhythm is a software library integrated via REST API into ECG management or remote patient monitoring platforms. | | K242925 https://fda.innolitics.com/device/K242925 | 2025 | MR Contour DL | GE Healthcare | Library / SDK | MR Contour DL does not have a user interface of its own and can be integrated with other systems. | | K242001 https://fda.innolitics.com/device/K242001 | 2025 | Philips VSC-MEDlib | Philips Medical Systems Nederland B.V. | Library / SDK | VitalSigns Camera Medical Library is a software library that can be integrated into a customer application for use during virtual consults or health screening. | | K243743 https://fda.innolitics.com/device/K243743 | 2025 | autoSCORE V 2.0.0 | Holberg EEG AS | Library / SDK | autoSCORE does not have a user interface. | | K243966 https://fda.innolitics.com/device/K243966 | 2025 | FaceHeart Vitals SDK-RR | FaceHeart Corp. | Library / SDK | FH Vitals SDK-RR is a software-only respiratory rate measurement tool intended to be integrated into third-party software applications on compatible mobile devices, laptops, or computers. | | K250652 https://fda.innolitics.com/device/K250652 | 2025 | ECG-AI Low Ejection Fraction LEF 12-Lead algorithm | Anumana, Inc. | Library / SDK | ECG-AI LEF 12-Lead algorithm does not provide a graphical user interface GUI of its own. | | K250649 https://fda.innolitics.com/device/K250649 | 2025 | Bunkerhill ECG-EF | BunkerHill Health | Library / SDK | Algorithm output is provided to third party software that displays the result to clinicians. | | K252086 https://fda.innolitics.com/device/K252086 | 2025 | DTX Studio Assist | Nobel Biocare / Medicim NV | Library / SDK | DTX Studio Assist is a Software Development Kit SDK designed to integrate with medical device software that displays two-dimensional dental radiographs. | | K251657 https://fda.innolitics.com/device/K251657 | 2025 | Personalized Therapy Comfort Settings PTCS | ResMed Corp | Library / SDK | Integrated via API into compatible ResMed PAP devices. | | K250233 https://fda.innolitics.com/device/K250233 | 2026 | PreemptiveAI Clinical SDK | Measure Labs, Inc. dba PreemptiveAI | Library / SDK | Software as a Medical Device SaMD SDK for integration into third-party mobile apps; operates on Android and iOS. | | K254161 https://fda.innolitics.com/device/K254161 | 2026 | Automated Aortic Stenosis Software AutoAS | GE Medical Systems Ultrasound | Library / SDK | The software can be integrated with a compatible ultrasound device in a headless manner. | | K252360 https://fda.innolitics.com/device/K252360 | 2026 | ECG-AI Pulmonary Hypertension PH 12-Lead algorithm | Anumana, Inc. | Library / SDK | Software module in a Docker container; no GUI; integrates with EMR/EMS via API. | | K253801 https://fda.innolitics.com/device/K253801 | 2026 | ECG-AI Cardiac Amyloidosis CA 12-Lead Algorithm | Anumana, Inc. | Library / SDK | Software module in a Docker container; no GUI; integrates with EMR/EMS via API. | | K253650 https://fda.innolitics.com/device/K253650 | 2026 | Anura Mobile Core SDK M1 | NuraLogix Corporation | Library / SDK | Software development kit SDK for integration into mobile applications; uses transdermal optical imaging via smartphone cameras. | | K254169 https://fda.innolitics.com/device/K254169 | 2026 | SmartSpectra Vital Signs Monitor 1.0 | Presage Technologies | Library / SDK | Software-only medical device SaMD SDK; analyzes optical video signals from fixed-mounted smartphones to estimate pulse and respiratory rates. | | K253463 https://fda.innolitics.com/device/K253463 | 2026 | ILR ECG Analyzer IM007 | Implicity, Inc. | Library / SDK | Cloud-based software algorithm; API-based communication via messaging queues; compatible with Abbott, Biotronik, Boston Scientific, and Medtronic implantable monitors; no client-side interface. | | K253699 https://fda.innolitics.com/device/K253699 | 2026 | Tempus ECG-PH | Tempus AI, Inc. | Binary / container | "Input data comprising ECG tracings, tracing metadata e.g., sample count, sample rate, patient age/sex , is provided to Tempus ECG-PH through standard communication protocols e.g., file exchange with other medical systems" | | K261306 https://fda.innolitics.com/device/K261306 | 2026 | AI Contouring VA10A | Varian Medical Systems | Library / SDK | "A software engine integrated into compatible Varian medical device platforms e.g., Eclipse, Velocity " | | K261519 https://fda.innolitics.com/device/K261519 | 2026 | Sonio Suspect | Sonio | Library / SDK | "Sonio will supply the C++ algorithm package to the third-party manufacturer and provide integration support as needed" | | K260234 https://fda.innolitics.com/device/K260234 | 2026 | MSK Go | Smart Alfa Teknoloji San. Ve Tic. A.S. | Library / SDK | "Software integrated into compatible ultrasound system's software." | | K260217 https://fda.innolitics.com/device/K260217 | 2026 | AI Platform 2.2 AIP002 | Exo Imaging | Library / SDK | "The AI modules are provided as software components to be integrated by another computer programmer into their legally marketed ultrasound imaging device. Essentially, the Algorithm and API, which are modules, are medical device accessories." | | K252589 https://fda.innolitics.com/device/K252589 | 2026 | Corvair Monza | AliveCor, Inc. | Library / SDK | "Corvair Monza has a C++ interface and a distributed binary library , which is used by the target device to statically link to Corvair Monza." | | K252029 https://fda.innolitics.com/device/K252029 | 2025 | AI-CVD | HeartLung Corporation | Library / SDK | "AI-CVD® is executed via parent software which provides the necessary inputs and receives the outputs." | | K252204 https://fda.innolitics.com/device/K252204 | 2025 | prolaio eVO2peak Module Version 1.0 | Prolaio, Inc. | Library / SDK | "The prolaio eVO2peak Module is a software-only Class II SaMD Python library." | | K251059 https://fda.innolitics.com/device/K251059 | 2025 | Syngo Carbon Clinicals VA41 | Siemens Healthineers AG | Library / SDK | "Syngo Carbon Clinicals is a plug-in that can be added to any SYNGO based hosting applications for example: Syngo Carbon Space, syngo.via etc... ." | | K251408 https://fda.innolitics.com/device/K251408 | 2025 | OsteoSight™ Hip v1 | Naitive Technologies, Ltd. | Library / SDK | "The device operates via integration with a host integration platform that facilitates the secure transfer of DICOM images and associated metadata from clinical imaging systems." | | K243685 https://fda.innolitics.com/device/K243685 | 2025 | MammoScreen BD | Therapixel | Binary / container | "MammoScreen BD takes as input a folder with images in DICOM formats and outputs breast density assessment in a form of a JSON file." | | K250119 https://fda.innolitics.com/device/K250119 | 2025 | Tempus ECG-Low EF | Tempus AI, Inc. | Binary / container | "Input data comprising ECG tracings, tracing metadata e.g., sample count, sample rate, patient age/sex , is provided to Tempus ECG-Low EF through standard communication protocols e.g., file exchange with other medical systems" | | K243239 https://fda.innolitics.com/device/K243239 | 2025 | Lung AI LAI001 | Exo, Inc. | Library / SDK | "Lung AI is developed as a module to be integrated by another computer programmer into their legally marketed ultrasound imaging device." | | K241770 https://fda.innolitics.com/device/K241770 | 2025 | Prostate MR AI VA10A | Siemens Healthcare GmbH | Library / SDK | "Prostate MR AI is a Computer Assisted Detection and Diagnosis algorithm designed to plug into a hosting workflow that assists radiologists in the detection of suspicious lesions and their classification." | | K242334 https://fda.innolitics.com/device/K242334 | 2025 | Ezra Flash | Ezra Ai, Inc. | Binary / container | "The software operates on DI-COM files on the file system, enhances the images, and stores the enhanced images on the file system." | | K242359 https://fda.innolitics.com/device/K242359 | 2024 | Strain AI SAI001 | Exo, Inc. | Library / SDK | "This software is developed as a module to be integrated by another computer programmer into their legally marketed ultrasound imaging device." | | K240408 https://fda.innolitics.com/device/K240408 | 2024 | REMI-AI Rapid Detection Module REMI-AI RDM | Epitel, Inc. | Library / SDK | "The REMI-AI Rapid Detection Module REMI-AI RDM is a seizure detection module which is integrated into the REMI Remote EEG Monitoring System and is only indicated for use within non-ICU Intensive Care Unit healthcare settings." | | K240786 https://fda.innolitics.com/device/K240786 | 2024 | AutoChamber | HeartLung Corporation | Library / SDK | "The AutoChamber Software is executed via a parent software which provides the necessary input and visualizes the output data." | | K241561 https://fda.innolitics.com/device/K241561 | 2024 | MammoScreen BD | Therapixel | Binary / container | "MammoScreen BD takes as input a folder with images in DICOM formats and outputs a breast density assessment in a form of a JSON file." | | K240953 https://fda.innolitics.com/device/K240953 | 2024 | AI Platform 2.0 AIP002 | Exo Imaging | Library / SDK | "In addition, the Al modules are provided as a software component to be integrated by another computer programmer into their legally marketed ultrasound imaging device. Essentially, the Algorithm and API, which are modules, are medical device accessories." | | K231010 https://fda.innolitics.com/device/K231010 | 2024 | Corvair | AliveCor, Inc. | Library / SDK | "This SaMD provides these capabilities in the form of an Application Program Interface API library. Any software or device "target device" can incorporate the Corvair API library into its device software to provide users with resting ECG analytics." | | K240612 https://fda.innolitics.com/device/K240612 | 2024 | CINA-VCF | Avicenna.Ai | Library / SDK | "CINA-VCF runs on a standard "off the shelf" server/workstation and consists of VCF Image Processing Application, which can be integrated, deployed and used with the CINA Platform cleared under K200855 or other compatible medical image communications devices." | | K240769 https://fda.innolitics.com/device/K240769 | 2024 | LVivo IQS | Dia Imaging Analysis, Ltd. | Library / SDK | "Essentially, the Algorithm and API, which is a module, is a medical device accessory." | | K232331 https://fda.innolitics.com/device/K232331 | 2024 | InVision Precision LVEF LVEF | InVision Medical Technology Corporation | Library / SDK | "The analysis results are visualized by the clinician's integrated image view application as adjustable annotations." | | K233968 https://fda.innolitics.com/device/K233968 | 2024 | CINA-iPE | Avicenna.Ai | Library / SDK | "CINA-iPE runs on a standard "off the shelf" server/workstation and consists of an Image Processing Application, which can be integrated, deployed, and used with the CINA Platform cleared under K200855 or other medical image communications devices." | | K232096 https://fda.innolitics.com/device/K232096 | 2023 | Transpara Density 1.0.0 | Screenpoint Medical B.V. | Library / SDK | "Transpara Density is designed as an optional feature of Transpara. To operate in a clinical environment the software must be embedded in a software application that generates output in standardized formats e.g. DICOM and handles communication with external devices" | | K231157 https://fda.innolitics.com/device/K231157 | 2023 | syngo.CT Lung CAD Version VD30 | Siemens Healthcare GmbH | Library / SDK | "The syngo.CT Lung CAD sends a list of nodule candidate locations to a visualization application, such as syngo MM Oncology, or a visualization rendering component, which generates output images series with the CAD marks superimposed" | | K230552 https://fda.innolitics.com/device/K230552 | 2023 | MR DWI/FLAIR Measurement V1.0 | Olea Medical | Binary / container | "MR DWI/FLAIR Measurement V1.0 is a docker totally independent from the OLEA platform in which it is integrated and has a dedicated Input/Output channels to be able to be integrated and deployed through any compatible configurable technical platform." | | K230575 https://fda.innolitics.com/device/K230575 | 2023 | Limbus Contour | Limbus Ai, Inc. | Binary / container | "Limbus Contour interfaces with the user's operating system file system importing DICOM image .dcm files and exporting segmented DICOM RT-Structure Set .dcm files ." | | K223502 https://fda.innolitics.com/device/K223502 | 2023 | MR Diffusion Perfusion Mismatch V1.0 | Olea Medical | Binary / container | "MR Diffusion Perfusion Mismatch V1.0 image processing application is designed as a docker installed on a technical platform i.e., a Medical Image Communications Device " | | K221762 https://fda.innolitics.com/device/K221762 | 2022 | BoneMRI v1.4 | Mrlguidance B.V. | Binary / container | "The software operates on DICOM files on the file system, enhances the images, and stores the enhanced images on the file system." | | K202404 https://fda.innolitics.com/device/K202404 | 2021 | BoneMRI | Mriguidance B.V. | Binary / container | "The software operates on DICOM files on the file system, enhances the images, and stores the enhanced images on the file system." | | K210543 https://fda.innolitics.com/device/K210543 | 2021 | IM007 | Implicity, Inc. | Library / SDK | "The Subject Device operates as a software module electronically interfaced to another computer system that handles ECG data" | | K212218 https://fda.innolitics.com/device/K212218 | 2021 | Advanced Algorithms for Treatment Management Applications AATMA | Elekta Solutions AB | Library / SDK | "As a medical image processing library, AATMA™ is designed to produce derived datasets in standard formats e.g., DICOM that can be utilized by other applications." | | K203696 https://fda.innolitics.com/device/K203696 | 2021 | RBknee | Radiobotics Aps | Binary / container | "RBknee operates in a Linux environment and can be compatible with any operating system supporting the third-party software Docker." | | K203258 https://fda.innolitics.com/device/K203258 | 2021 | syngo.CT Lung CAD | Siemens Healthcare GmbH | Library / SDK | "The syngo.CT Lung CAD sends a list of nodule candidate locations to a visualization application, such as syngo MM Oncology, or a visualization rendering component, which generates output images series with the CAD marks superimposed" | | K201411 https://fda.innolitics.com/device/K201411 | 2021 | Visage Breast Density | Visage Imaging GmbH | Library / SDK | "Visage Breast Density is designed as an add-on module to the Visage 71 product for distributing, viewing, processing, and archiving medical images." | | K201232 https://fda.innolitics.com/device/K201232 | 2020 | Limbus Contour | Limbus Ai, Inc. | Binary / container | "Limbus Contour interfaces with the user's operating system file system importing DICOM image .dcm files and exporting segmented DICOM RT-Structure Set .dcm files ." | | K193216 https://fda.innolitics.com/device/K193216 | 2020 | syngo.CT Lung CAD | Siemens Medi Cal Solutions, Inc. | Library / SDK | "The location information of the nodule candidates are collected into a final candidate list passed to hosting application." | | K192109 https://fda.innolitics.com/device/K192109 | 2019 | KOALA | Ib Lab GmbH | Binary / container | "KOALA operates in a Linux environment and can be deployed to be compatible with any operating system supporting the third-party software Docker." | | K190424 https://fda.innolitics.com/device/K190424 | 2019 | HealthICH | Zebra Medical Vision, Ltd. | Library / SDK | "HealthICH interacts with users through the PACS/workstation via the Zebra Imaging Analytics platform IMA ." | The 44 binaries include established manufacturers with repeated clearances: Thirty-four of the 44 are AI devices, and 21 of the 44 were cleared in 2024 or later. The libraries make the same point from the other side. For non-engineers, a library is a software component that cannot run independently: Across the 1,006 AI-enabled SaMD summaries, the text names a specific Windows Server release in 21, AWS in 20, Google Cloud in 6, and Azure in 2. Each one commits the manufacturer to that configuration. When the customer brings their own cloud, the manufacturer is then confronted with a software change order, when it should have been just a new record in the device history record DHR with appropriate installation qualification rather than a letter-to-file-or-510 k question. Aidoc is an interesting case study. From 2018 to 2022, BriefCase cleared at least 18 times with the whole stack inside the device; K222277 describes it as "a standard off-the-shelf operating system, the Microsoft Windows server 2012 64bit, and additional applications, which include PostgreSQL, DICOM module and the BriefCase Image Processing Application." Microsoft ended support for Windows Server 2012 in October 2023. That year Aidoc filed a Special 510 k K230020 whose purpose was the cut: "The new device consists of only the algorithm analysis module which can be integrated with image communication platforms that meet the BriefCase input and output requirements." The same summary adds that "the SW architecture was changed to separate the image communication platform from the BriefCase SW." Every BriefCase-Triage clearance since is the algorithm module alone. It is my speculation the deprecation of Microsoft Windows server 2012 forced the conversation for Aidoc and they finally arrived to the more optimal configuration that could have been their foundation all along. Some assessments end in an unnecessary 510 k submission. I ran all 1,006 through an LLM classifier, looking for sponsors whose only stated change from their own predicate was where the software runs. It flagged twenty. Reading those summaries confirmed twelve: seven Special 510 k s, the cheaper version of this mistake, and five Traditional 510 k s. Eleven moved an unchanged algorithm to a different computer; one, Siemens' Syngo Carbon Clinicals, pulled tools out of an application into a plug-in a type of SDK or library . Had the sponsors followed this playbook from the start, most of these would not have been necessary. Responsibility for the boundary is often implicitly split across silos. Cybersecurity owns the global system view, engineering owns the architecture diagram, regulatory owns the risk file, and quality owns the installation qualification procedure. Each discipline can add a box. That box then cascades across the submission: the threat model feeds the software requirements, which expand the verification and penetration-testing plans. In my experience, a single cloud item mistakenly drawn inside the boundary can multiply a submission's documentation and testing burden by five in the premarket and even more in the postmarket. That is how medical device startups burn runway and delay clearances on scaffolding that was never part of the core technology. Okta follows this path when engineering introduces it because the development test harness needs a login. The cybersecurity analyst sees it on the architecture diagram and includes it in the threat model. The regulatory writer then creates a system item with corresponding requirements and verification protocols. By the time anyone asks whether the device boundary actually requires an identity provider, the assumption is already baked into the design history file and premarket submission. Everyone did their job within their specialty, but no one evaluated the boundary holistically. Each discipline can answer questions inside its known knowns and can ask questions inside its known unknowns. Outside both, it does not know there is a question. Whether Okta belongs inside the boundary sat outside engineering's known unknowns, and the regulatory lead, who could have answered it in a sentence, never saw Okta on the diagram. That is the point of widening the known unknowns: it adds no answers, only questions, and a question that gets asked can reach the person who can answer it. Okta is the pattern, not the only case. Here are some more examples: Preventing this requires cross-disciplinary alignment before documentation begins. Turning a web service into a headless binary or folder watcher may take a week of engineering and, in my experience, saves multiple FTE years of combined cross-functional effort over the lifecycle of the device. The refactor can also eliminate a penetration test of a system that may never reach production. The cleared device is the part you will still be shipping in year five. Draw the line there. Data from FDA Device Explorer by Innolitics fda.innolitics.com . The quoted descriptions of K232613 come from its public 510 k summary; the boundary recommendations are mine.