Search Results
Found 1 results
510(k) Data Aggregation
(69 days)
RadUnity receives medical images from CT imaging acquisition devices adhering to the DICOM protocol for image transfer. RadUnity performs image management and digital image processing (centralized specification and reformatting) on the data. The processed images are transferred using the DICOM protocol to other devices supporting this standard protocol.
RadUnity is indicated for use by qualified radiology professionals and specialists.
RadUnity is not intended for primary diagnostic review. RadUnity is not intended for mammographic image review or interpretation.
RadUnity is stand-alone software device (SaMD) which allows centralized specification, management, standardization, and networking of CT images. RadUnity's software ingests DICOM CT image data and reformats them according to predefined user preferences.
Radunity processes industry standard DICOM imaging studies. Currently, the RadUnity solution only processes computed tomography (CT) images. The data may flow into the system from PACS, a post-processing system, or any DICOM node (e.g., directly from a modality unit). The data is transferred for image processing and standardization. The data is then routed to user defined DICOM destinations and output in DICOM format.
RadUnity is fundamentally a workflow management system which performs image processing and standardization which allows the clinical user to view the CT images with consistent formatting.
RadUnity provides the user with the ability to duplicate current clinical workflow steps required to generate images for qualified clinician interpretation that may involve automatic or manual steps. The RadUnity solution requires manual user interaction to generate and route images to DICOM destinations for qualified clinician interpretation.
The input DICOM images needed for RadUnity are referred to as "source volumes". These source volumes are commonplace in the radiology community today (e.g., lung or bone reconstructions) and contain the needed information to create soft tissue and other thicker slice and lower resolution image volumes.
The provided document is a 510(k) Summary for the RadUnity (Version 1.0.0) device. This type of submission focuses on demonstrating substantial equivalence to a predicate device, rather than providing detailed acceptance criteria and studies for novel performance claims.
The document indicates that RadUnity is a software medical device (SaMD) that receives, processes (centralized specification and reformatting), and transfers medical images (CT only) using the DICOM protocol. It is intended for use by qualified radiology professionals and specialists and not for primary diagnostic review.
Therefore, the information regarding acceptance criteria and the study proving the device meets these criteria is not explicitly detailed in the provided text in the manner one might expect for a device with a diagnostic claim (e.g., sensitivity, specificity for detecting a specific condition). The regulatory submission focuses on demonstrating that the device functions similarly to cleared predicate devices for image management and processing.
However, based on the non-clinical performance testing and software verification and validation section, we can infer some aspects of "acceptance criteria" through the lens of substantial equivalence.
Here's an attempt to answer your questions based on the available information:
1. Table of Acceptance Criteria and Reported Device Performance
The document does not provide a table of quantitative acceptance criteria (e.g., specific accuracy metrics) and corresponding reported device performance for RadUnity in its own right, because it is not intended for primary diagnostic review. Instead, the document discusses aspects of "equivalence" to predicate devices.
The "performance" is generally described in relation to its functional equivalence to predicate devices:
| Acceptance Criteria Category (Inferred from Equivalence Discussion) | Reported Device Performance (Inferred from "SE Discussion") |
|---|---|
| Intended Use Equivalence | RadUnity is equivalent to the primary predicate (AquariusAPS server) and secondary predicate (Centricity PACS-IW with Universal Viewer) in receiving, processing, managing, and transferring DICOM CT images. Differences (RadUnity only processes CT, not other modalities) do not raise new questions of safety or effectiveness. |
| Technological Characteristics Equivalence | Device Type: Same as predicates (SaMD). |
| Operating Environment: Equivalent to predicates (local web browser-based GUI communicating to local image processing server). Minor differences do not raise safety/effectiveness concerns. | |
| Computer Hardware: Equivalent to predicates (industry standard computer hardware). Minor differences do not raise safety/effectiveness concerns. | |
| Operating Systems Supported: Equivalent to predicates (Microsoft Windows, Internet Browser). More current versions but equivalent functionality. | |
| Functional Equivalence | Graphic User Interface: Equivalent to predicates (Web browser based). Minor differences do not raise safety/effectiveness concerns. |
| Image Input Type: Equivalent to predicates for DICOM CT images (RadUnity does not require other DICOM types). No new safety/effectiveness questions. | |
| Interoperability: Equivalent to predicates (receive/transfer DICOM CT images using DICOM protocols). Minor differences do not raise safety/effectiveness concerns. | |
| DICOM Tag Processing | Equivalent to predicates (capable of performing actions based on DICOM tags). Minor differences do not raise safety/effectiveness concerns. |
| Image Presentation/Generation Settings | Equivalent to predicates (control image generation and presentation settings, like 'Profiles' functionality being similar to 'Smart Reading Protocols'). Minor differences do not raise safety/effectiveness concerns. |
| Image Management | Equivalent to secondary predicate Centricity PACS-IW's 'Smart Reading Protocols' (configuring source volume specific profile mapping and applying to future images). |
| Image Processing Functionality | Equivalent to predicates (Filtering, Smoothing, Edge Enhancement, MPR, MIP, MinIP). Minor differences do not raise new questions of safety and effectiveness. |
| Image Export | Equivalent to predicates (export reformatted images/sequences to DICOM capable destinations). Minor differences do not raise safety/effectiveness concerns. |
| Automation Functionality | Equivalent to primary (Autobatch) and secondary (Smart Reading Protocols) predicates (e.g., 'Profile' functionality for layout, series placement, automatic post-processing). |
| Software V&V & Cybersecurity | Design requirements successfully met, intended use and user needs validated. Conforms to FDA's cybersecurity guidance and DICOM standards. |
2. Sample size used for the test set and the data provenance (e.g. country of origin of the data, retrospective or prospective)
The document states: "No clinical performance data was necessary to claim substantial equivalence."
This indicates that clinical data (and thus a clinical test set with specific sample sizes from a particular provenance) was not used or required for this 510(k) submission. The evaluation was primarily based on non-clinical performance (software verification and validation) and comparison to predicate devices.
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)
Given that no clinical performance data was necessary, and RadUnity is not intended for primary diagnostic review, there is no mention of a test set with ground truth established by experts in the provided text.
However, for Usability validation testing, it is mentioned that it "was performed by U.S. Board Certified Radiologists." This suggests experts were involved in testing the usability of the device, but not for establishing ground truth on image content for diagnostic purposes.
4. Adjudication method (e.g. 2+1, 3+1, none) for the test set
Since no clinical test set for diagnostic performance or ground truth establishment is mentioned, there is no information on adjudication methods.
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
No MRMC comparative effectiveness study was done or mentioned. The device is not intended for primary diagnostic review, and its purpose is image management and processing. Therefore, human reader improvement with/without AI assistance is not a relevant metric for this specific device.
6. If a standalone (i.e. algorithm only without human-in-the loop performance) was done
The document discusses "Software verification and validation testing," which would encompass standalone algorithm performance testing against design requirements. While the specifics of these tests are not detailed, the statement "The software verification and validation testing verified that the design requirements were successfully met. The Intended use and user needs were successfully validated" indicates that the algorithm's functional performance was evaluated.
The device itself, as "RadUnity's software," performs the image processing and reformatting functions. This is inherently a standalone algorithmic function, though it requires "manual user interaction to generate and route images to DICOM destinations for qualified clinician interpretation."
7. The type of ground truth used (expert consensus, pathology, outcomes data, etc)
For the software verification and validation, the "ground truth" would be the design requirements and expected functional outputs of the software, as opposed to clinical ground truth derived from pathology or expert consensus on a disease. The output of RadUnity is processed images reformed and standardized according to user preferences, which are then transferred to other devices for interpretation.
8. The sample size for the training set
No information about a training set is provided. RadUnity's function is image processing and reformatting based on predefined user preferences and DICOM standards, not a machine learning model that would typically require a training set. If there's an underlying AI component (which isn't explicitly stated but could be implied by "digital image processing" in some modern contexts), the training data details are not included in this summary.
9. How the ground truth for the training set was established
As no training set is mentioned, no information is provided on how ground truth for a training set was established.
Ask a specific question about this device
Page 1 of 1