Scope and how “sponsor does not own the data‑generating device” was determined

Based on the radiology-focused FDA-cleared/approved SaMD submissions and labeling excerpts provided, a device was counted as meeting your criterion when the text indicates the software ingests/receives DICOM images from external imaging modalities (e.g., CT/MR/CR/DR/US) and/or from PACS/VNA/archives, and/or is described as software-only / hardware independent / off‑the‑shelf, with no indication the sponsor supplies the imaging acquisition hardware. Typical qualifying language includes “images acquired from… DICOM‑compliant medical imaging systems,” “receives… from modalities,” “hardware independent,” “software-only,” and explicit modality lists (CT/MR/etc.) ^{5958188187135136}.

Across the provided dataset, every radiology SaMD entry included in the context was assessed as relying on third‑party acquisition hardware (i.e., the sponsor does not own/provide the scanner or other data-generating modality), with the supporting excerpts quoted below per device.

Radiology SaMD devices identified (sponsor relies on third‑party acquisition hardware)

PACS / image management / viewing (predominantly LLZ)

These are classic radiology SaMDs where the sponsor’s product is a PACS / image management / viewer and the data is generated by external modalities and delivered via DICOM/PACS workflows.

RadUnity (Version 1.0.0) — RadUnity Corp. (2024) — LLZ

• Classified with “Product Code LLZ” and PACS-related regulation naming ^154153155.
• Evidence of third‑party acquisition dependency: it “ingests DICOM CT image data” ¹⁵⁴ and is limited to “Image input type DICOM CT images” ¹⁵⁷. This implies CT images are produced by external CT systems and provided as DICOM.

IntelliSpace Radiology — Philips Healthcare Informatics, Inc. (2018) — LLZ

• Explicitly supports receiving studies “via DICOM” from many modality types (CT, MR, US, CR, DX, etc.) ¹³⁵¹³⁶.
• This modality-wide DICOM ingestion indicates the software is downstream of third‑party imaging acquisition systems ^135136138.

Centricity Radiology RA600 / Cardiology CA1000 / Digital Hardcopy — GE (2004, 2006) — LLZ

• Intended for “images acquired from CT, MR, CR, DR, US, XA and other DICOM-compliant medical imaging systems” ^5958188.
• Receives studies “from a PACS server or directly from a DICOM‑compliant modality or archive” ^5958188187.
• Also described as usable with “‘off the shelf’ PC hardware” ⁵⁷¹⁸⁶, reinforcing it is not tied to sponsor-owned acquisition hardware.

AMICAS WEB/INTRANET IMAGE SERVER — Autocyt Group, Inc. (1997) — LLZ (Lower Level of Concern noted)

• “remote viewing of files generated by a medical scanning device” ¹¹.
• “Image acquisition is via the industry-standard DICOM 3.0 protocol allowing the images to be produced from the digital data originated by the scanner” ¹¹.
• This is direct evidence the scanner (data generator) is external to the sponsor’s SaMD ¹¹.

Medsynapse RIS PACS & Medsynapse VNA — Medsynaptic Private Ltd (2019) — LLZ

• “As a software-only device, it does not control image acquisition” ²¹⁶.
• “can process medical images from DICOM compliant modalities” ²¹⁸.
• This explicitly separates the SaMD sponsor from the acquisition device ownership/control ²¹⁶²¹⁸.

VidiStar PACS & DICOM Viewer — VidiStar, LLC (2009) — LLZ

• Works with images “generated by OEM vendor equipment” ¹⁶⁶¹⁶⁷.
• Supports “virtually any DICOM and non-DICOM digital imaging modality” ¹⁶⁵.
• This is strong vendor-neutral/third‑party acquisition language ^165166167.

eVolve PACS — eVolve PACS Inc. (2021) — LLZ

• Displays/handles images from “Digital imaging units (including DR, CR, CT, MR, US, RF, and 2D/3D mammography) … and other imaging devices” ²⁹¹.
• Processes DICOM modality messages (e.g., MPPS) from modalities ²⁸⁸, indicating external modality sources.

Augmento — Deeptek Medical Imaging Pvt Ltd (2023) — LLZ

• “receives medical images and data from various DICOM-compliant sources (i.e. CT scanners, MR scanners, ultrasound systems… PET Units… imaging gateways…)” ⁹³⁷⁹⁷.
• This explicitly enumerates third‑party acquisition device types ⁹³⁷.

syngo Imaging — Siemens (V20A 2005; V30 2007; V31 2008) — LLZ

• Described as “hardware independent” and distributed as “software only” or with common IT hardware ^75117160159.
• Integrates with “any HL7- / DICOM-compatible RIS” and supports DICOM images/objects ^118119159.
• This indicates Siemens provides PACS/workstation software that consumes externally generated DICOM imaging data ^117118159.

AMICAS PACS, Version 6.0 — AMICAS, Inc. (2008) — LLZ (also interfaces with CADe outputs)

• “receives images acquired from DICOM-compliant medical imaging systems” ⁴⁵⁴⁹.
• Workflow: images imported “from the imaging modality” and also sent to CAD; CAD outputs are generated by “3rd party Medical Devices approved by FDA” ⁴⁶.
• This is a clear example where both the imaging modality and CAD processor are external to the PACS sponsor ⁴⁶⁴⁵.

SUITESTENSA — EBIT srl (2017) — LLZ

• Supports mammography images “received in the DICOM For Presentation format” ²⁴²²⁹⁸ and states HL7/DICOM compliance ²⁴¹.
• The “received” language indicates images originate from external modalities and are then managed/viewed in the SaMD ²⁴²²⁴¹.

DEMASQ Imaging Software Device — DEMASQ Limited (2009) — LLZ

• “receives medical images and data from various imaging sources (including but not limited to CT, MR, US… radiographic devices… scanners, imaging gateways)” ⁷⁸¹.
• This is explicit third‑party acquisition reliance ⁷⁸.

Xmaru View V1 and Xmaru PACS — Rayence Co., Ltd (2016) — LLZ

• “receives… diagnostic image data from imaging modalities” ⁸⁴ and supports multiple modality types ⁸².
• Indicates the SaMD is downstream of external modalities ⁸⁴⁸².

SntryPACS — QSTAR Technologies, Inc. (2008) — LLZ

• “receives digital images and data from various sources (i.e. CT scanners, MR scanners, ultrasound systems… imaging gateways, etc.)” ¹⁵⁰¹⁴⁹.
• “compatible with any DICOM modality” ¹⁴⁷, strongly implying sponsor does not own the acquisition devices.

Exam-PACS — CoActiv, LLC (2004) — LLZ

• “receives digital images… from various sources (e.g. CT scanners, MR scanners… imaging gateways)” ¹⁷⁸¹⁷⁶.
• Also describes use of DICOM gateways/film digitizers when DICOM images aren’t directly available ¹⁷⁵, reinforcing reliance on external acquisition systems.

Visage PACS — Visage Imaging, Inc. (2008) — LLZ

• “receives image data in DICOM format via the hospital network… universal connections to archives, modalities, and workstations” ¹¹⁶¹¹¹.
• This is explicit interoperability with external modalities/archives ¹¹⁶¹¹¹.

LifeSys PACS — Lifetrack Medical Systems, Inc. (2017) — LLZ

• Receives “DICOM images” and displays images from CT/MRI/US/X-ray etc. ¹⁸²¹⁸¹.
• Uses “off the shelf” hardware components ¹⁸¹, again separating sponsor from acquisition hardware.

McKesson Radiology (2014) and McKesson Radiology Mammography Plus (2015) — McKesson — LLZ

• Intended to process/display images from “DICOM conformant modalities such as X-Ray Radiography… CT… MRI… Ultrasound… Nuclear Medicine” ^146143222223.
• Also “intended for installation and use with off-the-shelf hardware” ^146141223, consistent with non-ownership of acquisition devices.

MediSystem PACS — Medilab (2023) — LLZ

• “connects to any PACS and displays DICOM images” ¹²⁴.
• Explicitly “not intended for the acquisition of mammographic image data” ¹²⁸, reinforcing it is not the data-generating device.

CHILI PACS — CHILI GmbH (2007) — LLZ

• “Receive and store new exams from the Modalities” ²⁵³ and supports DICOM images/objects ²⁵².
• This directly indicates external modality acquisition ²⁵³²⁵².

DG PACS — DICOM Grid, Inc. (2016) — LLZ

• Describes PACS as providing access to “images from multiple modalities” and notes DICOM as the universal format ⁸⁸.
• While it doesn’t explicitly say “third-party,” the multi-modality PACS framing implies images originate from external modalities ⁸⁸⁸⁹.

EFAI PACS Picture Archiving and Communication System — Ever Fortune.AI (2021) — LLZ

• “displays, processes, stores, and transfers medical data from original equipment manufacturers (OEMs) that support the DICOM standard” ⁶⁷.
• This is explicit that the data-generating equipment is OEM equipment (not the SaMD sponsor) ⁶⁷.

CharruaPACS System — CharruaSoft SA (2013) — LLZ

• “receives digital images and data from various sources (e.g. CT scanners, MR scanners, ultrasound systems… imaging gateways, etc.)” ⁵².
• Strong third‑party acquisition evidence ⁵².

CLARISO PACS — Clariso, Inc. (2013) — LLZ

• “software Teleradiology system used to receive DICOM images” ²⁰⁵ and used to view DICOM studies ²⁰⁴.
• Also “not intended for the acquisition of mammographic image data” ²⁰⁵, reinforcing downstream role.

MedCommons Open Radiology Gateway — MedCommons, Inc. (2004) — LLZ

• “receives… digital images and data from various types of imaging… system, such CT, MR, US… radiographic devices, scanners, imaging gateways” ²⁵.
• Also applies functions to images “acquired and stored on an image server” ³¹⁸, indicating the gateway is not the acquisition device.

Merge PACS — Merge Healthcare Incorporated (2019) — LLZ (explicit VNA/RIS/HIS/EMR integration)

• “processes and displays medical images from DICOM-compliant modalities” ²⁸⁴.
• “Data can be received directly from acquisition modalities, CAD systems, and other image processing systems” ²⁸².
• Can integrate with “vendor-neutral imaging archives (VNAs) … and … RIS/HIS … EMR/EHR” ²⁸⁴, which strongly supports the “sponsor does not own the data-generating device” pattern (it plugs into existing enterprise infrastructure) ²⁸⁴²⁸².

DR Systems PACS, Release 6.1 — DR. Systems, Inc. (2004) — LLZ (explicit CADe input mention)

• Handles images from “a variety of diagnostic imaging systems” ²³³²²⁸.
• Displays images from many modalities and includes “processed data from FDA-cleared third party image processing systems, including… computer-aided detection” ²³⁰²²⁸.
• This is a clear example of a sponsor’s PACS consuming outputs from other vendors’ acquisition and processing devices ²³⁰²³³.

Vitrea View — Vital Images, Inc (2017) — LLZ (explicit archive/repository language)

• Provides access to data “hosted within disparate archives and repositories” for DICOM and non‑DICOM data ¹⁹⁵¹⁹².
• This indicates the sponsor’s SaMD is a viewer/distribution layer over externally generated and stored imaging data ¹⁹⁵¹⁹².

ImageGrid Radiology Viewer System — Candelis, Inc. (2009) — LLZ

• Can “query, retrieve, and display medical images that it retrieves from a DICOM SCP” ¹⁷⁴¹⁷⁰.
• Receives images “from various imaging sources” ¹⁷¹¹⁷², indicating external acquisition.

Lightning Viewer — Nexsys Electronics Inc. dba Medweb (2024) — LLZ (mentions CAD overlays; DICOMweb listed among standards)

• “displays images and reports from a PACS” via browser-based “zero-footprint” access ²⁸⁰.
• Can display overlays from “Computer-Aided Diagnosis (CAD) and AI software” ²⁷⁸ (i.e., it can consume outputs from other systems).
• Standards list includes “DICOMweb” among other technologies ²⁸⁰, reinforcing interoperability with external systems.

Non-PACS radiology SaMD (still LLZ product code in these excerpts) where third‑party acquisition is explicit

These are radiology SaMDs that do more than archive/view (e.g., enhancement, perfusion analysis, post-processing, decision support) but still clearly rely on external scanners for data generation.

iRAD Image Enhancement System — Claritas HealthTech (2021) — LLZ

• “takes as input DICOM files of MRI, CT, and X-Ray images” and outputs enhanced DICOM to PACS ¹⁶.
• “selection of input DICOM images from PACS servers” and sends back after enhancement ¹⁵.
• This is explicit reliance on externally acquired images and existing PACS infrastructure ¹⁵¹⁶.

AutoMIStar — Apollo Medical Imaging Technology (2019) — LLZ

• Performs analysis of “brain images acquired by DICOM compliant imaging devices” ²⁵⁹.
• Can connect to “modality scanners, workstations, PACS” to receive CT/MRI images ²⁶¹.
• This directly indicates the sponsor does not provide the CT/MRI scanners generating the data ²⁶¹²⁵⁹.

iSchemaView RAPID — iSchemaView, Inc. (2013) — LLZ

• “receives DICOM images from external DICOM image providers (modalities (CT/MRI Scanners), PACS and Workstations)” ³⁴.
• Explicitly: “RAPID is entirely independent from CT, MRI, or PACS platforms” ³⁴.
• This is one of the clearest statements matching your criterion (sponsor does not own/control the acquisition platform) ³⁴.

Brainomix 360 e-CTP — Brainomix Limited (2023) — LLZ

• “Data and images are acquired through DICOM compliant imaging devices” ¹⁷³.
• Runs on off‑the‑shelf/virtual platforms ¹⁷³, reinforcing it is not the acquisition device.

Brainomix 360 e-MRI — Brainomix Limited (2023) — LLZ

• Same pattern: “Data and images are acquired through DICOM compliant imaging devices” ^235236234 and supports DICOM file upload ^235236234.

Cercare Medical Neurosuite — Cercare Medical ApS (2021) — LLZ (explicit “decision support software”)

• Described as “software-only” and installable on customer PC / remote desktop ¹³⁰.
• “Acquires medical image data from DICOM” ¹³³ and is intended for MRI-derived neuroimaging ¹³⁰.
• This indicates reliance on externally generated MRI data ¹³⁰¹³³.

syngo.via View&GO VA40A — Siemens (2023) — LLZ

• Explicitly: “software-only medical device… installed on common IT hardware… hardware itself is not… part of the medical device” ¹⁶[E3].
• Interfaces “with any Long-term storage (e.g. PACS) via DICOM” and renders data from “connected modalities” ²⁷⁰.
• This is strong evidence the sponsor does not own the acquisition modalities generating the data ²⁷⁰¹⁶[E3].

What about QIH (and other FDA device-type terms like CADe/CADx)?

• In the provided excerpts, explicit “QIH” terminology was generally not present for most devices (many are categorized under LLZ and described as PACS/viewers/workstations). Where workstation-like products appear (e.g., Centricity RA600/CA1000), the excerpts still classify them under LLZ and describe DICOM workstation behavior rather than using “QIH” explicitly ^{186188187575958}.
• CADe/CAD/CADx-related terms appear mainly as interoperability inputs, not as the primary function of the SaMD:
  • AMICAS PACS 6.0 describes parallel sending to CAD and importing CAD outputs; CAD is from “3rd party Medical Devices” ⁴⁶.
  • DR Systems PACS mentions “computer-aided detection” as third‑party processed data input ²³⁰²²⁸.
  • Lightning Viewer mentions displaying overlays from “Computer-Aided Diagnosis (CAD) and AI software” ²⁷⁸.
  • McKesson Radiology Mammography Plus references “Computer Aided Detection Structured Reports (CAD SR)” ²²⁵²²².

Key implication for your research question

Within this radiology SaMD set, the dominant regulatory/device-type pattern is PACS / medical image management and processing under product code LLZ, and these systems are inherently downstream of imaging acquisition hardware. The labeling repeatedly frames the SaMD as receiving DICOM studies from modalities, PACS, archives, and hospital systems, which strongly supports the conclusion that the sponsor does not own/provide the device that generates the imaging data (CT/MR/X-ray/US scanners, etc.) ^{595813513615014934261}.

Limitations of this answer (based on provided excerpts)

• This summary is constrained to the devices present in the provided context; it is not an exhaustive search of all FDA-cleared radiology SaMD.
• For several entries, the evidence is implicit (e.g., “PACS images from multiple modalities”) rather than an explicit statement like “third-party” or “vendor-neutral,” though many devices do include explicit modality lists and DICOM interoperability language ^8889918482.
• Explicit “QIH” labeling was not found in most excerpts; the dataset is heavily weighted toward LLZ PACS/image management devices rather than explicitly labeled QIH categories ^{186188187575958}.