Search Results
Found 1 results
510(k) Data Aggregation
(80 days)
The intended use of the SIEMENS branded ARTISTE™, ONCOR™ and PRIMUS™ family of linear accelerator systems is to deliver X-Ray photon and electron radialion for the therapeulic treatment of cancer.
COHERENCE™ RT Therapist is a component of the linear accelerator system and is based on the syngo@ architecture. It enables patient management, patient selection/selup, palient positioning verification, treatment delivery/verification, and treatment recording.
COHERENCE™ RT Therapist Workspace Connect v2.3 can be Interfaced with 3rd party devices conforming to the DICOM standard.
COHERENCE™ RT Therapist Connect Workspace, v2.3:
The COHERENCE™ RT Therapist Connect Workspace v2.3 release is intended to update customers with the currently released COHERENCE™ RT Therapist Connect Workspace with versions v2.1a (ONCOR / PRIMUS systems). The technological characteristics of the COHERENCE™ RT Therapist Connect Workspace v2.3 remain unchanged from the currently cleared products.
The syngo® Software Architecture:
The COHERENCE™ RT Therapist Connect software utilizes the proprietary syngo® software architecture design provides a method of delivering customized software applications based on the modality as clinically supporting packages. From these applications SIEMENS utilizes, as part of the Oncology clinical focus package, multiple applications for patient set-up and position verification, treatment localization, treatment verification, portal imaging as well as data processing, image reformatting, display and printing. The currently cleared COHERENCE™ and syngo@ products also include an array of image-oriented software tools, support for DICOM connectivity, Siemens Remote Service, and virus protection features.
The provided text describes the COHERENCE™ RT Therapist Connect Workspace, v2.3, and its substantial equivalence to predicate devices, but it does not contain the specific information requested about acceptance criteria and a study proving the device meets those criteria, as typically found in a clinical performance study summary.
This document is a 510(k) summary, which focuses on demonstrating substantial equivalence to a legally marketed predicate device rather than providing detailed clinical performance study results with specific acceptance criteria, sample sizes, and ground truth methodologies. The device described is a software update for a radiation therapy system, and the testing performed primarily consists of bench testing (unit, integration, system integration, and regression testing) to ensure functionality and safety.
Therefore, many of the requested fields cannot be filled from the provided text.
Here's an attempt to answer based on the information available:
1. A table of acceptance criteria and the reported device performance
Acceptance Criteria Category | Reported Device Performance |
---|---|
Functional Requirements | Successfully verified and traced in accordance with the Siemens product development (lifecycle) process (PDP). All testable requirements in the Product Requirements Specifications (PRS) for the Sys_VA32a project were met. Specific requirements for the implementation of the third-party OIS were also verified. |
Safety Requirements | Risk management ensured via risk analysis to identify potential hazards and mitigations. These hazards are controlled by software means, user instructions, verification of requirements, and validation of clinical workflow. Adheres to recognized and established industry practice and relevant international standards to minimize electrical, mechanical, and radiation hazards. |
Verification & Validation | Software verification and regression testing performed successfully to meet previously determined acceptance criteria. System-level validation and regression testing performed successfully, demonstrating that the software meets acceptance criteria as noted in the system test plans. |
Consensus Standards | Tested to meet requirements for conformity (where applicable) to IEC 60601-1-4:1996+ A1: 1999, IEC 62304:2006, IEC 61217 (2007), and IEC 62274:2005. |
2. Sample size used for the test set and the data provenance (e.g., country of origin of the data, retrospective or prospective)
- Sample Size for Test Set: Not specified. The document refers to "testable requirements" and "system test level on production prototype devices" but does not quantify the number of cases or datasets used.
- Data Provenance: Not specified. The testing described appears to be internal validation of software rather than a study using external clinical data. It is implied that the testing was performed by Siemens personnel.
3. Number of experts used to establish the ground truth for the test set and the qualifications of those experts (e.g., radiologist with 10 years of experience)
- Number of Experts: Not specified.
- Qualifications of Experts: The testing was performed by "appropriately trained and knowledgeable test personnel." No further details on specific expert qualifications (e.g., medical professionals) are provided, as this was functional and safety testing of software, not a clinical diagnostic study.
4. Adjudication method (e.g., 2+1, 3+1, none) for the test set
- Adjudication Method: Not specified. The verification and validation processes are mentioned but not the specific methods for resolving discrepancies if they arose during testing.
5. 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
- MRMC Study: No, an MRMC comparative effectiveness study was not done. This document describes a software update for a radiation therapy system, not a diagnostic AI tool requiring assessment of human reader performance.
6. If a standalone (i.e., algorithm only without human-in-the-loop performance) was done
- Standalone Performance: The testing described (unit, integration, system integration, and regression testing) is essentially an assessment of the algorithm's functionality and adherence to specifications, which could be considered a form of standalone testing in the context of software validation. However, the document doesn't present "performance" in terms of clinical metrics but rather in terms of meeting functional and safety requirements.
7. The type of ground truth used (expert consensus, pathology, outcomes data, etc.)
- Type of Ground Truth: The "ground truth" for this software validation was the Product Requirements Specifications (PRS) and "previously determined acceptance criteria" specified in system test plans. The software's performance was measured against these predefined functional and safety requirements, rather than against external clinical ground truth like pathology or patient outcomes.
8. The sample size for the training set
- Sample Size for Training Set: Not applicable. This document is about a software update for an existing system, not a machine learning or AI algorithm that would typically require a training set.
9. How the ground truth for the training set was established
- Ground Truth for Training Set Establishment: Not applicable, as there is no mention of a training set or machine learning in the provided document.
Ask a specific question about this device
Page 1 of 1