university of central floridaitech.fgcu.edu/faculty/zalewski/cnt4104/projects/sundaram.doc · web...
Post on 15-Mar-2020
4 Views
Preview:
TRANSCRIPT
UNIVERSITY OF CENTRAL FLORIDATHESIS APPROVAL
The members of the Committee approve the thesis entitled Requirements Analysis of Application Software for Telemedicine and the Health Care Industry of Senthilnathan Sundaram, defended July 19, 2002
Janusz Zalewski, Chair
Christian S. BauerCommittee Member
Ronald EaglinCommittee Member
It is recommended that this thesis be used in partial fulfillment of the requirements for the degree of Master of Science from the School of Electrical Engineering and Computer Science in the College of Engineering and Computer Science.
Erol Gelenbe, Director, School of EECS
Issa Batarseh, Assistant Dean for Graduate Studies
Martin P. Wanielista, Dean of College
Patricia J. BishopVice Provost and Dean of Graduate Studies
The committee, the college, and the University of Central Florida are not liable for any use of the materials presented in this study.
i
REQUIREMENTS ANALYSIS OF APPLICATION SOFTWARE FOR TELEMEDICINE AND THE HEALTH CARE INDUSTRY
by
SENTHILNATHAN SUNDARAMB.E. University of Madras, 1997
A thesis submitted in partial fulfillment of the requirements for the degree of Master of Science
in the School of Electrical Engineering and Computer Science in the College of Engineering and Computer Science
at the University of Central FloridaOrlando, Florida
Summer Term2002
ii
© 2002 Senthilnathan Sundaram
ii
ABSTRACT
The problem faced by the telemedicine and the healthcare industry is the inability
to access high-density data at a particular location at a particular instant of time. This is
one of the main reasons for the doctors' offices being crowded with patient records,
preventing them from going 'paperless'. The information required by this industry is not
Just from a single source. Though software packages exist to help the doctor's offices
become paperless, they seldom offer capabilities like bidirectional data transfer between
various external sources, such as hospital servers, image servers, other doctor's offices
etc., in an inexpensive, secure and efficient way, maintaining reliable connectivity.
This thesis provides a generalized formulation of requirements on software that
shall help the telemedicine and the health care industry to get to the point where the
physician shall be able to send and receive any type of data over a secure and efficient
virtual private network. The software shall also help the doctors' offices in managing
patient records more effectively. The software requirements were put to an extensive
analysis and verification process against the following criteria: consistency,
completeness, correctness, clarity, traceability and testability. The results of these
processes led to the detection of bugs and several improvements in the original
requirements specification document. The requirements focus was on security issues that
address records privacy and protection of patient data.
iii
I dedicate this thesis of mine to my loving parents T. Sundaram and S. Meenakshi for the
pristine love, affection and laudable upbringing they had given me and also dedicate it to
my wife Usha and daughter Sneha who made my life more meaningful.
iv
ACKNOWLEDGMENTS
I would like to express my sincere gratitude to my advisor Dr. Janusz Zalewski, who has
been my beacon of hope right from the day I got my admission at the Univerisity of
Central Florida. His valuable advice and guidance has given me the courage to wade
through the odds and emerge as a successful professional whom the world is witnessing
today. I shall always remember his help without which I couldn’t have made this
achievement.
I would also like to thank Mrs. Janet Heiner who had offered the best help during my
admission phase at the University of Central Florida. I would also like to thank my
department for giving me this wonderful opportunity of doing my Master’s degree at
UCF.
I would also like to thank my friends in and out of UCF who have been of tremendous
help during this important phase of my life. Their constant encouragement and criticism
has helped me get here.
Last but not the least, I would like to thank my parents for the support and valuable
advises they had given me during this difficult phase where I had to be a student as well
as a responsible father.
v
TABLE OF CONTENTS
LIST OF FIGURES..........................................................................................................viii
CHAPTER ONE: INTRODUCTION..................................................................................1
1.1 Telemedicine..............................................................................................................3
1.2 Insurance Companies.................................................................................................5
1.3 Hospitality Industry...................................................................................................7
1.4 Law Enforcement.......................................................................................................8
1.5 Potential Problems.....................................................................................................9
CHAPTER TWO: PROBLEM DESCRIPTION...............................................................12
CHAPTER THREE: SOFTWARE REQUIREMENT SPECIFICATION.......................16
3.1 Description of Interfaces..........................................................................................17
3.2 Specific Requirements.............................................................................................22
3.3 Additional Requirements.........................................................................................49
3.4 System Architecture.................................................................................................52
3.5 Security Issues.........................................................................................................54
CHAPTER FOUR: SOFTWARE REQUIREMENTS REVIEW.....................................60
4.1 General Discussion..................................................................................................60
4.2 Software Requirements Verification.......................................................................63
CHAPTER FIVE: SOFTWARE DEVELOPMENT PLAN..............................................75
CHAPTER SIX: CONCLUSION......................................................................................81
LIST OF REFERENCES...................................................................................................83
vi
LIST OF FIGURES
Figure 1.1.1: General users of the Hospital Server..............................................................4
Figure 1.2.1: Common methods used by road warriors.......................................................5
Figure 1.2.2: A VPN using Secure SHell............................................................................6
Figure 1.2.3: VPN for road warriors using L2TP................................................................6
Figure 1.3.1: Generalized approach used by the hospitality industry..................................7
Figure 1.3.2: VPN usage by a food chain............................................................................8
Figure 1.4.1: Usage of VPN by law enforcement official...................................................9
Figure 2.1: Access from Doctor’s Office..........................................................................13
Figure 2.2: From the Emergency Room for Rapid Consultation.......................................14
Figure 2.3: From the ambulance to the doctors’ in the ER................................................14
Figure 2.4: Medical data transfer for educational purposes..............................................15
Figure 3.1: Context diagram of the proposed system........................................................16
Figure 3.2.2: Login Screen................................................................................................23
Figure 3.2.6: Error Message for unauthorized use............................................................24
Figure 3.2.11: Dialog box for unsuccessful login..............................................................25
Figure 3.2.14 Error Message for maximum no. of attempts..............................................25
Figure 3.2.16: Search Request...........................................................................................26
Figure 3.2.20: Screen Displayed to Doctor.......................................................................26
Figure 3.2.21: Dialog box for an unsuccessful search.......................................................27
Figure 3.2.25: Display after opening a data item...............................................................28
Figure 3.2.45: Display for saving changes........................................................................31
vii
Figure 3.2.48: Display after logging in as ‘Other’.............................................................32
Figure 3.2.58: Office Visit Form.......................................................................................34
Figure 3.2.60: Error Message for unauthorized use.........................................................35
Figure 3.2.63: Previous Prescription Display....................................................................36
Figure 3.2.65: Display while printing is in progress.........................................................36
Figure 3.2.69: Screen to view Previous Diagnosis Code...................................................37
Figure 3.2.71: Display to create a new prescription..........................................................37
Figure 3.2.78: Special Request Form................................................................................39
Figure 3.2.89: Error Message for Invalid Date..................................................................41
Figure: 3.2.98: Screen to Edit the Lists.............................................................................42
Figure 3.2.99: Error Message............................................................................................42
Figure 3.2.102: Screen to ADD a name to the list.............................................................43
Figure 3.2.106: Screen to ADD a facility to the list..........................................................44
Figure 3.2.110: Screen to ADD a special request code to the list.....................................45
Figure 3.2.115: Screen to REMOVE a name to the list.....................................................46
Figure 3.2.119: Screen to REMOVE a facility to the list..................................................47
Figure 3.2.123: Screen to REMOVE a special request code to the list.............................47
Figure 3.3.1: Reminder screen...........................................................................................49
Figure 3.3.3: Display for compressing data.......................................................................50
Table 1: Comparison of compression softwares................................................................50
Figure 3.3.4: Comparison of ratio of compression............................................................51
Figure 3.3.5: Comparison of compressed file sizes...........................................................51
Figure 3.4.1: Architecture of the proposed system............................................................52
viii
Figure 3.5.1: The transmission end of the proposed system..............................................54
Figure 3.5.2: The receiving end of the proposed system...................................................54
Figure 3.5.3: Client-Initiated Tunneling on a dial-in VPN................................................55
Figure 3.5.4: The router-terminated VPN..........................................................................56
Figure 3.5.5: A LAN-to-LAN VPN with the firewall handling the VPN process............56
Figure 3.5.6: The VPN server in the DMZ........................................................................57
Figure 3.5.7: The VPN server behind the firewall.............................................................57
Figure 3.5.8: The VPN server on one branch of the LAN.................................................58
Figure 3.5.9: Client-Initiated tunneling on a dial-in VPN.................................................58
Figure 3.5.10: VPN usage from ambulance – a modified approach..................................59
Table 4.2: Results of Verification......................................................................................67
Figure 5.1: Spiral Model....................................................................................................76
Figure 5.2: Gantt chart.......................................................................................................77
Figure 5.3: Estimated Man-Hours for development of product........................................77
Figure 5.4: Architectural Design.......................................................................................80
ix
CHAPTER ONE: INTRODUCTION
Operation of big software systems such as airline reservation systems, online
banking systems, insurance systems etc., now a days involve computer networks, in
particular Virtual Private Networks (VPNs). This is particularly true for the health care
industry where records are spread among many different offices, hospitals and insurance
companies. The problem faced by the telemedicine and the health care industry is the
inability to access high-density data at a particular location at a particular instant of time.
Lacks of proper software, networking techniques are a few causes for this.
Software’s for doctors’ office management are ubiquitous. But they seldom go
beyond the capabilities of appointment scheduling. Software that shall provide bi-
directional data access and transfer between the geographically distributed sources in a
secure and reliable way is what the telemedicine and the health care industry needs.
Requirements on application software for such networks are difficult to express and
analyze because of the completely new issues related to distribution, security and privacy
of information.
VPN is a concept that blurs the line between a public and private network. A
private network could be a common internal LAN of a company accessed only by its
workers. The Internet is a good example of a public network. VPNs can be created using
hardware and software or a combination of both that creates a secure link between peers
over a public network.
1
Now a question might be grappling our mind on how is this possible. The
answer is secure virtual connections are created between two systems or two networks
and the packets of information routed through various machines on the Internet on an
adhoc basis.
With several ISP’s having expanded internationally as well, the user could dial-in
to the nearest point-of-presence (POP) of the ISP or use one of the toll-free numbers
offered by them for roaming users. Having each office get a T1, frame relay or ISDN line
to the nearest POP would definitely be a more cost-effective solution than getting a line
between two offices at geographically distributed locations. Security of data being
transferred can be customized for any application under development. VPNs also allow
consolidating Internet connections into a single router and single line, saving money on
equipment and infrastructure. VPNs could be a plausible solution to the access problems
faced by the telemedicine and healthcare industry. A few other application areas where
the use of VPNs could contribute the most are also described below.
2
1.1 Telemedicine
The industry faces demands from government and the public to provide improved
service while reducing costs. That may well be one of the reasons for this industry to
think about adopting VPNs as a cost-effective way to meet these challenges. The possible
areas of VPN deployment and usage in this industry are:
Physician’s home office
The network of doctor’s (NPPN, CCN etc.,) can use VPNs to tie together
geographically dispersed offices.
Linking hospitals with physician’s offices.
Linking a hospital with a teaching facility.
In the Emergency Room, Ambulance
VPNs in telemedicine could help
The doctor look-up the patient’s records right from his desk at the office and offer
consultation.
Sharing of medical expertise with co-physicians
Analysis of patient’s condition prior to arrival at the ER
Rapid consulting & diagnosis
We have to bear in mind the following:
Medical field is a data-heavy field – for doctors to make diagnosis they need
information, often in high-density forms such as X-rays etc.,
3
Protection of patient privacy is also a major consideration
Unauthorized access of patient’s health records must be avoided – Hence security
is of paramount importance.
Assumptions made include, all data is available on a server located in the hospital of
choice and restricted access is provided to it and all records are updated periodically.
The possibilities of deploying a VPN in this industry are immense. The following
people have a great need to access the medical records of a patient from the hospital
server.
Figure 1.1.1: General users of the Hospital Server
4
1.2 Insurance Companies
Consumer insurance companies are an example of a business model that, of
necessity employs large number of widely distributed representatives. Every insurance
company, be it health, automobile, life or accident they have a big number of road
warriors who can benefit from close contact with the central office.
By linking their field agents directly to the company network,
The representatives get the latest data on rates and services
The customer can see the details himself and feel comfortable that he is not being
talked away with a bunch of paper work.
Contracts that need home office review can receive swift approval
High level of customer satisfaction could be achieved.
Automobile company agents could process claims much faster
One of the traditional methods adopted by the road warrior is shown in Figure 1.2.1
Figure 1.2.1: Common methods used by road warriors
5
Figure 1.2.2 describes an approach for insurance companies to use VPN’s. Since
large amounts of data, such as graphics, are not probably going to be moved through the
connection, it can be efficient for the road warriors to use SSH. An assumption made in
this case is that this industry relies a lot on paper work and almost every thing is in paper
form, which is later fed to the database maintained on the computers.
Figure 1.2.2: A VPN using Secure SHell
On the other hand the road warrior could use the L2TP available on their laptops
and dial into any ISP, use L2TP to implement the tunnel from their laptop, and then
connect to the ISP’s POP that is running L2TP to serve the branch and central office
LANs. This approach could be well understood using Fig 1.2.3.
Figure 1.2.3: VPN for road warriors using L2TP
6
1.3 Hospitality Industry
With the explosive growth of the Internet, little or no preference is being given in
going to a hotel and placing an order for food or room. It is rather easy to pick-up the
phone or visit the website and book a hotel room rather than doing it the hard way of
driving there. But little do we know on how these orders are being taken care of.
Encryption is one area of paramount importance because any transactions with this
industry involve money and security of financial information has to be guaranteed.
Not much of authentication is required. A preliminary scheme for logging on is
sufficient. The general available approach irrespective of the technology behind it is
given below in Figure 1.3.1.
Figure 1.3.1: Generalized approach used by the hospitality industry
Note: This approach is good only if the customer is calling a particular hotel or
take-out food restaurant or any other business related to the hospitality industry in an area
of his choice. For example, it works well if we are calling Papa John’s pizza at UCF or
Radisson Hotel in Miami to place an order. But if we are looking to place an order in
general to Papa Johns or to Radisson, this approach is not appropriate. A VPN could help
this industry and the customers a whole lot.
7
Various businesses pertaining to the hospitality industry, like take-out restaurants,
hotel chains etc., could benefit a great deal by using VPNs. A simple example of a pizza
chain using VPNs is shown in Figure 1.3.2
Figure 1.3.2: VPN usage by a food chain
1.4 Law Enforcement
Police officers could use virtual private networks to verify information such as
Tag validity, driving record, criminal record etc., right from the computer inside their
vehicles in the event of a pullover or chase. They need accurate response in real-time in
order to take necessary actions. A wireless laptop connected to the nearest ISP’s POP
would do this job great, but the mobility of this workforce is certainly a problem. The
costs incurred on these setups are high and definitely a VPN would be a cost-effective
solution. A general idea on how the current setup works is given below in Figure 1.4.1.
Further study is to be done on how a VPN could be deployed in this area of work.
8
Figure 1.4.1: Usage of VPN by law enforcement official
1.5 Potential Problems
The potential problems that could be faced while deploying a VPN in the
industries described above are discussed individually in this section. The possible
solutions to these problems will be addressed in Section 2 of this report.
1.5.1 Telemedicine
1. In user authentication – Only physicians and insurance companies should be
given access to the records. Hence the number of users could be high and a proper
authentication scheme such as kerberos.
2. In key handling – a proper choice of key management system has to be made to
prevent security breaches
3. In encryption - A strong encryption scheme like RSA encryption must be chosen.
9
4. Congestion – The data heaviness could definitely pose out to be a problem for
high-density data transmission. A proper technique for congestion control has to
be implemented. A leaky bucket or token bucket could be considered
1.5.2 Insurance Companies
1. The road-warriors should be equipped with proper computers and connections to
the nearest ISP’s.
2. The ISP should have sufficient point-of-presences in the city or state in which the
VPN is going to be deployed.
3. There are no clear standards of hardware or software
4. Compatibility: All field agents should have the same kind of equipment to avoid
any problems in compatibility
5. Encryption: Proper encryption is required to avoid security breaches in financial
transactions.
1.5.3 Hospitality Industry
Encryption is one area of paramount importance because any transactions with
this industry involve money and security of financial information has to be guaranteed.
Not much of authentication is required. A preliminary scheme for logging on is
sufficient.
10
1.5.4 Law Enforcement
The vital problem in deploying a VPN is the ISP’s POPs. Since the law
enforcement officials are always on the move, it is not possible for us to confine their
area of work to the area of coverage offered by the ISP’s. A proper choice of ISP and
hardware is required. A static VPN is required as the officers should always be online
and dial-up is considered inefficient in this case.
11
CHAPTER TWO: PROBLEM DESCRIPTION
Recent studies conclude that early and specialized pre hospital patient
management contributes to emergency case survival. Especially in cases of serious
injuries of head, the spinal cord, and internal organs, the method of transport and
generally the method of providing care are crucial for the future of the patient.
Considering the importance of VPN’s in this industry we will now narrow our
focus on VPNs for telemedicine. As discussed in sections 1.1 and 1.5, the main idea is to
use an insecure medium or a public network such as the Internet, to transfer time-
sensitive patient information bi-directionally in a secure fashion, using VPNs. Having
narrowed our discussion to telemedicine, the question grappling our minds is “Where,
what kind of a setup and how would a VPN deployment help this industry save time and
money without any security threats?”
Thought the ideas described below could have been implemented and well
demonstrated using different transmission techniques, our idea is to offer a cost effective,
fast and reliable solution to the problems using VPNs. Not to mention that a lot of
enhancements have been done to make the design distinct. Advantages of using VPNs
include:
12
1. Rapid response time in prehospital setting
2. Decreased mortality
3. Improved patient outcomes
4. Improved access
5. Reduced costs
6. Reduced professional isolation
7. Improved quality of care.
Described below are the possible setups for different scenarios of telemedicine.
Figure 2.1 shows a setup that could be used by a doctor from his office or anywhere to
access the patient’s records from the hospital. This figure shows a highly preliminary
setup, which will be modified as we proceed further in this report.
Figure 2.1: Access from Doctor’s Office
Doctors in the ER could analyze the patient’s condition prior to his/her arrival for
treatment. This scenario, in whatever form it exists, could be supplanted with a VPN
based solution as in Figure 2.2.
13
Figure 2.2: From the Emergency Room for Rapid Consultation
The Labview real-time patient monitoring system will keep track of all vital signs
of the patient like temperature, pressure, ECG, pulse rate, and could even control the
quantity of medicines being administered to the patient.
Figures 2.3 and 2.4 describe the possible suggestions of VPN deployment in an
ambulance and in medical schools. The setup described in Figure 2.2 will allow
transmission of vital signs and still images of the patient from the ambulance and could
bring an expert/specialist to evaluate the patient data and issue directions to the
emergency personnel on treatment procedures until the patient is brought to the hospital.
This also allows the ER personnel to prepare themselves for the emergency, well ahead.
Figure 2.3: From the ambulance to the doctors’ in the ER
14
Also, telemedicine has been shown to reduce professional isolation by providing
peer and specialist contact and continuing education. A new medical procedure could be
demonstrated to any number of students at a university or teaching facility, in real-time
using VPNs. This setup will definitely prove to be useful for medical students.
Figure 2.4: Medical data transfer for educational purposes
For telemedicine and the health care systems outlined above, we are trying, in this
thesis, to develop specific requirements and then analyze them with respect to a set of
certain criteria previously used in development of software systems for other domains.
15
CHAPTER THREE: SOFTWARE REQUIREMENT SPECIFICATION
The objective of this chapter is to produce a set of requirements to develop a prototype
telemedicine system capable of delivering an integrated patient information such as vital
signs (temperature, blood pressure, pulse), medical records, audio and possibly video
information, in an integrated format to the desktop PC of a delivering physician,
wherever he may be as long as the computer is on the internet. The context diagram of
the proposed system is shown in Figure 3.1.
Figure 3.1: Context diagram of the proposed system
When designing the software shown in Figure. 3.1 the external interfaces must be
precisely defined. The interfaces of the software to be developed are described below in
Section 3.1.
16
3.1 Description of Interfaces
The intended inputs and outputs to/from the software to be developed are listed
below.
3.1.1. Interface to the Doctor’s desktop
Operations or commands input from the desktop include:
Command for viewing vital signs of the patient for that visit
Command to bring-up a form for this office visit
Post comments on vital signs on that form
Post diagnosis code and comments on present condition on that form
Request to open patient’s directory
Command to compare diagnosis codes from previous visit
Command to initiate a new prescription or retain the old one
If diagnosis code suggests that the patient should have and
ECG/Angiogram/Scan to be done?
Does the diagnosis code require the patient to have a surgery or hospital care?
Then the command to bring-up the form
Command to transfer patient information to the form
Choose from the list of services requested
17
Command to electronically transfer requests to the service provider and close
the patient directory.
Outputs to the doctor’s desktop include:
A form showing the patient details and vital signs.
Dialog box saying that the inputs provided has been updated on the database
An editable form containing all details of the patient pertaining to this visit.
Patient’s directory showing all the files
An on-line prescription with a digital signature
An on-line service request that can be used to order special services like hospital care,
surgery, MRI.
3.1.2. Interface to the hospital & images database
Operations or commands provided as input to the hospital DB:
Access request
User name and password
Request a search operation
Command to browse files
Command to download files
Command to post comments on the bulletin board with the priority levels
18
Outputs from the hospital database include:
Login screen
Search Query
Display of directories by date of service
Upon selecting a file, it provides two options. One is for browsing the file and
the other is for downloading the file.
Form to post comments on the bulletin board with priority levels.
3.1.3. Interface to the Real-time monitoring system
Assumptions made include a patient being treated and attached on him are a
sphygmomanometer, digital thermometer, ECG leads and an automatic drug flow control
device.
Operations or commands provided as input to the Real-time system include:
Command to record body temperature
Command to record Systolic and Diastolic blood pressure
Command to record pulse rate
Command to record ECG
Command to control drug flow
19
Outputs from the Real-time monitoring system include:
A form indicating the temperature, blood pressure, pulse rate and ECG of the
patient. The form also contains a provision for the nurse/doctor to make a
digital signature and time stamp it and provide alert signals.
3.1.4. Interface to the Mobile user
Assumptions made include, a patient being treated on an ambulance or at a distant
location from the hospital and attached on him are a psygmomanometer, digital
thermometer and ECG leads.
Operations or commands provided as input to the mobile user include:
All commands from Section 3.1.4 are applicable here
Command to record video images of the patient and compress them
Command to record the audio message of the paramedic and compress the
file.
Transmit the file to the ER with a note as incoming patient.
Outputs from the mobile user include:
All outputs from Section 3.1.4 are applicable here and
Comments about the current condition of the patient
Compressed video and audio files
20
3.1.5. Interface to the Local Database
Operations or commands provided as input to the local database include:
Access request
Enter user name and password
Enter a search condition (Patients name…)
Browse files
All commands listed in Section 3.1.3 are applicable here
Outputs from the local database include:
Login screen
Query for search
Search results
Apart from this, all outputs listed in Section 3.1.3 are also applicable here.
21
3.2 Specific Requirements
The software should be portable between different operating systems such as
Linux and Windows. It should be easy to use and should require minimum manual
operation. This means that the software should have a user-friendly interface so that the
system would not pose an additional workload to the users. The software should allow
bidirectional communication between the user and the data source in real time. It should
provide security of operation and confidentiality of information (restricting access to non-
privileged users), by proper compression and encryption algorithms.
On the technical side, the software should:
Allow collection of vital signs and still images of the patient for visual inspection
by experts.
Have tools for computer assisted diagnosis like electronic stethoscope, digital
sphygmomanometer
Be able to avoid congestion while transmitting high volumes of data and images
in real-time.
Sample video images automatically at rates compatible with the transmission
capacity available
The specific requirements expressed in terms of inputs and outputs listed in Section 3.1
are presented below.
22
3.2.1 The software shall start execution in response to a double click on an icon.
Note: The appearance of the icon is to be determined.
3.2.2 Upon startup, the software shall prompt the user to login as shown in
Figure 3.2.2.
Figure 3.2.2: Login Screen
3.2.3 Depending on the selection of the ‘doctor’ or ‘patient’ radio button shown in
Figure 3.2.2, the software shall apply respective access procedures.
3.2.4 The software allows the user to gain access to the clinical database or to the
hospital database by selecting the appropriate radio buttons shown in Figure 3.2.2.
3.2.5 The software shall permit the following combinations of radio buttons shown in
Figure 3.2.2, at the time of login:
Doctor & Clinical DB
Doctor & Hospital DB
Other & Clinical DB
Other & Hospital DB
Patient & Clinical DB.
23
3.2.6 If the radio buttons ‘Patient’ and ‘Hospital DB’ were selected, then the software
shall display the error message shown in Figure 3.2.6.
Figure 3.2.6: Error Message for unauthorized use
3.2.7 If the user clicks on the OK button from screen in Figure 3.2.6, the software shall
display a login screen from Figure 3.2.2 unless the limit of login attempts has
been reached, in which case the software shall exit.
3.2.8 The software shall accept a combination of letters and numbers and ‘_’ up to a
maximum of 7 characters as a valid username.
3.2.9 The software shall accept a password of 6-8 characters in length beginning with a
letter and including letters and digits only, with no special characters or spaces.
3.2.10 Upon clicking the OK button in Figure 3.2.2, the software shall start processing
the logon data, which includes a valid username, password and one of the
permissible combinations of radio buttons listed in the Requirement 3.2.5.
3.2.11 If the logon was not successful due to the incorrect username and password, the
dialog box shown in Figure 3.2.11 is displayed.
24
Figure 3.2.11: Dialog box for unsuccessful login
3.2.12 The software shall exit in response to a click on the CANCEL button shown in
Figure 3.2.11.
3.2.13 The software shall respond to a click on the RETRY button shown in Figure
3.2.11 by displaying the login screen in Figure 3.2.2.
3.2.14 The software shall allow the user to make 3 attempts to logon unsuccessfully,
after which it shall display, the message shown in Figure 3.2.14.
Figure 3.2.14 Error Message for maximum no. of attempts
3.2.15 The software shall exit in response to a click on the OK button shown in Figure
3.2.14.
3.2.16 After a successful logon using the option “doctor”, the user shall be prompted to
enter the name of the patient and to order a search for the directory using the
dialog box shown in Figure 3.2.16
25
Figure 3.2.16: Search Request
3.2.17 The software shall use the directory and file formats identical to the ones in the
Windows and Linux operating systems.
3.2.18 The software shall exit in response to a click on the CANCEL button shown in
Figure 3.2.16.
3.2.19 The software shall respond to a click on the SEARCH button shown in Figure
3.2.16 by executing the search operation and displaying the results of a successful
or unsuccessful search.
3.2.20 Upon a successful search, all information pertaining to this patient shall be
displayed in a window sorted by date as shown in Figure 3.2.20
Figure 3.2.20: Screen Displayed to Doctor
3.2.21 If the search according to the Requirement 3.2.19 was unsuccessful the software
shall display the error message shown in Figure 3.2.21
26
Figure 3.2.21: Dialog box for an unsuccessful search
3.2.22 The software shall respond to a click on the RETRY button shown in Figure
3.2.21 by displaying the screen shown in Figure 3.2.16.
3.2.23 The software shall exit in response to a click on the CANCEL button shown in
Figure 3.2.21.
3.2.24 All patient information pertaining to a particular office visit recognized by date,
such as diagnosis, treatments offered, prescriptions and other requests made shall
be available under this date as specified in Figure 3.2.20.
3.2.25 The software shall respond to the double click on the data item named with the
current date as shown in Figure 3.2.20 and display the contents as shown in
Figure 3.2.25. The content displayed shall include forms for office visits and
forms for special requests. (Note: The appearance of the form icons is to be
decided).
27
Figure 3.2.25: Display after opening a data item.
3.2.26 The Office Visit Form shall include the following: the patients vital signs namely
Temperature ( C), Pressure (psi), Pulse (beats per sec) and an area to post
comments on the vital signs pertaining to this visit. The software shall allow the
doctor to post the diagnostic codes and the appropriate treatment suggested, in
this form. The form will also have provision for the doctor to choose to reissue the
old prescription or create a new prescription.
3.2.27 The Special Request Form shall include information to place special requests such
as surgery scheduling, hospital care, a second electro-cardiogram and MRI/Scan.
3.2.28 The software shall allow the doctor to enter a diagnosis code that appears in an
encrypted format. Note: This code is the doctor’s digital signature and shall be
placed on the forms mentioned in the Requirements 3.2.25 and 3.2.26, along with
the date and time stamp.
3.2.29 The software shall print a copy of the form pertaining to the current office visit
upon a request. Note: This copy shall be given to the patient to be handed over at
the front desk.
3.2.30 In reference to Figure 3.2.2, if at the time of login, the “Patient” radio button was
selected, then the software shall allow the user to enter the username and
password to gain restricted access to his/her health records.
Note: If the ‘Patient’ radio button is selected then the user shall be allowed to
select only the ‘Clinical DB’ radio button as discussed in the requirement 3.2.5.
28
3.2.31 The login procedure for a patient to access his health records is the same as
described in the Requirements 3.2.2 and 3.2.6 through 3.2.10.
3.2.32 Upon a successful login, the software shall grant access to all his records and a
window shown in Figure 3.2.20 shall be displayed.
3.2.33 If the logon was not successful due to the incorrect username and password, the
dialog box shown in Figure 3.2.11 is displayed.
3.2.34 In response to a click on the CANCEL or RETRY button on screen shown in
Figure 3.2.11, the software shall perform the operations mentioned in the
Requirements 3.2.12 and 3.2.13 respectively.
3.2.35 The software shall allow the user to make 3 attempts to logon unsuccessfully,
after which it shall display, the message shown in Figure 3.2.14.
3.2.36 The software shall exit in response to a click on the OK button shown in Figure
3.2.14.
3.2.37 The software shall allow the user to select the data item from which information is
required, by double clicking on the respective icon shown in Figure 3.2.20. Note:
All data items may be stored in a compressed format.
3.2.38 The restricted privileges granted by the software for a patient login include
permissions only for viewing and printing and the software shall deny requests to
download, edit or upload data into or from the server.
3.2.39 In reference to Figure 3.2.2, if at the time of login, the “Other” radio button was
selected, then the software shall allow the user to enter the username and
password to gain access to the database and the login procedure specified in
29
Requirements 3.2.2 and 3.2.6 through 3.2.10 shall be followed. Note: This
category of users can opt to login either to the Clinical DB or to the Hospital DB.
3.2.40 Upon a successful login the software shall offer the following choices to the user:
Create a new patient record
Update an existing record
Transmit or Retrieve files to and from the database,
and optionally:
Compress the sub-directories that are uncompressed after the end of the day.
3.2.41 If at the time of login, the “Clinical DB” radio button in Figure 3.2.2 was selected,
then the user shall be granted access to the VPN local database in the doctor’s
office and to all required information stored there.
3.2.42 If at the time of login, the “Hospital DB” radio button in Figure 3.2.2 was
selected, then the user shall be granted access to the VPN server at the hospital,
but only if a valid login combination mentioned in the Requirement 3.2.5 was
chosen.
3.2.43 The software shall allow full access to privileged users who can use the hospital
server to view the records, download data, and append comments, treatments or
other required information to the database.
3.2.44 Upon any amendment to the existing data, the software shall prompt the user to
save the changes made as shown in Figure 3.2.45
30
Figure 3.2.45: Display for saving changes
3.2.45 The software shall respond to a click on the OK button shown in Figure 3.2.45, by
saving the changes to the existing data item, which was amended.
3.2.46 The software shall exit in response to a click on the CANCEL button shown in
Figure 3.2.45.
3.2.47 Due to compatibility and storage reasons, all images shall be in the JPEG format
and all video files shall be in the ‘*. avi’ format.
3.2.48 In reference to the Requirement 3.2.39, the software shall prompt the user to
choose one of the options mentioned in the Requirement 3.2.40 using the dialog
box shown in Figure 3.2.48.
Figure 3.2.48: Display after logging in as ‘Other’
3.2.49 The software shall permit the following combinations of radio buttons shown in
Figure 3.2.48.
Create/Edit records & Clinical DB
Send/Receive & Clinical DB
Other & Clinical DB
31
Send/Receive & Hospital DB
3.2.50 Based on the options chosen in Figure 3.2.48 the software shall grant different
privileges of access to the information as discussed in the Requirements 3.2.57
and 3.2.58.
3.2.51 The software shall exit in response to a click on the CANCEL button shown in
Figure 3.2.48.
3.2.52 The software shall accept a username and password to be valid if they meet the
criteria mentioned in the Requirements 3.2.8 and 3.2.9.
3.2.53 The software shall display the error message shown in Figure 3.2.11 if an invalid
username or password was entered for the Requirement 3.2.53.
3.2.54 After an unsuccessful login according to the Requirement 3.2.48, the software
shall respond to a click on the RETRY button shown in Figure 3.2.3 by
redisplaying the login screen in Figure 3.2.48.
3.2.55 The software shall allow the user to make 3 attempts to logon unsuccessfully,
after which it shall display the message shown in Figure 3.2.14.
3.2.56 If the ‘Create/Edit records & Clinical DB’ option or ‘Other & Clinical DB’ option
was chosen from Figure 3.2.48., the software shall grant creating and updating
privileges to the user.
3.2.57 If the ‘Send/Receive & Clinical DB’ option or the ‘Send/Receive & Hospital DB’
option shown in Figure 3.2.48 was chosen, the software shall grant only viewing,
uploading and downloading privileges.
32
3.2.58 In response to a double click on the Office Visit Form icon shown in Figure
3.2.25, the software shall display the form shown in Figure 3.2.58.
33
Figure 3.2.58: Office Visit Form
34
3.2.59 The software shall allow the ‘Diagnosis and Prescription’ part of the form shown
in Figure 3.2.62 to be edited only, if the login option of ‘Doctor’ was chosen in
response to the Requirement 3.2.2
3.2.60 In response to an attempt by an unauthorized user (Patient or Other) to enter data
in the fields under ‘Diagnosis and Prescription’ in the form shown in Figure
3.2.62, the software shall display the error message shown in Figure 3.2.60
Figure 3.2.60: Error Message for unauthorized use
3.2.61 The software shall exit in response to a click on the OK button shown in Figure
3.2.60.
3.2.62 Upon logging in as a ‘Doctor’, the software shall allow data to be entered in the
fields under the header ‘Diagnosis and Prescription’ in the office visit form shown
in Figure 3.2.58.
3.2.63 The software shall display the screen shown in Figure 3.2.63 in response to a click
on the View Previous Prescription button shown in the office visit form in Figure
3.2.58.
3.2.63aThe software shall not allow the prescription shown in Figure 3.2.63 to be edited.
35
Figure 3.2.63: Previous Prescription Display
3.2.64 In response to a click on the OK button shown in Figure 3.2.63, the software shall
redisplay the Office Visit Form shown in Figure 3.2.58.
3.2.65 In response to a click on the PRINT button shown in Figure 3.2.63, the software
shall print a copy of the prescription to the default printer and shall display the
screen shown in Figure 3.2.65.
Figure 3.2.65: Display while printing is in progress
3.2.66 The software shall cancel the print job, in response to a click on the CANCEL
button shown in Figure 3.2.65.
3.2.67 Upon completion of the print job, the software shall display the screen shown in
Figure 3.2.63.
3.2.68 The software shall not provide the user with any print options and shall print one
copy of the prescription using the default settings set by the administrator.
36
3.2.69 In response to a click on the ‘View Previous Diagnosis Code’ button shown in
Figure 3.2.58, the software shall display the screen shown in Figure 3.2.69
Figure 3.2.69: Screen to view Previous Diagnosis Code
3.2.70 In response to a click on the OK button shown in Figure 3.2.69, the software shall
redisplay the Office Visit Form shown in Figure 3.2.58.
3.2.71 Upon clicking the button ‘Click Here to create a New Prescription’ shown in
Figure 3.2.58, the software shall display the screen shown in Figure 3.2.71
Figure 3.2.71: Display to create a new prescription
3.2.72 In response to a click on the OK button shown in Figure 3.2.71, the software shall
redisplay the Office Visit Form shown in Figure 3.2.58.
37
3.2.73 In response to a click on the button CLEAR shown in Figure 3.2.71, the software
shall clear the data that was entered in the screen shown in Figure 3.2.71.
3.2.74 In response to a click on the PRINT button shown in Figure 3.2.71, the software
shall print a copy of this new prescription to the default Printer
Note: Refer the Requirements 3.2.65 through 3.2.67 for more information about
the printing procedure.
3.2.75 In response to a click on the SAVE button shown in Figure 3.2.58, the software
shall save the information entered in the form and shall exit to redisplay the
screen shown in Figure 3.2.25.
3.2.76 In response to a click on the CLEAR button shown in Figure 3.2.58, the software
shall clear the recent changes made to the Office Visit Form.
3.2.77 In response to a click on the PRINT button shown in Figure 3.2.58, the software
shall print a copy of this Office Visit Form to the default printer. Note: Refer the
Requirements 3.2.65 through 3.2.67 for more information about the printing
procedure.
3.2.78 In response to a double click on the Special Request Form icon shown in Figure
3.2.25, the software shall display the form shown in Figure 3.2.78.
38
Figure 3.2.78: Special Request Form
3.2.79 The software shall allow the date to be entered in a mm/dd/yy format in the space
provided in the Special Request form shown in Figure 3.2.78.
3.2.80 In response to a click on the arrow next to the field marked ‘Doctor’s Name’ in
Figure 3.2.78, the software shall display the list of doctor’s names and shall not
allow the form to be saved or printed without a doctor’s name being selected from
the drop down list.
3.2.81 If the user clicks on the arrow next to the space marked ‘ Special Request Code’
in Figure 3.2.78, the software shall provide a drop down list of codes and
appropriate names of special requests from which the user can select one item.
Note: An example of the drop-down list of special requests is given here:
5632 – MRI
5745 – CT Scan
7867 – Surgery
39
3.2.82 In order to facilitate the needs of an experienced user, who remembers the Special
Request Codes, the software shall allow the user to enter the code (4 digit
numbers) as a method of selection of a special request in the space marked
‘Special Request Code: ‘, in Figure 3.2.78.
3.2.83 The software shall allow the user to make only one Special Request per form and
Note: Any additional requests must be done using a new Special Request Form.
3.2.84 If the user clicks on the arrow next to the space marked ‘ Facility Requested’ in
Figure 3.2.78, the software shall provide a drop down list of codes and
appropriate names of facilities, from which the user can select one item.
3.2.85 In order to facilitate the needs of an experienced user, who remembers the Names
of the Facilities, the software shall allow the user to enter the code (4 digit
numbers) as a method of selection of a facility, in the space marked ‘Facility
Requested: ‘, in Figure 3.2.78.
3.2.86 The software shall allow the user to have only one Facility selected from the drop
down list mentioned in Requirement 3.2.84.
3.2.87 Following the choice of the Facility, the software shall allow the user to enter a
date in which the service is requested, in the field marked ‘Date of Service’, in
Figure 3.2.78.
3.2.88 The software shall accept a date entered in the mm/dd/yy format as a valid entry
in the field marked ‘Date of Service’, in Figure 3.2.78.
40
3.2.89 The software shall accept only future dates as a service date; otherwise it shall
display the error message shown in Figure 3.2.89.
Figure 3.2.89: Error Message for Invalid Date
3.2.90 The software shall respond to a click on the RETRY button shown in Figure
3.2.89, by redisplaying the form shown in Figure 3.2.78.
3.2.91 The software shall exit the special request form in response to a click on the
CANCEL button shown in Figure 3.2.89.
3.2.92 The software shall allow the user to place a check mark in the box provided on the
Special Request Form in Figure 3.2.78, for requesting a confirmation when the
request has been completed.
3.2.93 The software shall allow the doctor to enter a code (digital signature) on the
Special Request Form in Figure 3.2.78, which can be used for identification
purposes.
3.2.94 The software shall allow the user to enter details about the special request, in the
field marked ‘Comments’ in Figure 3.2.78.
Note: For example, if a special request for an X-ray is selected, then the user can
enter details like which part of the body has to be imaged and how.
41
3.2.95 The software shall respond to a click on the OK button shown in Figure 3.2.78 by
saving this form and sending the request to the selected facility for processing.
3.2.96 The software shall exit in response to a click on the CANCEL button shown in
Figure 3.2.78.
3.2.97 The software shall print a copy of the Special Request Form, in response to a click
on the PRINT button shown in Figure 3.2.78.
Note: Refer the Requirements 3.2.65 through 3.2.67 for more information about
the printing procedure.
3.2.98 In response to a click on the EDIT LISTS button shown in Figure 3.2.78, the
software shall display the screen shown in Figure 3.2.98.
Figure: 3.2.98: Screen to Edit the Lists
3.2.99 The software shall display the error message shown in Figure 3.2.99, if the user
attempts to click on the ADD or REMOVE without selecting one of the radio
buttons shown in Figure 3.2.98.
Figure 3.2.99: Error Message
42
3.2.100 In response to a click on the OK button shown in Figure 3.2.99, the
software shall redisplay the screen shown in Figure 3.2.98.
3.2.101 The software shall allow the user to select one radio button from Figure
3.2.98 and the user shall be allowed to choose the desired operation which can be
either add or remove an entry into the list, using the ADD and REMOVE buttons
shown in Figure 3.2.98.
3.2.102 Upon selecting the radio button marked ‘Doctor’s Name’ and clicking on
the ADD button in Figure 3.2.98, the software shall display the screen shown in
Figure 3.2.102.
Figure 3.2.102: Screen to ADD a name to the list
3.2.103 Upon entering a name and in response to a click on the OK button shown
in Figure 3.2.102, the software shall add the new name to the existing list
discussed in the Requirement 3.2.80 and shall redisplay the screen in Figure
3.2.78.
43
3.2.104 In response to a click on the CLEAR button shown in Figure 3.2.102, the
software shall clear all the fields and redisplay the screen shown in Figure
3.2.102.
3.2.105 In response to a click on the CANCEL button shown in Figure 3.2.102, the
software shall redisplay the Figure 3.2.98.
3.2.106 Upon selecting the radio button marked ‘Facility Requested’ and clicking
on the ADD button in Figure 3.2.98, the software shall display the screen shown
in Figure 3.2.106.
Figure 3.2.106: Screen to ADD a facility to the list
3.2.107 Upon entering the facility name and place and in response to a click on the
OK button shown in Figure 3.2.106, the software shall add the facility name to the
existing list discussed in the Requirement 3.2.84 and shall redisplay the screen in
Figure 3.2.78.
3.2.108 In response to a click on the CLEAR button shown in Figure 3.2.106, the
software shall clear all the fields and redisplay the screen shown in Figure
3.2.106.
3.2.109 In response to a click on the CANCEL button shown in Figure 3.2.106, the
software shall redisplay the Figure 3.2.98.
44
3.2.110 Upon selecting the radio button marked ‘Special Request Code’ and
clicking on the ADD button in Figure 3.2.98, the software shall display the screen
shown in Figure 3.2.110.
Figure 3.2.110: Screen to ADD a special request code to the list
3.2.111 Upon entering the special request code and the description and in response
to a click on the OK button shown in Figure 3.2.110, the software shall add the
special request code entered to the existing list discussed in the Requirement
3.2.81 and shall redisplay the screen in Figure 3.2.78.
3.2.112 In response to a click on the CLEAR button shown in Figure 3.2.110, the
software shall clear all the fields and redisplay the screen shown in Figure
3.2.110.
3.2.113 In response to a click on the CANCEL button shown in Figure 3.2.110, the
software shall redisplay the Figure 3.2.98.
3.2.114 In response to a click on the CANCEL button shown in Figure 3.2.98, the
software shall redisplay the Figure 3.2.78.
45
3.2.115 Upon selecting the radio button marked ‘Doctor’s Name’ and clicking on
the REMOVE button in Figure 3.2.98, the software shall display the screen shown
in Figure 3.2.115.
Figure 3.2.115: Screen to REMOVE a name to the list
3.2.116 Upon entering a name and in response to a click on the OK button shown
in Figure 3.2.115, the software shall remove the name from the existing list
discussed in the Requirement 3.2.80 and shall redisplay the screen in Figure
3.2.78.
3.2.117 In response to a click on the CLEAR button shown in Figure 3.2.115, the
software shall clear all the fields and redisplay the screen shown in Figure
3.2.115.
3.2.118 In response to a click on the CANCEL button shown in Figure 3.2.115, the
software shall redisplay the Figure 3.2.98.
3.2.119 Upon selecting the radio button marked ‘Facility Requested’ and clicking
on the REMOVE button in Figure 3.2.98, the software shall display the screen
shown in Figure 3.2.119.
46
Figure 3.2.119: Screen to REMOVE a facility to the list
3.2.120 Upon entering the facility name and place and in response to a click on the
OK button shown in Figure 3.2.119, the software shall remove the facility name
from the existing list discussed in the Requirement 3.2.84 and shall redisplay the
screen in Figure 3.2.78.
3.2.121 In response to a click on the CLEAR button shown in Figure 3.2.119, the
software shall clear all the fields and redisplay the screen shown in Figure
3.2.119.
3.2.122 In response to a click on the CANCEL button shown in Figure 3.2.119, the
software shall redisplay the Figure 3.2.98.
3.2.123 Upon selecting the radio button marked ‘Special Request Code’ and
clicking on the REMOVE button in Figure 3.2.98, the software shall display the
screen shown in Figure 3.2.123
47
Figure 3.2.123: Screen to REMOVE a special request code to the list
3.2.124 Upon entering the special request code and the description and in response
to a click on the OK button shown in Figure 3.2.124, the software shall remove
the special request code entered from the existing list discussed in the
Requirement 3.2.81 and shall redisplay the screen in Figure 3.2.78.
3.2.125 In response to a click on the CLEAR button shown in Figure 3.2.123, the
software shall clear all the fields and redisplay the screen shown in Figure
3.2.123.
3.2.126 In response to a click on the CANCEL button shown in Figure 3.2.123, the
software shall redisplay the Figure 3.2.98
48
3.3 Additional Requirements
3.3.1 The software shall prompt the user to compress any data items that are not
compressed. After a patient’s name is entered and proper options are chosen in
Figure 3.2.48, any data item that is not compressed shall initiate this prompt as
shown in Figure 3.3.1
Figure 3.3.1: Reminder screen
Note: The need for compression is optional and is based on the memory usage at
the time of access or storage. Compression of data is recommended as it increases
the ease transmission of high volume of data over VPNs.
49
3.3.2 In response to a click on the NO button shown in Figure 3.3.1, the software shall
display the screen shown in Figure 3.2.20. The user shall now be allowed to work
on the data without compressing it.
3.3.3 Upon selection of the option ‘Yes’, the compression software shall begin
execution and Figure 3.3.3 shall be displayed.
Figure 3.3.3: Display for compressing data
3.3.4 The software shall respond to the double click action by the user on the name that
appears in the window as shown in Figure 3.3.3, by compressing the contents of
the data item.
Note: Since data compression is very crucial in the transmission of high volume of data through VPNs, two
compression softwares have been put to test and the results are discussed below.
SOFTWARE ORIGINAL SIZE % COMPRESSED COMPRESSED SIZE
PKZIP 7947264 Bytes 75 1.97MB
WINZIP 7947264 Bytes 79 1.87MB
50
Table 1: Comparison of compression softwares
A graphical representation of the data shown in Table 1 is shown in Figures 3.3.4 and
3.3.5
Figure 3.3.4: Comparison of ratio of compression
Figure 3.3.5: Comparison of compressed file sizes
51
3.4 System Architecture
Based on the fact that physicians have access to the patient information both from
their own office databases and from the hospital databases makes this architecture more
feasible. The architecture could be well described by the Figure given below.
Figure 3.4.1: Architecture of the proposed system
Using a simple GUI interface the physician’s office will collect all patient
information and store it in the database. The patient will now be hooked up to a labview
real-time monitor where his vital signs and other required information are recorded,
stamped with the time and date and updated in the database.
52
Imaging information such as X-rays, Scan images are also stored in a compressed
digital format in the database. Every office visit of the patient, the diagnosis, the
prescriptions provided and the next scheduled visit are updated on the database.
The patient information such as the hospital visits, treatment provided and other
diagnostic information can be accessed by the physician from his desktop computer via
the Internet. This is mainly done for post-hospital care. In order to do this, a secure VPN
connection should be established between the hospital and the doctor’s office. The factors
that may affect the process include time, speed of the connection and the security.
When these factors are properly addressed, then the physician can request a
download of data from the hospital server to his desktop computer. Once this is done the
downloaded data is integrated with the existing patient information in the doctor’s office.
This patient information file, in whatever format, can now be accessed from the
central database in the doctor’s office via a VPN server and firewall, from anywhere.
Access to the VPN server is granted to participating physicians and also to patients who
request their records. The data will basically be available for viewing purposes only and
downloads will be permitted only on-demand.
53
3.5 Security Issues
To prevent information security from being compromised the proposed system
will have the following components in the transmission and receiving ends of the
data.
Figure 3.5.1: The transmission end of the proposed system
Figure 3.5.2: The receiving end of the proposed system
A possible solution to one of the scenarios discussed in section 2 is a client-
initiated tunneling on a dial-in VPN. Figure 3.5.3 shows a way of implementing this
scheme for a doctor’s office and enable access to medical records and real time data. In
54
this figure, the doctor dials into the Internet connecting through a local ISP’s network
access server (NAS). VPN software runs on the user’s computer, tunneling and
encrypting the data there for its passage through the Internet. The user now makes a
request to access the VPN server of the hospital. Upon authentication, the user gets
access to the VPN server and continues to get or transmit the required data. The doctor
can request data from the database or monitor the condition of the patients through the
computers placed next to them.
Figure 3.5.3: Client-Initiated Tunneling on a dial-in VPN
The problems to be addressed include BW of transmission, compatibility, speed
and reliability. Having a firewall and VPN together is one solution. The location of the
firewall and VPN server is paramount in any VPN design.
Note: It is not necessary that the same architecture be used at both ends of a VPN.
For the sake of clarity, however we will zoom in on only one end of our VPN and take a
closer look to examine some scenarios available, and choose one based on the level of
security demanded by the application. Figure 3.5.4 shows one scenario with the router as
55
a terminator. All basic functions of a VPN, like tunneling, encryption etc., is done by the
router. To do this without a noticeable penalty, the router must be properly configured to
handle the load.
Figure 3.5.4: The router-terminated VPN
We must be wary of the fact that the traffic behind the routers may not be
tunneled or encrypted. This area outside the firewall, accessible by public and vulnerable,
is known as the demilitarized zone (DMZ). This situation could be handled by having the
termination point of the VPN right into the firewall as shown in Figure 3.5.5.
Figure 3.5.5: A LAN-to-LAN VPN with the firewall handling the VPN process
Responsibilities of firewalls vary from packet filtering to an application level
gateway capable of logging and controlling, even authenticating, all inbound and
outbound traffic. This design with a firewall having VPN capabilities minimizes the load
56
handled by the router. But the drawback to combining VPN terminator with the firewall
is, the load it places on the firewall.
The solution to this problem is to handle the operations of the firewall and the
VPN server separately as shown in Figure 3.5.6.
Figure 3.5.6: The VPN server in the DMZ
This design provides added security and the VPN server could filter out attackers
trying to penetrate into the LAN. Also, the non-VPN traffic would bypass the VPN
server. The position of the VPN server should carefully be chosen and figures 3.5.7 and
3.5.8 describe the possible variations from the model shown in Figure 3.5.6.
Figure 3.5.7: The VPN server behind the firewall
The approach described in Figure 3.5.7 has enhanced security because the VPN
server cannot be attacked until the firewall is breached. Traffic is decrypted and passed
on to the LAN at that point. On the other hand, Figure 3.5.8 shows the VPN server being
57
placed on a branch of the LAN wherein the systems downstream get to participate in it
and the workstations on the other branch would just ignore the VPN traffic.
Figure 3.5.8: The VPN server on one branch of the LAN
After analyzing the various possibilities of firewall and VPN server locations, the
model described Figure 3.5.3 is being redefined and shown in Figure 3.5.9.
Figure 3.5.9: Client-Initiated tunneling on a dial-in VPN
A variation to the model described about VPN usage in the ambulance in Figure
2.3 is shown in Figure 3.5.10. Here the patient in the ambulance is connected to the
necessary devices and their outputs are monitored and recorded by a labview setup. The
patient’s personal details like name, address etc., if found, are keyed into the computer by
58
the paramedic. A camera is used to obtain video images of the patient’s condition or
injury. Finally, all these video, text and real-time data should be transferred from the
ambulance to the computer in the ER via Internet and VPN.
Figure 3.5.10: VPN usage from ambulance – a modified approach
The setup will be using a form like the one given below for transmitting patient
data from a remote location for rapid consultation and diagnosis.
Another method of implementing a VPN gateway that uses IPSec is the
FreeS/WAN method. It is an open source implementation of the IPSec and is portable.
The issues of prime concern such as encryption, key handling are well addressed by
FreeS/WAN, which seems to be a good and economical solution. FreeS/WAN uses a
component called KLIPS, which is compiled, into the Linux kernel, to provide triple data
encryption standard and MD5 shared key authentication while the Internet key exchange
handles the connection parameters. Noticing the subtle difference between the transport
and tunnel modes of IPSec and considering the security issues in our design, we decide to
use the tunnel mode, which allows point-to-site or site-to-site communications in a secure
fashion.
59
CHAPTER FOUR: SOFTWARE REQUIREMENTS REVIEW
The development of any product, be it software or hardware, shall be successful if
the developer knows how to do the right thing – building a product – right. Though
impossible in software development, it is highly recommended that the developers have a
complete and unambiguous understanding of what the customer expects. During the
course of development, the developer would be surprised to discover that what he builds
and what the customer wants are not identical. The difference, expectation gap, though
not large initially, tends to grow over time. This is because, arriving at a common
decision of what the fully developed software product shall be and do is very difficult.
This difference is also caused by incomplete, informal and poorly documented
requirements that plague software groups of all types.
4.1 General Discussion
The main goal of any software developer is to develop a superior quality product that
shall obtain the best customer satisfaction ratings. Improved customer satisfaction and
controlled requirements instability could be achieved by a culture that emphasizes high-
quality requirements. The quality of the requirements cannot be compromised and can be
ensured only by a Software Requirements Review (SRR). Reviewing the software
requirements shall provide an opportunity to correct any problems before the
60
development group accepts them. The SRR also provides an opportunity to ensure a
common understanding of the user’s stated requirements.
Also important is the process of reviewing the proposed changes to the requirements
after the SRR and evaluating the impact of this change on the development process,
before approving the change. One of the commonly frustrations that is commonly
encountered by software developers is discovering requirement problems late in the
development process or after the product has been delivered. A requirement that may
seem to be fine when reading may not be correct when we tend to work with it during
development. A SRR can reveal the ambiguities and vagueness in some requirement
statements. Substantial effort is required to correct such errors that cost time and money
and hence are not desirable. As a result of the SRR process, one can increase confidence
that:
The requirement statements demonstrate the intended software behaviors and
characteristics.
The requirements are accurate, complete, and traceable.
All views of the requirements are consistent.
The requirements provide an adequate basis to proceed with product construction and
testing.
A Software Requirement Review is not a single discrete phase that we perform
after all the requirements have been documented. It shall be custom defined, based on
the complexity of the software to be developed. In general, the SRR is classified into two
categories namely:
61
1. Software Requirements Analysis
2. Software Requirements Verification
Software Requirements Analysis is the initial review process where the ‘raw’
requirements as elicited from the system stakeholders shall be examined. These
requirements may be incomplete and expressed in an informal and unstructured way. The
prime focus during this phase is on making sure that the requirements meet the customer
needs rather than the details of the description. In this thesis we focus on the Software
Requirement Analysis via the following two techniques:
Walkthroughs
Inspection.
Walkthrough is a software engineering review process in which the designer or
programmer leads one or more members through a segment of the design, while other
members ask questions and make comments about the technique and other problems. A
walkthrough is used to provide early peer approval of the requirements. In this thesis, the
designer, myself, updated the document with new requirements and every week
conducted walkthroughs with the advisor, who raised questions about the need of every
requirement and indicated possible errors and violation of the development standards.
The reviewer had marked all his comments about the requirements on the
document and the designer updated the comments. The reviewer ensured that the
comments made during the previous week’s walkthrough were correctly updated when
the document was resubmitted for review again along with new requirements the
following week. These weekly walkthroughs and comments by the reviewer proved to be
62
a stepping-stone in discovering whether the requirements shall necessarily demonstrate
the intended behavior of the software to be developed. The designer and the reviewer had
met approximately 40 times during the software requirement elicitation, analysis,
documentation and review stages of this thesis.
Inspection is a formal evaluation technique in which a person or a group examines
the software requirements in detail. The goals of an inspection are to identify and
describe the defects in a software element such as a requirement. This is a rigorous peer
examination technique that verifies whether the software requirements document is fit for
further use. In this thesis the inspection process was conducted formally and has been
incorporated into the Requirement Verification stage.
4.2 Software Requirements Verification
Software Requirements Verification is the final stage of requirements
engineering. Verification determines whether the product of a development activity meets
the criteria established for it at the beginning of the activity. This process is done to check
the requirements and certify whether they represent an acceptable description of the
software, which is to be developed. The requirements problems that could be discovered
by this process are two fold:
a. Poorly worded requirements which are ambiguous
b. Errors in the requirements that were not detected during the analysis
process.
63
Verification ensures that the requirements conform to the traits of excellent
requirement statements and specification. This can be conducted according to certain
criteria of which we chose the following: consistency, completeness, correctness, clarity,
traceability and testability. This process is not a single phase that we perform on the
requirements. Every single requirement is checked to conform to all the traits mentioned
above.
Check for Completeness of the software requirements is done to confirm that each
requirement fully describes the functionality to be delivered and no requirements or
necessary information is missing.
Check for Consistency of the software requirements is done to ensure that entities
and relations in each requirement don’t conflict with other software requirements.
Inconsistencies may be a result of genuine requirement conflicts, which must be resolved
or may be the result of mistakes or omissions in the requirements.
Check for Correctness of the software requirements is done to ensure that each
requirement accurately describes the functionality to be built. A software requirement
that conflicts with any external process or law is not correct. Such requirements, if found,
shall be corrected. This process shall also check for the compliance of the document with
other related documents or standards.
Check for Clarity of the requirements is done to ensure that all readers of a
requirement shall arrive at one single and consistent meaning of it. This process also
requires that each requirement be uniquely labeled and expressed separately from other
requirements.
64
Check for Traceability is done to ensure that a relationship can be established
between a requirement and its predecessor during the software development process.
Check for Testability is done to confirm whether a requirement is written in such
a way that it helps in establishing test conditions and performance tests to ensure whether
those conditions have been met.
During the course of this verification process the designer has applied the
following checks to every requirement and the results of these checks have been
discussed in Table 4.2
Consistency and Completeness of the requirements listed in this thesis Section 3.2
were checked for the following aspects:
Are all requirements written at a consistent and appropriate level of detail?
Do the requirements provide the necessary basis for design?
Are all the internal references to other requirements correct?
Are all the figures labeled and referenced properly?
Are all external hardware, software and communication interfaces defined to the
appropriately?
Are any requirements missing?
Is any necessary information missing in any requirement?
Are there any requirements that have been defined more than once or appear similar?
Clarity and Correctness of the requirements listed in this thesis Section 3.2 were
checked for the following aspects:
Does any of the requirements conflict with its predecessors or successors?
65
Are all the requirements described in a succinct, concise and unambiguous language?
Did testing, demonstration, review or analysis verify the requirements?
Does every requirement fall under the scope of this thesis?
Are all the requirements free of spelling mistakes and grammatical errors?
Can all the requirements be implemented with known constraints?
Are there any messages or displays that require special interpretation?
Are all the terms used in the document and in the requirements defined appropriately?
Traceability and Testability of the requirements listed in this thesis Section 3.2 were
checked for the following aspects:
Are all the requirements uniquely identified?
Are all the requirements correctly identified?
Is it possible to trace the requirements to a specification or another higher-level
requirement?
Are all the requirements testable?
Do the requirements that are capable of being tested have test criteria?
Finally, all the requirements have been also been checked for the following aspects:
Have all the security issues and safety considerations related to this software been
addressed?
Have all the hardware configurations that would help in the system design been
addressed?
Have all the hardware design trade-off’s been discussed with appropriate reasoning?
66
Does this document contain explanations of future research work that could be
pursued on this topic?
The results of the checks on the requirements and on the document as whole are
presented in Table 4.2:
Table 4.2: Results of Verification
REQUIREMENT
#
RESULTS OF VERIFICATION
CRITERIAFAILED
ACTION NEEDED
3.2.1 Correctness TBD should be removed
3.2.2 Correctness Change to ‘Upon startup the
software shall prompt the user to
login by displaying the screen
shown in Figure 3.2.2’.
3.2.3 Completeness Stating about the access
procedures, which are not
question, where are the access
referenced. This might raise a
question, where are the access
procedures defined?
3.2.7 Correctness The word display should be
replaced by redisplay.
3.2.13 Correctness The word display should be
67
replaced by redisplay.
3.2.16 Clarity The word ‘option’ should be
replaced by the phrase ‘radio
button marked ‘Doctor’ in Figure
3.2.2’.
3.2.16 Consistency Inconsistent with Requirement
3.2.5. Change the statement
accordingly.
3.2.17 Completeness The file and directory formats are
used for what? Should state that
similar formats are used for storage
and display.
3.2.20 Correctness The term ‘this patient’ is
misleading. The requirement
should be more general.
3.2.20 Clarity A replacement for the term ‘this
patient’ shall be ‘pertaining to the
patient whose name was entered in
Figure 3.2.16.’
3.2.22 Correctness The word ‘display ‘ should be
replaced by redisplay.
3.2.24 Correctness Replace ‘this date’ with ‘that date’.
3.2.25 Completeness The term ‘current date ‘ is
68
misleading. There may or may not
be a data item named with the date
of access.’
3.2.25 Correctness Also the word ‘display’ should be
changed to ‘by displaying’ and the
TBD should be removed.
3.2.26 Completeness The word ‘this form’ raises a
question “Which Form?” in the
readers’ mind. Hence it should be
replaced by ‘Office Visit Form’.
3.2.32 Correctness The term ‘his’ is misleading. It has
to be replaced with more
appropriate word or phrase to
make the requirement more
meaningful. ‘records pertaining to
the patient who is accessing it’
shall replace it.
3.2.39 Consistency With Requirement 3.2.5. Modify
the requirement to state that the
‘Other’ radio button and either the
‘Clinical DB or the Hospital DB’
radio button has to be selected
inorder to maintain the reference to
69
the requirement 3.2.5.
3.2.40 Clarity The word ‘login’ is ambiguous and
misleading. It must provide more
detail as to where the user is trying
to login, such as login as ‘Other &
Hospital DB’ or ‘Other & Clinical
DB’.
3.2.41 Consistency Inconsistent with requirement 3.2.5
3.2.42 Consistency Inconsistent with requirement 3.2.5
3.2.56 Completeness Missing Requirement. What
happens upon a successful logon?
The figure 3.2.25 is displayed.
This should be stated in the
requirement.
3.2.59 Completeness The phrase ‘in response to’ should
be replaced by ‘as a part of the
login procedure in the ‘.
3.2.62 Clarity Requirement ambiguous to 3.2.59
and hence should be removed
3.2.76 Correctness The word ‘Recent’ is misleading.
The requirement should state that
the changes made to the form
during the current session shall be
70
cleared and nothing else shall be
deleted.
4.3 Corrected Requirements
The requirements that did not meet the verification criteria discussed in Table 4.2,
have been modified and are presented below.
3.2.1 The software shall start execution in response to a double click on an icon.
3.2.2 Upon startup, the software shall prompt the user to login by displaying the screen
shown in Figure 3.2.2.
3.2.3 Depending on the selection of the ‘doctor’ or ‘patient’ radio button shown in
Figure 3.2.2, the software shall apply respective access procedures described in
Requirements 3.2.38 and 3.2.39.
71
3.2.7 If the user clicks on the OK button from screen in Figure 3.2.6, the software shall
redisplay a login screen from Figure 3.2.2 unless the limit of login attempts has
been reached, in which case the software shall exit.
3.2.13 The software shall respond to a click on the RETRY button shown in Figure
3.2.11 by redisplaying the login screen in Figure 3.2.2.
3.2.16 After a successful logon using the radio buttons marked “Doctor” and “Clinical
DB” in Figure 3.2.2, the user shall be prompted to enter the name of the patient
and to order a search for the directory using the dialog box shown in Figure
3.2.16.
3.2.17 The software shall use the directory and file formats identical to the ones in the
Windows and Linux operating systems for display and structuring purposes.
3.2.20 Upon a successful search, all information pertaining to the patient whose name
was entered in Figure 3.2.16 shall be displayed in a window sorted by date as
shown in Figure 3.2.20
3.2.21 The software shall respond to a click on the RETRY button shown in Figure
3.2.21 by redisplaying the screen shown in Figure 3.2.16.
3.2.24 All patient information pertaining to a particular office visit recognized by date,
such as diagnosis, treatments offered, prescriptions and other requests made shall
be available under that date as specified in Figure 3.2.20.
3.2.25 The software shall respond to the double click on the data item named with the
date of access as shown in Figure 3.2.20 and shall display the contents as shown
in Figure 3.2.25. The content displayed shall include forms for office visits and
forms for special requests.
72
3.2.26 The Office Visit Form shall include the following: the patients vital signs namely
Temperature ( C), Pressure (psi), Pulse (beats per sec) and an area to post
comments on the vital signs pertaining to this visit. The software shall allow the
doctor to post the diagnostic codes and the appropriate treatment suggested, in the
office visit form. The office visit form will also have provision for the doctor to
choose to reissue the old prescription or create a new prescription.
3.2.32 Upon a successful login, the software shall grant access to all records pertaining
to the patient who is accessing it and a window shown in Figure 3.2.20 shall be
displayed.
3.2.39 In reference to Figure 3.2.2, if at the time of login, the “Other” radio button and
either the ‘Clinical DB’ or the ‘Hospital DB’ radio button was selected, then the
software shall allow the user to enter the username and password to gain access to
the database and the login procedure specified in Requirements 3.2.2 and 3.2.6
through 3.2.10 shall be followed.
3.2.40 Upon a successful login using the options ‘Other & Hospital DB’ or ‘Other &
Clinical DB’ mentioned in the Requirement 3.2.5, the software shall offer the
following choices to the user:
Create a new patient record
Update an existing record
Transmit or Retrieve files to and from the database, and optionally:
Compress the sub-directories that are uncompressed after the end of the day.
73
3.2.41 If at the time of login, the “Clinical DB” radio button was chosen along with
‘Doctor’ or ‘Other’ or ‘Patient’ radio button in Figure 3.2.2, then the user shall be
granted access to the VPN local database in the doctor’s office and to all required
information stored there.
3.2.42 If at the time of login, the “Hospital DB” radio button in Figure 3.2.2 was selected
along with ‘Doctor’ or ‘Other’ or ‘Patient’ radio button in Figure 3.2.2, then the
user shall be granted access to the VPN server at the hospital.
3.2.56 Upon a successful logon, the software shall display the screen shown in Figure
3.2.25.
3.3.59 The software shall allow the ‘Diagnosis and Prescription’ part of the form shown
in Figure 3.2.62 to be edited only, if the login option of ‘Doctor’ was chosen as a
part of the login procedure in the Requirement 3.2.2.
3.2.76 In response to a click on the CLEAR button shown in Figure 3.2.58, the software
shall clear the changes that were made to the Office Visit Form on the day of
access.
74
CHAPTER FIVE: SOFTWARE DEVELOPMENT PLAN
Having discussed extensively the software requirements and having verified them,
the next step would be to formulate a development plan. Since this is a large-scale client
software communicating with external systems via different interfaces, a spiral model
shall be very effective for the development. The spiral model, originally proposed by
Boehm, is a software process model that combines the iterative nature of prototyping
with the controlled and systematic aspects of the linear model. Using this model the
software shall be developed in a series of incremental releases or phases. During the
initial stages, the software might be a paper model or a prototype that may not be
complete. During the later stages, increasingly more complete version of the software
shall be produced.
The advantage of this model includes the capability to assess both technical and
management risks associated with the software. It also allows establishing a more
effective communication between the developer and the customer. This is a prime factor
with respect to this thesis. This communication with the customer shall remain the vital
source of information and shall constitute to changes even during the last iterations of
development and testing. This software for the telemedicine and the health care industry
has high chances of the requirements being added or removed. Hence the spiral model
75
shown in Figure 5.1 shall be the best method for development.
Figure 5.1: Spiral Model
76
The duration of various stages of the software development process till date has
been shown in the Gantt chart in Figure 5.2.
Figure 5.2: Gantt chart
The software development plan would be complete with the description of the
human factors related to various stages of development such as the man-hours and the
total time required for successful completion of each phase of development. These details
are described in the table shown in Figure 5.3
Figure 5.3: Estimated Man-Hours for development of product.
77
An architecture level description of the software to be developed is based on the
context diagram shown in Figure 3.1. Considering the interactions with external entities
the software shall basically comprise of the following modules:
1. GUI Module (includes Login part)
2. Database Module, interacting with authentication, clinical and hospital databases.
3. Real-Time Patient-Monitoring Module, handling real-time communication.
4. Mobile-User Module, interacting from an ambulance to the emergency room.
The login part of the GUI module would be the one that interacts with the user and
shall process the username and passwords and provide the user with appropriate
messages based on the results of the login operation. It shall communicate with other
parts of the GUI module to display the messages if the logon was unsuccessful and why.
This module shall have the capability of restricting unauthorized users by deactivating the
system when an invalid username or password is entered more than three times. The
system administrator could bring the software back to the working condition. The user
profiles (Doctor, Other or Patient) and the databases for which access is sought (Clinical
DB or Hospital DB) shall be selected using this module. Based on these options and a
successful login, this module shall provide access to the required databases. This module
shall communicate with the authentication database via the database module to ascertain
whether the user is authorized or not. The GUI module shall be programmed to
communicate with the login, database, real-time patient-monitoring module and the
mobile user module. The GUI module shall process the data displayed by these modules
and provide user-friendly displays and messages to the user.
78
The database module shall communicate with 3 databases. The first database to be
communicated by this module shall be the authentication database. This database
contains all the authorized usernames and passwords of all users and shall be used for
authentication purposes. The other two databases to which the software shall
communicate via this module are the Clinical DB and the Hospital DB. This module shall
provide the capability to conduct a search operation on the Clinical and Hospital
databases based on the patients name and display the appropriate results. This module
shall communicate with the GUI module for display of the results.
The real-time patient-monitoring module shall provide the capabilities of obtaining
the output from devices like the digital thermometers, sphygmomanometers and
electronic drug-flow meters via sockets. This module via a bus and socket programming
shall read the output from the sensors attached to every one of these devices. This module
shall communicate with the GUI module for display of appropriate results.
The mobile-user module shall be programmed to provide the capabilities of reading
the data output from the sensors of devices like the digital thermometer,
sphygmomanometer and electronic drug-flow meter and shall communicate with the
database module in order to transfer the information from the mobile user’s computer to
the hospital database. This module shall also communicate with the login module in order
to authenticate users and grant access to the authorized databases. Note: The devices from
which the output is sought shall be present in the ambulance itself.
79
A graphical representation of the architectural design is shown in Figure 5.4.
Figure 5.4: Architectural Design
80
CHAPTER SIX: CONCLUSION
One of the major problems faced by the telemedicine industry is to get fast access
to the required data, which most of the times is high in volume, at a required place at a
required time. Doctors have problems in accessing the data from their desktops and have
to rely on secondary resources like fax machines. These issues were addressed by this
thesis, which discusses a comprehensive solution to the problem. The detailed software
requirement specification of the proposed system has been developed and some issues
associated with the design, such as security and data compression have been addressed.
Since the communication between the various points of this system is based on a virtual
private network, it has been addressed in the software requirements. The requirements
were put thorugh rigorous validation procedures such as walk-through, inspection, test
for consistency and completeness etc. The errors were corrected and missing
requirements were added to the existing set, to make sure the outcome is a
comprehensive solution to the problems faced by the telemedicine industry. An
architectural design and a development plan have been proposed as the next step.
The software requirements have been developed in such a way to facilitate
handling future enhancements. For example, other components could be added to the
system, such as an ambulance. Further research could be done on how all the medical
records pertaining to an individual could be loaded on to a microchip embedded on a
81
small plastic card similar to a credit card. This will help paramedics access the medical
history of the individual during an emergency. Though this technique provides a leverage
of easy access to medical records, it has the disadvantages of the individual losing the
card with such valuable information on it or forgetting the card while traveling.
82
LIST OF REFERENCES
1. S. Karnouskos, “Supporting nomadic users within virtual private networks”, 128-
133, IEEE Journal, 2000
2. R.Younglove, “Virtual Private Networks – how they work?”, Computing & Control
Journal, PP. 260-263, Dec 2000
3. L. Taylor, “ VPNs are hot, but what are they?”, Intranet Journal, 2000
4. S. Patton et. al., “A layered framework strategy for deploying high assurance VPNs”
199-202, IEEE 2000
5. P. Ferguson, et. al., “ What is a VPN?”, Revision April 1 1998,
http://www.employees.org:80/~ferguson/vpn.pdf
6. A. Zhao et. al., “Research on Tunneling techniques in virtual private networks”,
691-697, IEEE 2000
7. A. Emmet, “VPNs: Very profitable networks”,
http://www.americasnetwork.com/issues/98issues/980501/980501_vpn.html, May 1998
83
8. H. Antonopoulou et. al., “ A service oriented standardized system for virtual private
networks”, Computer Systems and Applications, 360-366, ACS/IEEE International
Conference, 2001
9. S. Karnouskos et. al., “ Space oriented virtual private networks”, 33rd Hawaii Intnl.
Conference on System Sciences, 1-9, 2000
10. R. Bell, “Virtual Private Networks: The major issues, problems and opportunities”,
IEEE, 1993
11. J-P. Redlich, “Virtual Networks on the Internet”, PP. 108-114, IEEE Journal, 1999
12. R. Isaacs, “Light-weight, dynamic, and programmable virtual private networks”,
IEEE Openarch 2000
13. W. Webb, “Advanced Telecommunication Services”, Smith System Engineering Ltd,
Guildford, 2000
14. D. Fowler, “ Virtual Private Networks: Making the right connection”, Morgan
Kaufmann Publishers Inc., CA, 1999
15. S. Bowens, “Implementing Virtual Private Networks”, McGraw-Hill, NY, 1999
16. C. Scott, “Virtual Private Networks”, Cambridge O’Reilly, 1999
84
17. White Paper, “IPSec”,
http://www.cisco.com/warp/public/cc/techno/protocol/ipsecur/ipsec/tech/ipsec_wp.htm,
2001
18. White Paper, “Network Management Solutions for IP VPN Services”,
http://www.cisco.com/warp/public/cc/pd/nemnsw/ipvpn/tech/nmvpn_wp.htm”, 2001
19. M. Takizawa et.al., “Telemedicine System using computer tomography van of high-
speed telecommunication vehicle” IEEE Transactions for Information Technology in
Biomedicine, Vol. 5, No. 1, March 2001
20. B. Woodward et.al., “Design of a Telemedicine System Using a Mobile Telephone”
IEEE Transactions for Information Technology in Biomedicine, Vol. 5, No. 1, March
2001
21. M. Moore, “Elements of success in Telemedicine projects”,
http://www.clt.astate.edu/mmoore/elements.htm, 2000
85
top related