It’s his 14th birthday, and your teenage son is exhilarated, exhausted, but still exclaiming, “Wow, that is so cool!” He has just spent the day on the new computer game you gave him—a 3D extravaganza of sight, sound, and action that has captivated him for the past 10 hours.

The challenge before us is to achieve even a fraction of such positive energy with a computer application as mundane as programming a hearing aid. Right now you’re saying, “You’ve got to be kidding me.” But bear with us. While a gamer’s level of enthusiasm is unrealistic, perhaps we can achieve at least a glimmer of that attitude with the software capabilities used to program modern hearing instruments.

Recent developments in digital hearing aids and their fitting systems parallel the growing role that software and firmware play in many consumer products and services, such as computers, cell phones, navigation devices, games, toys, ATMs, grocery stores, the Internet, e-mail, and medical monitoring, to name just a few. Digital functionality has become so integrated into our everyday lives that we hardly even notice anymore.

Along with the penetration of software-driven products, the expectations of consumers have been elevated. Indeed, the mind-set of sophisticated consumers is that technology advances rapidly; they expect things to keep improving, and the hearing aid manufacturing and dispensing communities are expected to meet that challenge.

Hearing instrument programming software has risen to a higher plane in recent years, and today’s software differentiates products and manufacturers, based on both the benefits it yields and the impression it creates. Software is no longer just a fancy screwdriver. It has the potential to affect not only the operation and benefits of hearing aids, but also the mind-set of the person wearing those hearing aids and the dispensing professional fitting them. It must combine scientific rigor with engineering elegance and an eye to design. Software has the potential to delight.

This article will outline the basic job requirements of hearing aid programming software and then illustrate how software can exceed those expectations. Readers interested in some of the history leading up to current developments are referred to the sidebar.

Basic Goals of a Hearing Aid Fitting

The basic goals of a hearing aid fitting include audibility, intelligibility, comfort, good sound quality, and ultimately wearer satisfaction.

Audibility across the required frequency range is the starting point for any hearing aid fitting. Along with audibility, we can also expect improved speech intelligibility. While good audibility may compromise comfort, simply because both signal and noise become audible, modern noise control algorithms have the potential to maintain comfort over a widening range of input levels and noise types. Good sound quality, as judged by the wearer, may not always accompany audibility, but modern instruments can balance these sometimes disparate goals better than ever. Ultimately, if the combination of these factors adds up to patient satisfaction, patients will hopefully keep the instruments in their ears, not in a drawer.

Beyond the Basics of Software Goals

While software control of hearing aid operation is essential and widely re­ported,1-7 adjustment of the hearing aid per se is not the topic of this paper. Instead of the usual discussion of what the hearing aid can do, we will focus on what software can do beyond the fitting.

We are setting forth a more challenging goal: instead of just satisfying a patient, let’s aim to delight that patient. And, while we’re at it, let’s delight the hearing care professional as well.

If we asked you to list the things you look for in selecting hearing aid programming software, beyond the basic fitting adjustments, you could create a long list. It may be possible to condense this wish list into the following five categories of goals:

  1. Maximize efficiency.
  2. Provide objective data to guide hearing aid adjustments.
  3. Optimize the use of technology, while minimizing workload.
  4. Build patient confidence.
  5. Assist in patient counseling.

To illustrate how modern software achieves these goals, the following sections sample some of the features of Starkey’s Inspire OS software system. Attached to each heading is a list identifying which of the above goals each feature supports. This is not an exhaustive discussion of Inspire OS features; rather, it highlights the stars in the software cast, with an occasional brief mention of some of the vital supporting players working behind the scenes.

Manufacturers competing in the current hearing instrument market have done an admirable job of designing excellent software. The examples we are using here are just that: examples. Although we hold the competitive systems in high regard, a thorough review and comparison of all software features are beyond the current scope (and space requirements) of this article.

Software development is not a small task. To make the Inspire OS platform, 25 people worked for 24 months, creating more than a million lines of software code. A sampling of their achievements will be presented here (to see an interesting e-mail string about the development of the software, read the “Software Magnitude and Milestones” sidebar at the end of this article).

Evidence-based Software Development

In recent years, a high level of importance has been placed on evidence-based approaches to product development, an approach that applies equally to creating hearing instruments and to creating software to support those instruments.8-11

FIGURE 1. Multi-Function Slider in Inspire OS software controls many variables in a confined space, requiring minimal cursor movement.

Evidence-based design principles have been used in the development of the Inspire OS software platform, and in this case the evidence consisted of what hearing professionals want and need. A customer request list of features and functionality was regularly generated, updated, and reviewed. Several customer surveys, internal focus groups, and cross-functional review teams, consisting of audiologists and engineers, all provided input before and during the software development process. Progress was monitored through customer focus groups using prototype software and direct observation of customers using the software in their offices and at Starkey.

The result of these data collection and development efforts is a software package embodying features that are designed to be meaningful and desirable, not frivolous or idiosyncratic. Fitting software must offer flexibility that is powerful, yet not overwhelming. Ultimately, the software should reflect the practical priorities of the professionals who are using it. Those priorities include speed, ease of use, and a logical flow from one operation to the next. Much of the software fine-structure in Inspire OS aims to achieve these goals, such as a Navigation Panel to select features and operations and a nearly instantaneous read/write capability.

One example that deserves special mention is Inspire’s slider controls (Figure 1). From a human interface perspective, anything that reduces the number and length of cursor movements will improve efficiency. A Multi-Function Slider in Inspire OS maximizes the efficiency of adjusting several parameters—overall channel gain, channel gain for high input levels, channel gain for low input levels, and compression ratios, in one or both ears—by containing them in a small space that requires minimal cursor movement. The slider expands when the cursor hovers over it, changing from the view on the left of the figure to that on the right.

FIGURE 2. Measured real-ear responses displayed on Inspire OS software screen. Graphs show responses to 50 (blue), 70 (green), and 90 (purple) dB SPL inputs. The dashed black line represents the maximum output of the instrument.

Integrated real-ear measurements and speech mapping (Goals addressed: 1-5). Any hearing professional who adheres to principles of evidence-based practice appreciates objective data about hearing aid operation. The Integrated Real-Ear Measurement capability of the Destiny 1600 provides an accurate model of the hearing aid’s real-ear aided response (REAR). By measuring the real-ear coupler difference (RECD) through the hearing aid in the patient’s ear, which takes only seconds, the software calculates a more accurate model of the REAR (Figure 2) for this individual’s ear, rather than for a hypothetical average ear.7 The Integrated REM in Destiny 1600 not only offers objective data (goal #2) but does so rapidly (goal #1) and with minimal effort (goal #3).

FIGURE 3. Speech Mapping shows the real-time responses to live speech (black line is patient’s hearing thresholds in dB SPL; purple is real-time input to hearing aid; pink is real-time hearing aid output; thin green line is prescriptive target output for a 70-dB SPL input; bold green line is hearing aid response matching target).

The Speech Mapping feature (formerly SoundView) generates a graphic display of the hearing aid response to any live input. In a typical scenario, one might ask a family member to speak. The acoustic characteristics of that voice at the input and the output of the hearing aid are viewed on screen in real time (Figure 3) and may be compared with the patient’s hearing thresholds or prescriptive targets. Speech Mapping helps a patient and family understand the nature of the hearing loss and the function of hearing aids (goal #5) and build their confidence in the technology (goal #4). When used with the custom RECD of a Destiny 1600, Speech Mapping displays the hearing aid output calibrated in each patient’s ear.

Datalogging (Goals addressed: 1, 2, 4, 5). When you ask patients at a follow-up visit how their new hearing aids have been performing for the past 2 weeks, the information you get back is vague at best. Most modern hearing instruments have some form of datalogging capability to objectify such reports.

The Data Log in the Destiny instrument and Inspire OS software (Figure 4), for example, quantifies the acoustic environment in which the patient is using the instruments (input levels, percent of time in different acoustic environments) and the ways in which the patient uses the instruments (use time, average VC setting, percent of time in different memories). Furthermore, if the Data Log sees an opportunity to improve patient benefit by adjusting any of the software presets in the aid, it will offer recommendations to the operator in the Data Log report. This tool can transform the hearing professional’s decision-making from dependence on subjective reporting and guesswork to a data-based decision-making process.

FIGURE 4. Sample Data Log report for a Destiny 1600 hearing instrument.

Self-diagnosis (Goals addressed: 1, 2, 3). The Self Check feature in the Destiny 1600 provides self-diagnosis of the integrity of the hearing aid microphone, receiver, and circuit. A baseline measurement at the time of the fitting establishes a performance reference, and subsequent diagnostic measurements check component integrity relative to that baseline.

The software displays the Self Check results on screen (Figure 5) when the hearing aid is attached to a programming cable. Alternatively, the hearing professional can enable a patient-run Self Check option, which presents an acoustic signal through the hearing aid to indicate when the instrument needs attention. Activating this option (only recommended with select patients) adds goal 4, building patient confidence, to the list of benefits.

FIGURE 5. Self Check screen display, showing integrity of microphone, circuit, and receiver.

Voice indicators (Goals addressed: 3, 5). Some software can program a hearing aid to emit a tone in order to signal a variety of conditions: low battery, program change, target volume setting, etc. Replacing those tones with speech signals, an option in the Destiny 1600, improves the clarity of the message, reduces reliance on the patient’s memory, and builds patient confidence in their handling of the instrument.

For adjustment and demonstration purposes, Inspire OS calls up graphic icons representing the indicators on an audiogram displaying patient thresholds. Clicking the icon plays a sample of the Indicator through the hearing aid for the patient and through the PC speakers for the spouse or significant other. An added bonus is the extensive array of voice options—more than 20 languages with both male and female voices.

Environmental simulations and demonstrations (Goals addressed: 2, 4, 5). Realistic demonstrations can improve a patient’s understanding of what hearing aids can do and how to use them. Surround Town, for example, is an acoustic virtual reality, created by the Inspire OS software and presented through a 5.1 surround sound system. It lets the operator control a variety of sound sources in several different environments (Figure 6) to demonstrate specific hearing aid features.

Instead of just hearing instructions from the hearing care professional, the patient experiences the benefits of proper hearing aid use and communication strategies aurally and visually, as if they were actually in different acoustic environments. In some cases, it allows the professional to recreate a problematic situation to pinpoint the source of a complaint.

FIGURE 6. Example of one acoustic environment created by Surround Town. The hearing aid wearer’s virtual position (the green figure in the middle) and a variety of sound sources can be changed to simulate this outdoor situation.

Hearing loss simulators (Goals 4, 5). Hearing loss simulators can help patients and families understand the implications of a hearing loss, an important goal in hearing rehabilitation. The Hearing Loss Simulator in Inspire OS, scheduled for release in spring of 2008, will simulate any degree and shape of hearing loss, including that of the patient. The dispensing professional can activate a number of real-world sounds to be heard through the simulated loss, with each sound represented on a customizable three-dimensional display. Family members listening to these simulations gain insight into the patient’s auditory experience, an important factor in helping them participate fully in the rehabilitative effort.

Automatic tasking (Goals addressed: 1, 3). With so many new features in modern instruments, hearing care professionals are tasked with managing numerous steps to ensure their full utility. In the case of the Destiny 1600, for example, at the time of the fitting, to gain maximum benefit from the technology, a hearing professional must run the Integrated Real-Ear calibration, initialize the Active Feedback Intercept, perform a Best Fit based on the patient’s audiogram, set the Self Check baseline, reset the Data Log, perform verification with Speech Mapping, and set programmed Reminders. These tasks are added, of course, to other time-consuming steps of talking to the patient about hearing aid features, ensuring that basic fitting goals are achieved, completing paperwork, counseling patient and family on hearing aid use and communication strategies, and so on.

The Accuracy and Clinical Usefulness of Manufacturer-Predicted REAR Values in Adult Hearing Aid Fittings,” by Nancy L. Aarts, PhD, and Carrie S. Caffee, MS. November 2005 HR Archives.

How to Use Live Speech Mapping as Part of a Hearing Instrument Fitting and Verification Protocol,” by Terry Ross and Kenneth E. Smith, PhD. June 2005 HR Archives.

To streamline the process and ensure that no steps are missed, Inspire OS offers a protocol called Auto Path, which automatically executes all six of these steps in logical order, prompting the hearing care professional as needed until completion. It does all of this in 90 seconds (binaurally) and guarantees that no steps are missed along the way. Professionals using Auto Path have reported reduction in time needed to complete an initial fitting, leaving more time for patient counseling.


Fitting software programs hearing aids better than ever before. But that’s not all it does. Modern software has great potential to improve efficiency, guide fitting adjustments with objective data, maximize technology while minimizing workload, build patient confidence, and assist in patient counseling. It also combines rigorous scientific algorithms with efficient, elegant design, and a dedication to improving patient counseling and increasing confidence.

Speed, ease, and usability are essential to the video game operator we met at the beginning of the article. The gamer would not think of using software that slowed the action. Now, with modern hearing aid programming software, there is likewise no reason for hearing care professionals to operate without these same benefits.

This article has described only a few examples of software features that approach these goals, and the authors have attempted to place them into an historical perspective. The motivated hearing care professional will continue to monitor the expanding array of applications to improve the patient experience and resulting benefits. And keep an ear out for that call from the fitting room, in the voice of either a hearing professional or a patient, “Oh, wow, that’s so cool!”

How Did We Get Here?

An historical perspective on hardware and software

Analog to digital. From the 1920s through the 1970s, all hearing aids used analog circuitry for their amplifier electronics. Electrical fitting adjustments, when available, were typically made by replacing modularized discrete components such as button receivers or capsulized resistors and later by turning potentiometers with screwdrivers.

Manufacturers began to incorporate programmable memories in hearing aids in the mid-to-late 1980s. Although the amplifier circuitry was still analog-based, potentiometers were no longer needed to adjust and retain settings. Instead, programmable re-writable digital chips in the hearing aids permanently stored parameter settings. These early digitally programmable (analog) instruments, as they were called, had only a few adjustable parameters, such as overall gain, maximum output sound pressure level, and high and low frequency response.

In the years before the personal computer became popular, fitting adjustments were often made with manufacturer-specific, dedicated hardware-based devices that controlled the hearing aids. They allowed the wearer to compare different stored settings in different listening environments to select the best one.11 Frequently, different settings were used for listening in quiet, in noise, and on the telephone. Hearing professionals came to know these stored settings as programs or memories, leading to some terminology confusion. In addition, practitioners could select from several prescriptive programming methods, such as NAL-R, POGO, or DSL[i/o].

In the early 1990s, hearing aid manufacturers began replacing digitally programmable analog devices with the first digital or DSP (digital signal processing) hearing aids. Initially mimicking analog functionality, with time digital processing began to dramatically extend the capability of hearing aids to include multichannel algorithms for compression, feedback cancellation, noise management, and directionality. As these features continued to evolve, the software used for fitting and adjusting the hearing aids became more sophisticated, allowing dispensing professionals to adjust dozens of parameters if they wished, or dared, to do so.

These software developments were paralleled by an increase in the use of personal computers, the birth of universal programming interfaces like HI-PRO (Madsen Electronics), and the advent of the NOAH software management program in 1993 (Hearing Instrument Manufacturers Software Association, HIMSA).11 Instead of using dedicated hardware in a remote control for programming one brand of hearing aid, NOAH allowed the same computer to access multiple manufacturers’ fitting software to program a variety of hearing aids.

Gradually, the software running on the PC and the firmware running inside the hearing aid—which controls signal processing algorithms in the aid—have become increasingly important compared to the hardware.12 Today, because almost all hearing aids are digital, professionals think less about what circuitry is inside a hearing aid than they did in the days of analog amplifiers. Indeed, digital integrated circuits are so flexible that they can be designed with entirely different features by different manufacturers, because they are differentiated by firmware inside the hearing aids and the design of the software interface.

Technology adoption in the software marketplace. Like other cutting edge developments, the cycles of development, deployment, and adoption of new hearing aid fitting software follow a technology adoption cycle.13,14 Namely, the rate of technology adoption never equals the rate of technology creation.

Different groups adopt technology at different rates and are categorized as Innovators, Early Adopters, Early Majority, Late Majority, and Laggards. To reach its current penetration of the mainstream market, fitting software has already matured to a great extent, after undergoing hundreds of hours of internal testing by manufacturers, plus alpha trials and beta field trials to ensure that it is working smoothly.

While digital hearing aids and the software to drive them are well established, the remaining challenge is to help each group adopt new features as they are developed. If new hearing aid features and computer technologies are developed, then in some cases the software may depart radically from previous software that practitioners are already comfortable using. To move forward, manufacturers must be ready to support all groups of existing customers.

Let us consider only the Early and Late Majorities. The Early Majority consists of pragmatists, whereas the Late Majority is made up of conservatives. The pragmatists are interested generally in incremental improvements to existing products and won’t buy from a manufacturer unless the company and product are well established. Pragmatists are not pioneering types and do not like much risk. However, once pragmatists are “on board” and succeeding with a product, they are quite loyal, and, as such, are frequently viewed as leaders by the Late Majority conservatives. These conservatives then adopt the new technology and are kept happy by relatively small feature additions and enhancements to existing software, whereas pragmatists are usually looking for larger changes. Conservatives prefer “plug and play” software that does not require special knowledge and extra operations.

As hearing aid capabilities improve, transferring those capabilities to the end user requires that as many groups as possible adopt the new features, and it is the manufacturers’ responsibility to encourage that process. One consideration in determining the amount of support required is the degree of computer literacy and ease of upgrading. Conservatives generally require more support than pragmatists since operating the software may not be as intuitive for them. It behooves hearing aid manufacturers to pay close attention to any operational issues early on and to build into the fitting software ways to avoid them, while also satisfactorily addressing the software users’ needs.

Other steps can help with transitioning from old to new software. For example, offering different levels of software functionality, ranging from simple and straightforward to complex and full-featured, can help create a good comfort level. Easy access to assistance is also important. In Inspire OS, clicking on a Starlink icon activates live online assistance from Starkey headquarters to address issues in a timely fashion.

Driving hearing aid functionality with firmware and software opens up another important possibility: the ability to update designs without changing hardware. For example, the latest Inspire OS software can be automatically upgraded online, and the firmware of Destiny hearing aids upgraded simply by hooking them up to that new software. This powerful capability allows patients and practitioners to benefit from the very latest developments. One more deterrent to technology adoption, the extra effort needed to upgrade, is thus removed.


  1. Yanz JL, Olson L. Open-ear fittings: an entry into hearing care for mild losses. Hearing Review. 2006;13(2):48-52.
  2. Merks I, Banerjee S, Trine T. Assessing the effectiveness of feedback cancellers in hearing aids. Hearing Review. 2006;13(4):53-57.
  3. Howes C, Olson L. The role of virtual reality in hearing instrument fittings. Hearing Review. 2006;13(5):60-63.
  4. Banerjee S, Recker K, Paumen A. A tale of two feedback cancellers. Hearing Review. 2006;13(7):40-44.
  5. Olson L, Pisa J. Large-scale beta clinical trial of a new hearing aid system. Hearing Review. 2006;13(10):50-56.
  6. Banerjee S, Olson L, Recker K, Pisa J. Efficacy and effectiveness of a pattern-recognition algorithm. Hear Jour. 2006;59:10:34-41.
  7. Yanz JL, Pisa JFD, Olson L. Integrated REM: real-ear measurement from a hearing aid. Hearing Review. 2007;14(5):44-51.
  8. Bentler R, Eiler C, Hornsby B, Moodie ST, Olson L, Valente M. Practical approaches to evidence-based practice. Hearing Review. 2007;14(6):36-41.
  9. Yanz JL. Panelists challenge “conventional wisdoms” on hearing aid design. Hear Jour. 2006;59(3):36-44.
  10. Bentler RA, Yanz JL. Hearing aid manufacturers’ panel to discuss evidence-based design. The HJ AudiologyNOW! Special Edition. April 2007.
  11. Cox R, et al. Special Issue: Evidence-based Practice in Audiology. J Amer Acad Audiol. 2005;16(7):410-522.
  12. Vonlanthen A, Arndt H. Hearing Instrument Technology for the Hearing Healthcare Professional. Clifton Park, NY: Delmar; 1995:125-129.
  13. Preves D. Digital Signal Processing for Hearing Aids. Livonia, Mich: International Hearing Society; 2006:2, 8-9.
  14. Moore GA. Crossing the Chasm: Marketing and Selling Disruptive Products to Mainstream Customers. New York City: Harper Business Essentials; 2002.
  15. Yanz J, Preves D. Assessing the feasibility of Bluetooth in hearing rehabilitation. Hear Jour. 2007;60(11):52-60.

This article was submitted to HR by Jerry Yanz, PhD, senior staff audiologist; David Preves, PhD, senior staff engineer; and Christopher Howes, product manager of fitting software, at Starkey Laboratories, Eden Prairie, Minn. Correspondence can be addressed to [email protected] or Jerry Yanz, PhD, Starkey Laboratories Inc, 6700 Washington Ave S, Minneapolis, MN 55344; e-mail: .

Software Magnitude and Milestones

The follow email string grew over a 24-hour period, prompted by a request to describe the magnitude of the software development effort that led to the initial release of Inspire OS in spring, 2006.

From: LW
Sent To: RD
Subject: claims

Hey, I’ve heard you make the statement a few times where you compare the number of lines of code to run the space shuttle to lines of code in Inspire…what is the comparison?

From: RD
Sent To: LW
Cc: TL, AP, NB, DE, DM, GC, JK
Subject: RE: claims

Hi L, I’m replying with a few more of the team on this as I’m not a great marketing person 🙂

  1. D, did you get a chance to ask G about lines of code? Maybe we can wag our lines of code and provide some interesting facts.
  2. Some points from me…
    • This project could be called the birth of a fitting system.
    • The system was designed ground up from scratch with the latest PC technologies.
    • The system was a group (software, hrt) effort…a true collaboration between audiologists and software engineers.
    • We could pull budgetary dollars if you wanted to show some estimated costs of development. I think the figure would be spooky.
    • For me, the cool factor comes from being able to build a system ground up, utilizing the some of the latest available technologies and completely new Software Engineering Development Process (SCRUM).
    • The system will be a platform for us to develop functionality for years to come.
    • It was one of the few systems developed using a Graphics Artist (N, could you estimate the number of images (buttons, screens, etc) that you have developed for the various locales?
    • It was created using a new Internet-based state-of-the-art translation tool that allows the system to be developed in many different languages.
    • N will be submitting the system after it is released for some various graphics/ui awards (no, we haven’t won them yet but we will :-)). And finally…
    • The system has caused the2 VP of Software Engineering, during the past 6 months alone, to fill a large bowl on his cupboard with wine corks and a recycling bin full of Gray Goose vodka bottles :-).

Team…I’m sure you can add some other really cool facts for L to help her out.

From: GC
Subject: RE: claims

As far as source code today, the line count is 826,227 with unit testing code included. This is raw lines of executable code, without documentation (code comments and so forth).

From: RD
Sent To: GC
Cc: LW, TL, AP, NB, DE, DM, JK
Subject: Re: RE: claims

Cool…with doco…bet we are past 900,000 lines…add in CAT also…

From: DM
To: RD, GC
Cc: LW, TL, AP, NB, DE, JK
Subject: RE: RE: claims

The shuttle has “over 250,000 lines of code.”

From: JK
Sent To: DM, RD, GC
Cc: LW, TL, AP, NB, DE
Subject: RE: RE: claims

R, you insult our code documentation efforts. 🙂 I’m sure we have over 1,000,000 if you include comments.
Here are some more facts:

  • We recompile the software about twice a day average. Each time it is compiled, there are 2600 different tests which automatically get run on 3 full-time testing computers taking 40 hours total (per compile).
  • We have 25 people at 2.25 years of effort, meaning we have about 55 man-years of development into Inspire (not counting DSP, Apps, Training).
  • We have 27 catalogs worth of products and options available in 19 different languages.
  • Each of those 19 languages had to translate 3200 strings.
  • Each catalog has 2115 product/style/matrix/circuit combinations you can order.
  • And lastly, during the development of Inspire:
    • 4 babies were born (B, K, P, E). (Did I miss any?)
    • JS consumed 1303 cans of Mountain Dew.
    • JG consumed a 1024 oz. jug of powdered protein mix, adding 50 pounds of body mass.
    • HJ baked 45 pans of goodies to share.
    • CH hit 6240 golf balls.
    • AP bought 25 pairs of shoes, fractured 4 bones, and only blew up 1 car engine.


From: LW
Sent To: JK, DM, RD, GC
Cc: TL, AP, NB, DE
Subject: RE: RE: claims

HAHAHA—ok this one wins!