Wireless Information System for Patient Health Care Management
Arooshi Kumar1, Rajita Kumar1 and Sanjuli Agarwal2
1
duPont Manual High School
2
Computer Science Department
Indiana University Southeast, Indiana
Email: sanagarw@ius.edu
Abstract
This paper builds an effective wireless patient
management system (WPMS) using open software that
can be accessed via a personal digital assistance (PDA)
or a cell phone. This allows health care profesioanls to
gain access to patient information from anywhere at
anytime. In this project, the wireless patient management
system was built using Java technology. The client side
was implemented using MIDlet and the server side was
developed using Java servlets. A study was conducted to
observe the effects of distance between client and server
on the response time of a wireless versus wired
connectivity. It was observed that the distance between
the client and server does not have a significant impact
on the response time of wired and wireless connectivity.
1. Introduction
The use of technology in all fields is constantly
increasing, especially in the medical field. Health care
informatics is becoming a more popular area of research
and development because doctors are constantly in need
of new technology so they can attend their patients in a
more efficient manner. One issue that should be
addressed is the amount of time spent managing
extensive patient information. It was researched that a
nurse will attend 20 patients on average in a hospital [8].
For each of these patients the nurse has to go to the main
desk to acquire the patient information before he/she can
see the patient. If there are 20 patients and 3-5 minutes
are spent to retrieving each patient’s information that is
60-100 minutes or one hour to one hour 40 minutes are
spent in patient information retrieval and management. If
the nurse simply held a cell phone in her hand and
accessed the information from a built in system it would
be much quicker and less time would be wasted. To
address this problem a wireless patient management
system (WPMS) is built. The system provides ubiquitous
access, allows making editing patient information easier,
and provides easier patient archiving. After the system is
built a performance study was conducted to see if the
wireless implementation of this system will respond as
quickly as a wired implementation of this system. The
effect of distance on the response time of the wired and
wireless system was also tested. In order to predict the
performance of this system it is hypothesized that as the
1-4244-1029-0/07/$25.00 ©2007 IEEE.
distance between the server and the client increases the
response time will increase as well.
Cell phones and Personal Digital Assistances
(PDA’s) are light weight devices that can access a server
anywhere, anytime. Wireless technology integrated with
the medical field can form an extensive framework that
can significantly aid health care providers. Nearly half of
the United States population owns cell phones and many
healthcare providers like doctors and nurses own these
devices. A wireless system can provide access to patient
information anywhere, anytime. Hand held devices such
as PDAs and cell phones, can access a wireless system
via a web server, with the aid of the internet. From the
handheld device a user can get online access to a desired
information server. With a wired system one has to
access it through a desktop computer or laptop from a
fixed location. Wireless connectivity provides mobile
access to information on light weight devices that are
easy to carry. There are several other implementations
available for patient management but WPMS provides
many features that are not available in existing systems
as shown in Table 1.
A three tier structure is one that distributes the
work of a system at three different levels. The first tier is
referred to as the “Client Tier”, the second tier as the
“Middle Tier”, and the third tier as the “Data Tier”. The
first tier is usually an interface which connects a client to
the actual system. The “Middle Tier” performs the core
logic of the application and also accesses the Data Tier.
The “Data Tier” contains a database. Here information
can be retrieved and updated in order for the system to
work. The Middle Tier accepts the client’s request via
the server and returns its output for the user to view. The
“Middle tier” allows the database and the client interface
to communicate.
Sun’s Java 2 Platform Enterprise Edition (J2EE)
development environment is used to build this system.
Since the goal was to create a “wireless system” J2EE
provided the servlet frame work to write business logic.
This development environment helps establish an
external communication with the middle tier, the web
server, and thus allowing clients to interact with the Java
servlets [1, 2, 7]. In order to build client access on PDA
or on cell phone J2ME (Java 2 Micro Edition) was used.
It provides a base for wireless toolkit to run which is a
364
combination of resources of KVM (Kilo Virtual
Machine) and API’s that allow applications to run on
mobile devices. It provides a cell phone emulator that
can be manipulated by the mouse or a stylus on a
computer. J2ME also provides a compiler and other tools
which allow easy development of client side interface
Table 1: Features of the proposed WPMS vs Existing systems
A servlet is a Java class that allows web servers
to host various applications. The extension to the basic
servlet is Httpservlet which supports the HTTP protocol.
Servlets provide server side java code for Web clients.
When a client calls the servlet, it runs on the “Middle
Tier” and executes the Java code for client on Web
Servert. The client can execute a HTTP GET or POST
request. The servlet will interpret the request and execute
either a doGet() or doPost () method. These methods
implement the core logic on the servlets [6, 10]. MIDlet
is a Java class that helps create the user/client side of a
system’s interface. It runs on the Client Tier in PDA or
cell phone and executes requests on the Web server.
MIDlet is the core building block of J2ME. The MIDlet
class can be in various stages in its life time. The first
stage is active and it enters this stage upon its startup to
obtain some resources. The second stage is the paused
stage where MIDLet released its resources and becomes
dormant. The third stage is destroying where MIDlet
releases all the resources and saves anything needed [5].
2. Methodology
Before the actual programming for this project
began, several Java software applications were installed
on to the computer. J2ME wireless toolkit was installed
next. The next step was to install Tomcat on the
computer. Tomcat was downloaded from the Apache
365
[3]. The Tomcat Web Server is the basis for the “Middle
Tier”. It is a standalone web server, which provides
HTTP (hypertext transfer protocol) for communication
with the client interface. The Tomcat Web server can
host servlets written in Java. It is compatible with any
platform particularly Unix and Windows [4].
Jakarta Project. Then the files were unzipped. Tomcat
was started using startup command in the bin directory.
By default, Tomcat runs on port 8080 of the computer. In
order to verify proper installation of the Server, a
browser (IE) was opened and http://localhost:8080 was
typed. The main page of Tomcat was displayed
indicating proper Web Server installation. The database
for the system was setup next. In order to setup the
database, Microsoft Access was also installed on the
computer. Multiple tables were created in the database
namely, User table, Patient History, Patient Information,
Diagnosis, Prescription, Insurance Information, Billing
and Appointment. Then specific field names were
entered for each table. In order to connect with java
servlets, a data source name was created via ODBC
(Open Database Connectivity) configuration. To set
ODBC up, several steps were taken. From the Start
menu, settings were chosen. In the Settings window the
control panel was chosen. In the list of settings the
Administrative tool was selected. Then, from this
window Data Sources (ODBC) was selected. A dialog
box appeared; in the dialog box the System DSN tab was
chosen. This created a data source for all the users. In the
System DSN tab, the add button was pressed. The next
dialog box asked what type of database the file is, and
Microsoft Access Driver (.mdb) was selected. Then data
source name and data base was selected to complete the
configuration.
Next, the wireless system had to be
programmed. The overview of all the steps to build a
MIDlet is shown in Figure 1. The first step in
programming the client side using J2ME was to design
the GUI (graphical user interface) on paper. This gave us
an overview of the how the screens should look. It was
also decided what parts of the screen required user
interactivity. It was laid out in a plan, so when the coding
process began, it was easy to know what to code. The
second step was to implement the actual Java code for
the project. The MIDlet was coded to accept user input
and invoke appropriate Java servlet for the response. The
third step was to compile the code. The compiler for the
MIDlet is provided by the J2ME toolkit. The toolkit was
opened from Windows start option. The project was
loaded in J2ME and then compiled. The fourth step was
to preverify the code for the MIDlet [8, 9]. After the code
was compiled it was ensured that no errors occurred on
the compiler screen. If an error occurred the compiler
would point out where the error would be and the error
was fixed and then recompiled, also it was tested on the
cell phone emulator to ensure the code was running
properly. The fifth step was to package the MIDlet and
prepare for the testing and deployment phases. The
packaging allows the storage of configuration data
including security, extension versioning and services.
The sixth step was to test the code. In the toolkit, run
option was chosen to execute the client. The cell phone
emulator is displayed on the screen if the code was error
free, otherwise an error will be reported. The seventh and
final step was to deploy the program onto an actual cell
phone.
compiler successfully compiled it meant the new servlet
was error free, otherwise the problems had to be
debugged. Lastly, the servlet was deployed and tested
along with the MIDlet.
After the patient management system was built,
tests were performed to compare response time of this
system for wired and wireless access. The distance
between the server and the client were changed and then
the response time of both the wireless and wired system
was recorded. The server was set up at Bowling Green
Kentucky. Then the client accessed the server from
Louisville, Cincinnati, and Bowling Green. These
distances were: 185km, 290 km, and 0 km respectively.
The response time was recorded for each client using the
Numion stopwatch. This stopwatch is available online.
The URL to the where the server was enter and then the
time taken for the server to respond to the client was
outputted by the Numion stop watch. Three times were
recorded for watch distance and then an average was
taken.
3. Design of System Architecture
The overall structure of WPMS is shown in
Figure 2. This system allows many features for patient
information management ranging from personal data
management to insurance and invoice processing. For
each module a health care provider can retrieve and
update the information. Detailed interaction possibilities
are shown in Figure 3. This diagram illustrates how
various features are implemented using different types of
servlets.
User Login

1. Design System Data Office Visit

2. Code Management Management
7. Deploy

3. Compile History and

6. Test Insurance Physician Physical Diagnosis
1. Chief
5. Package 4. Preverify Complaint
2. History of
Preventing
Illness
3. Past Medical
History
Figure 1: MIDlet Design Cycle 4. Review of Prescription
Patient Billing System
5. Family
In order to provide service over the internet, History
6. Past Surgical
servlet had to be programmed. The first step was to code History
the servlet by extending HttpServlet. The second step 7. Social
History
was to compile the servlet. In order to do this a command 8. Medication
Appointment
prompt window was opened and moved to the directory 9. Allergies
10.Physical
where servlets were stored. Subsequently to compile the Exam
servlet, following command was typed, javac (Class of
Servlet).java. The fourth step was to preverify that the
servlet had no errors on the cell phone emulator. If the
Figure 2: Structure of WPMS
366
 in the screens of Figure 4. The first screen shot in Figure
4 shows a user login frame for a doctor or nurse. Once a
Confirms
User ID user is authenticated, the systems gives two options one
Login
Post
and for system data management and the other for office visit
Password
Servlet management as shown in Figure 2. The second screen
DetailsServlet
shot in Figure 4 is displayed if the user selects system
1. Patient • View Past Patient
data management. It allows a user to retrieve insurance,
EnterDetailsServlet
2.Details
3.Diagnosis
Information patient, physician, billing and appointment information.
• Enter Current
4. Prescrip-
Patient Information
The third screen shot in Figure 4 is displayed if user
tion DiagnosisServlet
5.Insurance selects office visit management. This allows a doctor or a
6.Appoint- • View Past Diagnosis
ment Information nurse to enter the complete patient profile at the office
EnterDiagnosis
• Enter Current Servlet visit time.
Diagnosis Information
Prescription
Servlet
5. Performance Results
• View Past Prescription
Information
EnterPrescription
• Enter Current Servlet In order to study the performance of this
Prescription
Information system, access time was observed from various distances
InsuranceServlet
• View Past Insurance as shown in Table 2.
Information
• Enter Current EnterInsurance
Insurance Information Servlet Table 2: Distances for Measuring Response Time

• View Past Appointment

AppointmentServlet Distance from Bowling Green
Information Location (km)
• Enter Current EnterAppointment
Appointment Servlet
Bowling Green 0
Information Louisville 185
Cincinnati 290
Figure 3: Interaction Diagram of WPMS
For the wired system, the response times are
4. Implementation and Screen Shots shown in Table 3, at a distance of 0 km were .203, .187
and .125. The average of the response time was .172. For
The wireless patient management system was the distance of 185 km (client accessed the servlet form
built and tested using Java technology. The client was Louisville) the response times obtained during the trials
able to connect to the Web server and database. The were .282, .283, and .288. The average response time
database via the servlet, could receive the clients’ was .284 seconds. For a distance of 290 km the slowest
request. The database updates were verified by response time obtained was .313 seconds and the fastest
comparing the client input data with the contents time acquired was .325.

Table 3: Response Time with Wired Access

Response Time (seconds)

Trial Trial
Distance (km) 1 2 Trial 3 Average
0 0.203 0.125 0.187 0.172
185 0.282 0.283 0.288 0.284
290 0.325 0.328 0.313 0.322

Figure 4: Screen Shots of WPMS

367
 For the wireless system the response time are because the distance from the mean is less. This average
shown in Table 4 at a distance of 0 km the lowest time distance from the mean, the standard deviation of each
was .313 seconds. The results of wired and wireless trial value was compared against the mean for that
access time at various distances are shown in Figure 5. particular distance in both the wired and wireless
The difference between response time of wired system implementation. All the data was within 1, or 2 standard
and the wireless system was maximum, at a distance of deviations away from the mean. The data didn’t have any
0 km. The wired system’s average response time was outliers in this experiment because none of the values
only .172 seconds whereas the wireless systems average were more than 3 standard deviations from the mean.
response time was .214 seconds. These statistics support that the averages taken were
accurate representations of the data.
Table 4: Response Time with Wireless Access
Table 6: Wireless System Statistics
Response Time (seconds) Standard How many standard
Distance (km) Trial 1 Trial 2 Trial 3 Average Deviation Mean deviations from mean
Distance from Time Trial Trial
0 0.25 0.188 0.204 0.214 (km) Means (Seconds) 1 2 Trial 3
0 0.0263 0.214 2 1 1
185 0.293 0.292 0.293 0.293
185 0.0005 0.293 0 2 0
290 0.313 0.331 0.328 0.324 290 0.0079 0.324 0 1 1

6. Conclusion
Graph 1: Comparative analysis of the effect of distance on In conclusion the system worked effectively.
the response time of a wireless versus a wired access
From the response time performance study it was
Response
0.350 Time (Seconds) concluded that the wired access to the system is slightly
0.300 faster than the wireless access for all the distances. The
0.250 response times in the two cases (wired and wireless)
0.200 Wired
were fairly close in most tests. This provides another
0.150 Wireless observation that even if one was to access the server
0.100 wirelessly; they would still be retrieving the data near the
0.050
same rate as a wired system because in wireless
0.000
environment only first segment is without wire.
0 50 100 150 200 250 300 350
Distance (km)
An extension for this project would be adding
more functionality, such as family history and interfacing
Figure 5: Impact of distance on response time with hospital record system. Adding more functionality
increases the system versatility and improved usability.
Also, the major future enhancement for this project
Table 5: Wired System Statistics would be to make it voice activated. Typing on the cell
phone can be eliminated if the doctor or nurse can talk
How many standard into the phone to enter the data for their patient. This will
Standard deviations from help the user of the system greatly and increase the
Deviation Mean mean systems efficiency and user satisfaction. Another future
Distance from Time Trial Trial Trial study would be to expand this system and allow other
(km) means (Seconds) 1 2 3 users to access this system. For example by extending
0 0.0336 0.172 1 2 1 the access of WPMS system to pharmacists’ will allow
185 0.0026 0.284 1 1 2 pharmacists to fill doctor’s prescription automatically.
290 0.0065 0.322 2 0 1
References
It can be observed from Tables 5 and 6 that the
data collected was accurate. Suppose two numbers 1. Knudson, Jonathan, and Dana Nourie. “Wireless
acquired for the same measurement are 0 and 100 the Development Tutorial Part I.” September 2003. 20
average of those two numbers is 50. In another case if September 2005
one number was 40 and the other number was 60 the <http://developers.sun.com/techtopics/mobility/midp
average is still 50. The average of fifty in the second /articles/wtoolkit/>.
example gives a more accurate representation of the data
368
2. Knudsen, Jonathon. “Wireless Tutorial Part II.”
September 2003. 20 September 2005
<http://developers.sun.com/techtopics/mobility/midp
/articles/tutorial2/>.
3. Goyal, Vikram. “J2ME Tutorial: Creating the Game
API of MIDP 2.0.” September 2005
<http://today.java.net/pub/a/today/2005/02/09/j2me1
.html>.
4. Knudsen, Jonathan. Wireless Java: Developing with
J2ME. 2nd ed. : Apress, 2003
5. Wadya, A. Van Halteran, V. Jones, R. Bults, D.
Kostantas, P. Vierhout, J. Peuscher, “Telematic
requirements for a mobile and wireless healthcare
system derived from the enterprise models”. In
ConTEL 2003, pp.527-534
6. Deitel, H.M., and P.J. Deitel. JAVA How to
Program. 5th ed. Upper Saddle River: Pearson
Education, 2003.
7. Havenstein, Heather . “Wireless Leaders &
.Laggards: Health Care." 16 May. 2005.
Computerworld. 9-22-2005
8. "Midlet." 21 September 2005
<http://en.wikipedia.org/wiki/MIDlet>.
9. J2ME wireless Toolkit 1.0.4_02 for Windows.
Downloaded software.
10. Deitel, H.M, P.J. Deitel, T.R. Nieto, and K.
Steinbuhler. Wireless Internet and Mobile Business:
How to Program. Upper Saddle River: Prentice Hall,
2002.

369