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) 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.
DICOM In. DICOM Out. It could be that simple. 🔗
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. 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 before; this article is a deeper dive on the topic.
Don't submit what you might not ship anyway 🔗
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.
This is a proven path 🔗
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.
All 104 clearances detailed
| 510(k) | Year | Device | Company | Shape | How the public summary describes it |
|---|---|---|---|---|---|
| K141069 | 2014 | Lung Density Analysis | Imbio, LLC | Binary / container | Operates as command-line executable; runs via command-line or scripting. |
| 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 | 2018 | LungQ Software | Thirona Corporation | Binary / container | LungQ is a standalone command-line software tool for processing thoracic CT scans. |
| K191688 | 2019 | SubtleMR | Subtle Medical, Inc. | Binary / container | The software operates on DICOM files on a file system; it has no user interface. |
| K200750 | 2020 | Neuro.AI Algorithm | TeraRecon, Inc. | Binary / container | The 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 | 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 | 2021 | SubtleMR | Subtle Medical, Inc. | Binary / container | The device has no user interface; it operates on DICOM files within clinical workflows. |
| 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 | 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 | 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 | 2022 | EFAI ChestSuite XR Pleural Effusion Assessment System | Ever Fortune.AI Co., Ltd. | Binary / container | Software-only device; operates on specialized servers (physical or virtual). Deployed as a Docker container. |
| K223396 | 2023 | Rapid RV/LV | iSchemaView, Inc. | Binary / container | Interface: Command Line. |
| 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 | 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 | 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 | 2024 | LungQ v3.0.0 | Thirona BV | Binary / container | Stand-alone command-line software running on Linux. |
| 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 | 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 | 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 | 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 | 2024 | TeraRecon 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 | 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 | 2025 | SubtleHD (1.x) | Subtle Medical, Inc. | Binary / container | The software operates on virtual machines (Linux/PC/Mac) without a user interface. |
| K243378 | 2025 | Rapid MLS | iSchemaView, Inc. | Binary / container | Comparison table row: Interface: Command Line. |
| K243859 | 2025 | PRAEVAorta 2 | Nurea | Binary / container | Software environment: Ubuntu, Docker. Connectivity: API-based, cloud or on-premises server. |
| 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 | 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 | 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 | 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 | 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 | 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 | 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 | 2015 | ZywieAI Software Library | Zywie, Inc. | Library / SDK | The ZywieAI Software Library is an object library (callable functions) for automated ECG analysis. |
| 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 | 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 | 2018 | Patient Status Engine | Isansys Lifecare, Ltd. | Library / SDK | The Software Library is run in third party devices. |
| 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 | 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 | 2019 | KardiaAI | AliveCor, Inc. | Library / SDK | The library is intended to be integrated into other device software. |
| K183322 | 2019 | physIQ Heart Rhythm and Respiratory Module | physIQ, Inc. | Library / SDK | No primary display; integrates via API. |
| K201985 | 2020 | KardiaAI | AliveCor, Inc. | Library / SDK | The library is intended to be integrated into other device software. |
| K200884 | 2020 | B-Secur HeartKey Software Library | B-Secur, Ltd. | Library / SDK | The library is intended to be integrated into other device software. |
| K220624 | 2022 | AI4CMR v1.0 | AI4MedImaging Medical Solutions S.A. | Library / SDK | Interface: 3rd party viewer as a plug-in. |
| 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 | 2023 | Low Ejection Fraction AI-ECG Algorithm | Anumana, Inc. | Library / SDK | No GUI; relies on third-party display systems. |
| 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 | 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 | 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 | 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 | 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 | 2025 | autoSCORE (V 2.0.0) | Holberg EEG AS | Library / SDK | autoSCORE does not have a user interface. |
| 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 | 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 | 2025 | Bunkerhill ECG-EF | BunkerHill Health | Library / SDK | Algorithm output is provided to third party software that displays the result to clinicians. |
| 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 | 2025 | Personalized Therapy Comfort Settings (PTCS) | ResMed Corp | Library / SDK | Integrated via API into compatible ResMed PAP devices. |
| 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 2026 | AI Contouring (VA10A) | Varian Medical Systems | Library / SDK | "A software engine integrated into compatible Varian medical device platforms (e.g., Eclipse, Velocity)" |
| 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 | 2026 | MSK Go | Smart Alfa Teknoloji San. Ve Tic. A.S. | Library / SDK | "Software integrated into compatible ultrasound system's software." |
| 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 | 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 | 2025 | AI-CVD | HeartLung Corporation | Library / SDK | "AI-CVD® is executed via parent software which provides the necessary inputs and receives the outputs." |
| 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 2024 | LVivo IQS | Dia Imaging Analysis, Ltd. | Library / SDK | "Essentially, the Algorithm and API, which is a module, is a medical device accessory." |
| 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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 | 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:
- Subtle Medical has cleared eight, all with some version of “the software operates on DICOM files on a file system; it has no user interface” (K191688).
- TeraRecon has cleared five, each “deployed as a containerized application” (K243158).
- Imbio has shipped “a single command-line executable program” since 2014 (K241847). Its first summary made the distinction explicit: the subject “provides a command-line interface, while the predicate device provides a graphic user interface” (K141069).
- Thirona has said LungQ “must be run from a command-line interpreter and does not have a graphical user interface” across three clearances (K173821, K232412, K250766).
- iSchemaView includes a row reading “Interface | Command Line” in the comparison tables for Rapid RV/LV (K223396) and Rapid MLS (K243378).
- Nurea’s PRAEVAorta 2 (K243859, 2025) cited K232613 as its predicate and filled the patient-data-input row with “Command line interface (API).” The summary lists what may sit on the other side: a client that “aims to provide a user interface to send images and receive the analysis results,” which can be a web client, PACS gateway, integrating solution, or marketplace. None of those is the device.
- Therapixel’s MammoScreen BD “takes as input a folder with images in DICOM formats” (K243685);
- MRIguidance’s BoneMRI “operates on DICOM files on the file system” (K221762);
- Limbus Contour “interfaces with the user’s operating system file system” (K230575).
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:
- AliveCor’s KardiaAI summary (K181823) says, “The library is intended to be integrated into other device software.”
- Anumana’s ECG-AI Low Ejection Fraction algorithm (K250652) “does not provide a graphical user interface (GUI) of its own.”
- Nobel Biocare’s DTX Studio Assist (K252086) is “a Software Development Kit (SDK) designed to integrate with medical device software that displays two-dimensional dental radiographs.”
- Mortara’s CardioConfirm (K161465, 2016), the oldest and clearest example, is a DLL embedded in an EMR. Its indications state that it “is intended to be controlled by a host application that manages user authentication, user permissions, and secure persistent storage of the tests.” Login, permissions, and storage sit in someone else’s product, and FDA wrote that into the cleared indications.
- ScreenPoint’s Transpara Density (K232096, 2023) does the same for networking: the software “must be embedded in a software application that generates output in standardized formats (e.g. DICOM) and handles communication with external devices.”
- Siemens’ AI-Rad Companion (K183271, 2019) takes it to the logical end: “Electrical safety and EMC testing requirements are addressed as part of the host system (CT device or PACS system).” The summary does not say so directly, but that reads like a SiMD-to-SaMD refactor with the GUI removed.
- Implicity’s ILR ECG Analyzer (K253463, 2026) puts viewing and storage outside the device at Enhanced documentation level. Its comparison table says viewing ECG data “belongs to the ‘client application’” and the device “stores results in the ‘client application.’”
- Nuralogix’s Anura Mobile Core SDK (K253650, 2026) spells out the consequence: “Any regulatory clearances and related tests that AMC-SDK has undergone do not apply to devices or software integrating AMC-SDK.” The summary adds that the final device manufacturer must “obtain the necessary regulatory approval/clearance for the final device.”
- Additional standouts include Exo’s ultrasound AI modules “to be integrated by another computer programmer into their legally marketed ultrasound imaging device” (K260217) and AliveCor’s Corvair (K231010), cleared as “an Application Program Interface (API) library.”
You can’t predict the postmarket. Don’t try. 🔗
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.
The Root Cause 🔗
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:
- A client's cybersecurity consultants wrote the login gateway and multi-tenant routing into the device, and the team was debating which tenancy model an overseas reviewer would accept. The question nobody had asked was whether the first overseas deployment would even use the same identity provider. It would not. The device became software that runs on a customer-supplied compute environment, "authentication server" went into the labeling, and the other consultants' requirement and risk lists were pruned back the following week.
- An engineer proposed signed cloud-storage links as the device's input contract, which would have pulled the storage service and the link signer into validation. The question was whether the on-premise appliance planned for next year would have object storage at all. It might not. The boundary moved one level down, to raw DICOM bytes arriving at the container, and fetching became the customer's transport layer.
- A client's cloud API, with its storage, thumbnails, identifier tracking, format conversion, logins, and logging, had been drawn as the device. The boundary was redrawn around the inference container and the rest reclassified as a data system FDA does not review. The argument that landed was not the smaller attack surface but portability: the container can later move between clouds or host applications with no new submission. The team refactored for a week and the study started.
- A client wanted a new AI detector filed as an amendment to its long-cleared imaging viewer, on the theory that add-ons review faster. Filing the package would have invited FDA to re-review a decade of cloud and cybersecurity changes to the viewer. Only the inference endpoint was submitted, with the already-cleared viewer as the display. No user interface, no human factors study, a penetration test scoped to one API.
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.
How to draw the boundary 🔗
- Decompose before you write the documents. Lock the system-item architecture before writing detailed design controls or threat models. Treat any new box inside the boundary as a major architectural decision requiring cross-disciplinary review. Three or four system items can be enough.
- Make the interface a Docker bind mount, a CLI, a documented file format, or lightweight API. If a hospital IT administrator can wire it to any upstream system without your help, it is external.
- Name external items abstractly. Use "Authentication server," not Okta, and "Cloud compute platform," not AWS. State the protocol and minimum spec in the labeling. Verify your side of the interface against one representative fixture. Implementing against an abstract interface is good engineering practice anyway because it forces you to spell out the requirements that matter.
- Implement external system items with labeling. Add a requirement stating the software shall implement one side of the interface, verify it with a combination of labeling statements, unit tests, integration tests involving adding reference implementation to emulate the opposite end of the interface, and installation-qualification procedures owned by the customer for lower risk external system items or manufacturer for higher risk ones.
- Write the indications so the boundary is visible. "Intended to be run on its own or as part of another medical device" told FDA in the first sentence that the viewer was not mine. It also leaves room for licensing the algorithm into other manufacturers’ products.
- Reuse language from existing precedent. SubtleMR's "operates on DICOM files on a file system; it has no user interface" (K191688) reappears almost word for word in BoneMRI (K202404, K221762) and Ezra Flash (K242334). Exo's four ultrasound modules (K240953, K242359, K243239, K260217) and DiA's LVivo IQS (K240769) share the sentence "the Algorithm and API, which is a module, is a medical device accessory." If your predicate already told FDA where the device stops, quote it, and the reviewer sees a boundary they have accepted before.
- Use multiple containers or CLIs if necessary. You can use multiple Docker images to describe complex systems of SaMD that run on different hardware, have distinct interconnections, etc. This is a mechanism to handle configurations with critical alarm infrastructure, for example. Often times a mission critical external system item sits between different medical device containers or CLIs.
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.
