Search Results

CuriePACS (Dicom PACS Software) Software is a software device that receives digital images and data from various sources (Computed Radiography, Magnetic Resonance Imaging, Ultrasound, Endoscopy, Computed Tomography, Digital X-Ray Mammography, Nuclear Medicine Imaging, Secondary Capture, Radio Fluoroscopy, X-Ray or other Angiograms such as CT Angio). Images and data can he captured, stored, communicated, processed and displayed within the system and or across computer networks at distributed locations. Lossy compressed mammographic images and digitized film screen images must not be reviewed for primary image interpretation. Mammographic images may only be interpreted using an FDA cleared monitor that offers at least 5 Megapixel resolution and meets other technical specifications reviewed and accepted by FDA.

CuriePACS is a comprehensive solution for Dicom imaging needs. This scalable PACS solution provides electronic viewing, storage and communication in a secure environment. The device consists of: 1. Dicom Server (MD Athena) - For storage and connectivity with all the modalities and 2. Image Viewer (MD Vision) - To connect to the server and retrieve images based on search criteria and other workflow requirements. Image modalities supported: CR. CT. DX. MG. MR. NM. RF. SC. US. XA (x-ray), and ES.

The provided FDA 510(k) summary for CuriePACS (K102148) describes a Picture Archiving and Communication System (PACS) software. A PACS system is primarily for viewing, storing, and communicating medical images, and not typically an AI-powered diagnostic device that produces specific performance metrics like sensitivity, specificity, or accuracy in detecting disease. Therefore, the information requested regarding acceptance criteria and a study proving performance in the context of diagnostic accuracy, human reader improvement with AI, or standalone algorithm performance, is not generally applicable to this type of submission.

Instead, the acceptance criteria for a PACS system like CuriePACS would revolve around its ability to:

• Receive, store, communicate, process, and display DICOM-compliant medical images and data from various modalities.
• Maintain data integrity and security.
• Provide image processing tools (e.g., brightness/contrast, zoom, pan, measurements).
• Meet system requirements and compatibility with specified hardware.
• Adhere to relevant regulatory standards (e.g., DICOM 3 compliance).
• Demonstrate substantial equivalence to a legally marketed predicate device.

The study that proves the device meets these types of acceptance criteria for a PACS system is typically a combination of non-clinical tests, primarily focusing on software validation and risk analysis, rather than clinical efficacy studies with patient data.

Here's an attempt to structure the answer based on the provided document and the understanding of PACS submissions:

Acceptance Criteria and Device Performance for CuriePACS (K102148)

Based on the provided 510(k) summary (K102148) for CuriePACS (Dicom PACS Software), the acceptance criteria and the study conducted are focused on its functionality as a PACS system rather than a diagnostic AI device. The primary method for demonstrating safety and effectiveness is through a comparison to a legally marketed predicate device and non-clinical testing.

1. Table of Acceptance Criteria and Reported Device Performance

Given the nature of a PACS software, the "acceptance criteria" are derived from its intended use, technological characteristics, and comparison to the predicate device. "Device performance" refers to its demonstrated capabilities through testing and its stated specifications.

2. Sample Size Used for the Test Set and Data Provenance

The 510(k) summary does not mention a clinical 'test set' with patient data, as this is typically not required for PACS software. The "test set" for this type of device would refer to the internal software verification and validation activities.

• Test Set Sample Size: Not specified in terms of patient data. The testing involves DICOM 3 compliance testing and bench testing (software validation and risk analysis). This typically means the software was tested with a variety of DICOM images (potentially synthetic or anonymized real-world images) and data structures to ensure proper handling, display, and functionality. The number of such test cases or images is not detailed.
• Data Provenance: Not applicable in the context of patient data for diagnostic performance. The data used for testing would be standard DICOM files and simulated scenarios.

3. Number of Experts Used to Establish Ground Truth for the Test Set and Qualifications

This information is not applicable to this 510(k) submission. A PACS system primarily handles and displays images; it does not perform diagnostic interpretation or generate reports that require expert ground truth for evaluating diagnostic accuracy. The "ground truth" for a PACS system is adherence to technical standards (e.g., DICOM) and correct software functionality.

4. Adjudication Method for the Test Set

Not applicable. Since there is no clinical "test set" requiring diagnostic interpretation or a human-in-the-loop component for evaluating diagnostic performance, no adjudication method (e.g., 2+1, 3+1) is mentioned or implied.

5. Multi-Reader Multi-Case (MRMC) Comparative Effectiveness Study

No, an MRMC comparative effectiveness study was not done. Such studies are typically conducted for AI-powered diagnostic aids to assess human reader performance with and without AI assistance. CuriePACS is a PACS system, not an AI diagnostic tool, so this type of study is not relevant to its 510(k) submission. Therefore, no effect size for human reader improvement is reported.

6. Standalone (Algorithm Only) Performance Study

No, a standalone performance study was not done in the context of diagnostic accuracy (e.g., sensitivity, specificity). CuriePACS is not an algorithm that provides diagnostic results; it is a software platform for image management. Its "performance" is evaluated based on its functional compliance and equivalence to a predicate device.

7. Type of Ground Truth Used

The "ground truth" for the testing of CuriePACS is based on:

• DICOM 3 standards compliance: Ensuring the software correctly handles and displays DICOM-formatted images and data according to the industry standard.
• Functional specifications: Verifying that all programmed features (e.g., image manipulation tools, storage, communication) work as intended.
• Risk analysis: Ensuring potential software hazards are identified and mitigated.

There is no "expert consensus, pathology, or outcomes data" ground truth as this device does not perform diagnosis.

8. Sample Size for the Training Set

Not applicable. CuriePACS is a PACS software, not a machine learning or AI algorithm that requires a "training set" of data for model development.

9. How the Ground Truth for the Training Set Was Established

Not applicable. As a PACS software, there is no "training set" in the context of machine learning, and thus no ground truth establishment process for such a set.

Ask a specific question about this device