Search Filters

Search Results

Found 1 results

510(k) Data Aggregation

    K Number
    K212136
    Manufacturer
    Date Cleared
    2021-09-29

    (83 days)

    Product Code
    Regulation Number
    874.3302
    Reference & Predicate Devices
    Why did this record match?
    Device Name :

    Cochlear Baha 6 System, Cochlear Baha Fitting Software 6, Cochlear Baha Baha Smart App

    AI/MLSaMDIVD (In Vitro Diagnostic)TherapeuticDiagnosticis PCCP AuthorizedThirdpartyExpeditedreview
    Intended Use

    The Cochlear™ Baha System is intended for the following patients and indications for use:

    Patient of any age for use with the Baha Softband (or Baha SoundArc. Patients aged 5 and . older for use with the Baha auditory osseointegrated implant system.

    • Patients who have a conductive or mixed hearing loss and can still benefit from sound amplification. The . pure tone average bone-conduction hearing threshold (measured at 0.5, 1, 2, and 3kHz) should be better than or equal to 55 dB HL.
      . Bilateral fitting is intended for patients who meet the above criterion in both ears, with bilaterally symmetric moderate to severe conductive or mixed hearing loss. Symmetrical bone-conduction thresholds are defined as less than a 10 dB average difference between ears (measured at 0.5, 1, 2, and 3 kHz), or less than a 15 dB difference at individual frequencies.

    Patients who suffer from unilateral sensorineural deafness in one ear with normal hearing in the other ear . (i.e. Single-sided deadness: SSD). Normal hearing is defined as a pure tone average air-conduction hearing threshold (measured at 0.5, 1, 2, and 3 kHz) of better than or equal to 20 dB HL.

    Baha for SSD is also indicated for any patient who is indicated for an air-conduction contralateral routing . of signals (AC CROS) hearing aid, but who for some reason cannot or will not use an AC CROS.

    Device Description

    The Cochlear Baha bone conduction hearing system provides an alternate solution for patients who may not benefit from an air-conduction hearing aids. Unlike air-conduction hearing aids, the Baha implant system utilizes a natural bone conduction pathway to send sound directly to the inner ear (cochlea), bypassing a damaged outer or middle ear. The Baha bone conduction hearing system has non-surgical and surgical options. For the non-surgical option, the external sound processor, which converts acoustic sound into mechanical vibrations, is securely placed behind the ear with a Baha Softband or Baha SoundArc. For the surgical option, the external sound processor is coupled with an abutment (Baha Connect) or magnet (Baha Attract). The mechanical vibrations travel the abutment or magnet to a small, titanium implant, which is surgically placed into the bone. The titanium implant has an osseointegrated bond with the surrounding bone, allowing transmission of high-quality sound directly to the inner ear.

    The updates made to Baha Fitting Software 6 and Baha Smart App add Remote Assist capabilities to the previously cleared Baha Fitting Software 6 and Baha Smart App (K202048). The changes introduced in this 510(k) are specific to the fitting software and smart app, and do not affect the cleared Baha 6 Max Sound Processor, Softband, SoundArc, Baha Connect abutments, Baha Attract magnet, or the BI300 titanium implant. Introduction of Remote Assist does not modify the intended functionality or fundamental operating principles of the bone conduction hearing system.

    By introducing Remote Assist, the healthcare professional can:

    • Communicate in real-time via video, audio, or messaging, and ●
    • Connect to and remotely adjust the recipient's Baha 6 Max Sound Processor through the . Baha Fitting Software 6 and Baha Smart App interface.
    AI/ML Overview

    The provided text describes a 510(k) premarket notification for the Cochlear Baha 6 System, specifically focusing on updates to the Baha Fitting Software 6 and Baha Smart App to introduce "Remote Assist" capabilities.

    However, the document does not contain the detailed study information typically associated with acceptance criteria and proof of a device meeting those criteria in the context of advanced AI algorithms for medical image analysis or similar diagnostic tools. The device in question is a hearing aid system, and the "Remote Assist" features relate to remote programming and communication, not to complex diagnostic or predictive AI.

    Therefore, many of the requested points relying on AI-specific study designs (like MRMC studies, expert consensus for ground truth on large image datasets, training set details, or standalone algorithm performance) are not applicable to this document. The provided text primarily focuses on demonstrating substantial equivalence to a predicate device for regulatory clearance.

    Below, I will answer the applicable questions based on the provided text. For those that are not applicable, I will explicitly state so and explain why.


    Device: Cochlear™ Baha® 6 System, Cochlear™ Baha® Fitting Software 6, Cochlear™ Baha® Baha Smart App
    Regulatory Clearance: K212136

    Acceptance Criteria and Device Performance

    The document does not explicitly present a table of predetermined "acceptance criteria" in the format of specific quantifiable metrics (e.g., sensitivity, specificity, AUC values) and then report performance against them. Instead, the "performance data" section focuses on demonstrating functional equivalence and safety/effectiveness compared to a predicate device through various testing types.

    The implicit acceptance criterion for this 510(k) submission is that the updated device, with its new "Remote Assist" functionalities, is as safe and as effective for its intended uses compared to the predicate Baha 6 System.

    Table of Device Performance (Based on provided text's summary of testing):

    Performance AspectReported Device Performance (Summary from text)
    Functional EquivalenceThe updated Baha 6 System, including the updated Baha Fitting Software 6 and Baha Smart App, are functionally equivalent to the cleared Baha 6 System. This was supported by:
    • Software testing of new features.
    • Regression testing of existing functionality (component and system level).
    • Smoke testing.
    • Functional test cases (e.g., measurements and programs).
    • Non-functional test cases (e.g., cybersecurity and deployment).
    • Hazard control verification.
    • System-level integration, performance, and design analysis tests. |
      | User Needs & Intended Use | Design validation demonstrated compliance of the new features with user needs and intended use. |
      | Usability Verification | Summative usability testing was conducted. Participants completed a series of tasks throughout a Remote Assist session, and feedback was collected. The results of this testing supported the overall conclusion of safety and effectiveness. (Specific quantitative results or measures of usability are not provided in this summary, but the general statement implies successful completion). |
      | Safety and Effectiveness | The updates have been shown to be as safe and as effective for their intended uses compared to the predicate Baha 6 System. This is the overarching conclusion of the submission, based on all the testing and comparisons. |

    Study Details (Applicable points only)

    2. Sample size used for the test set and the data provenance:

    • Sample Size: The document does not specify a quantitative sample size for any "test set" in terms of number of patients or cases. It mentions "participants" for usability testing, but no number is given. The testing described is primarily software verification and validation, not a clinical trial with a patient-based test set as might be seen for a diagnostic AI.
    • Data Provenance: Not explicitly stated in terms way data for an AI would be (e.g., country of origin). The testing seems to be internal development and verification. No mention of retrospective or prospective clinical data.

    3. Number of experts used to establish the ground truth for the test set and the qualifications of those experts:

    • Not Applicable. This device is a hearing aid system with remote programming capabilities, not a diagnostic tool requiring expert interpretation of medical images or clinical data to establish a "ground truth" for disease states. The "ground truth" for its functionality is based on its engineering specifications, user needs, and established audiological principles.

    4. Adjudication method (e.g. 2+1, 3+1, none) for the test set:

    • Not Applicable. An adjudication method is typically used in studies involving human readers or multiple experts to resolve discrepancies in ground truth labeling or diagnostic assessments. This type of study design is not described here, as the testing focuses on software functionality, safety, and effectiveness compared to a predicate device.

    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:

    • Not Applicable. An MRMC study is relevant for evaluating the impact of AI on human diagnostic performance (e.g., radiologists reading images with and without AI assistance). This device is not an AI diagnostic tool and its purpose is to provide hearing assistance and remote fitting, not to aid human "readers" in diagnosis or interpretation.

    6. If a standalone (i.e. algorithm only without human-in-the-loop performance) was done:

    • Not Applicable/Implicit. The "algorithm" here is the software that facilitates remote programming and communication for a hearing aid. The performance described (functional equivalence, cybersecurity, etc.) is inherently "standalone" in the sense that the software's core functions are tested. However, this is not an AI algorithm performing a diagnostic task without human intervention; it's a software system designed to be used by both clinicians (human-in-the-loop for programming) and patients for control. The testing confirmed the software's ability to perform its intended functions.

    7. The type of ground truth used (expert consensus, pathology, outcomes data, etc):

    • The "ground truth" for this device's performance is its engineering specifications, functional requirements traceability to user needs, and compliance with general safety and performance principles for medical devices. For example, a "ground truth" for a functional test might be "the software successfully adjusted gain by X dB as per the input, and the sound processor responded correctly." This is based on design documents and expected behavior, not external clinical "ground truth" like pathology.

    8. The sample size for the training set:

    • Not Applicable. This device description does not mention the use of machine learning or deep learning algorithms that would require a distinct "training set" of data for model development. The software is programmatic, not primarily data-driven in its learning capacity at the point of clearance.

    9. How the ground truth for the training set was established:

    • Not Applicable. As there's no stated training set for AI/ML, there's no process described for establishing ground truth for such a set.
    Ask a Question

    Ask a specific question about this device

    Page 1 of 1