See discussions, stats, and author profiles for this publication at: https://www.researchgate.net/publication/38081171

Using web services to realize remote hearing assessment

Article  in  Journal of Clinical Monitoring and Computing · November 2009

DOI: 10.1007/s10877-009-9208-6 · Source: PubMed

CITATIONS

12READS

599

3 authors, including:

Some of the authors of this publication are also working on these related projects:

Literacy and CAP View project

Yongbo Wan

University of Kentucky

13 PUBLICATIONS   158 CITATIONS   

SEE PROFILE

Gregg D Givens

East Carolina University

42 PUBLICATIONS   480 CITATIONS   

SEE PROFILE

All content following this page was uploaded by Gregg D Givens on 26 December 2013.

The user has requested enhancement of the downloaded file.

USING WEB SERVICES TO REALIZE REMOTEHEARING ASSESSMENTJianchu Yao, PhD, Yongbo Wan, MS

and Gregg D. Givens, PhD

Yao J, Wan Y, Givens GD. Using web services to realize remote

hearing assessment.

J Clin Monit Comput 2010; 24:41–50

ABSTRACT. Background. Internet-based tele-audiology is

expected to relieve the dilemma between the lack of resources

and high demand of audiological care services. This paper

presents a web services based, distributed pure-tone hearing

assessment system that improves accessibility of traditionally

underserved groups to audiology care. Methods. The system

employs browser-server network architecture to connect

patients to audiology specialists through a web server where all

application software is hosted. Software on the server is

designed with a three-tier approach which makes the system

scalable to include other audiological services. Hearing test

data are stored in a standard database and can potentially be

integrated into established electronic medical records. On the

remote patient side, off-the-shelf audiometers are adopted.

The Internet connection of these audiometers can be flexibly

configured either with or without a computer. Two aspects of

the system were tested: (1) the clinical effectiveness of the

system: double-blinded experiments were conducted to assess

hearing ability of 30 subjects and paired t-tests were utilized to

compare assessment results from the remote approach and the

conventional setup; and (2) to analyze the system bandwidth

requirements, data traffic among the server, the audiometer,

and the audiologist terminal was examined with a network

monitoring software (wireshark). Results. Paired t-test results

have demonstrated that the remote hearing assessment is

equivalent in effectiveness to its conventional counterparts at

all tested frequencies (P values are in the range of [0.12, 0.94]),

and the bandwidth required by the system is less than 1 Mbps,

falling within the capacity of average commercial Internet

service subscription. Conclusions. The project developed a

remote hearing assessment system based on services on a web

server. The system minimizes hardware and software

requirements on the audiologist’s computer and can be

realized with regular Internet service subscription. Patient

operations involved in hearing assessment are simple; making

hearing test services more accessible to those otherwise may

not be able to obtain the desired hearing care.

KEY WORDS. remote hearing assessment, browser-server network

architecture, distributed systems, web services, three-tier software

architecture.

INTRODUCTION

After the Internet became available to the general public,distributed systems, usually consisting of a server, database,and a number of terminals, were employed in manyapplications and business sectors such as online shopping

From the East Carolina University, Greenville, NC 27858, USA.

Received 3 August 2009. Accepted for publication 20 October2009.

Address correspondence to J. Yao, East Carolina University,Greenville, NC 27858, USA.E-mail: yaoj@ecu.edu

Journal of Clinical Monitoring and Computing (2010) 24:41–50

DOI: 10.1007/s10877-009-9208-6 � Springer 2009

[1, 2], ticket booking [3], and Internet banking [4]. Today,with the growing prevalence of high-speed Internet ser-vices, online transactions have become an integral part ofmany’s daily life. Over the years, the architecture of dis-tributed systems has experienced several reformations [5].The first generation of such systems started with themainframe paradigm, in which their servers ran all theapplications but allowed few, if any, user interactionsthrough terminals. Significant delay existed between themainframe server and the terminal. Following the main-frame approach, most of the distributed systems used theclient–server architecture and became more interactivewith rich graphical user interfaces. As a result, these systemswere more user-friendly and their usability was greatlyimproved. However, this architecture came with animportant drawback: the user interactions and other busi-ness rules were implemented on the client computers andtherefore escalated resource needs (hardware and software)on the client machine, resulting in the phenomena knownas ‘‘fat client’’. Browser-server (BS) architecture was thenintroduced which allowed regular web browsers to accesscentral services hosted on a server that can be located any-where over the Internet. This new technology simplifiedthe client terminal requirements and consequently foundextensive applications in many segments of the e-world.

Web services have been adopted in the medical appli-cations more slowly and less pervasively compared to thebusinesses sector. Telemedicine applications have beenreported using distributed systems to enable remote vitalsigns monitoring [6], medical consultation [7, 8] ormedical image transmission [9, 10]. These systems usuallyemploy text messages and medical images, allowingsharing information among physicians and other healthcare professionals to make accurate remote diagnosis andappropriate treatment possible.

In spite of the progress in the telemedicine specialtiesnoted above [6–10], only few tele-audiology applicationshave been found. This is surprising considering the po-tential to expand traditional hearing care services tounderserved groups and regions [11–16], and the dispro-portionate lack of hearing care services. Hearing loss posesthe third most common disease among American seniors;it is strongly associated with elder functional decline anddepression because individuals experiencing hearingproblems are likely to withdraw from social occasions toavoid embarrassment [11, 17–19]. In the military, almostone-third of the soldiers who have served in the recentIraq and Afghanistan wars, where blast injuries are com-mon from roadside bombs and other explosives, have aconcomitant hearing and otological impairment. Unfor-tunately, hearing loss is often under detected and under-treated [17] for a variety of reasons, including the lack ofaccess to hearing care professionals.

Applications of Internet technology to hearing assess-ment is primarily focused on remote assessment usingpoint-to-point Internet connection [11, 12, 14, 15],mobile phone [20], or standard personal computercomponents [16]. For example, Givens et al. [11, 12]devised a real-time diagnostic audiometric applicationthat allowed audiologists to conduct remote hearing testsvia the Internet. Results from this project demonstratedthat remote hearing tests can obtain comparable resultswith their conventional face-to-face counterparts. Severalfeatures of the employed system, however, are less thandesired because it (1) required installation of proprietarysoftware on dedicated computers on the audiologist end,burdening medical professionals with technical details(e.g., software/network); and (2) supported only point-to-point connection between an audiologist and a pa-tient, not allowing concurrent conduct of multiple testsessions.

To address the issues from this previous system, thispaper presents the design and development of a distributedsystem with browser-server architecture that simulta-neously supports multiple remote hearing assessment ses-sions over the Internet. The following sections examinethe design process beginning with the analysis of designrequirements from a development and application per-spective (‘‘Design Considerations’’), followed by thedescription of how the design requirements were met(‘‘Method’’); explain protocols of the pilot test, and reportresults from these tests (‘‘System Test and Results’’).

DESIGN CONSIDERATIONS

In a real scenario where a patient’s hearing is assessedremotely through a system with distributed architecture,the patient, either on his/her own or assisted by clinicalstaff, must connect an audiometer to the Internet. Theaudiologist, who is geographically separated from thepatient, logs onto the system using a computer terminal.After verifying the patient’s information from the data-base, the audiologist remotely operates the audiometerthrough the user interface to generate pure-tone soundsand observes the patient responses displayed on thecomputer screen. From the clinical service perspective, asystem like this, in addition to satisfying general require-ments such as ease of use, reliability, and cost-effective-ness, must be designed with several critical features:

• Improve hearing services accessibility to the public andpromote the concept of hearing health care anywhere/anytime.

• Separate technological details from clinical services.Ideally, the audiologist and patient can successfully

42 Journal of Clinical Monitoring and Computing

complete the hearing test process with minimal or nomore extra effort than when the test is done in aconventional face-to-face mode.

• Securely share information among different depart-ments within a clinical institution or among differentstakeholders in the healthcare industry (hospitals,speech-hearing specialist, insurance company, andpatients, etc).

• Interface with existing electronic medical records sothat hearing test results can be readily integrated intothe patient’s medical file.

• Be compatible with (or adaptable to) various hardware/software platforms (operating systems: Linux/Win-dows; web browsers: Internet Explorer/Firefox/Moz-illa, etc.).

In addition to these general usability requirements,system designers should meet these technical consider-ations for modern information systems.

• Low maintenance and easy upgrade is critical forinformation systems in an era where technologieschange rapidly and systems, components, and toolsare expected to improve continuously. Functionalblocks of the system should be modular to allowflexible configuration and, when improvements areneeded to be made, minimize possible changes.

• The system should be designed with the capacity ofbeing integrated into the existing telemedicine infra-structure, serving as an add-on service to institutionsthat have the capability to provide other telemedicinespecialties [21]. Building upon basic infrastructuresystems (e.g., scheduling, billing, and reimbursement,etc.) will promote wider acceptance of the system byclinical practitioners.

• The design should permit and encourage adoption ofstandard technologies and utilization of open resourcesto streamline the development process and improve itscost-effectiveness.

METHODS

Figure 1 illustrates the layout of the conceptual system forremote hearing assessment. Distributed on the Internet,the system consists of three primary parts: a clinical pro-fessional’s computer terminal, a web server and its data-base, and an audiometer and its access point device on thepatient side. The part that requires the most design effortin this distributed system is the web server and its database(which can possibly be implemented on the same or adifferent server). The web server hosts all the applicationsand provides the Internet Information Services (IIS) [22].Services offered by the web server accomplish primarilythe hearing test procedure, which can be incorporatedinto existing telemedicine platforms that usually includeother necessary services such as appointment scheduling,billing, and reimbursement.

The audiometer on the patient side connects to theInternet with either built-in Internet connectivity or anexternal bridging device. This connection can be wired orwireless. The status of the audiometer’s Internet con-nection is monitored by the web server: once the audi-ometer presence is detected, it is reported to the systemdevice list, allowing the medical professionals to select fortheir hearing diagnosis sessions.

This web service-based hearing assessment system wasdesigned employing browser-server network architecture.The application software was implemented under a three-tier model. This section provides more information on theimplementation of the network and software architecture,as well as the operational sequence of hearing test.

Browser-server network architecture

The distributed system is implemented under browser-server (BS) architecture. As introduced earlier, systemswith the BS architecture realize all the applications on theserver. Specifically, all application services, including

Fig. 1. The distributed layout of the tele-hearing test system.

Yao et al.: Using Web Services to Realize Remote Hearing Assessment 43

necessary computation and user interface updating, areimplemented on the web server. The client terminalsimply displays the user interface through a web browser.This design supports ‘‘thin’’ clients by simplifying re-source requirements on the user’s computer. Any Internetaccess device with typical web browser installed would betechnically sufficient for an audiologist to perform ahearing test. Since only plugging-in the audiometerpower is required on the patient end, the system willpromote access to hearing care services anywhere anytime, potentially making health services more accessible tothose traditionally underserved.

The web server was designed under the ASP (ActiveServer Pages, [23]) .NET framework to realize this func-tion. Since all applications run on the server, informationcontained in the user interface has to be transmitted fromthe server to the client terminal (which only passivelydisplays the web pages). Typically, the web server updatesthe interface based upon requests received from the user: ifthere is no user request, the interface will not be refreshed.To simplify operations, the user terminal in this imple-mentation was programmed to refresh periodically with aninterval of 0.2 s. To reduce the amount of Dataflow andachieve ‘‘real-time’’ dynamic information updates, a pro-gramming technique called AJAX (Asynchronous Java-Script And XML, [24]) was utilized to develop the systemsoftware. With AJAX components provided with Micro-soft .NET technology, desired data can be obtained fromthe web server without reloading the entire page.

The three-tier software architecture

The software on the web server was designed with three-tier architecture in order to improve the system’s modu-larity and flexibility. The three tiers include: a PresentationLayer, a Business Logic Layer, and a Data Access Layer[25]. The presentation layer, or the user interface, is thetopmost level of the system that allows users to interactwith the system. The business logic layer contains businesslogics and rules for tele-hearing operations. The data accesslayer accomplishes data exchange to and from the database.These layers are discussed in the following paragraphs.

Presentation layer

The system user interfaces include several web pagesthrough which users can operate audiometers, save andextract testing results, etc. Information presented by thesepages can be categorized into five groups: PatientDemographics, User Role Management, Hearing Test,Test Results, and Test Scheduling. All users are requiredto login to the system before they can access any systeminformation. As illustrated in Figure 2, users with differentroles (administrator, audiologist, and patient) are assigned

with different privileges (defined in the Business LogicLayer as described next) to prevent unauthorized infor-mation access. An audiologist, for example, can use the‘‘Hearing Testing’’ page to perform remote hearing testsand access both ‘‘Patient Demographics’’ and patient‘‘Hearing Test Results’’ pages. Through the ‘‘HearingTest’’ page (see Figure 3), the audiologist has full controlof the remote audiometer: change pure-tone frequencyand level, and select from either air or bone conduction,and stimulus modes (steady or pulsed sounds).

Data access layer

System data are stored in a database server (which is lo-cated on the same machine as the web server in thisimplementation). These data include all the user man-agement information, patient demographics, patienthearing test results, etc. The data access layer provides thesystem applications with methods to access data in thedatabase (e.g., create, delete, update, read, sort, andsearch), separating data from their applications and logics.Only through the data access layer can the system data beaccessed, which improves system scalability and security.

Business logic layer

The business logic layer works between the presentationlayer and the data access layer and realizes primarily threegroups of operational rules: user role management, hear-ing test sequences, and data exchanges between the pre-sentation layer and the data access layer. All informationexchange between the presentation layer (user interfaceweb pages) and the data access layer is governed by thedefined logic. For example, the methods provided by thislayer allow a specific user to access only information re-lated to him/her (e.g. when an audiologist logs into thesystem, the logic defined in this layer returns informationonly for this individual’s patients). Visual Studio 2008 swebsite administration tool (WAT) was used in the

Fig. 2. User roles and their access to information in the presentation layer.

44 Journal of Clinical Monitoring and Computing

project to manage website accesses. WAT has a number ofbuilt-in static methods that support user role managementwith regard to performance, security, and flexibility. As anexample, it can block a user with a patient role fromattempting to access information that is not associatedwith him/her. For user role management in our hearingtest system, the website configuration file (web.configure)

was modified by overwriting the default setting in theserver to enable all the embedded functions.

The business logic also defines the operation sequenceduring hearing tests. The logic specifies that an audiologistmust first select the patient and his/her audiometer fromthe device list before further steps; after the server receivesa response from the patient, the results will be saved

Fig. 3. The hearing test user interface that allows an audiologist to remotely operate the patient audiometer.

Fig. 4. Sequence diagram of a typical hearing test.

Yao et al.: Using Web Services to Realize Remote Hearing Assessment 45

immediately; when a test session finishes, the audiologistmust end a test session to disconnect the audiometer fromthe system. The operation sequence is detailed in the nextsection Sequence of hearing test operations. Additionally, thebusiness logic layer accomplishes the validation of oper-ations and parameters received from the presentationlayer: prior to the execution of a received command, thislayer checks whether the input parameters are sufficientand valid. It alerts any detected input errors to preventpossible false operations.

Sequence of hearing test operations

Clinical hearing tests are based on a stimulus–responsebehavioral model: an audiologist tests the patient withpure-tone sounds with various frequencies and volumelevels and observes the patient’s responses. The lowestvolume level (in decibels, DB) at a certain frequency (Hz)is recorded as the threshold. During a hearing test session,an audiologist may check a subject’s hearing with pure-tones or voice presented via a headphone or a bonetransducer of an audiometer. Six frequencies (250, 500,1,000, 2,000, 4,000, and 8,000 Hz) are usually examinedto obtain a complete understanding of the patient’shearing over a defined audible spectrum [26].

The tele-hearing system enables operating the audiom-eter and observing the responses remotely. In practice, thehearing test starts with scheduling through or outside theweb services. Prior to the scheduled time, the patient (or thecare assistant) connects the audiometer to the Internet, asindicated in the sequence diagram (Figure 4) by ‘‘Com-munication through Other Means’’. During a remotehearing test, interactions between the audiologist and thepatient through different parts of the system generally in-clude the following steps, as referenced in the sequencediagram (Figure 4). In the list, step numbers are provided inparenthesis, and detailed technical steps, such as those re-quired to establish Bluetooth connections are ignored.(1) The audiologist logs in the system using his/her

user ID and password;

(2–4) The audiologist finds the scheduled test from the

system and starts a test session;

(5–10) The patient (or the care assistant) turns on the

audiometer and the access point device to connect

the audiometer to the Internet. In our imple-

mentation, an off-the-shelf Bluetooth [27] OT-

OPod audiometer [28] from Otovation, LLC was

used for the prototype. There are two specific

access methods to connect the OTOPod audi-

ometer to the Internet: to use a dedicated Blue-

tooth-to-Internet gateway device [29] or a regular

computer with Bluetooth-USB adapter [30]. For

the first option, the patient only needs to turn on

the power and plug in gateway device to a live

Internet socket. For the latter, a Bluetooth driver

needs to be installed prior to successful connection

of the audiometer to the Internet. Once con-

nected to the Internet, the audiometer will be

detected by the server. At this point, all the de-

vices are ready for a hearing test session;

(11) The audiologist, following standard testing pro-

tocols, sends out the test commands through the

server;

(12) These commands are transmitted from the server

to the audiometer through the Internet, the

gateway device, and Bluetooth telemetry;

(13) The audiometer accepts the commands and

generates corresponding sounds (this sounds may

or may not be heard by the patient);

(14) The patient, when hears a sound, responds by

pressing the button on the audiometer (it is as-

sumed that the patient cannot hear the generated

sound if no response is received from the patient

in a time limit);

(15–16) The patient’s responses travel exactly in the

direction opposite to the commands until they are

displayed on the audiologist’s terminal;

(17) The lowest sound intensity receiving a positive

patient response for each frequency point is auto-

matically recorded in the test results and stored in

the database through the data access layer.

Steps from 11 to 17 are repeated until all thefrequencies are tested.

(18–20) The audiologist ends the test session and discon-

nects the connections between the devices.

After the test session is done, other communicationmeans, again, can be used to complete additional logisticitems required to complete the consultation procedure.

SYSTEM TEST AND RESULTS

In working to complete design of this system, two types oftests have been carried out: (1) tests to understand band-width requirement of the web server, gateway device, andclient terminal; and (2) tests to examine the functionalityof various parts of the system and to verify that resultsfrom the remote mode are equivalent to those from theconventional face-to-face mode.

Bandwidth requirement tests

To realize automatic interface refreshing (especially afterthe server receives a positive patient response, the response

46 Journal of Clinical Monitoring and Computing

needs to be forwarded to the physician’s monitor), theinterface was set up to refresh periodically every 0.2 s, arefresh rate which significantly increases Dataflow be-tween the server and the browser. As noted earlier, webprogramming techniques (ASP, AJAX, etc.) were em-ployed to minimize this problem. Understanding thenetworking bandwidth requirement on the web server iscritical to plan for cases when the number of concurrenttest session is large. Therefore, the transmission of TCPpackets during test sessions was examined using a freenetwork monitoring software product (wireshark [31]).

Figure 5 shows the traffic (in kb) captured from theweb server network interface card (NIC) during theentire process of a hearing test session: from the audi-ologist logging into the system, associating with thedevice and conducting a hearing test, to terminating thetest session and logging out. In the figure, ‘‘Total’’indicates traffic passing through the server NIC; ‘‘S&A’’(Server and Audiometer) represents data exchange be-tween the web server and the audiometer through theBluetooth/Ethernet gateway device. This data exchangeincludes audiologist commands (to generate sounds withdifferent frequencies and intensities), confirmation, andpatient responses. ‘‘S2B’’ (Server to Browser) refers todata sent from the server to the audiologist browser, and‘‘B2S’’ (Browser to Server) indicates flowing in theopposite direction. The average total transmission rate ofthe web server for the test session is 425.1 kbps (thou-sand bits per second), with a ‘‘server to browser’’ rate of346.0 kbps, a ‘‘browser to server’’ rate of 77.3 kbps, anda transmission rate between the server and the audiom-eter of only 1.8 kbps. The peak total bandwidth isapproximately 1 Mbps, which falls in the bandwidth of

subscribed services from commercial Internet serviceproviders.

System functionality tests

The system’s functionality was tested in a clinic setting.With appropriate Internal Research Board (IRB) ap-proval, 30 volunteers (age range 25–60; 13 males, 17 fe-males) were recruited to participate in this test. Most ofthe volunteers have normal hearing; while some experi-ence hearing loss at various levels. Hearing capability ofthese individuals was assessed over a period of 2 months.The tests were carried out with three different conditionsto verify the functionality and effectiveness of the pro-posed remote system: (1) conventional face to face test; (2)remote test with a laptop computer working as the accesspoint that connects the audiometer to the Internet; and(3) remote test with a Bluetooth-Internet access point (inplace of the laptop). All the tests were double blind: thevolunteers, during the tests under the three conditions, satin a sound booth with the same audiometer without beinginformed the order of the three testing modes (whichwere randomized). Three different audiologists indepen-dently collected hearing data—thresholds of the six re-quired frequencies—from the same subject, each using adifferent testing mode. An audiologist, before his/herown test, had no knowledge of the patient results fromother testing conditions. To expedite the process, onlyone ear of each patient was tested with the three condi-tions. The selection of the ear was random. Figure 6shows the experiment setting of the tests: (a) an audiol-ogist was working on the terminal: the desktop was forthe two remote modes (gateway and laptop); the laptop

Fig. 5. Network traffic flow tracking.

Yao et al.: Using Web Services to Realize Remote Hearing Assessment 47

behind was for the conventional mode, and (b) a volun-teer was sitting in a sound booth during the test, with hishand holding the audiometer.

The 30 thresholds for each of the six frequenciescollected with the three testing conditions were ana-lyzed with paired t-test (degree of freedom: 29) todetermine the equivalence of results from the threetesting modes. Normality of the thresholds was firstchecked. In the analysis, thresholds from the two re-mote modes are paired with those from the conven-tional mode, respectively. Six of these pair tests wereapplied to find out the level of agreement at all sixtones. Analysis results are summarized in Table 1. It canbe observed from the table that all the p-values are inthe range of 0.115–0.935 and greater than 0.05,revealing that there is no statistically significant evidenceto reject the null hypothesis: the two remote test modescan obtain equivalent testing results as the conventionalface-to-face condition for all the test frequencies.

DISCUSSION

The test results demonstrated that the proposed remotehearing system, either with a dedicated wireless device orwith a personal computer as the access point, is functional.Thanks to its browser-server architecture, the system al-lows use of any Internet access device to login and per-form the hearing test. The webpage on the server wereconfigured so that data exchange between the web serverand the browser is secure. The findings demonstrated thatthe remote tests can achieve comparable results as theconventional face-to-face modes for all required fre-quencies. In addition, several technical issues are worthyof more discussion:

• Internet bandwidth requirement: The peak data transmis-sion rate for a single test was 1 Mbps, which does notappear to be excessive compared to bandwidth pro-vided by regular Internet subscription services. How-ever, the web server bandwidth may become an issue asthe number of concurrent test sessions increases. On theclient side, when an audiologist uses the system toperform hearing tests with a low speed Internetconnection, the client computer may experiencenoticeable delay between two consecutive screenupdates, although web programming techniques suchas AJAX were employed as described in the Methodssection. A further quantitative analysis of the capturedpackets reveals that, out of all the data transmittedbetween the server and the client browser, the majority(99%) of which were data sent to the client forperiodical refreshing of the audiometer status. Theessential data (commands, confirmations, responses)transferred for a hearing test hold only a very small

Fig. 6. Medical professional site and patient site when performing a hearing test.

Table 1 . Paired t-tests: conventional versus gateway and conven-tional versus computer

Test model

pair

Conventional versus

remote with gateway

access point

Conventional versus

remote with computer

access point

P value

250 Hz 0.163 0.115

500 Hz 0.524 0.297

1000 Hz 0.493 0.861

2000 Hz 0.712 0.526

4000 Hz 0.625 0.536

8000 Hz 0.561 0.935

48 Journal of Clinical Monitoring and Computing

portion (�1%) of the server’s dataflow. Future programimprovements are expected to substantially decreasethis data transmission by only updating those data thatchange. With these improvements, data services sub-scription from regular commercial internet serviceproviders should suffice the application, allowingaudiologists to perform remote hearing test literallyanywhere anytime.

• The three-tier software architecture: The current systemallows pure-tone tests with both air and bone conduc-tion and support masking for patient whose have oneear severely worse than the other. Other importanttele-audiology testing services, such as speech tests, canbe easily included by expanding the business logic layerdue to the system’s three-tier architecture, whichseparates business logic from user interface and dataaccess.

• Interfacing the system with electronic medical records: Sincedata are collected in the system, rather than being savedto a proprietary database located on the audiologist’slocal computer, a standard database on a public servercan be used. Interfacing the system with standardizedmedical records should be convenient. This shouldencourage future integration of tele-audiology withother tele-medicine specialties when the appropriateplatforms are ready [21].

• Bluetooth device competition: During recent experimentsat a local ENT clinical building, it was observed that,since many working individuals are equipped withBluetooth devices, the Bluetooth/Ethernet access pointdevice may discover more Bluetooth devices that it canhandle (one Bluetooth master device can only talk toup to seven slave devices). This may generate acompeting situation for the Bluetooth connectionbetween the audiometer and its access point. In spiteof this, once the two devices are connected, as welearned earlier, data transmission between them isminimal and should not be an issue.

CONCLUSIONS

A distributed, web based system that supports remotediagnosis of patient hearing is presented in this paper. Thesystem architecture, specific implementation techniques,and initial testing (both technical and medical) results aredescribed. The system is designed with the browser-servernetwork architecture which allows an audiologist orphysician to perform hearing assessment with any Internetaccess device through regular browsers. The system canwork in different flexible configurations and support

hearing test anytime, anywhere as long as Internet access isavailable. The project demonstrated the technical feasi-bility of using remote test as an extension of the traditionalface-to-face hearing services. The system is promising tobetter serve traditionally underserved population, reduceservice cost and improve quality of life.

REFERENCES

1. Joo KH, Kinoshita T, Shiratori N. Design and implementation

of an agent-based grocery shopping system. IEICE Trans Inf

Syst 2000; 383: 1940–1951.

2. Shen X, Radakrishnan T, Georganas ND. vCOM: electronic

commerce in a collaborative virtual world. E Commerce Res

Appl 2002; 1: 281–300.

3. Smith AD. Information exchanges associated with Internet

travel marketplaces. Online Information Review 2004; 28:

292–300.

4. Dignum F. Information management at a bank using agents:

theory and practice. Appl Artif Intell 2000; 14: 677–696.

5. Browser/Server for the Corporate Intranet…the next computing

paradigm, http://www.browsersoft.com/browserserver/.

6. Magrabi F, Lovell NH, Celler BG. A web-based approach for

electrocardiogram monitoring in the home. Int J Med Inform

1999; 54: 145–153.

7. Perminov VV, Perepelitsina EY, Antsiperov VE, Nikitov DS.

Remote medical consultations over the internet: an imple-

mentation based on web-service technologies. J Commun

Tech Electron 2008; 53: 104–112.

8. Yamaguchi T, Sakano T, Fujii T, Ando Y, Kitamura M.

Design of medical teleconsultation support system using super-

high-definition imaging system. Syst Comput Japan 2002; 33:

1203–1212.

9. Wei JC, Valentino DJ, Bell DS, Baker RS. A web-based tele-

medicine system for diabetic retinopathy screening using digital

fundus photography. Telemed J E Health 2006; 12: 50–57.

10. Hsiao C-H, Hsu T-C, Chang JN, Yang SJH, Young S-T, Chu

WC. Developing a medical image content repository for

e-learning. J Digit Imaging 2006; 19: 207–215.

11. Givens GD, Blanarovich A, Murphy T, Simmons S, Blach D,

Elangovan S. Internet-based tele-audiometry system for the

assessment of hearing: a pilot study. Telemed J E Health 2003;

9: 375–378.

12. Givens GD, Elangovan S. Internet application to tele-audiol-

ogy-nothin’ but net. Am J Audiol 2003; 12: 59–65.

13. Krumm M, Ribera J, Schmiedge J. Using a telehealth medium

for objective hearing testing: implications for supporting rural

universal newborn hearing screening programs. Semin Hear

2005; 26: 3–12.

14. Krumm M. Audiology telemedicine. J Telemed Telecare 2007;

13: 224–229.

15. Krumm M, Riberaw J, Klich R. Providing basic hearing tests

using remote computing technology. J Telemed Telecare 2007;

13: 406–410.

16. Choi JM, Lee HB, Park C, Oh SH, Park KS. PC-based tele-

audiometry. Telemed J E Health 2007; 13: 501–508.

Yao et al.: Using Web Services to Realize Remote Hearing Assessment 49

17. Bogardus ST, Yueh B, Shekelle PG. Screening and manage-

ment of adult hearing loss in primary care’’, scientific review

and clinical applications. JAMA 2003; 289: 1986–1990.

18. Kronenfeld JJ. Changing conceptions of health and life course

concepts, health: an interdisciplinary. J Soc Stud Health, Illn

Med 2006; 10: 501–517.

19. Lam BL, Lee DJ, Marin OG, Zheng DD, Caban AJ. Con-

current visual and hearing impairment and risk of mortality.

The National Health Interview Survey 2006; vol 124.

20. Nakamura N. Development of mobileaudiometer for screening

using mobile phones, in 26th Annual International Conference of

the IEEE EMBS, San Francisco, CA, USA, 2004; pp. 3369–

3372.

21. Distributed RIS/PACS & telemedicine, http://www.medweb.

com/.

22. The official microsoft IIS site, http://www.iis.net/.

23. The official ASP.NET site, http://www.asp.net/.

24. Server-side ASP.NET AJAX programming, http://www.asp.net/

ajax/.

25. Three tier architecture in ASP.NET, http://www.beansoftware.

com/ASP.NET-Tutorials/Three-Tier-Architecture.aspx.

26. Martin FN, Clark JG. Introduction to audiology, 9th ed.: Pearson,

2006.

27. The Official bluetooth techology info site, http://www.blue

tooth.com/bluetooth/.

28. http://www.otovation.com/.

29. Parani100, http://www.sena.com/download/datasheet/ds_parani

100.pdf.

30. EZURIO, http://www.ezurio.com/products/highspeedusbad

aptor/.

31. WireShark, http://www.wireshark.org.

50 Journal of Clinical Monitoring and Computing

Reproduced with permission of the copyright owner. Further reproduction prohibited without permission.

View publication statsView publication stats