design_phase3.txt

The application uses the MVC Design Pattern. The Model would be implemented using objects with a SQLite database backend. The rendering would be implemented via Android GUI. The relational database will allow easy and fast access to the data and enforces business rules using constraints, and relationships. 

The Object Model consists of the following Objects:
- User is an abstract class to hold features common to any user of the app (username).
- Nurse is a subclass of User which contains functionality unique to the Nurse role. It contains methods that are wrappers for methods implemented in ERAdmin that allows to maintain, manipulate and save data.
- Physician is a subclass of User which contains functionality unique to the Physician role.
- UserManager is used to authenticate user credentials and return the User object based on User role. On the first launch of the app, the passwords.txt file will be read and written to the database.
- VitalSigns holds a single instance of vital signs taken (including timestamp).
- Prescription holds the information for a medication prescribed by a Physician.
- ERVisit is a container for all information and data relevant to a Patient's single ER visit. It contains the ER arrival time, health card number of Patient, time when Patient was seen by the doctor, and isClosed attribute used to identify visits that are resolved. It stores an ArrayList of VitalSigns, and an ArrayList of Prescriptions. The ArrayList data structure will keep the records in order since the most recent record will be appended to the end of the list, and allows easy access to the latest record. 
- Patient holds the patient's personal information and current ERVisit. It is used to access patient information and update the patient's current ER visit.
- ERAdmin is used to maintain a directory of Patients. It works like a general controller of the data model in the system. It provides functionality to look up a Patient, sign the Patient in the ER (new ERVisit), record a Patient's vitals or presrciptions (by accessing a Patient's current ERVisit object and using functionality provided in ERVisit), set the date-time Patient is seen by the doctor, and retrieve a Patient's medical record. Every time a new set of vitals is added, the urgency of the Patient is updated. "Close Case" is used to remove a patient from the current Patient lists in the case when the patient is dismissed from the ER. It sets the Patient's current ERVisit object to null, and removes the Patient from the current Patient lists. ERAdmin is responsible for saving all of its information on current patients in the database everytime new information is added or updated. On the first launch, ERAdmin will read the patient_records.txt file and write its content to the database. ERAdmin contains the following data structures:
    • "PatientList" is a HashMap that maps health card numbers of patients to the corresponding Patient object. A HashMap allows instant access of Patients by health card number key. 
    • "urgencyList" is an ArrayList of Patients ordered by urgency. The ArrayList will keep the patients in order, allow iteration over the list, and allow removal of a single Patient either on dismissal, or when they are sent to the doctor.
    • "patientsSentToDoctor" is an ArrayList of Patients sent to be evaluated by a physician. Again, an ArrayList was chosen here to allow iteration over these Patient objects, append a Patient sent to the Physician, and remove a single Patient on dismissal. 
- DBAdapter encapsulates the connection to the database. It will create the database when the app will be launched for the first time and maintains the connection.
- TriageDBAdapter is a subclass of DBAdapter. It contains all CRUD operations necessary to maintain the database.

The database would contain tables for all data-related objects described above with Foreign Keys that enforce the relationships between the tables according the application business logic. The constraints will enforce the uniqueness of certain fields as well as set default values where required. The schema is presented in the "Database Schema.png" file.

The GUI will consist of the following screens:
- A Login screen which the user will use to enter their credentials. The login screen will contain a link to a Help page.
- A Nurse Screen will display a list of current patients by urgency, and a list of patients sent to the doctor. The lists will be used to redirect users to the Patient Screen. It will also have navigation buttons that allow the Nurse to search for a patient, look up a Patient's medical record, and add a new Patient. The screen will be available only for Users with Nurse credentials.
- A Doctor screen will display a list of patients sent to the doctor. The list will be used to redirect users to the Patient Screen. It will have navigation buttons that allow the Physician to search for a patient and to look up a Patient's medical record. The screen will be available only for Users with Physician credentials.
- A Patient screen will present Patient information, Patient's current visit details and will have a list of VitalSigns and Prescriptions (available only for Physicians). It will also have navigation buttons that will allow the user with corresponding credentials to sign in a Patient (Nurse), sign out a Patient (Nurse and Physician), view Medical History of the patient, add new vital signs (Nurse) and add a new prescription (Doctor). 
- A Medical Record screen displays a patient's medical history as formatted text.
- The following screen exist for user input: Vital Signs screen, Prescription screen, New Patient screen.
- ListFragments will be used to display lists of Patients, VitalSigns, and Prescriptions. Dialog windows will be used for searching patients. Tabs are used to navigate between different fragments. On the Action Bar, icon buttons are used for navigation.