Reference no: EM132312154
Web Application Assignment Details
B(i) - Background information and description
This assignment is an extension of the work you completed in Practical Set 1 for Glebe Family Medical Practice.
In this assignment you will create a simplified web-based Intranet application to support the work of the reception and medical staff in Glebe Family Medical Practice. This Intranet application will be referred to as the Patient Record Application (or PRA). PRA will be used by reception staff to register new patients in the practice, and medical staff (doctors and nurses) to maintain medical history for patients. This is a very simplified system and leaves out many aspects that would be required in a real system for a general practice. Read the Functional Requirements section (section B(ii) of this document) to determine what is specifically required for PRA. The MySQL database that supports the functionality of PRA is named generalPractice. The generalPractice database is described in section B(iii) of this document. You will need to design and create the PHP web pages for this assignment.
B(ii) - Functional Requirements
PRA must
a) be coded using HTML 5, CSS, JavaScript, and PHP as necessary. Note: all four files described below must be PHP files to achieve the server-side functionality.
b) provide easy-to-use navigation for the user as described in the following page descriptions.
c) provide the following page content and functionality for each page as described.
Employee login page (login.php).
Page purpose/description:
The purpose of this page is to provide a login facility for employees of Glebe Family Medical Practice that need to use PRA. No other pages within PRA will be accessible unless the employee has successfully logged in first (see Implementation Note below).
Page content:
The page will have the following content:
1. the following text:
Glebe Family Medical Practice Patient Record Application
Note: This Intranet Application is for the use of employees of Glebe Family Medical Practice only. Patient information accessed via this system is private and confidential. Staff logging into this system are reminded of their legal responsibility to maintain patient confidentiality at all times. Information stored within this system may not be shared with external entities without the consent of the treating doctor. By logging into this system, I agree to be bound by this requirement.
2. An HTML login form which contains
• a text box to capture the employee ID
• a password box to capture the employee's password
• a submit button
3. Appropriate design and instructions for the staff member
4. The provision for displaying error messages as detailed below
Page functionality:
The login page will
1. need to use postback (submit to itself),
2. authenticate the employee credentials (employee id and Password) as supplied by the employee in the login form against the records in the staff table of the generalPractice database
3. allow or deny access to the subsequent pages of PRA depending on the result of authentication as follows:
a. Successful login attempt: Successful authentication should automatically redirect the employee to the Find Patient (findpatient.php) page.
b. Failed login attempt: Unsuccessful authentication should automatically redirect to the login page so that the employee may try to login again. An appropriate error message must be displayed to the employee if the login attempt fails or if the employee tries to access any of the protected pages of PRA. The message display must be implemented using appropriate PHP server-side code; it is not to be a JavaScript alert (or any other browser side component). The message should be displayed in an appropriate location on the login page in a suitable colour. The message must appropriately indicate the problem that caused it to occur.
Employee Login Credentials:
The passwords that are stored in the staff table of the generalPractice database are encrypted using the sha256 algorithm. A list of employee ids and (decrypted) passwords can be found in the Employee Credentials document.
Site Navigation:
The login page will have no direct hypertext links to any other pages of the system. Access to PRA is only possible after successful login.
Find Patient Page (findpatient.php).
Page purpose/description:
This page will act as a search page to find patient records. The logged-in employee will be able to enter key information about a patient in a search form to locate the patient's record within PRA. The employee will then be able to choose a specific patient record to view from the search results.
Page content:
The page will have the following content:
1. Navigation to the other pages of PRA as appropriate including a Log Off link (this link must run the logoff.php page).
2. current server date
3. logged-in employee name
4. An HTML form (the search form) which contains
• a text box for the Patient Surname (mandatory field)
• a text box for the Patient First name
• a text box for the Patient Suburb
• a text box for the Patient Phone number
• a submit button
As indicated above the only field that is mandatory in the search form is the Patient Surname. That is, a search may be performed on the basis of the surname of the patient only. However, this may result in many matches in the database, so any of the other fields may also be entered by the employee to reduce the number of matches to assist the employee to find the patient record more quickly.
5. A search results (Patient List) section that lists patient record(s) that match details from the form.
6. Appropriate design and instructions for the staff member
Page functionality:
The Find Patient page will
1. validate that a Patient surname has been entered in the search form (using client-side JavaScript)
2. use postback (submit to itself) for the search form,
3. search the generalPractice database for patient records that match details provided by the employee in the search form. The search may find zero, one or many matches depending upon the search terms entered by the employee. The output from the search depends on the number of matches found:
a. One or more records found: generate a summary list of matching patient records underneath the search form. The employee will be able to choose the record they want to view more detail about from this list (see point 4 below). The summary list provides the following details:
i. Surname
ii. First name
iii. Full address
iv. Phone number
v. Email address
b. Zero records found: display an appropriate message underneath the search form instead of a list of results, and provide a link to the Add New Patient page (addpatient.php). This link must only be displayed if no matches are found by the search.
4. enable the employee to choose a specific patient record for viewing from the search results list. To do this, the surname and first name of each patient in the summary list is to be a hypertext link. When clicked, the hypertext link sends the patient_id of the patient to the Patient Record (patientrecord.php) page. The Patient Record page will then display the full details of the chosen patient record (details provided below).
General Page Notes:
• The design of this page is open to your creativity but it must appropriately display all required information in a clearly readable, well organised and usable format.
• This page must only be accessible by a logged-in user. If a user tries to access this page and they are not logged in they must be automatically redirected to the logoff.php page (which redirects to the login page) and then display an appropriate error message on the login page indicating that the error has occurred.
Patient Record page (patientrecord.php).
Page purpose/description:
The purpose of this page is to display to the user the content of the chosen patient record (the choice occurs on the Find Patient page as described above).
Page content:
The page will have the following content:
1. Navigation to the other pages of the system as appropriate including a Log Off link (this link must run the logoff.php page).
2. current server date
3. logged-in employee name
4. for the chosen patient:
a. Patient Personal information: Surname, First name, Date of Birth, Address, email, phone number.
b. Past Consultations: list of each past consultation date and the diagnosis for the patient. Each record in the list will have a hypertext link to the Show Details page (details.php)
c. Consultation: This will be a form (consultation form) with the following fields:
i. Consultation date (automatically filled in with the server date)
ii. Consultation Notes
iii. Diagnosis
iv. Treatment
v. A submit button
5. Appropriate design and instructions for the staff member
Page functionality:
The Patient Record page will
1. obtain data from the generalPractice database to display the content as indicated above in points 4(a) to 4(b) for the chosen patient record. This information cannot be modified by the user. It is likely that separate sql queries will be required to obtain data from the database for 4(a) and 4(b). That is, you should not try to obtain the data using one sql query.
2. need to use postback (submit to itself) for the consultation form,
3. perform server-side input validation as follows for the consultation form:
i. Consultation date
• must have a value
• cleaned to avoid possible sql injection
ii. Consultation Notes
• must have a value,
• cleaned to avoid possible sql injection,
• may only contain alphanumeric ["0" to "9", "a" to "z", "A" to "Z"] characters, spaces [" "], hyphens ["-"], commas [","], period ["."] and exclamation marks ["!"].
Note: Error messages as a result of the above server-side validation must be displayed inline (ie, no alert boxes are to be used). Additionally, the database should not be updated if there is an error with the user input
iii. Diagnosis - cleaned to avoid possible sql injection
iv. Treatment - cleaned to avoid possible sql injection
Note: there is no client-side validation on this form
4. When the consultation form data passes the server-side validation, the details entered in the form will need to be inserted into the consultation table of the generalPractice database.
General Page Notes:
• The design of this page is open to your creativity but it must appropriately display all required information in a clearly readable, well organised and usable format.
• This page must only be accessible by a logged-in user. If a user tries to access this page and they are not logged in they must be automatically redirected to the logoff.php page (which redirects to the login page) and then display an appropriate error message on the login page indicating that the error has occurred.
Logoff page (logoff.php).
The purpose of this page is to log the employee off the system and automatically return them to the login page. The page must not display anything to the user. The page should remove all session variables and end the session (if sessions were used). It should then redirect to the login page. This page can be accessed from any of the pages as detailed above.
Show Details page (details.php).
This page does not need to exist in this version of PRA. In a more complete version of PRA the purpose of this page would be to display to the user the full details of the chosen record from the Patient Record Page. The content displayed on this page may be a record from the patient's Medical History, Medication, or Consultation information etc.
Add New Patient page (addPatient.php).
This page does not need to exist in this version of PRA. In a more complete version of PRA the page would utilise the New Patient form that you created in Prac Set 1 to add a new patient into the database.
B(iii) - Database Description
To connect to the generalPractice database use the following in your php script
$dbConn = new mysqli("localhost", "TWA_student", "TWA_2019_Autumn", "generalPractice"); if($dbConn->connect_error) {
die("Failed to connect to database " . $dbConn->connect_error); }
Attachment:- Technologies for Web Applications.rar