university of central floridaitech.fgcu.edu/faculty/zalewski/cen4935/projects/... · web viewfigure...

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.


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.21 by displaying the screen shown in Figure 3.2.16.


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.


after which it shall display, the message shown in Figure 3.2.14.


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.


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.


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.


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.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.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



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.


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.


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.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.


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.106.



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


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.110.





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.115.



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


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.119.



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.123.


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


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


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


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.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 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

http://www.americasnetwork.com/issues/98issues/980501/980501_vpn.html

http://www.employees.org/~ferguson/vpn.pdf

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

http://www.cisco.com/warp/public/cc/pd/nemnsw/ipvpn/tech/nmvpn_wp.htm

http://www.cisco.com/warp/public/cc/pd/nemnsw/ipvpn/tech/nmvpn_wp.htm

http://www.cisco.com/warp/public/cc/techno/protocol/ipsecur/ipsec/tech/ipsec_wp.htm

university of central floridaitech.fgcu.edu/faculty/zalewski/cen4935/projects/... · web viewfigure...

Documents