WO2015142312A1

WO2015142312A1 - Console devices for comprehensive remote hearing assessment and related systems and methods

Info

Publication number: WO2015142312A1
Application number: PCT/US2014/030426
Authority: WO
Inventors: Jianchu Yao; Daoyuan YAO; Gregg D. Givens
Original assignee: East Carolina University
Current assignee: East Carolina University
Priority date: 2014-03-17
Filing date: 2014-03-17
Publication date: 2015-09-24
Anticipated expiration: 2016-09-17

Abstract

A console device at a patient site includes a Transmission Control Protocol (TCP) socket module, a User Datagram Protocol (UDP) socket module and a controller. The controller is configured to: operate the TCP socket module to receive operational command data from a web client associated with a remote audiologist; process the operational command data to control operation of an audiometer at the patient site; process audiometer data including patent speech data to convert the patient speech data to UDP packets; and operate the UDP socket module to transmit the converted patient speech data to the web client associated with the remote audiologist for evaluation of the patient speech data.

Description

CONSOLE DEVICES FOR COMPREHENSIVE REMOTE HEARING ASSESSMENT AND RELATED SYSTEMS AND METHODS

[0001] A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner, East Carolina University of Greenville, N.C., has no objection to the reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever.

Field of the Invention

[0002] The invention relates to hearing evaluation systems used to diagnose hearing impairments.

Background

[0003] It is estimated that approximately 28 million people in the United States, including 1.46 million children, have a hearing deficiency in frequencies important to the understanding of speech. Early identification of hearing loss and appropriate intervention can be critical to preventing or ameliorating further hearing loss or language delay or disorder. Indeed, early identification can be particularly important in children who are, typically, more receptive to rehabilitation.

[0004] Conventional hearing evaluation or assessment tests are performed in a clinical setting with personal interaction between the patient and a clinician. In these settings, the patient is often required to sit in a sound isolation booth and to visually signal to the clinician when sounds generated from an audiometer become audible.

Unfortunately, this clinic or office setting structure can be burdensome and time consuming, particularly for those individuals located in remote or rural regions for whom access to audiological specialists may be limited or the cost of transportation to a clinic or office may be unaffordable, or in industrial settings where frequent or periodical screenings may be beneficial.

Summary of Embodiments of the Invention

[0005] Embodiments of the present invention provide a console device for use at a patient site in a telehearing system including a web client associated with a remote audiologist and a web server that communicatively connects the console device and the web client over the Internet. The console device includes a Transmission Control Protocol (TCP) socket module, a User Datagram Protocol (UDP) socket module and a controller. The controller is configured to: operate the TCP socket module to receive operational command data from the web client associated with the remote audiologist; process the operational command data to control operation of an audiometer at the patient site; process audiometer data including patent speech data to convert the patient speech data to UDP packets; and operate the UDP socket module to transmit the converted patient speech data to the web client associated with the remote audiologist for evaluation of the patient speech data.

[0006] In some embodiments, the controller is configured to operate the TCP socket module to connect the console device to the web server. In some embodiments, the audiometer data includes control messages associated with the patient speech data, and the controller is configured to: process the audiometer data to convert the control messages to TCP packets; and operate the TCP socket module to transmit converted control messages to the web client associated with the remote audiologist

substantially concurrently with the transmission of the converted patient speech data. In some embodiments, the operational control data received from the web client includes a speech track, and the controller is configured to process the operational command data to play the speech track at the audiometer.

[0007] The console device may include a wireless interface configured to establish a direct wireless connection with the audiometer. The controller may be configured to: operate the wireless interface to establish a wireless connection with the audiometer; operate the wireless interface to forward the processed operational command data to the audiometer; and operate the wireless interface to receive the audiometer data from the audiometer.

[0008] In some embodiments, the wireless interface is a Bluetooth interface that is configured to operate using a serial port profile (SPP) and using a headset profile

(HSP) and/or a hands-free profile (HFP. The Bluetooth interface may be configured to forward the processed operational command data using the SPP. The Bluetooth interface may be configured to receive the patient speech data using the HSP and/or the HFP. The controller may be configured to: convert TCP packets of operation command data received at the TCP socket module to Bluetooth (BT) packets; convert BT packets of patient speech data received at the Bluetooth interface to UDP packets; and convert BT packets of control messages associated with the patient speech data received at the Bluetooth interface to TCP packets.

[0009] In some embodiments, the controller is configured to: operate the wireless interface to establish a wireless connection with a headset associated with an assistant at the patient site; operate the wireless interface to receive assistant voice data from the headset; process the assistant voice data to convert the assistant voice data to UDP packets; and operate the UDP socket module to transmit the UDP packets of assistant voice data to the web client associated with the remote audiologist for realtime playback of the assistant speech data. The wireless interface may be a Bluetooth interface configured to receive the assistant speech data using a headset profile (HSP) and/or a hands-free profile (HFP). The controller may be configured to process the assistant voice data to convert BT packets received at the Bluetooth interface to UDP packets.

[0010] In some embodiments, the controller is configured to: process patient and/or assistant video data associated with video of the patient and/or the assistant captured at the patient site to convert the video data to UDP packets; and control the UDP socket module to transmit the converted video data to the web client associated with the remote audiologist for real-time playback of the video data.

[0011] The controller may be configured to operate the UDP socket module to receive audiologist video data associated with video of the audiologist from the web client and display the video of the audiologist. The console device may include a display, and the controller may be configured to control the display to display the video of the patient and/or assistant and the video of the audiologist in real-time to provide videoconferencing capabilities.

[0012] In some embodiments, the console device includes a display, and the controller is configured to operate the display to display a user interface (UI) that is configured to receive user input from an assistant at the patient site to configure and/or coordinate a hearing test session. The controller may be configured to operate the display to display test information including ongoing test information during the hearing test session. The UI may be configured to receive user input from an assistant at the patient site to initiate a voice and/or video call with a remote audiologist that is conducting the hearing test session.

[0013] In some embodiments, the controller is configured to coordinate multiple tasks including receiving operational command data at the console device, converting the operational command data at the console device, transmitting the converted operational control data to the audiometer and receiving patient speech data from the audiometer at the console device and assign each task a priority based on its tolerance to time delay. Receiving patient speech data from the audiometer at the console device may be assigned the highest priority.

[0014] The controller may be configured to segment the patient speech data received from the audiometer into units and convert each segmented unit to UDP packets to send to the server. The segmented units may have a length of about 100 ms.

[0015] In some embodiments, the console device is configured to process audiometer data including patent speech data to convert the patient speech data to UDP packets and operate the UDP socket module to transmit the converted patient speech data to the web server with a maximum latency of less than about 100 ms.

[0016] Other embodiments of the present invention provide a telehearing system including at least one web server in communication with the Internet and configured to provide a web-based service that hosts a telehearing diagnostic testing system, a plurality of web clients associated with remote audiologists at different geographical locations and a plurality of portable console devices. Each of the console devices is at a different patient site and includes a Transmission Control Protocol (TCP) socket module, a User Datagram Protocol (UDP) socket module and a controller. The controller is configured to: operate the TCP socket module to connect the console device to the web server over the internet; operate the TCP socket module to receive operational command data from a web client associated with one of the remote audiologists; process the operational command data to control operation of an audiometer at the patient site; process audiometer data including patent speech data to convert the patient speech data to UDP packets; and operate the UDP socket module to transmit the converted patient speech data to the web client associated with the one of the remote audiologists for real-time playback of the patient speech data. [0017] In some embodiments, multiple consoles and audio logists users can simultaneously access the web-based service to allow multiple concurrent speech hearing tests to be carried out.

[0018] Other embodiments of the present invention provide a console device for use at a patient site during a telemedicine session including a web client associated with a remote physician and a web server that communicatively connects the console device and the web client over the Internet. The console device includes a Transmission Control Protocol (TCP) socket module, a User Datagram Protocol (UDP) socket module and a controller. The controller is configured to operate the TCP socket module to send and receive numeric data to and from the web server; operate the UDP socket module to receive physician audio and/or video data associated with audio and/or video of the physician captured at the web client and display the video of the audiologist at the patient site; and process patient audio and/or video data associated with audio and/or video captured at the patient site and operate the UDP socket module to transmit processed patient audio and/or video for display at the web client associated with the physician.

[0019] As will be appreciated by those of skill in the art in light of the above discussion, the present invention may be embodied as methods, systems and/or computer program products or combinations of same. In addition, it is noted that aspects of the invention described with respect to one embodiment, may be incorporated in a different embodiment although not specifically described relative thereto. That is, all embodiments and/or features of any embodiment can be combined in any way and/or combination. Applicant reserves the right to change any originally filed claim or file any new claim accordingly, including the right to be able to amend any originally filed claim to depend from and/or incorporate any feature of any other claim although not originally claimed in that manner. These and other objects and/or aspects of the present invention are explained in detail in the specification set forth below.

Brief Description of the Drawings

[0020] Figure 1A is a block diagram of a test/communication console device that communicates using the Internet according to embodiments of the present invention. [0021] Figure IB is a perspective view of an audiometer and associated headsets according to embodiments of the present invention.

[0022] Figure 2 is a block diagram of a telehearing system having client-server architecture according to embodiments of the present invention.

[0023] Figure 3 is block diagram illustrating data flow between various devices in the system of Figure 2.

[0024] Figure 4 is a block diagram of a console device according to embodiments of the present invention.

[0025] Figure 5 is a block diagram illustrating hardware and modules that may be implemented on the console device of Figure 4.

[0026] Figures 6A and 6B illustrate exemplary screenshots from a display of or in communication with the console device of Figure 4.

[0027] Figure 6C illustrates exemplary Bluetooth communications between the console device of Figure 4 and an audiometer.

[0028] Figures 7 and 8 are data flow diagrams that illustrate exemplary operations according to embodiments of the present invention.

[0029] Figure 9 illustrates an exemplary screenshot of a speech test window (e.g., web page) according to embodiments of the present invention.

[0030] Figures 10-12 are data flow diagrams that illustrate exemplary operations according to embodiments of the present invention.

[0031] Figure 13 is a block diagram of a web-based service hosting a telehearing diagnostic system with defined access levels for different users and/or different user categories according to embodiments of the present invention.

[0032] Figure 14 is a schematic illustration of exemplary operations of the web-based service according to embodiments of the present invention.

[0033] Figure 15A is a block diagram of an exemplary display of a portal and/or web page with examples of permissible actions according to user-based privilege/access levels according to embodiments of the present invention.

[0034] Figure 15B is a block diagram of a web-based service hosting a telehearing diagnostic system in conjunction with a multimedia communications provider according to embodiments of the present invention. [0035] Figure 16 is a flowchart of operations for performing a hearing diagnostic test according to embodiments of the present invention.

[0036] Figure 17A is a block diagram of a data processing system according to embodiments of the present invention.

[0037] Figure 17B is a block diagram of another exemplary feature or function of a data processing system according to embodiments of the present invention.

[0038] Figures 18A-18C illustrate exemplary web pages according to embodiments of the present invention.

[0039] Figure 19 illustrates a prototype console device.

Detailed Description of Embodiments of the Invention

[0040] The present invention will now be described more fully hereinafter with reference to the accompanying figures, in which preferred embodiments of the invention are shown. This invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein.

[0041] Like numbers refer to like elements throughout. In the figures, layers, regions, or components may be exaggerated for clarity. Broken lines illustrate optional features or operations unless specified otherwise.

[0042] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention. As used herein, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms "comprises" and/or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. As used herein, the term "and/or" includes any and all combinations of one or more of the associated listed items. As used herein, phrases such as "between X and Y" and "between about X and Y" should be interpreted to include X and Y. As used herein, phrases such as "between about X and Y" mean "between about X and about Y." As used herein, phrases such as "from about X to Y" mean "from about X to about Y." [0043] Unless otherwise defined, all terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. It will be further understood that terms, such as those defined in commonly used dictionaries, should be interpreted as having a meaning that is consistent with their meaning in the context of the specification and relevant art and should not be interpreted in an idealized or overly formal sense unless expressly so defined herein. Well-known functions or constructions may not be described in detail for brevity and/or clarity.

[0044] It will be understood that when an element is referred to as being "on",

"attached" to, "connected" to, "coupled" with, "contacting", etc., another element, it can be directly on, attached to, connected to, coupled with or contacting the other element or intervening elements may also be present. In contrast, when an element is referred to as being, for example, "directly on", "directly attached" to, "directly connected" to, "directly coupled" with or "directly contacting" another element, there are no intervening elements present. It will also be appreciated by those of skill in the art that references to a structure or feature that is disposed "adjacent" another feature may have portions that overlap or underlie the adjacent feature.

[0045] It will be understood that, although the terms first, second, etc. may be used herein to describe various elements, components, regions, layers and/or sections, these elements, components, regions, layers and/or sections should not be limited by these terms. These terms are only used to distinguish one element, component, region, layer or section from another region, layer or section. Thus, a first element, component, region, layer or section discussed below could be termed a second element, component, region, layer or section without departing from the teachings of the present invention. The sequence of operations (or steps) is not limited to the order presented in the claims or figures unless specifically indicated otherwise.

[0046] Spatially relative terms, such as "under", "below", "lower", "over", "upper" and the like, may be used herein for ease of description to describe one element or feature's relationship to another element(s) or feature(s) as illustrated in the figures. It will be understood that the spatially relative terms are intended to encompass different orientations of the device in use or operation in addition to the orientation depicted in the figures. For example, if a device in the figures is inverted, elements described as "under" or "beneath" other elements or features would then be oriented "over" the other elements or features. Thus, the exemplary term "under" can encompass both an orientation of over and under. The device may be otherwise oriented (rotated 90 degrees or at other orientations) and the spatially relative descriptors used herein interpreted accordingly. Similarly, the terms "upwardly", "downwardly", "vertical", "horizontal" and the like are used herein for the purpose of explanation only unless specifically indicated otherwise.

[0047] The term "patient" refers to the individual(s) being tested and can include the user or client at the local patient testing site. As used herein, the term "substantially real time" means receiving and/or transmitting data between sites during the test accounting for system delays in remote transmission between sites which may be on the order of seconds or less or potentially minutes in length as a result of routing, traffic, transmission route and/or system communication link employed which can impede the transfer such that slight delays may occur,

[0048] The term "automatic" means that substantially all or all of the operations so described can be carried out without the assistance and/or manual input of a human operator. The term "about" means the noted number can vary a small amount from the recited value, typically ±10%. The term "electronic" means that the system, operation or device can communicate using any suitable electronic media and typically employs programmatically controlling the communication between participants using a computer network. The term "programmatically" means the action is directed via a computer program code. The term "hub" means a node and/or control site (or sites) that controls and/or hosts data exchange between different user sites using a computer network. The term "HIPAA" refers to the United States laws defined by the Health Insurance Portability and Accountability Act.

[0049] The terms "healthcare data" and "clinical data" and "patient records" are used interchangeably and include any and/or all of a treatment, medicinal, drug or prescription use, laboratory tests and/or results, diagnostic information, demographic information, a physical location, a home address (such as a zip code), insurance information other relevant data associated with a patient.

[0050] The term "registered" means that the user is a recognized participant of the system. The term "administrative user" refers to a user that does not perform clinical actions or clinical services and is typically a user that does not have permission to access patient medical records. Different types of administrative users can have different access levels to the system. The term "web-based" means that the service uses at least one server to communicate with different users over the World Wide Web, typically via the hypertext transfer protocol (HTTP).

[0051] Embodiments of the invention may use a computing architecture in which the user interface, the application processing logic, and/or the underlying database(s) can be encapsulated in logically-separate processes. In any given application utilizing this type of computing architecture, the number of tiers may vary depending on the requirements of the particular application; thus, such applications are generally described as employing an n-tier architecture. See, e.g. , Exforsys.com, N-Tier Client- Server Architecture. For instance, some embodiments of the invention may employ a 2-tier architecture, commonly referred to as a client-server architecture, wherein a client application such as a web browser makes a request from a web server, which processes the request and returns the desired response (in this case, web pages). Other embodiments of the invention may be structured as a 3 -tier or other larger multi-tier architecture, wherein the web server provides the user interface by generating web pages requested by a web browser, which receives and displays code in a recognized language such as dynamic HTML (Hypertext Markup Language); middleware executing on an application server handles the business logic; and database servers manage data functions. Often, the business logic tier may be refined into further separate tiers to enhance manageability, scalability, and/or security.

[0052] Accordingly, in some web-based hearings services, the web applications can use a 3 -tier architecture with a presentation tier, a business logic tier, and a patient record data tier. The web application tiers may be implemented on a single application server, or may be distributed over a plurality of application servers. The presentation tier can provide web pages that allow a user to request hearing test services, schedule the test services, and allow communication between the patient user and the remote audiologist user during the hearing test session. The presentation tier may communicate with other tiers in the application such as the business logic tier and/or patient record data tier by accessing available components or web services provided by one or more of the other application tiers. The presentation tier may communicate with another tier to allow authorized users to access patient record data and/or database stored procedures, instructions, or protocols. The business logic tier can coordinate the application's functionality by processing commands, scheduling tests and evaluating data. The functionality of the business logic tier may be made accessible to other application tiers by, for example, the use of web services. The business logic tier may also provide the logic, instructions or security that can separate and distinguish clinical users from non-clinical users (e.g., administrative users). While the patient data record tier can hold the private patient records data and encapsulate such records from unapproved parties so as to comply with HIPAA or other privacy regulations. The patient records data tier can make data available through, for example, stored procedures, logic, instructions and the like accessible, for example, by web services.

[0053] As will be appreciated by one of skill in the art, embodiments of the invention may be embodied as a method, system, data processing system, or computer program product. Accordingly, the present invention may take the form of an entirely software embodiment or an embodiment combining software and hardware aspects, all generally referred to herein as a "circuit" or "module, " Furthermore, the present invention may take the form of a computer program product on a computer-usable storage medium having computer-usable program code embodied in the medium. Any suitable computer readable medium may be utilized including hard disks, CD-ROMs, optical storage devices, a transmission media such as those supporting the Internet or an intranet, or magnetic or other electronic storage devices.

[0054] Computer program code for carrying out operations of the present invention may be written in an object oriented programming language such as Java, Smalltalk , C# or C++. However, the computer program code for carrying out operations of the present invention may also be written in conventional procedvaral programming languages, such as the "C" programming language or in a visually oriented programming environment, such as Visual Basic.

[0055] Certain of the program code may execute entirely on one or more of a user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer. In the latter scenario, the remote computer may be connected to the user's computer through a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). Typically, some program code executes on at least one web (hub) server and some may execute on at least one web client and with communication between the server(s) and clients using the Internet.

[0056] The invention is described in part below with reference to data flow diagrams, flowchart illustrations and/or block diagrams of methods, systems, computer program products and data and/or system architecture structures according to embodiments of the invention. It will be understood that each block of the illustrations, and/or combinations of blocks, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general- purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions/acts specified in the block or blocks.

[0057] These computer program instructions may also be stored in a

computer-readable memory or storage that can direct a computer or other

programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory or storage produce an article of manufacture including instruction means which implement the function/act specified in the block or blocks.

[0058] The computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions/acts specified in the block or blocks.

[0059] As noted above, the present invention provides systems, methods and associated devices for performing diagnostic hearing tests which use a computer network with a distributed, client-server architecture to allow interaction between remote sites and ("local") patient sites. [0060] The present invention provides "smart" console devices that support multiple modes of hearing tests (including speech tests) and coordinate communication between audiologists, assistants and patients. In some embodiments, the console device provides: 1) a gateway that connects to a portable diagnostic audiometer as well as the Internet; 2) a user interface that enables an assistant to coordinate remote hearing test sessions; and 3) audio and video capability which provides two-way audio and video communication between the patient, the audiologist and the assistant.

[0061] In some embodiments, the gateway is responsible for transferring commands and responses between the audiologist and patient, as well as repeated voices in speech tests. It may transmit the test commands issued by the remote audiologist via the Server 31 and may send the patient's responses from the Bluetooth link shared by the audiometer and the gateway back to the audiologist via the Server 31.

[0062] The user interface may be provided on a display of the console device. It may provide test session information such as patient name, date, time, test category (audiogram, speech, etc) and test events (e.g., issued command and response). It may provide current system or test status. It may provide control of audio and video interactions between the audiologist and the patient and/or assistant (e.g., call audiologist button, audiologist is calling indicator, etc.).

[0063] The system may include audio equipment like a headset and video equipment such as a camera. These devices may be integrated with the console device or in communication with the console device. For example, the voice of the assistant may be sent to the console device from the headset via Bluetooth wireless link and forwarded to the remote audiologist through the Internet. The video of the assistant and patient may be captured by the camera and forwarded to remote audiologist via the Internet.

[0064] Referring to Figure 1A, embodiments of the present invention provide systems 10 that allow for remote hearing diagnosis. The systems 10 can include a console device 100 that connects an audiometer 102 to the Internet 20. The console

100 can include an "on-board" or integral audiometer 1001 or the console 100 can connect to an off-the-shelf or standard audiometer 102 (the latter of which does not typically have Internet access capability), either way so as to connect the audiometer to a global computer network, e.g., the Internet. The systems 10 also include a web- based diagnosis system having a client-server architecture 30 (Figures 2 and 3). The audiometer 102 can be in communication with a hearing output device 60 such as earphones or an ear probe assembly. Ear probes may be configured to be a single use disposable device, being initially sterilized to meet medical sterility guidelines. For example, a single use, disposable (cost effective) ITE-or earplug design can be used either for a biotelemetry reading and/or for the tone output.

[0065] In some embodiments, as illustrated in Figure IB, the audiometer 102 may be in communication with a patient headset 62 for use with speech tests. The headset 62 includes earphones (speakers) 62A and a microphone 62B. In some embodiments, the audiometer 102 is in communication with a bone conductor 64 for bone conduction testing. In some embodiments, the audiometer 102 is shipped together with the console device 100 and the devices 62 and/or 64.

[0066] Conventional audiometers 102 have certain data exchange capability (either hardwired or wirelessly). See, e.g., U.S. Patent No. 7,370,533, the contents of which are hereby incorporated by reference as if recited in full herein, and the OTOPod audiometer from Otovation, LLC, of King of Prussia, PA, which uses the Bluetooth wireless protocol to exchange data with a computer. Through this connection, audiologists can operate the audiometer and receive hearing data from the audiometer 102. As described in greater detail below, to allow remote diagnosis function over the Internet 20, the console 100 can convert data from an audiometer 102 to TCP and/or UDP packets (which are in turn sent to the audiologist over the Internet 20 via the Server 31) and also convert operational commands from an audiologist (typically received in TCP packets) into a format that can be accepted by the audiometer 102. Alternatively, the console 1001 can be configured to perform these functions for an on-board audiometer 102. Depending on the communication port 102p on the conventional audiometer 102 or the configuration of the on-board audiometer 102 in the integrated console 1001, the connection lOO i between the console 100 or 1001 and the audiometer 102 can be wired (e.g., RS-232 or USB) and/or wireless (e.g., using a wireless protocol such as Bluetooth or Zigbee) or configured to operate both ways to allow a user to select either. The console connection 100p₂ to the Internet 20 can also be wired (e.g., an Ethernet port) or wireless (e.g., a Wi-Fi interface) and may be configured to be operate both ways to allow for a user to select either to facilitate different patient preferences.

[0067] In some embodiments, a particular patient test site can use a dedicated console 100 and/or audiometer. In some embodiments, the system 10 can be configured to provide a console 100 to a patient user for use at any desired location having access to the Internet 20. In some embodiments, the system 10 is configured to ship the console 100 and audiometer 102, or the integrated version 1001, to a patient's residence. After the test, the console 100, 1001 can be returned, such as using a prepaid mailing package (properly insulated for weather and protection), courier or shipment pick-up, or physical drop-off at a shipping center or at a return center. In other embodiments, a local facility, such as a hospital, doctor's practice or other "community" location, may have an inventory of the devices 100 (and 102) and/or 1001 that can be loaned to registered patients for use.

[0068] Calibration and proper operation of the audiometers 102 and/or consoles 100, 1001, can be performed after each use and prepared for subsequent use. The use, status, and location of the devices 100, 102, 1001 can be tracked for inventory control. For example, if a patient has a scheduled hearing test, the console 100, 1001 can be shipped to that patient in advance of the test and identified as "at patient site" with an associated scheduled test date and expected return date to allow for inventory management. Courtesy reminders can be sent electronically and/or telephonically regarding a scheduled test time. Reminders can also be sent right after the test date and again if a unit (100, 102, 1001) has not been returned within a defined period. Charges for "overdue" units can be applied to patients that are not prompt. A patient may be required to sign a contract to that effect; such a contract can be provided as a condition to use the system 10 (such as a point and click or electronic signature upon registering as a participating patient).

[0069] Referring to Figure 2, the system 10 includes at least one web server 31 and a plurality of web clients 35i -35n (with "n" being an integer number corresponding to the number of participating or registered users). Typically, "n" is greater than 10; more typically, n is between 100-10,000, or even more, corresponding to the number of registered users (not including patient users). Some of the users, e.g., at least the audiologist user 40, can communicate with the system 10 via any suitable device having website browsing capability, including, for example, PDAs 35₃ and cellular telephones 35₄ as shown in Figure 2. Thus, the audiologist user 40 can communicate with the patient user 50 during a hearing test via the Internet 100 using a PDA

(personal digital assistant) or cellular telephone (shown with 35₃, 35 ) having web- browsing capability (or palm, laptop or desktop computer 370 (Figure 15B)). The system 10 can support multiple concurrent hearing tests at multiple web clients.

[0070] Figure 3 illustrates the system 10 with an assistant 52 with a respective patient 50 at a patient site 54. It may be desirable for the assistant 52 to facilitate the hearing test and operate the console device 100 at the patient site 54, particularly for speech tests that may involve several rounds of back-and-for h interaction between the audiologist 40 and the patient 50. The assistant 52 may also interact with the audiologist 40 over the Internet before, during and/or after a hearing test.

[0071] As illustrated, the server 31, the web client 35 associated with the audiologist 40 and the console 100 are all connected to the Internet 20 via an Ethernet or Wi-Fi connection or link. Accordingly, the web client 35 and the console 100 are communicatively connected via the server 31 and exchange data over the Internet 20. It is contemplated that one or more of these devices (e.g., the console 100 and/or the web client 35) may connect to the Internet 20 some other way, such as via a mobile communication technology standard (e.g., 3G or 4G).

[0072] As illustrated in Figure 3, the console 100 and the audiometer 102 are communicatively connected and can exchange data through a Bluetooth wireless protocol. The console 100 and a communications headset 53 (or similar device) associated with the assistant 54 can be communicatively connected and also exchange data through the Bluetooth wireless protocol in the illustrated embodiment. The headset 53 may be similar to the "patient" headset 62 shown in Figure IB. That is, the headset 53 may include a microphone 62B and at least one speaker 62A. It is contemplated that the audiometer 102 and/or the assistant headset 53 may be connected to the console 100 through other (direct) wireless communication interface. The audiometer 102 and/or the headset 53 may also have a wired connection with the console 100.

[0073] Information flow between the various devices is also schematically shown in

Figure 3. The types of information exchanged during a test session may include, inter alia: 1) test command and response data (e.g., numerical data); and 2) audio and/or video data. The audio data may include speech data that is associated with a patient during a speech test. The patient speech data may be captured by the microphone 62B associated with the patient headset 62 (Figure IB).

[0074] The audio data may also include audio data captured by microphones 351, 361 that may be used for real-time communication between the audiologist 40 and the patient 50 and/or the assistant 52. The audio data may include assistant voice data captured by a microphone associated with the assistant headset 53 that may be used for communication between the audiologist 40 and the assistant 52.

[0075] The video data may include video data captured by cameras 350, 360 that may be used for real-time communication between the audiologist 40 and the patient 50 and/or the assistant 52 (e.g., videoconferencing). In some embodiments, the camera 350 and/or the microphone 351 are integrated with the web client 35 associated with the audiologist 40. In some embodiments, the camera 360 and/or the microphone 361 are integrated with the console 100 at the patient site 54.

[0076] As illustrated by the data streams, test command and response data as well as audio and video data are shared between the web client 35 and the server 31. Test command and response data as well as audio and video data are also shared between the console 100 and the server 31. Test command and response data as well as audio data are shared between the console 100 and the audiometer 102. Audio data is shared between the headset 53 associated with the assistant 52 and the console 100.

[0077] As described in greater detail below, the console 100 is configured to integrate audiometer command/response data flow, audio/voice stream data flow and video data stream flow to support multiple tele-audiology modalities and/or three-party communication that is often desirable with a hearing assessment session.

[0078] Referring to Figure 4, the console 100 can include at least one controller or processor 104 and electronic memory 106. The processor 104 can be any

commercially available or custom microprocessor, microcontroller, digital signal processor or the like. The memory 106 may include any memory devices and/or storage media containing the software and data used to implement the functionality circuits or modules used in accordance with embodiments of the present invention, including those modules described below in connection with Figure 5. The memory 106 can include, but is not limited to, the following types of devices: cache, ROM, PROM, EPROM, EEPROM, flash memory, SRAM, DRAM and magnetic disk. In some embodiments of the present invention, the memory 106 may be a content addressable memory (CAM).

[0079] The console 100 may further include a network interface 108 configured to connect the console 100 to the Internet 20. The network interface 108 may support a wired connection to the Internet 20 (e.g., an Ethernet or USB port) and/or may support a wireless connection to the Internet 20 (e.g., a Wi-Fi interface). The console 100 may include a Bluetooth interface or module 110 configured to communicatively connect the console 100 and the audiometer 102 and/or the headset 53 of the assistant 52. In some embodiments, the Bluetooth module 110 includes a BlueCore4-Ext™ device available from CSR, Cambridge, UK or a similar type device that implements the Bluetooth 2.0+ Enhanced Data Rate specification so as to deliver data rates up to 3 Mbps. Other types of (direct) wireless interfaces are contemplated for connecting the console 100 and the audiometer 102 and/or the assistant headset 53 (e.g., Wi-Fi Direct).

[0080] The console 100 includes a display 112 configured to display, inter alia, connectivity information, test data, test progress and audio/text messages/video received from the audiologist. The console 100 includes a user interface 114 (UI) which may be integrated with the display 112. The UI 114 can include a touch- sensitive display or may be a keypad or the like which may be provided as a touch screen input or a physical keypad or as a separate keyboard that connects to the console 100. The console 100 may include input port(s) 116 and/or output port(s) 117 for connecting various devices. For example, console may include serial ports, USB ports or the like for connecting equipment such as a microphone, a camera, a user interface device (e.g., keyboard) and so forth. The console 100 may include an integrated camera 360 and/or an integrated microphone 361. The console 100 may also include a speaker 362.

[0081] Figure 5 illustrates exemplary hardware and software modules that may be associated with the console 100. As noted above, the memory 106 (Figure 4) may include any memory devices and/or storage media containing the software and data used to implement the functionality of the hardware and modules illustrated in Figure 5.

[0082] As illustrated in Figure 5, the console 100 includes a TCP socket module 120, a UDP socket module 122, an audiometer (AMT) module 124, an audio and video (A/V) capture and playback module 126 and a user interface (UI) module 128. The console 100 also includes an operating system 130, an audio driver 132 and a camera driver 134 in the illustrated embodiment.

[0083] The TCP socket module 120 is configured for connecting to the server 31, receiving messages from the server 31 and sending responses to the server 31. The TCP socket module 120 may also be used to realize connection reliability

mechanisms. The UDP socket module 122 is configured for exchanging audio and video data between the server 31 and the console 100. Control messages associated with the audio and video data may be exchanged through the TCP socket module 120. The controller 104 (Figure 4) may be configured to direct the TCP socket module 120 and the UDP socket module 122 to carry out these operations.

[0084] The audiometer module 124 is configured for initiating a connection to the audiometer 102 via a defined interface, such as a Bluetooth link, UART, USB and so forth. The A/V capture and playback module 126 is configured for opening (e.g., initiating) the audio and video devices, capturing audio and video streams, and sending the audio and video streams to the UDP socket module 122 under the control of TCP messages. The UI module 128 is configured for displaying network interface and audiometer parameters during setup, for displaying the connection status between the server 31 and the audiometer 102 and for displaying test progress during a test session.

[0085] The operating system 130 may be any operating system suitable for use with a data processing system, such as IBM®, OS/2®, AIX® or zOS® operating systems or

Microsoft® Windows® operating systems, Unix or Linux™. IBM, OS/2, AIX and zOS are trademarks of International Business Machines Corporation in the United

States, other countries, or both while Linux is a trademark of Linus Torvalds in the

United States, other countries, or both. Microsoft and Windows are trademarks of

Microsoft Corporation in the United States, other countries, or both. The audio driver

132 is configured to control operation of the microphone 361 and/or the speaker 362 (Figure 3) and facilitates input and output of audio signals to and from the console. The camera driver 134 is configured to control operation of the camera 360 (Figure 3) that may be integral with or in communication with the console 100,

[0086] With reference to Figures 6A and 6B, multiple categories of information may be displayed on the display 112 of the console device 100 or on a display in communication with the console device 100. Connection information and status 140 may be displayed. This may include the configuration of the tele-hearing system in order to connect the console device 100 to the server 31; for example, the server IP address and the port number through which the devices exchange data. Test information 142 such as the patient name, audiologist name and test type (e.g., pure- tone or speech) may be displayed. Ongoing test status information 144 may be continuously or intermittently provided as an event log with date and time stamps. A call interface 146 may be displayed that allows the patient or the assistant to communicate with the audiologist, such as a "CALL" button and/or ringing notification, A text message window 148 may be provided for exchange of text messages between the audiologist and the patient and/or assistant. A picture or camera image 150 of the audiologist connected to the console 100 may be provided. The picture 150 may comprise a video window for videoconferencing with the audiologist.

[0087] In some embodiments, the console 100 exchanges data with the audiometer 102 through a two-way, dual-mode Bluetooth link. In one direction, commands initialized by the audiologist through the server 31 are forwarded to the audiometer 102. In the other direction, the console 100 receives data from the audiometer 102. Such data may include "button-down" responses in pure-tone audiometry or audio data in speech tests including a patient's speech repeats in the audio track. Because the Bluetooth link transmits signals in both numeric and audio formats, the console device 100 may coordinate switching of serial port profile (SPP) and headset/hands- free profiles (HSP/HFP). For example, SPP may be used for numeric command data and HSP/HFP may be used for audio or speech data. HSP and/or HFP may support Bluetooth Core Specification Version 2.1 + EDR that currently provides a maximum data rate of 3 Mbps and a maximum throughput of 2.1 Mbps. These data rates may change in the future. [0088] For example, as shown in Figure 6C, a SPP Bluetooth link may be established between the console device 100 and the audiometer 102 and numeric (e.g., command/response) data may be transferred between the devices. A HSP Bluetooth link may then be established and audio data may be transferred between the devices.

[0089] The data exchange between the console device 100, the server 31 and the web client 35 associated with the audiologist can use both TCP and UDP protocols.

Audiologist commands are transmitted in connection-oriented TCP packets. Audio signals, such as those transmitted from the console 100 to the web client 35, are transmitted using the UDP protocol.

[0090] The console device 100 is configured to process data received from one end (audiometer 102 or server 31) before it forwards data to the other end. Commands from the server are extracted from the TCP packets and encoded into Bluetooth (BT) packets before being forwarded to the audiometer 102 (e.g., using SPP). During a speech test, the console device 100 receives audio streams from the audiometer 102 (e.g., using HSP or HFP). In some embodiments, this audio signal is segmented into units before the segmented signal is packed into UDP packets and sent to the server 31. In some embodiments, the segmented units have a length of between about 50 and 150 ms. In some embodiments, the segmented units have a length of about 100 ms.

[0091] In some embodiments, the console 100 includes an adaptive filter 100F (e.g., a Wiener filter) to improve the quality of the streamed audio signals (Figure 4). The implementation of the filter 100F may be performed in the time domain based on signal statistics (e.g., mean and variance) of individual local segments. In some embodiments, the filter is implemented on the console 100 using C/C++.

[0092] The console device 100 may coordinate multiple tasks (or threads), which may be assigned different priorities depending on their tolerance to time delay. Receiving audiometer data is typically assigned with the highest priority to help ensure that no audio signal is lost.

[0093] Figure 7 is a data flow diagram and flowchart that illustrates exemplary operations and methods according to some embodiments. The patient 50 or assistant

52 may first schedule an appointment, for example by inputting the desired appointment date and time at the console 100 which transmits the data to the server 31. Before and/or at the time of the scheduled appointment, the console 100 can be powered on and connect to the server 31. In some embodiments, the controller 104 (Figure 4) is configured to operate the TCP socket module 120 to connect to the Internet 20 and the server 31. About the same time, the audiologist 40 logs on to the web server 31 via his or her web client 35 and selects the specific appointment.

[0094] In response to the audiologist 40 logging on and preparing the test, the server 31 may send a notification signal to prompt the patient 50 and/or the assistant 52 to get ready for the test. In response, the patient 50 or assistant 52 can confirm they are ready for the test (for example, by using the user interface 114 on the console device 100) and the console device 100 transmits a ready signal that is received at the web client 35 associated with the audiologist. The notification signal and the response signal may be received and transmitted as TCP packets at the console device 100.

[0095] Upon confirmation that the patient 50 and assistant 52 are ready, the audiologist 40 starts the test. For example, in a pure-tone audiogram test, the audiologist 40 sets test parameters such as frequency, level, headset type, stimulus type and tone mode. After setting the parameters, the audiologist initiates the test and operational command data is received at the console 100. In response, the console 100 forwards a command to the audiometer 102 which generates a sound at the selected frequency and volume. If the patient 50 hears the pure-tone sound, he or she may push a button on the audiometer and the console 100 sends a response back to the audiologist 40.

[0096] In some embodiments, the operational command data is received as TCP packets at the TCP socket module 120 (Figure 5) of the console 100. The console 100 is configured to process the TCP packet data and convert the data to Bluetooth packets that are communicated to the audiometer 102 using the Bluetooth interface 110 and/or the audiometer module 124 (Figure 5). The console 100 is configured to receive the patient response as Bluetooth packets at the Bluetooth interface 110 and/or the audiometer module 124. The console 100 is configured to process and convert the Bluetooth packets to TCP packets which are transmitted using the TCP socket module 120.

[0097] Figure 8 is a data flow diagram and flowchart that illustrates exemplary operations and methods associated with speech tests according to some embodiments. The audiologist selects test parameters and a speech track and, in response, operational command data is received at the console 100. The operational control data includes an identification of the selected speech track. In some embodiments, the operational command data is received as TCP packets at the TCP socket module 120 (Figure 5). In response, the console 100 may send an acknowledgement using the TCP socket module 120.

[0098] The console 100 is configured to process the operational command data and forward the processed data as Bluetooth packets to the audiometer 102. In response, the audiometer 102 plays the speech track selected by the audiologist 40 and identified in the operational command data. The patient 50 attempts to repeat the speech track. The patient's speech is captured by a microphone associated with the audiometer 102. For example, the patient may be wearing the headset 62 (Figure IB) and the microphone 62B may capture the patient's speech.

[0099] The audiometer 102 transmits the captured speech data as Bluetooth packets to the console 100 (for example, using the HSP link). The console 100 is configured to process and convert speech data from Bluetooth packets to UDP packets and transmit the speech data as UDP packets using the UDP socket module 122 (Figure 5). The speech data is forwarded to the audiologist 40 for real-time playback of the patient's speech (e.g., at the web client 35 associated with the audiologist). The audiologist 40 then reviews the patient response.

[0100] Figure 9 illustrates an exemplary screenshot that may be displayed at the web client 35 associated with the audiologist 40. Specifically, an interface for setting up and accessing a speech test is illustrated in Figure 9. The audiologist 40 may select the desired test mode (e.g., "MCL" for maximum comfort level or "UCL" for uncomfortable level). The audiologist 40 then selects an audio track from a provided list L and hits the "play" or "start" button or icon to send the operational command data to the console 100 via the server 31. The audiometer 102 plays words in the selected track and records what the patient 50 attempts to repeat. The patient's repetition is transmitted from the console 100 and sent to the audiologist's terminal 35 via the server 31. The audiologist 40, depending on whether or not the patient has correctly repeated the words, presses the appropriate button (indicated as a "check" button or icon or an "X" button or icon). The audiologist can press the "silence" button or icon (shown next to the "check" and "X" buttons or icons) to record the number of word readings without receiving a patient response. The rate of successfully repeated words may be automatically calculated and stored in a database at the server 31. Other speech test modes such as SRT (Speech Recognition

Threshold) and different word recognition scores (WRS1 , WRS2, and WRS3) may be displayed and/or selected.

[0101] Figures 7 and 10 are data flow diagrams and flowcharts that illustrate exemplary operations and methods associated with two- and three-party

communication including the audiologist 40. In Figure 7, the patient 50 and/or the assistant 52 initiates a call (which may be an audio call or a videoconference) with the audiologist 40. In response to receiving an answer from the audiologist, the console 100 may establish an audio link (e.g., a Bluetooth link) with an appropriate device, such as the assistant headset 53 or the patient headset 62. The voice of the patient 50 and/or the assistant 52 may be sent to the console device 100 from the headset via the Bluetooth wireless link and forwarded to the remote audiologist 40 via the Internet 20. Video of the patient 50 and/or the assistant 52 may be captured by the camera 360 at the patient site and forwarded to the remote audiologist 40 via the Internet 20. Audio and/or video of the audiologist may also be captured (e.g., at the audiologist terminal 35) and forwarded to the console device 100. In this way, the audiologist 40 and the patient 50 and/or the assistant 52 can communicate in real-time before, during and/or after a hearing test. Figure 10 illustrates the reverse scenario in which the audiologist 40 initiates the call with the patient 50 and/or the assistant 52. As described above, the audio and video data may be received at and transmitted from the console device 100 as UDP packets.

[0102] Figures 11 and 12 are data flow diagrams and flowcharts that illustrate devices and exemplary operations and methods associated with enhanced reliability mechanisms that may be implemented between the web server 31 and the console device 100. A "heartbeat packet" (e.g., a beacon signal) can be used to maintain the online status of the console device 100 and the acknowledgement or response packet can be used to represent the online status of the audiologist. When the console device

100 malfunctions and/or the network access is down, the web server 31 can detect the online/offline status change and record any previous test data and/or a fault in the database 32. Similarly, when the webpage is closed due to incorrect operations by the audioiogist or web client 35, the console device 100 can disconnect from the server 31 automatically after sending a plurality (e.g., three) of heartbeat packets within a defined time frame, e.g., 10 seconds to 2 minutes, without receiving a response.

[0103] The at least one web server 31 can include a single web server as a control node (hub) or may include a plurality of servers (not shown). The system 10 can also include routers (not shown). For example, a router can coordinate privacy rules on data exchange or access. Where more than one server is used, different servers (and/or routers) may execute different tasks or may share tasks or portions of tasks. For example, the system 10 can include one or combinations of more than one of the following: a security management server, a registered participant/user directory server, a patient record management server, a scheduling server, an inventory tracking server, and the like. The system 10 can include firewalls 51 and other secure connection and communication protocols. For Internet based applications, the server 31 and/or at least some of the associated web clients 35 can be configured to operate using SSL (Secure Sockets Layer) and a high level of encryption. Furthermore, given the ubiquitous nature of the Internet, test devices may readily be moved from site to site. Additionally, additional security functionality may also be provided. For example, incorporation of a communication protocol stack at the client and the server supporting SSL communications or Virtual Private Network (VPN) technology such as Internet Protocol Security Architecture (IPSec) may provide for secure

communications between the patient sites and the test administration sites to thereby assure a patient's privacy.

[0104] As shown in Figures 1A and 2, the systems 10 may include a web portal lOp that controls participant access. The web portal lOp may also communicate with the server 31 that controls traffic. The web portal lOp may be configured to be user- specific based on defined privacy or privilege levels of the user. That is, each web client 35 can display a different web portal lOp configuration and/or different web pages associated with a specific user type (showing different permissible actions, commands and data options).

[0105] The server 31 can provide a centralized administration and management application. The server 31 can be configured to provide session management, tracing and logging systems management, workload management and member services. The server 31 can include or communicate with a plurality of databases including participant/user profiles, a security directory, routing security rules, and patient records. The server 31 can include several sub-servers for integration into web systems, such as, but not limited to, a web application server (WAS) which may comprise an IBM WebSphere Application Server, a Directory Server such as an LDAP directory server, and may include an Anonymous Global Patient Identifier (AGPI) Server, a DB2 Server, and a Simple Mail Transfer Protocol (SMTP) Server. It is noted that although described herein as "servers" other suitable computer configurations may be used. The server 31 can be configured with web application functions that appear at portal sites lOp. The server 31 may comprise and/or be configured as a Web Sphere Business Integration (WBI) server. The web server 31 can include a web-based administration application. The web application can be used to: allow a user to register as a participant, manage Access Control Lists (ACLs), logon using universal ID or password access, logoff, define profile preferences, search, approve test requests, receive test request(s), schedule tests, schedule shipments of consoles 100 (optionally with 102) or 1001, and the like.

[0106] The web clients 35 can be associated with different users and different user categories or types. Each category or type may have a different "privilege" or access level to actions or data associated with the systems 10. For example, the systems 10 can include clinician users, administrative users, and accounting users, each of which can have different access levels or restrictions to data and/or actions allowed by the system.

[0107] The web clients 35 can be distributed at different geographic locations in different time zones and states or even countries. In other embodiments, the web clients 35 can be at a single medical center with audiologists that can administer the test. Different user types may be at different geographic locations. For example, one or more of accounting, insurance submission and oversight, inventory management

(of the test devices), and scheduling may be handled at different locations from the audiologists. Indeed, a nurse (where used) may be located in a different location from the audiologist and yet work "together" as a clinician team on a particular patient case.

The nurse user (where used) may have a different portal configuration than an audiologist user. Similarly, a physician user (where used) may have the same or a different configuration than a nurse and/or audiologist user. In other configurations, the nurse and audiologist use the same web client 35 at the same location, but each includes different log-on identifiers, which gives them different privileges, actions and/or commands associated with the hearing system.

[0108] An assistant user 52 may have the same or different privilege or access level as a patient user 50 at a patient site 54. In some embodiments, although the patient 50 and assistant 52 use the same console device 100 at the same location, each includes different log-on identifiers, which gives them different privileges, actions and/or commands associated with the hearing system.

[0109] The patient test site can be at a multi-user site, such as a factory or industrial office, a medical related facility, such as a hospital, general practice clinic, or pediatrician's office, nursing home or may be a private residence or other location where a patient has access to the Internet.

[0110] Referring to Figures 2, 3 and 13, the web-based service system 10 can have a distributed, client-server architecture 30. The term "web-based service" is intended to be interpreted broadly so as to encompass many discrete or different web-based services under the umbrella of the web-based hearing test system 10, typically separating the clinical services from the administrative services, such as from users associated with the management, maintenance, support and financial services. That is, for example, the services related to the management and support of the system 10 can be separated from the services rendered by audiologists to the patients. In some embodiments, under this architecture, patients, assistants, audiologists, nurses, and other users (e.g., financial workers such as those workers/users in billing, collections or accounting) can log onto the system 10 with different privileges (and possibly with different portal configurations, web pages and/or user interfaces). The different user categories, e.g. , audiologists 40, administrative support 41, accounting 42, nurses 43, and optionally, physicians 44, can each have different tasks and different access levels to the system. A nurse 43 and audiologist 40 (and or physician 44) may have the same level of privilege or the audiologist (and physicians 44, where allowed) and nurses 43 may have different levels of access or privileges. They may use the same portal or client or different portals/clients. [0111] In some embodiments, the physician users 44 may be configured to communicate with the system 10 independent of an assistant, such a nurse (e.g. , in parallel) or may be configured to access the system 10 after an assistant, (e.g., in series) or other user requests medical evaluation by the physician. To facilitate timely intervention, the physician session can be scheduled while the patient-user is being tested by the audiologist or shortly after a hearing test when a patient user can still be on-line and accessible, e.g. , proximate in time to a hearing test session (such as within 10-60 minutes after such a test session), typically upon referral via a nurse or audiologist. The system 10 may allow physicians to identify their available status using a web page. The system 10 can identify a queue of available physicians and update that queue so that physicians can connect into the system in a timely manner. The physician session can be remotely carried out in substantially real time after the audiologist or nurse requests a medical evaluation if a nurse or audiologist user determines that such is a desired action based on information obtained during a hearing test. The physician 44 can access the system 10 to review a patient's records and/or interview and communicate with the patient user for further evaluation. In some embodiments, the physician 44 and audiologist 40 or nurse 43 can be in communication with each other participate in the medical evaluation. Alternatively, the medical evaluation can be summarized and sent to the audiologist forming a medical record after the audiologist has terminated a hearing test session.

[0112] The distributed structure can promote increased efficiency in management by tracking transactions through the at least one server 31. The system 10 can support multiple hearing tests at different user sites including clinical users, audiologists 40, nurses 43, physicians 44 (or physician assistants), where used, patients 50 and administrative users 41 concurrently.

[0113] As shown in Figure 13, the system 10 can include a patient record database and/or server 210 as well as a user privilege based and/or restricted access register

220. The patient record database and/or server 210 can include electronic medical records (EMR) with privacy access restrictions that are in compliance with HIPPA rules due to the client-server operation and privilege defined access for different users. The hearing tests can be performed using the system 10 while allowing interactions between users 50, 40 in a substantially real-time manner. [0114] Figure 13 also illustrates that the console 100 (and optionally a separate audiometer 102) or integrated console 1001 can be matched to a requesting patient 50R or requesting assistant 52R in advance of a scheduled test date. The

administrative support user 41 can be directed to ship or provide the console 100, 1001 to the assistant or patient based on the scheduled test date or request for a test by a participating (and approved or registered) patient 50. The inventory management system can be managed by the administrative support function 41, which can include an electronically tracked queue of inventory as well as status and projected and actual use. The support function 41 can also send the test reminders, return reminders, and track shipments, returns and pick-ups.

[0115] Figure 14 illustrates that the server 31 can pair patient users 50 (and possible assistant users 52) with audiologist users 40 for hearing tests. The server 31 (or subservers, databases or other servers in communication therewith) can match a patient's geographic location, time zone, insurance compatibility issues and schedule preferences (if provided) to a registered audiologist that is in that same geographic location and/or time zone or a compatible time zone and has openings (dates and times) that meet scheduling parameters. In some embodiments, the system 10 can be configured to define what states, countries or appropriate jurisdictions that a registered audiologist is licensed to practice in (where such states have those requirements for practicing medicine on its citizens or on patients within its borders) and is in good-standing, before selecting the audiologist for scheduling. The system 10 can have a compliance monitoring circuit that can require certificates of compliance and proof of licensure annually or at other intervals. Thus, the system 10 can be able to electronically consider only those registered audiologists licensed in a state associated with the patient, then select one for testing based on those

audiologists licensed for that state. After this initial pre-selection, other rankings can be used to select a match (such as audiologist availability, those within the same state, region or zip code) or the system can select via an arbitrary, random or in serial order, an audiologist that is matched to a patient. The system can be configured to allow a patient to be retested using the same audiologist. The system 10 can also provide more than one audiologist "referral" and allow the user/patient to select the one for his/her test. [0116] The test may be requested but not scheduled until an assistant or a patient has an actual console 100, 1001, at which time the assistant or patient may electronically communicate the device indentifying data (e.g. , serial number, part number, revision number, manufacturer and the like). The test can then be (promptly) scheduled. In other embodiments, the test is scheduled first, and the test device 100, 102 and/or 1001 is then shipped or scheduled for pick-up locally by the patient proximate in time to a scheduled test date.

[0117] It is contemplated that different test consoles or audiometers may be used or may be revised over time. The system 10 can be configured to allow for use with different audiometers 102 and different consoles 100 by providing for a test input that defines what equipment is at the patient site. The system 10 can thus support multiple known equipment configurations while providing the same diagnostic output and modify the control and communication of the test administration based on the knowledge of the tools and the different operational protocols.

[0118] Figure 15A illustrates an example of a user interface or web portal, which identifies a user type and is correlated to an access level (shown as Levels I-III). For audiologists, the portal can display patient information and location with the type of adapter or other adapter information. Different actions can be selected depending on the user. The portion of the display 11 showing "Type of Action" illustrates three different action types for three different user types. The top is for a patient user, the middle is for an audiologist user, and the lower is for an administrative user. If an audiologist selects the action "perform test", a pop-up menu or subsequent screen can be displayed which allows the audio test output selections.

[0119] As illustrated in Figure 15B, some embodiments of the present invention may allow a patient and an audiologist to access a web portal providing a diagnostic hearing test while using online multimedia communications to synchronize and coordinate the hearing test. Services related to online multimedia communications may be provided by a third-party online multimedia communications service provider

310, which may be, e.g. , a consumer videoconferencing service provider such as

Skype, Microsoft Live Messenger, Yahoo! Messenger, America Online Instant

Messenger, or Apple iChat. Audiologist 40 and patient 50 and/or assistant 52 can both access the diagnostic hearing test provided by web portal lOp over the Internet 20. At the same time, webcams 350 and 360, communicatively coupled to computers 370 and 380 used by audiologist 40 and patient 50 and/or assistant 52, respectively, may transmit multimedia communications between audiologist 40 and patient 50 and/or assistant 52 over the Internet 20 via online multimedia communications service provider 310. Once connected to a patient 50 and/or assistant 52 via online multimedia communications service provider 310, an audiologist 40 may use online multimedia communications to facilitate the administration of the hearing test provided by web portal lOp by, e.g., responding to patient inquiries, demonstrating proper use of test equipment, or indicating when patient 50 and/or assistant 52 is to perform test-related activities, allowing visual monitoring of the patient during the hearing assessment and the like. In other embodiments, and as described in detail above, functionality for providing online multimedia communications may be integrated into the system 10 web portal lOp, such that a separate third-party service provider is unnecessary.

[0120] Referring to Figure 16, in some embodiments, a web-based service can host a diagnostic hearing system (block 200) with at least one server that includes hearing diagnostic software that programmatically allows patients or assistants and audiologists to communicate. The service can accept input from registered clinicians to communicate with the web-based service (block 210). The service can accept user input from patients or assistants to communicate with the web-based service to request a test, schedule a test, or take a test (block 220). The web-based service allows an interactive hearing test between the clinician and a respective patient and/or assistant (block 230). The service can optionally provide a web portal that allows audiologists to select a patient-test identifier to initiate a hearing test session (block 235).

[0121] Patient data records can be electronically saved in a database and/or server associated with the web-based service (block 240). The system can include a database of registered authorized users (block 245) and can be configured to electronically identify an audiometer at the patient test location (block 250). The system can select an audiologist to perform a hearing test for a patient based on patient location and/or test times (block 255). Optionally, the system can select the audiologist only if the audiologist has a current medical license for the state where the patient is located (block 260).

[0122] The system can identify a user and/or user category or type and correlate the user/user type to an approved access level (block 270). A user portal provides information regarding electronic tracking and inventory control of console devices, including those ready for use, those in use and those scheduled for use (in the queue for refurbishment, being returned and/or in preparation (recalibration, etc...) after a prior test, or reserved for patient use) (block 280). A console device can be shipped to a patient test site or a patient in advance of a test session (block 285), e.g., after a test is scheduled or shipping to a patient/patient test site, then upon receipt having the patient or assistant electronically confirm that by entering the web portal and entering the device identifier or other identifying information, then having a test date scheduled.

[0123] The hearing test can be administered by the registered audiologist user at a test administration site, remote from the patient site in a manner which can allow interaction (typically one or more of a non-verbal, verbal, and/or visual

communication interaction either one or two way) between the user and the clinician during at least a portion of the administration of the test. A video input associated with the patient and/or audiologist may also be used to allow one or two-way visual communication. The diagnostic hearing tests can be performed such that they meet or comply with standardized guidelines such as the American National Standards

Institute ("ANSI") requirements or other agency or regulatory standards, as desired for the particular testing authority in a particular jurisdiction.

[0124] The system 10 can be configured to allow the audiologist to control the test sequence and auditory hearing assessment tones from the remote administration site.

Thus, the hearing test can be performed such that the hearing tones (frequency and decibel level) are generated and output locally at the patient site from the console device 1001 or audiometer 102 in response to commands transmitted from the remote site over the Internet as received by the console device 100, 1001 that selects the desired tone/level which are transmitted from the expert or test administration site to the local site via the computer network. In turn, the local audiometer 22, based on the received or relayed commands, generates the tones and controls the levels output to the user/patient so that they are output to the patient in a controlled calibrated manner.

In certain embodiments, the system is also configured to accept the patient's input or response during the test and transmit the associated data back to the administration site where it can be considered and evaluated. The system can also allow the test administrator (typically an audiologist) to adjust the test sequence or tone based on the patient's indicated response during the testing protocol. Thus, the audiologist can adjust the testing parameters or protocol based on the patient's response during the testing procedure. In so doing, the test administrator can, inter alia; (a) select or adjust the tone transmitted to the patient, (b) repeat one or more of the tones or frequencies, and/or (c) render a diagnostic evaluation.

[0125] The system 10 can also be configured to carry out a remote-controlled

(internet based) tympanometry examination and/or an otoacoustic emission (OAE) test. Tympanometry tests the condition of the middle ear and/or the mobility of the eardrum (tympanic membrane) and the conduction bones by creating variations of air pressure in the ear canal. Tympanometry is an objective test of middle-ear function.

The tympanometry evaluation can be done in conjunction with the hearing (pure tone audiometry) test as it is a measure of energy transmission through the middle ear. In evaluating hearing loss, tympanometry permits a distinction between sensorinueural and conductive hearing loss, when evaluation is not apparent by other testing.

Furthermore, tympanometry can be helpful in making the diagnosis of otitis media by demonstrating the presence of a middle ear effusion. OAE measures an acoustic response that is produced by the inner ear (cochlea) which, generally stated, bounces back out of the ear in response to a sound stimulus. The test is typically performed by placing a small probe that contains a microphone and speaker into an infant's ear. A clinician can determine which sounds yielded a response/emission and the strength of those responses. If there is an emission present for those sounds that are critical to speech comprehension, then the infant has "passed" the OAE hearing screen.

[0126] Figure 17A illustrates an exemplary data processing system or database environment that may be included in devices operating in accordance with some embodiments of the present invention. As illustrated in Figure 17 A, a data processing system which can be used to carry out or direct operations of the hub and/or web application {e.g. , comprising an Administrative Server) includes a processor 138, a memory 136 and input/output circuits 146. The data processing system may be incorporated in, for example, one or more of a personal computer, server, router or the like. The processor 138 communicates with the memory 136 via an address/data bus 148 and communicates with the input/output circuits 146 via an address/data bus 149. The input/output circuits 146 can be used to transfer information between the memory (memory and/or storage media) 136 and another computer system or a network using, for example, an Internet protocol (IP) connection. These components may be conventional components such as those used in many conventional data processing systems, which may be configured to operate as described herein.

[0127] In particular, the processor 138 can be commercially available or custom microprocessor, microcontroller, digital signal processor or the like. The memory 136 may include any memory devices and/or storage media containing the software and data used to implement the functionality circuits or modules used in accordance with embodiments of the present invention. The memory 136 can include, but is not limited to, the following types of devices: cache, ROM, PROM, EPROM, EEPROM, flash memory, SRAM, DRAM and magnetic disk. In some embodiments of the present invention, the memory 136 may be a content addressable memory (CAM).

[0128] As further illustrated in Figure 17A the memory (and/or storage media) 136 may include several categories of software and data used in the data processing system: an operating system 152, application programs 154, input/output device drivers 158, and data 156. The application programs can include a User Registry module 120, a hearing test module 124, a patient record module 125, and the like.

The data 156 can include user profiles with defined access levels 126. The user profiles 126 may additionally or alternately include an application program.

[0129] Figure 17B illustrates the system 10 can include a Hearing Trend Analysis

Module 122 (that may be an application program similar to the modules discussed above with respect to Figure 17A) that can access electronically stored patient records (shown as records 125R1, 125R2 and 125R3) in the patient record database

125 and generate a visual output/display of a graph of hearing test trends. Thus, in some embodiments, the system 10 can be configured to electronically store hearing test results of a patient in a database taken at different past points in time, electronically review the patient's past hearing test results (typically upon request by a user), then electronically predict future hearing test results based on the review of past results. A trend can be electronically generated and shown on a display associated with a client 35 (e.g., an audiologist or nurse). The trend can be in graphic form and may indicate a risk of future hearing loss (hearing ability) based at least in part on the past results (change over time or during a specific time interval) and may predict future changes in hearing based on the trend. An increased monitoring period (shorter time interval between tests) can be set for those patients identified as being at increased risk of having a hearing loss. As shown, the system 10 can be configured to generate a "flag" 125F that increases the test frequency or monitoring schedule if that patient is identified as being at risk of hearing loss. The system 10 may also be configured to alert employers via email, postal mail and/or using text messages or other suitable communication protocol 125A to notify an employer (such as

Environmental Health and Safety Department personnel or clinical staff) and/or patient-users themselves, of patients having increased risk of hearing loss so that the employer can take corrective action so that those patients can be fitted with hearing loss equipment of different jobs to inhibit further hearing loss. The system 10 may also be configured to notify regulatory agencies such as OHSA (Department of Occupational Health and Safety) of identified cases of hearing loss for employee protection. The notification may be such that any patient identifier data is removed from any such notice to meet HIP PA guidelines.

[0130] As will be appreciated by those of skill in the art, the operating system 152 may be any operating system suitable for use with a data processing system, such as

IBM®, OS/2®, AIX® or zOS® operating systems or Microsoft® Windows® operating systems, Unix or Linux™. IBM, OS/2, AIX and zOS are trademarks of

International Business Machines Corporation in the United States, other countries, or both while Linux is a trademark of Linus Torvalds in the United States, other countries, or both. Microsoft and Windows are trademarks of Microsoft Corporation in the United States, other countries, or both. The input/output device drivers 158 typically include software routines accessed through the operating system 152 by the application programs 154 to communicate with devices such as the input/output circuits 146 and certain memory 136 components. The application programs 154 are illustrative of the programs that implement various features of the circuits and modules according to some embodiments of the present invention. Finally, the data 156 represents the static and dynamic data used by the application programs 154, the operating system 152, the input/output device drivers 158 and other software programs that may reside in the memory 136.

[0131] While the present invention is illustrated with reference to the application programs 120, 124, 125 in Figure 17A (and 122 in Figure 17B) as will be appreciated by those of skill in the art, other configurations fall within the scope of the present invention. For example, rather than being application programs 154 these circuits and modules may also be incorporated into the operating system 152 or other such logical division of the data processing system. Furthermore, while the application programs 120, 124, 125 (122) are illustrated as modules in a single data processing system, as will be appreciated by those of skill in the art, such

functionality may be distributed across one or more data processing systems. Thus, the present invention should not be construed as limited to the configurations illustrated in Figures 7 A, 7B but may be provided by other arrangements and/or divisions of functions between data processing systems. For example, although

Figure 7A, 7B are illustrated as having various circuits and modules, one or more of these circuits or modules may be combined without departing from the scope of the present invention.

[0132] Typically, during "on-boarding" or customer set-up, a client 35 is brought into the network or system 10 and assigned one or more privacy levels based on a legal or organizational entitlement to send and/or receive certain types (and/or content) of data. An organization may include one or a plurality of web clients 35, each with one or more different assigned privacy levels. The privacy level can define what data that entity or person associated with that entity can receive, send or access.

[0133] As shown in Figure 3, the server 31 can communicate with a register 120 that can correlate a subscriber user with a particular privacy level and can act to control communications to inhibit or prevent access to non-authorized or non-entitled data, using, for example, a security directory, participant profiles, and rules. Each subscriber/user or registered participant has an assigned privacy level. [0134] The console devices 100 and associated audiometer 102 or integrated console device 1001 can be configured to provide, in a calibrated or controlled manner, hearing assessment signals (speech and non-speech signals) in a plurality of different frequencies (such as 5-10 or more frequencies). In some embodiments, at least 8 different frequencies are evaluated during the test, with frequencies ranging between about 20-20, 000Hz, and more typically between 125-12,000 Hz. The frequency of the tone will also be output to the user/patient with known intensity levels ranging from about 0 to about 120 dB (sound pressure level), depending on the test frequency. The hearing test, provided by the computer networked system, is able to generate tone presentations which meet ANSI standards, thereby providing, in some embodiments, a web-based testing protocol which meets recognized standardized hearing diagnostic standards.

[0135] The audiometer 102 (stand alone or on-board) can include a tone generator an output device and an input device. The output device 60 (Figure 1) can be a transducer such as a bone conduction oscillators or vibrators, insert earphones (i.e., over-the-ear ("OTE"), in-the-ear ("ITE"), behind-the-ear ("BTE")), or conventional supra-aural earphones or headphones or the console devices can include several types of output devices for serial use by the patient according to audiologist

directions/instructions. In some embodiments, it is anticipated that speakers may also be acceptable output devices.

[0136] The tone generator is configured to generate the desired frequency tone at the desired level and transmit the tones to the output device. The tone presentation of the hearing signal generated by the tone generator may be "continuously on" or manipulated to present a "pulse tone." For additional discussion of test signals and audiologist controls/commands and on-board test adapter configurations, see, U.S. Patent No. 6,916,291, the contents of which are hereby incorporated by reference as if recited in full herein. One example of suitable testing protocols is shown in Table 1.

Table 1. Frequency and maximum hearing levels for device

125 70

250 90 45

500 120 60

1000 120 70

2000 120 70

3000 120 70

4000 120 60

6000 1 10 50

8000 100

12000 90

[0137] The tone presentation may be adjusted or determined depending on the configuration of the output device in use or the particular testing protocol desired (different output devices may be used at different local patient sites typically depending on (a) the patient and (b) the noise associated with the testing

environment). In certain embodiments, the pulse length is presented to the patient such that it does not exceed about 225 ± 35 ms. For air conducted signals, the tone is typically transmitted to the user for at least about 20ms and such that it is equal to or less than about 50ms. For bone-conducted signals, the rise or onset time shall be no less than 20ms. When the tone is terminated, the "fall" time is less than about 20 ms. The duration of the tonal plateau can be presented to the patient such that it is equal to or above about 150 ms.

[0138] As shown above in Table 1, the testing protocol can include 10 different frequencies ranging from 125Hz to 12000Hz. Additional or lesser frequencies can be used, depending on the applicable test standard, although typically, the test frequencies will be between 20-20,000 Hz. The frequency accuracy for each test signal tone generated can be presented to the patient such that the signal is within about 1% of the indicated tone frequency.

[0139] In certain embodiments, the hearing assessment presentation signals can include frequency tones, narrow band noise, broadband noise, recorded noise and speech, as well as live speech. In certain embodiments, the device 20, 22 or 201 may also be configured such that the harmonic distortion of the tone frequencies are able to meet the current ANSI standards; an example of a current standard ANSI-S3.6 1996 is listed in Table 2. Thus, in certain embodiments, the maximum level of the harmonics of the test tone relative to the level of the fundamental may be presented so as to not exceed the values given in Table 2 below.

Table 2: Maximum permissible harmonic distortion, expressed in percent *

* ANSI-S3.6 1996

[0140] In operation, the desired hearing tone presentation is transmitted to the output device and to the patient. In response, the patient can indicate a response to the tone to the input device. The input device can be a voice activated or speech recognition input microphone, or a physical input port such as a keypad, button, screen-contact software switch, or physical switch. As noted above, in certain embodiments, the input device can be (or include) a video camera which is video linked to the test administration site so that the clinician can visually monitor the patient's response during the test. Further, two individually operable input devices can be employed: one for use when the patient acknowledges a tone to the right ear and one for when the patient acknowledges hearing from the left ear. It will be appreciated that, in some embodiments, the input device may be on the output transducer headset itself as an alternative to the housing body of the device. The device 100, 102 and/or 1001 may, in some embodiments, include or communicate with a microphone to measure the ambient or environmental noise within the testing room or locale, at the patient site. This embodiment can allow the system to assure that the test complies with appropriate standards, such as ANSI S3.1-1999. This standard specifies the maximum permissible noise levels (MPANL) allowed in a room for audiometric threshold assessment. In certain embodiments, the microphone can be configured to measure or detect sound pressure levels or noise in the range of between about 20Hz to 20kHz, and may, in some embodiments, detect sound pressure levels at octave intervals 125 to 8,000Hz or up to 12,000 or greater Hz. The microphone may operate prior to initiation of the testing procedure to determine what the noise or sound level is and if a particular type of output device should be employed (such as whether supra-aural or insert earphones are appropriate to meet the applicable standard).

Sound level measurement of ambient noise

Table 3: Octave band ears covered maximum permissible ambient noise levels

Values are in dB re: 20wPa to nearest 0.5 dB

[0141] In other embodiments, a passive biotelemetry reading of the

structure/operation of the ear (i.e., middle ear analysis, cochlea hair cell response, and the like) can be obtained. This measurement or reading can be administered in addition to (or separately from) the tone hearing test protocol. The biotelemetry sensor can be incorporated into the transducer output device 60 (Figure 1) or can be an additional component. In operation, an operator at the test administration site can activate the local biotelemetry sensor in the ear of the subject and the associated measurement can be passively obtained (without requiring the subject to verbally or visually communicate). The measurement can be relayed to the test administration site via the communication link to the computer network 10. The biotelemetry methods/systems can acquire multiple data sets and transmit them through the computer network to allow a remotely located clinician to generate a biotelemetry analysis of the auditory system of the patient. The multiple data sets can include data corresponding to auditory evoked potentials from clicks, tonal or speech stimuli, otoacoustic emissions from either distortion-product and/or transient approaches, middle-ear compliance (achieved from either single or multiple frequency stimulation and pressure) and/or acoustic reflex response. Thus, for example, the system can be configured to provide the remote web-gathering of auditory evoked potentials. The local biotelemetry sensor may be activated/controlled by the remote site in a manner that allows for adjustment during the evaluation and/or measurement such that the data is relayed to the remote/test administration site in substantially "real-time" or at certain points in time during administration of the test. Embodiments of systems and methods related to web-based acquisition and analysis of transient and distortion product otoacoustic emissions and middle ear testing will be described further below.

[0142] Figures 18A-18C illustrate exemplary web pages 10pi-10p₃ associated with an audiologist user 40. Figure 18 A illustrates a Patient Information web page with the patient information, patient ID, and Console Device ID. The user 40 can start a new test or view results of a test. Based on the selection of the "start test" in the NEW TEST section of web page 10pi, Figure 18B displays the second web page 10p₂ with control selections and actions for the audiologist. The interface on the left with "PATIENT RESPOND" indicates that it is waiting for a patient to respond to the signal and indicates the status of the device (Left, Right, connector, stimulus and mode). The connector type refers to air conduction or bone conduction. The stimulus selection includes tone and NBN (narrow band noise) and the mode refers to steady and pulsed. The web page 10p₂ also illustrates a duration selection input and a device initialization input as well as an END TEST selection. Figure 18C illustrates a third web page 10p₃ that provides the hearing test results with the audiometer and/or test adapter identification and Left and Right hearing results by connector type (A or B).

[0143] In summary, particular aspects of the invention provide a distributed telehearing system that can be configured so that maintenance, support, and management can be physically and/or logically separate from clinical services and may use any suitable architecture such as, for example, browser-server or client- server.

[0144] Some aspects of the invention provide a console device that facilitates reliable connectivity and includes features that address technical challenges associated with bandwidth requirements for remote hearing tests, including speech tests, and for multi-party real-time audio and video communication between various parties involved in such remote hearing tests.

[0145] Although the console device 100 has been described as being used in connection with telehearing systems, it is contemplated that the console device 100 as described herein may be used for a variety of telehealth applications. As described herein, the console device 100 provides solutions to bandwidth concerns that arise in connection with the (real-time) audio and/or video communication that is desirable in many telehealth services.

[0146] It is also contemplated that a smartphone, tablet computer or the like may run an "app" or application program that provides the functionality of the console device 100 described herein. For example, the application program may be on an iPhone, iPad, Android device or the like, with that device serving as the "console" as described herein.

EXAMPLE

[0147] A functional prototype of the console device 100 described above has developed (Figure 19) based on a high-performance evaluation board which includes a 720MHz ARM Cortex-A8 processor, 512 MB SDRAM and peripheral interfaces including audio input/output interfaces, a USB port (for external camera), a LAN port, a serial port, a touch screen interface (for the 7" LED display) and a keyboard interface. An extended Bluetooth interface (EKWT12) is provided that enables the connection and data communication between the console device and the audiometer. Multiple profiles such as the serial port profile (SPP), headset profile (HSP) and hands-free profile (HFP) are supported by the Bluetooth interface, which in turn enables both the pure-tone audiogram test and the speech test. These hardware components satisfy the needs to implement the modules described above in connection with Figure S.

[0148] Initial tests and calculations have been performed to verify that the latency involved in the data transmission and bandwidth can satisfy the application needs.

Table 4 illustrates the response rate of the Bluetooth audiometer responding to numeric commands and the average, minimum and maximum latency at the server in the pure-tone audiogram test. The maximum latency of about 0.6 seconds is acceptable for the pure-tone audiogram test session.

Table 4: Results of Pure-Tone Audiogram Test (5000 repeats)

[0149] Table 5 presents the results of transmission rates of the audio data in speech tests and the average, minimum and maximum latency of the audio data from the patient to the web server. The maximum unidirectional latency of voice data is reasonable in both the speech test and the three-party communication.

Table 5: Results of Voice Transmission (2000 UDP packets)

[0150] Table 6 presents the setup time of voice communication session between an audiologist and an assistant. The maximum setup time is on the order of one second, which is also acceptable in three-party communication.

Table 6: Results of Voice Communication Setup Time (100 Repeats)

[0151] The network communication capacity was also examined. A pure-tone audiogram test only needs fairly limited capacity because it transmits messages with lengths of only a dozens of bytes during each test point (at a certain frequency and dB level). Therefore, no bandwidth verification is necessary for the pure-tone audiogram testing mode. For the speech test session, the voice of the audiometer is captured at the rate of 8,000 Hz, in stereo and 16 bits per sample, which will need a maximum bandwidth of about 256 kbps to transmit the voice data. According to the Bluetooth Enhanced Data Rate (EDR) specification v2.0+, the enhanced data rate is about 3 Mbps, although the practical data transfer rate can be lower at about 2.1 Mbps. It is apparent that the Bluetooth link capacity can meet the higher bandwidth requirement for typical speech tests.

[0152] The foregoing is illustrative of the present invention and is not to be construed as limiting thereof. Although a few exemplary embodiments of this invention have been described, those skilled in the art will readily appreciate that many modifications are possible in the exemplary embodiments without materially departing from the novel teachings and advantages of this invention. Accordingly, all such modifications are intended to be included within the scope of this invention as defined in the claims. In the claims, means-plus-function clauses, where used, are intended to cover the structures described herein as performing the recited function and not only structural equivalents but also equivalent structures. Therefore, it is to be understood that the foregoing is illustrative of the present invention and is not to be construed as limited to the specific embodiments disclosed, and that modifications to the disclosed embodiments, as well as other embodiments, are intended to be included within the scope of the appended claims. The invention is defined by the following claims, with equivalents of the claims to be included therein.

Claims

THAT WHICH IS CLAIMED IS:

1. A console device for use at a patient site in a telehearing system including a web client associated with a remote audiologist and a web server that communicatively connects the console device and the web client over the Internet, the console device comprising:

a Transmission Control Protocol (TCP) socket module;

a User Datagram Protocol (UDP) socket module; and

a controller configured to:

operate the TCP socket module to receive operational command data from the web client associated with the remote audiologist;

process the operational command data to control operation of an audiometer at the patient site;

process audiometer data including patent speech data to convert the patient speech data to UDP packets; and

operate the UDP socket module to transmit the converted patient speech data to the web client associated with the remote audiologist for evaluation of the patient speech data.

2. The console device of claim 1, wherein the controller is configured to operate the TCP socket module to connect the console device to the web server.

3. The console device of claim 1, wherein the audiometer data includes control messages associated with the patient speech data, and wherein the controller is configured to:

process the audiometer data to convert the control messages to TCP packets; and

operate the TCP socket module to transmit converted control messages to the web client associated with the remote audiologist substantially concurrently with the transmission of the converted patient speech data.

4. The console device of claim 1 , wherein the operational control data received from the web client includes a speech track, and wherein the controller is configured to process the operational command data to play the speech track at the audiometer,

5. The console device of claim 1, further comprising a wireless interface configured to establish a direct wireless connection with the audiometer.

6. The console device of claim 5, wherein the controller is configured to: operate the wireless interface to establish a wireless connection with the audiometer;

operate the wireless interface to forward the processed operational command data to the audiometer; and

operate the wireless interface to receive the audiometer data from the audiometer.

7. The console device of claim 6, wherein the wireless interface is a Bluetooth interface that is configured to operate using a serial port profile (SPP) and using a headset profile (HSP) and/or a hands-free profile (HFP), wherein the

Bluetooth interface is configured to forward the processed operational command data using the SPP, and wherein the Bluetooth interface is configured to receive the patient speech data using the HSP and/or the HFP.

8. The console device of claim 6, wherein the wireless interface is a Bluetooth interface, and wherein the controller is configured to:

convert TCP packets of operation command data received at the TCP socket module to Bluetooth (BT) packets;

convert BT packets of patient speech data received at the Bluetooth interface to UDP packets; and

convert BT packets of control messages associated with the patient speech data received at the Bluetooth interface to TCP packets.

9. The console device of claim 5, wherein the controller is configured to: operate the wireless interface to establish a wireless connection with a headset associated with an assistant at the patient site;

operate the wireless interface to receive assistant voice data from the headset; process the assistant voice data to convert the assistant voice data to UDP packets; and

operate the UDP socket module to transmit the UDP packets of assistant voice data to the web client associated with the remote audiologist for real-time playback of the assistant speech data.

10. The console device of claim 9, wherein the wireless interface is a Bluetooth interface, wherein the Bluetooth interface is configured to receive the assistant speech data using a headset profile (HSP) and/or a hands-free profile (HFP), and wherein the controller is configured to process the assistant voice data to convert BT packets received at the Bluetooth interface to UDP packets.

11. The console device of claim 1, wherein the controller is configured to: process patient and/or assistant video data associated with video of the patient and/or the assistant captured at the patient site to convert the video data to UDP packets; and

control the UDP socket module to transmit the converted video data to the web client associated with the remote audiologist for real-time playback of the video data.

12. The console device of claim 11 , wherein the controller is configured to:

operate the UDP socket module to receive audiologist video data associated with video of the audiologist from the web client and display the video of the audiologist.

13. The console device of claim 12, further comprising a display, the controller configured to operate the display to display the video of the patient and/or assistant and the video of the audiologist in real-time to provide videoconferencing capabilities.

14. The console device of claim 1, further comprising a display, the controller configured to operate the display to display a user interface (UI) that is configured to receive user input from an assistant at the patient site to configure and/or coordinate a hearing test session.

15. The console device of claim 14, wherein the controller is configured to operate the display to display test information including ongoing test information during the hearing test session.

16. The console device of claim 14, wherein the UI is configured to receive user input from an assistant at the patient site to initiate a voice and/or video call with a remote audiologist that is conducting the hearing test session.

17. The console device of claim 1, wherein the controller is configured to coordinate multiple tasks including receiving operational command data at the console device, converting the operational command data at the console device, transmitting the converted operational control data to the audiometer and receiving patient speech data from the audiometer at the console device and assign each task a priority based on its tolerance to time delay.

18. The console device of claim 17, wherein receiving patient speech data from the audiometer at the console device is assigned the highest priority.

19. The console device of claim 1, wherein the controller is configured to segment the patient speech data received from the audiometer into units and convert each segmented unit to UDP packets to send to the server.

20. The console device of claim 1 , wherein the console device includes an integral audiometer.

21. The console device of claim 1, the console device configured to process audiometer data including patent speech data to convert the patient speech data to UDP packets and operate the UDP socket module to transmit the converted patient speech data to the web server with a maximum latency of less than about 100 ms.

22, A telehearing system comprising:

at least one web server in communication with the Internet and configured to provide a web-based service that hosts a telehearing diagnostic testing system;

a plurality of web clients associated with remote audiologists at different geographical locations; and

a plurality of portable console devices, each one at a different patient site, each one comprising:

a Transmission Control Protocol (TCP) socket module; a User Datagram Protocol (UDP) socket module; and

a controller configured to:

operate the TCP socket module to connect the console device to the web server over the internet;

operate the TCP socket module to receive operational command data from a web client associated with one of the remote audiologists;

operate the UDP socket module to transmit the converted patient speech data to the web client associated with the one of the remote audiologists for real-time playback of the patient speech data.

23. The system of claim 22, wherein multiple consoles and audiologists users can simultaneously access the web-based service to allow multiple concurrent speech hearing tests to be carried out.

24. A console device for use at a patient site during a telemedicine session including a web client associated with a remote physician and a web server that communicatively connects the console device and the web client over the Internet, the console device comprising:

a Transmission Control Protocol (TCP) socket module;

a User Datagram Protocol (UDP) socket module; and

a controller configured to:

operate the TCP socket module to send and receive numeric data to and from the web server;

operate the UDP socket module to receive physician audio and/or video data associated with audio and/or video of the physician captured at the web client and display the video of the physician at the patient site; and

process patient audio and/or video data associated with audio and/or video captured at the patient site and operate the UDP socket module to transmit processed patient audio and/or video for display at the web client associated with the physician.