UNIVERSITY OF CENTRAL FLORIDA
UNIVERSITY OF CENTRAL FLORIDA
THESIS 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. Bauer
Committee Member
Ronald Eaglin
Committee 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. Bishop
Vice 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.
REQUIREMENTS ANALYSIS OF APPLICATION SOFTWARE FOR TELEMEDICINE AND THE HEALTH CARE INDUSTRY
by
SENTHILNATHAN SUNDARAM
B.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 Florida
Orlando, Florida
Summer Term
2002
© 2002 Senthilnathan Sundaram
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.
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.
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.
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
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
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
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
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.
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.
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.,
• 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.
[pic]
Figure 1.1.1: General users of the Hospital Server
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
[pic]
Figure 1.2.1: Common methods used by road warriors
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.
[pic]
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.
[pic]
Figure 1.2.3: VPN for road warriors using L2TP
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.
[pic]
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.
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
[pic]
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.
[pic]
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.
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.
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.
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:
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.
[pic]
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.
[pic]
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.
[pic]
Figure 2.3: From the ambulance to the doctors’ in the ER
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.
[pic]
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.
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.
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
• 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
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
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
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.
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.
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.
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. Depending on the selection of the ‘doctor’ or ‘patient’ radio button shown in Figure 3.2.2, the software shall apply respective access procedures.
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.
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.
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
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.
8. The software shall accept a combination of letters and numbers and ‘_’ up to a maximum of 7 characters as a valid username.
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.
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.
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.
Figure 3.2.11: Dialog box for unsuccessful login
12. The software shall exit in response to a click on the CANCEL button shown in Figure 3.2.11.
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.
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
15. The software shall exit in response to a click on the OK button shown in Figure 3.2.14.
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
Figure 3.2.16: Search Request
17. The software shall use the directory and file formats identical to the ones in the Windows and Linux operating systems.
18. The software shall exit in response to a click on the CANCEL button shown in Figure 3.2.16.
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.
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
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
Figure 3.2.21: Dialog box for an unsuccessful search
22. The software shall respond to a click on the RETRY button shown in Figure 3.2.21 by displaying the screen shown in Figure 3.2.16.
23. The software shall exit in response to a click on the CANCEL button shown in Figure 3.2.21.
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.
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).
Figure 3.2.25: Display after opening a data item.
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.
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.
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.
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.
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.
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.
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.
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.
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.
35. The software shall allow the user to make 3 attempts to logon unsuccessfully, after which it shall display, the message shown in Figure 3.2.14.
36. The software shall exit in response to a click on the OK button shown in Figure 3.2.14.
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.
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.
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 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.
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.
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.
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.
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.
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
Figure 3.2.45: Display for saving changes
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.
46. The software shall exit in response to a click on the CANCEL button shown in Figure 3.2.45.
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.
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’
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
• Send/Receive & Hospital DB
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.
51. The software shall exit in response to a click on the CANCEL button shown in Figure 3.2.48.
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.
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.
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.
55. The software shall allow the user to make 3 attempts to logon unsuccessfully, after which it shall display the message shown in Figure 3.2.14.
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.
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.
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.
[pic]
Figure 3.2.58: Office Visit Form
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
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
[pic]
Figure 3.2.60: Error Message for unauthorized use
61. The software shall exit in response to a click on the OK button shown in Figure 3.2.60.
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.
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.63a The software shall not allow the prescription shown in Figure 3.2.63 to be edited.
[pic]
Figure 3.2.63: Previous Prescription Display
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.
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.
[pic]
Figure 3.2.65: Display while printing is in progress
66. The software shall cancel the print job, in response to a click on the CANCEL button shown in Figure 3.2.65.
67. Upon completion of the print job, the software shall display the screen shown in Figure 3.2.63.
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.
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 [pic]
Figure 3.2.69: Screen to view Previous Diagnosis Code
70. In response to a click on the OK button shown in Figure 3.2.69, the software shall redisplay the Office Visit Form shown in Figure 3.2.58.
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
[pic]
Figure 3.2.71: Display to create a new prescription
72. In response to a click on the OK button shown in Figure 3.2.71, the software shall redisplay the Office Visit Form shown in Figure 3.2.58.
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.
74. In response to a click on the PRINT button shown in Figure 3.2.71, the software shall print a copy of this new prescription to the default Printer
Note: Refer the Requirements 3.2.65 through 3.2.67 for more information about the printing procedure.
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.
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.
77. In response to a click on the PRINT button shown in Figure 3.2.58, the software shall print a copy of this Office Visit Form to the default printer. Note: Refer the Requirements 3.2.65 through 3.2.67 for more information about the printing procedure.
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.
[pic]
Figure 3.2.78: Special Request Form
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.
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.
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
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.
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.
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.
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.
86. The software shall allow the user to have only one Facility selected from the drop down list mentioned in Requirement 3.2.84.
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.
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.
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.
[pic]
Figure 3.2.89: Error Message for Invalid Date
90. The software shall respond to a click on the RETRY button shown in Figure 3.2.89, by redisplaying the form shown in Figure 3.2.78.
91. The software shall exit the special request form in response to a click on the CANCEL button shown in Figure 3.2.89.
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.
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.
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.
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.
96. The software shall exit in response to a click on the CANCEL button shown in Figure 3.2.78.
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.
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.
[pic]
Figure: 3.2.98: Screen to Edit the Lists
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.
[pic]
Figure 3.2.99: Error Message
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.
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.
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.
[pic]
Figure 3.2.102: Screen to ADD a name to the list
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.
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.
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.
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.
[pic]
Figure 3.2.106: Screen to ADD a facility to the list
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.
108. In response to a click on the CLEAR button shown in Figure 3.2.106, the software shall clear all the fields and redisplay the screen shown in Figure 3.2.106.
109. In response to a click on the CANCEL button shown in Figure 3.2.106, the software shall redisplay the Figure 3.2.98.
110. Upon selecting the radio button marked ‘Special Request Code’ and clicking on the ADD button in Figure 3.2.98, the software shall display the screen shown in Figure 3.2.110.
[pic]
Figure 3.2.110: Screen to ADD a special request code to the list
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.
112. In response to a click on the CLEAR button shown in Figure 3.2.110, the software shall clear all the fields and redisplay the screen shown in Figure 3.2.110.
113. In response to a click on the CANCEL button shown in Figure 3.2.110, the software shall redisplay the Figure 3.2.98.
114. In response to a click on the CANCEL button shown in Figure 3.2.98, the software shall redisplay the Figure 3.2.78.
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.
[pic]
Figure 3.2.115: Screen to REMOVE a name to the list
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.
117. In response to a click on the CLEAR button shown in Figure 3.2.115, the software shall clear all the fields and redisplay the screen shown in Figure 3.2.115.
118. In response to a click on the CANCEL button shown in Figure 3.2.115, the software shall redisplay the Figure 3.2.98.
119. Upon selecting the radio button marked ‘Facility Requested’ and clicking on the REMOVE button in Figure 3.2.98, the software shall display the screen shown in Figure 3.2.119.
[pic]
Figure 3.2.119: Screen to REMOVE a facility to the list
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.
121. In response to a click on the CLEAR button shown in Figure 3.2.119, the software shall clear all the fields and redisplay the screen shown in Figure 3.2.119.
122. In response to a click on the CANCEL button shown in Figure 3.2.119, the software shall redisplay the Figure 3.2.98.
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
[pic]
Figure 3.2.123: Screen to REMOVE a special request code to the list
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.
125. In response to a click on the CLEAR button shown in Figure 3.2.123, the software shall clear all the fields and redisplay the screen shown in Figure 3.2.123.
126. In response to a click on the CANCEL button shown in Figure 3.2.123, the software shall redisplay the Figure 3.2.98
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.
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. 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
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 |
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
[pic]
Figure 3.3.4: Comparison of ratio of compression
[pic]
Figure 3.3.5: Comparison of compressed file sizes
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.
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.
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.
[pic]
Figure 3.5.1: The transmission end of the proposed system
[pic]
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 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.
[pic]
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 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.
[pic]
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.
[pic]
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 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.
[pic]
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.
[pic]
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 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.
[pic]
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.
[pic]
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 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.
[pic]
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.
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 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:
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 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.
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.
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?
• 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?
• 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 |
| |CRITERIA |ACTION NEEDED |
| |FAILED | |
|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 replaced by redisplay. |
|3.2.16 |Clarity |The word ‘option’ should be replaced by the phrase |
| | |‘radio button marked ‘Doctor’ in Figure 3.2.2’. |
|3.2.16 |Consistency |Inconsistent with Requirement 3.2.5. Change the |
| | |statement accordingly. |
|3.2.17 |Completeness |The file and directory formats are used for what? |
| | |Should state that similar formats are used for |
| | |storage and display. |
|3.2.20 |Correctness |The term ‘this patient’ is misleading. The |
| | |requirement should be more general. |
|3.2.20 |Clarity |A replacement for the term ‘this patient’ shall be |
| | |‘pertaining to the patient whose name was entered in |
| | |Figure 3.2.16.’ |
|3.2.22 |Correctness |The word ‘display ‘ should be replaced by redisplay. |
|3.2.24 |Correctness |Replace ‘this date’ with ‘that date’. |
|3.2.25 |Completeness |The term ‘current date ‘ is 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 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 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.
1. The software shall start execution in response to a double click on an icon.
2. Upon startup, the software shall prompt the user to login by displaying the screen shown in Figure 3.2.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.
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.
13. The software shall respond to a click on the RETRY button shown in Figure 3.2.11 by redisplaying the login screen in Figure 3.2.2.
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.
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.
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
21. The software shall respond to a click on the RETRY button shown in Figure 3.2.21 by redisplaying the screen shown in Figure 3.2.16.
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.
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.
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.
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.
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.
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.
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.
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.
56. Upon a successful logon, the software shall display the screen shown in Figure 3.2.25.
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.
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 shown in Figure 5.1 shall be the best method for development. [pic]
Figure 5.1: Spiral Model
The duration of various stages of the software development process till date has been shown in the Gantt chart in Figure 5.2.
[pic]
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
[pic]
Figure 5.3: Estimated Man-Hours for development of product.
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.
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.
A graphical representation of the architectural design is shown in Figure 5.4.
Figure 5.4: Architectural Design
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 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.
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,
6. A. Zhao et. al., “Research on Tunneling techniques in virtual private networks”, 691-697, IEEE 2000
7. A. Emmet, “VPNs: Very profitable networks”, , May 1998
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
17. White Paper, “IPSec”, , 2001
18. White Paper, “Network Management Solutions for IP VPN Services”, ”, 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”,
, 2000
-----------------------
[pic]
[pic]
[pic]
[pic]
[pic]
[pic]
[pic]
[pic]
[pic]
[pic]
[pic]
[pic]
[pic]
[pic]
[pic]
[pic]
................
................
In order to avoid copyright disputes, this page is only a partial summary.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related searches
- university of west florida careers
- university of west florida employment
- university of west florida job openings
- university of west florida jobs
- university of west florida human resource
- university of south florida hospital
- university of west florida hospital
- map of central florida cities and towns
- university of south florida map
- university of south florida campus map
- map of central florida counties
- university of south florida college of medicine