BTE 324 Schedule Patient Phase 2

We will design an XML file for storage of doctors and patients. This will serve as the basis for a file I/O portion of a patient scheduling system.

1) Create a new base package, as , i.e., j.doe's package should be edu.miami.cis324.hw4.jdoe.

2) Create a resources folder inside your project (outside of the src folder, that is, directly under the project itself.) This folder should hold all your XML files.

3) Create in the resources folder an XML document called schedulerData.xml that complies with the attached scheduling.xsd XML Schema. Create entries (editing your XML document directly) for all four patients and all four doctors from Assignment 3 in this document.

4) Also add to your XML document (manually) the following set of visits:

5) You can reuse the Patient and Doctor interfaces, the MedicalSpecialty enum, the PatientImpl and DoctorImpl classes, the generic Visit< V,T> interface, and the generic VisitImpl< V,T> class that you defined under Assignment 3. You will have to copy them to the new project. In this assignment, we are going to keep the doctors and patients separate, that is, a doctor will not be able to be a patient, and thus you do not need to make Doctor a subinterface of Patient (but you can if you wish). You can improve or modify your classes and interfaces if you wish.

6) Create a SchedulerData class that holds:

• A list of Patients
• A list of Doctors
• A list of Visits, where the visits refer to a patient Id, a doctor Id, and a date.

Make sure that the three lists are initialized to empty lists upon construction of the SchedulerData object. Provide methods in your class to get each of the three lists, and to add elements to each list. For example, provide a method addPatient(Patient p) that adds a patient to the list of patients. Do not provide setters for the entire lists. You can add any other methods to this class as you desire, but remember that this class is designed to hold data, not to execute complex operations (for example, you can place a toString() that return a String representation of all the lists, but do not create methods that print the entire lists to the console).

7) Create a class SchedulerXMLReaderUtils, which will hold utility methods to read the XML data. Inside this class:

a) define a static method called readSchedulingXML that:

• Takes a file name as a parameter.
• Opens for input a file as specified by the file name using a BufferedReader, and enveloping it with an XMLEventReader. If the file does not exist, throws a FileNotFoundException.
• Reads the XML contents of the XML file, populating a SchedulerData object with all patients, objects, and visits encountered in the XML file (make sure you take the ids from the XML file, instead of auto-generating them), and
• Returns the SchedulerData object.

You can define any other auxiliary methods that you may need inside this same class.

8) Create a new SchedulerXMLReadTest class, with a main method. In this main method:

a) Read the schedulerData.xml in the resources folder, using the readSchedulingXML method in your SchedulerXMLUtils class.

b) List all upcoming visits to the console output ordered by visit date. You can reuse the methods that you designed for this in Assignment 2. The format is:

Visit date:
Doctor:
Specialty:
Days until visit:
May 11, 2018
John Smith
GENERAL_MEDICINE
xx
Patient:
First name: George
Last name: Harrison
email: george@something.com
SSN: 567-39-9282
Age: 57

Extra credit

1. Use an interface called Person and an abstract class called PersonImpl to define the methods that are common to both Doctor and Patient, so that you do not have to repeat the same code in both implementations. You will have to redesign (somewhat) your inheritance hierarchy.

look-ahead

Writing out an XML file was not included in the tasks above. However, It will be part of the functionalities required for the upcoming tasks for the final project below, and so it may be a good idea for you to start creating methods to write XML files. If you do so, make a second test class and call it SchedulerXMLWriteTest.

A Full System

Now, In this project, you will use the different system components you have been building throughout the semester to build a fully integrated Patient Scheduling System that could be used by a Doctor's Office to schedule patients for appointments. You need to read the specifications below and think carefully about the design. The requirements below, reflect how you will build on the assignments you have done. However, there are even better ways to go further such as using an RDBMS and make this an internet application, etc. You are free to add these components if you wish. But only the items below are required - there is very little time, and so much to do as usual. It may be a great exercise for an independent study if you would like to take this exercise further.

Design a Patient Scheduling System with the following characteristics:

User Interface:

• Enter a new patient
  • Generate a new patient Id via an auto-increment function
  • Enter first name, middle initial, last name, date of birth, and SSN.
• Review/edit information for an existing patient
• Mark a patient as removed
  • The patient must continue to exist in the system, but he or she must not be shown in any listing or selections, his or her information must not be edited anymore, and no new visits must be scheduled for him or her.
• Restore (un-remove) a patient
  • This should be done in a separate screen, since it will have to list the patients that have been removed.
• Enter a new doctor
  • Generate a new doctor Id via an auto-increment function
  • Enter first name, middle initial, last name, date of birth, and SSN.
  • Select a specialty from a closed list of specialties (define your own specialties, or use the ones from the assignments)
• Review/edit information for an existing doctor
• Mark a doctor as removed
  • The doctor must continue to exist in the system, but he or she must not be shown in any listings or selections, his or her information must not be edited anymore, and no new visits must be scheduled for him or her.
• Restore (un-remove) a doctor
  • This should be done in a separate screen, since it will have to list the doctors that have been removed.
• Enter a new visit:
  • Select a patient from the list of existing patients
  • Select a doctor from the list of existing doctors
  • Enter a visit date and time
  • Make sure you link the patients and doctors to the visit by Id, not by name
• Edit existing visits:
  • Change date (only for visits in the future)
• Remove existing visit:
  • Remove the visit entirely from the system.
• Provide information on demand, on screen. For patients and doctors, only list their first and last names, in the format you desire. Always list the visit date and time. Tables are suggested.
  • List all visits (only for non-removed patients and doctors, if functionality implemented)
  • List all upcoming visits (only for non-removed patients and doctors, if functionality implemented)
  • List all visits for one patient (including those in the past). Allow selection of the patient from a list of patient names, but be sure to use the patient Id to look up the visits.
  • List all upcoming visits for one patient (only those in the future). Allow selection of the patient from a list of patient names, but be sure to use the patient Id to look up the visits.
  • List all visits for one doctor (including those in the past). Allow selection of the doctor from a list of doctor names, but be sure to use the doctor Id to look up the visits.
  • List all upcoming visits for one doctor (only those in the future). Allow selection of the doctor from a list of doctor names, but be sure to use the doctor Id to look up the visits.

Remember to try to reuse the same code as much as possible. In particular, note that entry and editing for patients and doctors is very similar. Try to use as much of the same code as you can to do both tasks.

Make sure that you use confirmation dialogs before storing a new patient or a new doctor, or before removing a patient or doctor.

Entry of dates can be done with any of the following alternatives:

• Enter separately the year, month, and day into three separate text boxes.
• Enter separately the year, month, and day into three separate combo boxes.
• Use a Date Picker (Preferred)

Entry of times shall be done by entering hour and minute separately in text boxes or combo boxes. Be sure to account for a 24-hour clock, or use an am/pm combo box to select. You can also use a Time Picker if you find one.

You are free to format your listings in any way you wish. Make sure that everything is easily readable. Also make sure that listings are appropriately sorted for easy understanding.

Use the MVC paradigm as much as possible to divide the tasks in your different classes.

Storage and retrieval of data:

Your system must store all patient, doctor, and visit information in XML. You can choose to either use a single XML file to store all three types of information, or you can use one XML file for each. Use XML Schema to define the nature of your XML file or files, and make sure that your XML file or files validate against your XML Schema(s).

At the start of your application, you should load all patient, doctor, and visit information from your XML file or files.

Every time a new patient, new doctor, or new visit is created, you should overwrite the pertinent file. Because you are overwriting, you need to write ALL the pertinent information:

• If you are using a single file, you need to write the entire file, that is, all the patients, all the doctors, and all the visits.
• If you are using three separate files, you need to write the corresponding set. That is, if you create a new patient, you need to overwrite all the patients, etc.

Be sure that all information pertaining to patients, doctors, and visits is stored in your XML file.

Notes:

• Data entry must be done using a Java Swing application.
• Your Doctors do NOT need to be Patients as well, you can keep them separate.