Search Results

Smith & Nephew's VISIONAIRE Patient Matched Cutting Blocks are intended to be used as patient-specific surgical instrumentation to assist in the positioning of total knee replacement intra-operatively and in guiding the marking of bone before cutting provided that anatomic landmarks necessary for alignment and positioning of the implant are identifiable on patient imaging scans.

The Smith & Nephew VISIONAIRE Patient Matched Cutting Blocks are intended for use with the following existing Smith & Nephew, Inc. Knee Systems and their cleared indications for use:

• Genesis II Knee System
• Legion Knee System
• Journey BCS Knee System
• Journey II Knee System

The Smith & Nephew VISIONAIRE Patient Matched Cutting Blocks are intended for single use only.

The subject of this premarket notification is to seek FDA clearance of software components to be used in the design and manufacture of the VISIONAIRE Patient Matched Cutting Blocks. Patient Matched Cutting Blocks were previously cleared for market via premarket notifications- K183010. The blocks are designed utilizing the VISIONAIRE Patient Matched Technology software components and patient imaging data (MRI, X-Ray). The blocks are intended to be used as patient-specific surgical instruments to assist in the positioning of total knee replacement implant components intra-operatively and in guiding the marking of bone before cutting.

The provided document, K200826, describes a 510(k) premarket notification for the "Smith & Nephew VISIONAIRE Patient Matched Cutting Blocks." This submission focuses on seeking FDA clearance for software components used in the design and manufacture of these cutting blocks, rather than the blocks themselves or a new AI algorithm for medical image analysis.

The document explicitly states:

• "No new mechanical testing was performed. No implants or new blocks are being introduced in this premarket notification." (Page 4)
• "There are no changes to the block design, packaging, material composition or manufacturing of Smith & Nephew VISIONAIRE Patient Matched Cutting Blocks as a result of these changes described in the premarket notification." (Page 4)
• "Clinical data was not needed to support the safety and effectiveness of the subject device(s)." (Page 4)
• "Software verification and validation testing was completed in line with FDA's guidance document entitled, 'General Principles of Software Validation; Final Guidance for Industry and FDA Staff,' dated January 11, 2002." (Page 4)

Therefore, the provided document does not contain the information requested regarding acceptance criteria and a study proving a device meets those criteria, specifically concerning the performance of an AI-powered diagnostic or decision-support system. The information requested (e.g., acceptance criteria tables, sample sizes for test sets, expert qualifications, MRMC studies, standalone performance, ground truth types) is typical for the validation of AI/ML medical devices that perform tasks like image analysis or diagnosis.

This 510(k) submission is for software changes related to the design and manufacturing process of previously cleared devices (K183010), not for a new AI algorithm that uses medical imaging directly for diagnostic or assistance purposes in the way implied by the questions. The software validation mentioned is general software validation (e.g., unit testing, integration testing, system testing) to ensure the software performs its intended function in designing the blocks correctly, not a clinical performance study with human readers or an AI-only performance study against ground truth established by experts.

To answer your request, if this were an AI medical device, the following information would be expected:

1. A table of acceptance criteria and the reported device performance: This would typically define metrics like sensitivity, specificity, AUC, or accuracy, along with objective thresholds that the device's performance must meet.
2. Sample sizes used for the test set and the data provenance: Details on the number of cases (e.g., scans, patients) in the test set, where the data came from (e.g., specific hospitals, demographics), and whether it was retrospectively collected or prospectively collected.
3. Number of experts used to establish the ground truth for the test set and the qualifications: How many domain experts (e.g., board-certified radiologists) reviewed the test cases to establish the definitive diagnosis or finding, and their experience levels.
4. Adjudication method for the test set: How disagreements among experts in establishing ground truth were resolved (e.g., majority vote, consensus meeting, senior expert review).
5. If a multi reader multi case (MRMC) comparative effectiveness study was done: Whether human readers were evaluated with and without the AI assistance, and the statistical significance of any improvement in their performance.
6. If a standalone (i.e. algorithm only without human-in-the-loop performance) was done: The performance metrics of the AI algorithm operating independently of human review.
7. The type of ground truth used: Whether ground truth was derived from expert consensus, histopathology, long-term patient outcomes, or another definitive method.
8. The sample size for the training set: The number of cases used to train the AI model.
9. How the ground truth for the training set was established: The process by which the training data was labeled and verified.

Since the provided document is not for an AI diagnostic device in the traditional sense, it lacks these specific details. The software in question essentially aids in the manufacturing design of a physical device, based on patient imaging data, rather than performing an interpretive or diagnostic function on the imaging itself.

Ask a specific question about this device