Abstract
Introduction
It is estimated that by the year 2025 there will be 700 million individuals worldwide with hearing loss. According to the National Institute on Deafness and Other Communication Disorders of the National Institutes of Health, roughly one-third of Americans over 60 years of age and one-half of those over 85 years of age have hearing loss. 1,2 These numbers pose a tremendous demand for hearing healthcare services. Tele-audiology, by making diagnostic hearing test services more accessible, presents a potential solution to the pressing needs.
Among several tele-audiology research projects, 3 –17 the authors have developed a browser-server–distributed pure-tone audiometry-only system. 15 –17 The central application server in this system hosts all the required software, with minimum hardware and software resource requirements added to the audiology clinic and patient client sites. These “thin clients” had the advantage of separating technical issues from clinical services and ultimately enhanced end-user convenience. Due to several technical challenges, this pure-tone threshold test-only prototype did not incorporate other test procedures required for in-depth diagnosis (i.e., speech test, 18 otoacoustic emissions, 19 and tympanometry 20,21 ). Specifically, unlike the pure-tone threshold, which can be collected by simply asking a patient to respond to single-tone voices heard from a headset with some simple signals (raising a hand or pressing a button), other hearing test procedures involve more profound operations. In a speech test, for example, not only does the audiologist need to operate the audiometer (AMT) with commands, but also the audio signals generated by the AMT and the patient's repeating voices both have to be returned to the audiologist, involving much more complicated real-time data exchange.
With these technical challenges addressed, this article presents a new system that can support both speech tests and pure-tone audiograms. Several characteristics in this comprehensive system support the involved interactions required for speech tests: 1. The new system adopts the same browser–server architecture used in its preceding version; therefore it handily inherits all the user convenience features. 2. Newly developed hardware and software support the exchange of both numerical and audio data required during speech tests between the audiologist and patient sites. 3. An auxiliary communication scheme with audio and video capacities boosts coordination among the medical professional, the patient, and the assistant who assists patients at the remote site.
The rest of the article is organized as follows: Materials and Methods describes the system architecture and its major components, with a focus on how such a system meets the technical needs for multiprocedure hearing tests. Results reports its clinical effectiveness from a comparison study conducted at an audiology laboratory at East Carolina University. Discussion comments on several items observed during this design–implementation–test cycle. The article is then concluded with ideas for future work planned ahead.
Materials and Methods
This study was given East Carolina University Institutional Review Board approval (protocol number 08-0700).
Overview of the Tele-Audiology System
The system's general network architecture in Figure 1 appears comparable to many other similar telemedicine applications, where the patients and medical professionals are located at two different geographical locations. As reported previously in our earlier publication, 16 the system features a “thick” application server (Part B in Fig. 1) that runs all the software to coordinate test sessions, exempting the users' equipment from any particular software installation and maintenance. As a result, the audiologist terminal is not limited to any particular hardware/software platforms. The server also hosts the databases (Part C). A console device (Part D) is designed and developed in order to connect the hearing test equipment (an AMT here) to the Internet and to exchange information between the server and the adopted Bluetooth® (Bluetooth SIG, Kirkland, WA)-enabled AMT. Built on this console device's touchscreen, the auxiliary communication mechanism (Part F) is designed to provide the critical supports that allow a remote assistant to set up and coordinate test sessions.

Architecture of the integrated remote hearing test system: part B, application server, graphical user interface; part C, application server, database; part D, console device; part E, hearing test procedures; part F, auxiliary audio communication; part G, options of Internet connection; and part H, browsing devices.
The implementation of the application server and its database, the console device, the procedures involved in a remote speech test, and the auxiliary communication channel (Parts B–F as shown in Fig. 1) are detailed next. The Internet connections that remote patients use can be a wired connection, regular 3G cellular infrastructure, or satellite communication, depending on what is available at the time and the location. The description of specific Internet options (Part G) and specific browsing devices (Part H), although graphically depicted in Figure 1, are not discussed in this article.
Application Server: Graphical User Interface
An application server hosts several graphical user interfaces (GUIs) that allow users to manage accounts, schedule appointments, conduct hearing tests, and report test results. An ActiveX control is integrated into the hearing test page to enable the real-time audio data transmission, which is essential during speech tests and audiologist–patient/assistant communications. Since some pages are similar to the previous prototype, we elaborate here only the pages unique to the new system:
Hearing test page
Two GUIs—the pure-tone audiogram test GUI and the speech test GUI—can be selected with corresponding tab controls. The screenshot of the speech test page is shown in Figure 2. It includes all the necessary components for setting up speech tests and displaying test status. Several Web control components are provided for the audiologist to complete a speech test: a radio checkbox with six test mode options (e.g., SRT for speech reception threshold, MCL for maximum comfortable level, and WRS for word recognition score); two combo boxes that determine the volume levels of the main channel and masking channel; a speech track list including the track files stored in the AMT; a “Play” and a “Stop” button that starts and stops the playing of a selected track file; and a “Save” button to record the test results. Lastly, two image buttons (a green tick “√” and a red cross “×”) are used to check whether a patient successfully repeats words read by the AMT.

User interface of the speech test page. dB, decibels; MCL, maximum comfortable level; NR, not recorded; SRT, speech reception threshold; UCL, uncomfortable listening level; WRS, word recognition score.
Communication user interface
Three communication means, including text, audio, and video communication, are provided by the tele-audiology system to facilitate interactions required in remote hearing tests. An edit box allows an audiologist to input the text, and a “Send” button sends the text to the console device. Several buttons can be used to start or stop a conversation with the patient or the assistant, as shown in Figure 3a. Images of the patient included in this Web page, as shown in Figure 3b, further help communication between the remote and local parties.

Auxiliary communication user interface:
Formal test report page
After a test (pure-tone audiogram or speech test) is completed, a formal audiometric test report is created and presented to the audiologist (Fig. 4). The report page can be found in the “Report” tab; the information displayed includes patient information and test results (pure-tone audiogram results for the two ears, as well as speech test results).

Audiometric test report page. ECU, East Carolina University; MCL, maximum comfortable level; SRT, speech recognition threshold; UCL, uncomfortable listening level; WRS, word recognition score.
Application Server: System Database
A relational database has been developed on the application server to manage physician and assistant accounts and test results. The database contains several tables to store audiologist and assistant information, appointments, test results, and system events. The “Physician Account” and “Assistant Account” tables record audiologist and assistant information such as user name, password, full name, and e-mail address. The “Appointments” table conserves appointment-related items like patient name and scheduled test (date and time). The “Test Results” and “Events” tables store test results and system event logs, respectively. The primary key “Id” in the “Appointments” table is associated with the foreign key “ApptId” in the “Test Results” and the “Event” tables. When the audiologist wants to search for more information related to a specific appointment, he or she only needs to input the primary key “Id”; the audiologist's name, patient's name, test date and time, and associated test results can be found and displayed. The structure of the relational database is illustrated in Figure 5.

Relational database of the tele-audiology system.
Of the three roles (Audiologist, Assistant, and Patient) that participate in remote hearing tests, “Patient” is not given access to the database in the current tele-audiology system. Instead, a role of “Technician,” in addition to “Audiologist” and “Assistant,” is added. Each of the three roles is given privileges to access the system database. The privileges granted to these roles and their data access schemes are determined during the stage of system design, which is described in Figure 6. The “Audiologist” role conducts hearing tests and has access to the “Test Results” table. The “Assistant” role is responsible for test appointment scheduling and test session set-up and is therefore restricted to the access of the “Appointments” table. The “Technician” (or system administrator) role, which maintains the server software and hardware and resumes the server in the event that system failures occur, is permitted to access only the “Events” table.

Role management and data access mechanism.
The Console Device
The console device works as a gateway at the patient site, relaying different types of data (numeric, audio, and video) between the AMT and the application server, and provides a user interface that allows an assistant to set up hearing test sessions. It actively manages its Bluetooth communication with the AMT.
Components of the console device
The block diagram of the console device is illustrated in Figure 7, composed of five functional modules, including a transmission control protocol (TCP) module, a user datagram protocol (UDP) module, an AMT module, an audio/video module, and a user interface (UI) module.

Block diagram of the console device. AMT, audiometer; OS, operating system; TCP, transmission control protocol; UDP, user datagram protocol; UI, user interface.
The TCP module connects the console device to the application server, receives control messages from the server, and sends the patient's responses to the server. This module sustains a reliable link by periodically sending a heartbeat packet to the server to maintain the connection state.
The UDP module exchanges audio and video data between the server and the console device, while control messages required to build the audio and video channels are transmitted through the TCP socket by the TCP module.
The console device AMT module initiates connections to an AMT via a peripheral interface (here a wireless Bluetooth link) and forwards commands to and responses from the connected AMT.
The audio/video module contains two components: the audio component opens the microphone and speaker and captures and sends the voice data streams to the UDP module, as well as receives and plays voice streams received from the UDP module, following control commands given via TCP messages; the video component captures raw images, compresses them into a JPEG format, and sends them to the server through the UDP module.
The UI module provides functions that display the connection status between the server and the AMT and sets up the network interface and AMT parameters, etc.
Hearing Test Procedures
A hearing test session largely consists of four phases: preparation, test in progress, auxiliary communication, and result assessment. In the preparation phase, the assistant schedules an appointment and notifies the audiologist and the patient. When the scheduled time approaches, the assistant connects the console device to the server while the audiologist and the patient get ready. The sequence of the pure-tone audiogram test is similar to the preceding version. 15,16 Therefore, only the speech test procedures are discussed here.
Once the speech test mode is entered, the audiologist, based on the patient's clinical needs, selects the proper test option (i.e., SRT, WRS, or MCL), volume level, or a track file and then hits the “Play” button. A command packet reflecting these settings is transmitted to the console device. Upon receiving this packet, the console device parses it and produces the corresponding Bluetooth commands, which are in turn delivered to the AMT while an acknowledgment packet is returned to the server. The AMT then plays the specific track file, records the voice of the patient, and sends the audio data via the Bluetooth audio link (HSP) to the console device, which further forwards the data to the server. When the audio data play on the audiologist's terminal, the successful rate that the patient repeats the words is calculated and stored in the database. The sequence diagram is shown in Figure 8.

Sequence of the speech test session. ACK, acknowledgment.
Auxiliary Audio Communication
Given the complexity involved in a speech test, a convenient auxiliary audio communication channel is designed in order to allow smooth coordination between the local and remote sites. The auxiliary audio communication is disabled in the middle of any ongoing speech test. If the audiologist needs to talk with the patient or the assistant, he or she clicks the “Call” button through the GUI, and the server sends a request packet to the console device. The console device then translates the request to appropriate AT commands and forwards them to the AMT or the Bluetooth headset that the assistant wears to set up the Bluetooth audio link. An acknowledgment packet is sent back to the server once the communication is established. The sequence diagram of the audio communication between the audiologist and the patient is shown in Figure 9.

Sequence of the voice communication. ACK, acknowledgment; AT, attention command for serial modem communication.
Results
In order to examine the functionality of this comprehensive tele-audiology system, experiments have been conducted in an audiology lab in the Department of Communication Sciences and Disorders at East Carolina University. Eighteen volunteers (2 males and 16 females) in the age range of 19–62 years were recruited to participate in the pilot study. The audiologist did not have prior knowledge of the participants' hearing condition. During a study, each subject received a pure-tone threshold test and a speech audiometry test using two different testing approaches. In the pure-tone audiometry, air conduction thresholds and bone conduction thresholds were collected at octave steps from 250 to 4,000 Hz (250, 1,000, 2,000, 3,000, and 4,000). In the speech audiometry, SRT thresholds and WRS scores in decibels (dB) based on a specific speech volume were collected using a computerized face-to-face approach and the tele-audiology approach. For all tests, the subjects were seated in a sound-treated booth meeting the American National Standards Institute S3.1-1991 standards. The AMT used in the computerized and tele-audiology tests was calibrated to American National Standards Institute S3.1-1996 standards. Figure 10 illustrates the setup on the patient site, where the subject holds a portable AMT and the console device is mounted on a cart.

A subject is tested with the developed tele-audiology system.
From the user experience perspective, minimal disruption is observed during this study. The audiologists who participated in this study had experience with traditional hearing tests. They were able to operate the tele-audiology system with minimal training because the user interfaces were very similar to what they had used previously. Patient subjects did not notice any difference between the remote and face-to-face testing approaches, which is reasonable as the equipment (AMT and headsets) they used in both approaches is essentially the same.
The clinical effectiveness of the prototype system was primarily evaluated from two perspectives: (1) the agreement of the pure-tone threshold findings obtained from the proposed remote tests to those face-to-face tests (using a software program called Symphony 22 ) and (2) the agreement of the speech thresholds among the two testing approaches.
Pure-Tone Thresholds
Tables 1 and 2 present the air conduction and bone conduction, respectively, thresholds from the two testing approaches (again, face-to-face test with Symphony and the remote test). These findings demonstrate that the remote test is within clinically acceptable agreement (<10 dB hearing level) with the non–server-based computerized testing system (labeled as Symphony in Tables 1 and 2), where both used the same off-the-shelf AMT (OTOpod 23 ).
Mean and Standard Deviation of Pure-Tone Thresholds (Air Conduction)
SD, standard deviation.
Mean and Standard Deviation of Pure-Tone Thresholds (Bone Conduction)
SD, standard deviation.
Speech Thresholds
Tables 3 and 4 show the means and standard deviations of the SRT thresholds and WRS word recognition rates, respectively, from the remote and face-to-face tests. For the speech test, the tele-audiology produced results comparable to the computerized system with the Symphony software. These results, again, demonstrate that the remote test model is consistent with its face-to-face counterparts, validating the effectiveness of the proposed system.
Speech Recognition Thresholds
SD, standard deviation.
Word Recognition Score
SD, standard deviation.
Discussion and Conclusions
This article presents a browser-server–based tele-audiology system that supports two remote test procedures—the pure-tone audiogram test and the speech test—for patient hearing diagnosis. It elaborated the system architecture, technical implementation, and initial clinical testing results. The system features, with an auxiliary communication channel, uniquely make speech tests convenient. The initial results from the experiments demonstrate that the proposed tele-audiology system generated testing results comparable to those of its traditional face-to-face counterparts.
The proposed system promises to better serve traditionally underserved populations, such as employees working in noisy environments, citizens in rural areas and underdeveloped countries, elderly individuals with no transportation, prisoners, and active and retired military service members.
Before its ultimate implementation, multiple milestones need to be achieved next: (a) Due to time constraints, these tests were performed when the audiologist and patient were connected to the system within the same Internet domain; more Internet connection cases will tested. (b) Non–hospital patient end settings (e.g., on vehicles or in field) will be investigated. (c) Variables with clinical impact (such as consumer and user satisfaction) will be examined.
Footnotes
Acknowledgments
The authors want to thank PhD student Kaila Higuchi for her assistance in collecting the clinical study data used in this article and Ms. Deborah Poage for her graphical and editorial help. This research and development project was conducted by East Carolina University and is made possible by a cooperative agreement that was awarded and administered by the U.S. Army Medical Research & Materiel Command and the Telemedicine & Advanced Technology Research Center, at Fort Detrick, MD, under contract W81XWH1120221.
Disclosure Statement
No competing financial interests exist.
