FDA 510(k) Search - By Innolitics (SaMD and AI Experts)

syngo.via protoNeo supports interpretation and evaluation of examinations within healthcare institutions network, for example, in Radiology, Nuclear Medicine and Cardiology environments.

The system is not intended for the displaying of digital mammography images for diagnosis in the U.S

Device Description

syngo®.via protoNeo, version VA20, is a medical software system that provides tools and features to cover the radiological tasks of reading images. The system receives, stores and distributes images from digital image acquisition devices such as computer tomography and magnetic resonance scanners. The system has workplaces which can be used to review, edit, and manipulate image data, as well as generate quantitative and qualitative data to support an authorized user in diagnosis and treatment planning.

syngo®.via protoNeo version VA20 is a software only medical device. It defines recommended configurations for the hardware to run on. The hardware itself is not seen as a medical device and is not within the scope of this 510(k) submission.

syngo®.via protoNeo is based on a client-server architecture. The server processes and renders the data from the connected modalities. The server provides central services including image processing and temporary storage while incorporating the local database. The client provides the user interface for interactive image viewing and processing and can be installed and stored on each workplace which is connected to the server over a network. Since the majority of the data processing is performed by the server, the client can be installed on standard off-the-shelf computers with a variety of monitor types. Using the industry standard application virtualization infrastructure, the client systems can also be distributed as a virtual application.

AI/ML Overview

The provided text describes a 510(k) premarket notification for syngo®.via protoNeo (Version VA20). It states that no clinical studies were carried out for this device. All performance testing was conducted in a non-clinical fashion as part of verification and validation activities. Therefore, it is important to note that the acceptance criteria and study details below are based on non-clinical performance testing and software verification and validation, not a clinical study involving human subjects or expert readers making diagnostic decisions.

Here's a breakdown of the information based on the provided document:

Acceptance Criteria and Reported Device Performance

Since no clinical study was performed, there are no specific performance metrics like sensitivity, specificity, or AUC reported from a clinical standpoint. The device relies on demonstrating substantial equivalence to its predicate device (syngo®.via protoNeo, K161685) through non-clinical performance testing and conforming to established standards.

The acceptance criteria are implicitly tied to the successful completion of the non-clinical verification and validation activities, demonstrating that:

The software functions as intended.
The software meets defined specifications.
The changes introduced in VA20 do not introduce new safety or effectiveness concerns compared to the predicate.
The device conforms to relevant industry standards (e.g., DICOM, ISO 14971, AAMI ES 60601-1, IEC 62304, IEC 62366-1, IEC 10918-1, IEC 15444-1).

The reported device performance, in this context, is that the system successfully passed these non-clinical tests and met the internal acceptance parameters for software functionality, image display, image manipulation algorithms, quantitative algorithms, automatic self-tests, dual monitor support, series navigator, and cybersecurity.

Acceptance Criteria (Implicit from V&V)	Reported Device Performance
Functional Equivalence: Device performs functions of intended use (viewing, manipulation, communication, storage of medical images) as per specifications.	Verification and validation testing confirms all software specifications have been implemented and met the defined acceptance criteria.
Image Display: Correct display of various DICOM modalities (Ultrasound, XA, RF, CT, MR, DX, CR, Nuclear Medicine, PET) and fused view.	Successful display of specified modalities.
Imaging Algorithms: Correct operation of MPR, MIP, VRT, CPR (with threshold based contour and stenosis display), Region Growing, Edge enhancement.	Algorithms operate as designed and specified during non-clinical testing.
Quantitative Algorithms: Accurate distance, angle, area, and pixel value evaluation, including SUV and Volume measurement enhancements.	Algorithms provide accurate measurements as designed during non-clinical testing.
Automatic Self-tests: Proper functioning of client installer checks, version checks, DICOM parser checks, and handling of missing image data.	Self-tests successfully detect and manage specified conditions.
Dual Monitor Support & Series Navigator: Proper functionality as new features.	Features operate correctly.
Cybersecurity: Secure login, encrypted client-server communication, and prevention of unauthorized access/modification/misuse.	Cybersecurity measures are implemented and demonstrate conformance by preventing unauthorized access, modification, misuse, denial of use or unauthorized use of information stored, accessed or transferred.
Conformance to Standards: Compliance with NEMA PS3.1-3.20 (DICOM), ISO 14971, ANSI/AAMI ES 60601-1, AAMI ANSI IEC 62304, IEC 62366-1, IEC 10918-1, IEC 15444-1.	Conformance to all listed standards is claimed.
Risk Analysis: Identified hazards mitigated, and controls verified.	Risk analysis conducted, mitigation controls implemented, and verified by V&V testing.
Software Level of Concern: Documentation for Moderate Level of Concern software included and compliant.	Documentation successfully submitted and deemed compliant with special controls.
No New Safety/Effectiveness Concerns: Device does not introduce new risks compared to predicate.	Siemens believes no new safety or effectiveness concerns are introduced.

Study Details Based on Provided Document:

Sample size used for the test set and the data provenance (e.g. country of origin of the data, retrospective or prospective):
- Test Set Sample Size: Not applicable. The document states, "No clinical studies were carried out for syngo.via protoNeo VA20. All performance testing was conducted in a non-clinical fashion as part of the verification and validation activities for the medical device." This implies testing was done on synthetic or de-identified datasets within the development environment, not a "test set" of clinical cases in the traditional sense.
- Data Provenance: Not applicable for a clinical test set. Non-clinical testing data provenance is not specified (e.g., country of origin, retrospective/prospective). It would typically be internal testing data.
Number of experts used to establish the ground truth for the test set and the qualifications of those experts:
- Not applicable as no clinical test set was used, and therefore, no medical experts were involved in establishing ground truth for such a set.
Adjudication method (e.g. 2+1, 3+1, none) for the test set:
- Not applicable as no clinical test set was used.
If a multi-reader multi-case (MRMC) comparative effectiveness study was done, If so, what was the effect size of how much human readers improve with AI vs without AI assistance:
- No MRMC comparative effectiveness study was done. The document explicitly states "No clinical studies were carried out."
If a standalone (i.e. algorithm only without human-in-the-loop performance) was done:
- No standalone clinical performance study was done. The testing was non-clinical software verification and validation. The device itself is a Picture Archiving and Communication System (PACS) software solution intended for use by trained professionals, where the output is evaluated by clinicians.
The type of ground truth used (expert consensus, pathology, outcomes data, etc.):
- For the non-clinical verification and validation, the "ground truth" would be the expected functional behavior and computed results based on the software's design specifications and algorithm definitions. This is established by the development team and subject matter experts in software engineering and medical imaging, comparing the software's output to known correct outputs or behaviors for specific inputs (e.g., pixel values, geometric calculations, image rendering). It is not expert consensus, pathology, or outcomes data from clinical cases.
The sample size for the training set:
- Not applicable. This device is a PACS solution, not a machine learning or AI algorithm that typically requires a large training set of annotated data for model development. Its functionality is based on established imaging algorithms and software engineering principles.
How the ground truth for the training set was established:
- Not applicable, as there is no mention of a training set or machine learning model development in the traditional sense for this PACS system.

Summary

Regulation Number and Section

§ 892.2050 Medical image management and processing system.

(a)
Identification. A medical image management and processing system is a device that provides one or more capabilities relating to the review and digital processing of medical images for the purposes of interpretation by a trained practitioner of disease detection, diagnosis, or patient management. The software components may provide advanced or complex image processing functions for image manipulation, enhancement, or quantification that are intended for use in the interpretation and analysis of medical images. Advanced image manipulation functions may include image segmentation, multimodality image registration, or 3D visualization. Complex quantitative functions may include semi-automated measurements or time-series measurements.(b)
Classification. Class II (special controls; voluntary standards—Digital Imaging and Communications in Medicine (DICOM) Std., Joint Photographic Experts Group (JPEG) Std., Society of Motion Picture and Television Engineers (SMPTE) Test Pattern).