Software DesignTeam G

Class Diagram –B.D.The software design for the mobile component of the project will follow a model view controller (MVC) design. In this case the model will encapsulate the disease, fitness and dietary information of the user. Though it will not store the specific information, it will have the methods to interact with the server and retrieve the data to relay it to the view. The view will be the user screen specific to the model that will allow for easy user interaction. The motivation of the MVC pattern is to make the model independent from the views. This allows the interaction of the application with the server to be independent and isolated to the model which contains access to the information. In the future, if any changes are made to the interaction of the model with the server, the view can remain unchanged. This abstraction allows for a greater maintainability of the code by separating the server interaction from the model that stores the data and the user interface. This is aided with the use of the observer pattern. The observer class will provide a mechanism to alert other objects of state changes without introducing dependencies on them. The individual views implement the observer interface and register with the controller. When a view changes, the controller will be notified and make appropriate adjustments to the information the model has to access and display the appropriate modified or new view with the updated data. In this way, every time the user moves to a new page or refreshes a page, she/he will view the most up to date information. This will also make different views of the same data possible, for example if the user would like a pie chart versus a table to view data.

The models will also have a mediator class that will observe and control interactions within the model class and subclasses. The main model class will have three subclasses, each built to access data applicable to the three major components of the project: Fitness, Disease, and Diet. Due to our need to implement specific data for specific diseases, the DiseaseModel will have four subclasses, one for each disease. Also, each disease will know how to access and submit its specific data to the database using the secure server compatible with Microsoft HealthVault. This will make the addition of any new diseases very simple. Similar to the already existing diseases, the specific disease model will be registered with the mediator.

The mediator is responsible for handling all communication from the models. One major goal of the design for understandability and simplicity is to eliminate redundant information. This is why the disease is separated from the diet and the fitness models. Almost all of the diseases require information from these two categories and to repeat entering the information would be both tedious to the user and redundant for the programmer. Instead, the mediator will keep track of what information is required from each model and inform the controller appropriately. Therefore, for a patient monitoring both obesity and asthma, the information in the models will interact appropriately. Diet and carbs will be handled in the dietModel, fitness will be handled in the exerciseModel and the blood glucose will be handled in the DiabetesModel, which is a subclass of DiseaseModel. However, all the information can be accessed together for

an overall health view using the mediator, which will know of all the models and will be able to retrieve the appropriate information using those models for the controller.

The controller will act as an intermediate between the models, which access and push the information to and from the server, and the view, which will display the information and interact with the user. The controller will interact with the mediator to pass data to and retrieve requested information from the appropriate model. The model never actually saves or stores the information, it simply knows how to accesses and push data to the server to eliminate security involved with storing any personal data directly on the device. The controller will also be responsible for navigation between views, and, as explained above, will be notified of requests through the observer. Therefore, when a new DiseaseModel is added, it will be registered with the mediator, controlled by the controller and then displayed using a specific view evoked by the controller to display the appropriate information.

Figure 1: Class Diagram

Entity-Relationship (ER) Diagram (Figure 1.5)– J.RThe ER diagram is subject to change after digging a little deeper into the interaction of

both new applications provided by Alberto. There is a definite use of a MySql database via the HVMLS service for provider information but its real structure is unknown at the moment. The ER diagram shown below (figure 1.5) is still the closest diagram representing the database that we believe is accurate. If there are any changes, they will not be very different. The biggest change will be the organization of tables and the introduction of more roles other than just Physician and Patient. There are also more roles for the provider that define their specialty as a doctor and therefore can see different set of patients.

The relational model starts with the user as a central entity. The user logs into an account that contains their userID as their primary key, username and password, their role, and HealthVault login credentials. The role specifies whether the user is a patient or a type of provider. The userID will provide the ability for the tables to interact with one another and keep patient and providers tied to each other. It will also serve as an identifier for each user’s security rules.

When the user logs on and is a patient, the system will search all the physicians that the user is sharing information with and display it on their settings screen. If the user is a provider, then the list of patients will appear on their main screen with options to request further information about each patient. The provider app uses the database to look up the stored patient id and record ids.

The patient will be able to search for physicians he/she can add to their shared list. Once information is shared, figure 1.5 shows that the patient can share with N amount of providers, while the providers can have access to N amount of patients. It is also important to add that every user must have an account with a UserID and supporting information.

Permissions are also a big part of keeping the security aspect of PHA a priority. Although Alberto handles most security aspects, the team needs to implement the sharing function on the patient application and therefore the permissions. Each patient will have the permissions that tells the view and controller what information to show the providers. These permissions can only be changed by the patient.

Figure 1.5: Entity-Relationship Diagram

Patient - provider mapping can be seen at http://cicats9.engr.uconn.edu:14080/HVMLS/help, which is an extension of the middle-layer service and acts as a RESTful API (representational state Transfer). Using HTTP request operations, the applications can have GET and POST information with simple JSON URLs.

Most importantly, it interacts with the database is a closer way by being able to get the full list of providers or patients, as well as add or remove from the lists.

Patients can listed by provider ID and Role ID, and the list of providers can be obtained by Patient ID. The role IDs can also be manipulated in much the same way. This is important to be able to have sharing capabilities within the applications, namely the provider.

Activity Diagram -W.L. (Patient App)

Figure 2.1: Patient Activity Diagram

This activity diagram describes how the user is likely to use the application. To start, they would either create an account for new users or login for returning users. Once logged in, the main menu would appear allowing the user to accomplish different tasks. The profile screen would allow the user to view basic information about their health. The settings screen would allow the user to change personal information including permission settings. The Daily Activities screen allows the user to input data to be uploaded into the Microsoft HealthVault. The data from the database can then be used to display data about individual diseases. The Medication center gives the user information about their medications including instructions and daily dosage.

Activity Diagram - Wei Lin (Provider App)

Figure 2.2: Provider Activity Diagram

This activity diagram shows how the typical provider/doctor is likely to use the provider PHA application. Typically, the provider will enter enter in their login information which contains a username and password. After logging in, the provider will be able to go to a list of all of their patients who are using the patient PHA application. From this list, the patient can search for a patient by different categories. The provider would then be able to view different aspects of the patient’s health. This includes different types of conditions, allergies, medications, procedures, and lab tests. The provider can also view the patient’s wellness which includes energy, happiness, comfort, mobility, and appetite which are rated by one to 1 to 10.When viewing the patient’s current conditions, the provider can view health data history to determine if action needs to taken. If it does, then the providers can notify/give feedback to the patient through the application. The Provider can also view/edit allergies, medical procedures, and lab tests as well as view the wellness of the patient. The provider can also check-up on other patients in a single activity by going back to the patient list at anytime.

PHA State Diagrams –C.C.

(Patient Version)Initial State: (Fig. 3)

When the patient starts the application, the login screen will be shown initially. The patient then chooses one of the three options: Create Account, Log-in, or Quit. The Login Menu will let the patient enter account name and password. When they press “Log In”, it goes to the main MenuIf the patient chooses to create account, he/she setups a PHA Account first, then go to HealthVault Account Selection Screen. Since MS HealthVault allows patient to use either Windows ID or Facebook to login, we also let the patient to choose which account they prefer to associate with PHA. When they are done and press confirm, the application will automatically login and show the main menu.

If the patient press “Quit” or press home button, the patient exit PHA and goes back the mobile operating system.

Figure 3: Initial State

Main Menu: (Fig. 4)In this state, the users are allow to choose one of five options from the main menu:

Profile, Medication Center, Disease Center, Daily Activity, and Settings. When the user click an option, the app will open another window that shows the chosen option. User can go back to this screen by pressing the physical back button on Android phone, or back button on the navigation bar if using iOS device.

Figure 4: Main Menu

Profile Menu: (Fig. 5)Once the patient presses “Profile”, his/her personal information and the medications they

are currently taking will be shown in this menu. The patient can change their personal info by pressing “Edit Account”, it goes to “PHA Account Edit Menu” and goes back to Profile Menu when pressed “Confirm Changes”. It also allows the patient to change their linked HealthVault account.

The center of this menu is where “Current Medications” shown. If they press one of the medicines, it directly goes to “Medications Center” and display the detail.

Figure 5: Profile

Medication Menu: (Fig. 6)It shows the details of currently displayed medicine, such as instructions, time chart, and

advice. The drop-down menu let the patient select which medicine that is going to be shown. “Take This Med” will record the current time and update the variable stored in data model. None of the above is going to other screen except “Add Medication Menu”, which goes to a menu that let you enter a new medicine.

Figure 6: Medication Menu

Disease Center Menu: (Fig.7)The disease center will also have a drop-down menu to let which disease information is

going to display. If the patient changes or update any information and press “Update”, it will record the current time and update the variable stored in data model.

Figure 7: Disease Center Menu

Daily Activity Menu: (Fig. 8)When the patient select “Daily Activity” from the Main Menu, it goes to “Daily Activity

Menu”. In this menu, the patient can choose a sub-menu “Diet & Nutrition”, “Exercise”, and “Daily Measurement”.

“Diet & Nutrition” menu shows the patient’s diet chart and nutrition intake. He/She can directly updates diet info on the screen without going to other menu. “Exercise” shows the fitness information and let patients update their fitness info. “Daily Measurement” shows their Blood-Glucose or Peak-Flow measurement in a time chart. This submenu allows the patient to input their measurement directly.

Figure 8: Daily Activity Menu

Settings Menu: (Fig. 9)Settings menu let the patient “Edit Account”, changes “Alert & Reminder” settings, and

modifies “Access Policy”. When the patient press “Edit Account”, it goes to “PHA Account Edit Menu” which is similar to “PHA Account Creation” menu. The “Change HealthVault Account” button goes to “MS HealthVault Selection Menu” and let the patient to choose which account they prefer to associate with PHA again. “Alert & Reminder” menu let the patient ser to modifies PHA reminder settings in “Notification Center” on the Mobile OS. “Access Policy” let the patient change which providers are allowed to access a medical data the policy is associated with. Those submenus will have a “Back” button to go back to the “Settings” Menu.

Figure 9: Settings Menu

(Provider Version)Initial State: (Fig. 10)

The initial state diagram is exactly the same as the one for patient version. The provider chooses one of the three options on the login screen: Create Account, Log-in, or Quit. The Login Menu will show name and password text-field. After they enter account information and press “Log In”, it goes to the Main Menu.

If the provider chooses to create account, he/she setups a PHA account. Notice that MS healthvault only support patient account, therefore, our Middle Layer Server holds the provider account system. When they are done and press confirm, the application will automatically login and show the main menu. If the provider press “Quit” or press home button, the provider exit PHA and goes back the mobile operating system.

Figure 10: Initial State

Main Menu: (Fig. 11)The Main Menu will show the provider’s personal information by default. The main

menu (or the window) has a Tab Group at the bottom if using iOS device (at the top if using Android operating system). The tab group only has two tabs. One is the currently shown screen “Provider Account Information”. The other one is “Patient List”. The provider can switch between those two by clicking the tab.

Provider Account Information only show the account information so it only has one screen.

Figure 11: Main Menu

Patient List: (Fig. 12)The patient list screen shows a list of patient. The screen also has a search bar beneath the

tab group that let the provider search for a patient by his or her name. Once the provider clicks

on a patient’s name, the app opens a window that contains all the personal health information about the selected patient. Under the personal information section, there are four buttons: “Diabetes Monitor”, “Asthma Monitor”, “Blood Pressure Monitor”, “Obesity Monitor”. The app opens an monitor screen when the provider clicks the corresponding button.

We are currently focusing on the design of diabetes model on both provider version and patient version. Other designs of disease model will be finished in the future.

Figure 12: Patient List

Diabetes Monitor: (Fig. 13)Diabetes Monitor Screen fetches the glucose measurement history and insulin intake

history from MS HealthVault through Middle Layer Server. In PHA patient version, this screen gives the patient suggested insulin amount next time he or she needs to take. The provider can adjust the insulin amount algorithm by sending a corrective factor (we call it “c value”) to the patient’s PHA through Middle Layer Server.

The provider enter the c value in the “C value” text-field, which is under the glucose measurement history section, and send the C value by clicking “Send”.

Figure 13: Diabetes Monitor

Sequence Diagram- Patient Application (Linh Nhan) A patient using the PHA App will be able to follow a sequence of steps when using the

application. Figure 10 begins by showing that the patient will have the option to open the application and close the application. When the patient chooses to open the application, they will be directed to the log in screen where they will be able to log into the system using the credentials they already have or sign up for an account if they are not registered yet. From Figure 10, it is shown that the paths differ slightly in the beginning, but the destination, the main menu and the actions that can be performed, are the same. These just reflect the different choices the user can make when entering the system and then the steps that can follow. When logging in with existing credentials, the patient is directed to the main menu screen upon successful log in. If the patient chooses to sign up for an account, they will be able to choose to create an account using a Windows ID or a Facebook ID. When a choice is made, the user will then create the account where they will be able to fill out relevant information pertaining to the account such as their name as well as the health issues pertaining to them. After filling in the appropriate information, the patient, when they are done confirming the information in the account, will be directed to the main menu screen. This is the part in Figure 10 that the patient, no matter which step they chose in the beginning, will be performing the same actions. Each of these tasks can be performed one at a time by the patient. For example, the patient can choose to go to any of the following screens: Profile, Medication, Disease Center, Daily Activity, or

Settings where they will be able to view and edit the information on these screens as they see fit. Of course, he/she will only be able to edit one of these at a time. For example, the patient will not be able to simultaneously edit their daily activity and the medication they are taking. When the user has finished editing or viewing the content they wish, they will then close the application, which will return them to their phone or tablet’s home screen.

This sequence diagram was based off of the state diagram that shows what the user is able to do, but it shows the sequence that the actions can be performed in. Furthermore, it only shows the action of one user versus what can be done simultaneously by other users such as what is displayed in our activity diagram. For example, the user, before being able to view their profile or medications, must be able to successfully log into the application first. Figure 10 shows the beginning steps of a patient using the application up until the patient chooses to close the application. Figure 11 represents the sequence diagram for the provider. There are slight differences in capability or what the provider is able to do as opposed to the patient when using the application.

Figure 10: Sequence Diagram for Patient using Med App

Sequence Diagram- Provider Application (Linh Nhan) Figure 11 depicts the actions that the provider is able to perform when using the application. Similarly to the patient, the provider can open and close the application. When they open the application, they will be directed to the log in screen where they will have the option of logging in with their existing credentials or to sign up for an account if they are new to the application. When the provider signs up for an account, they will be directed to an account creation screen where he/she will have to fill out their account information. Once they confirm their account, they will be directed to the main menu, which is where a provider, who logs in with existing credentials, will be when they successfully log in. From Figure 11, it is shown that the actions of new providers and returning providers will be the same; they will be able to view the patients they have. New providers may or may not have patients in their list depending on their interactions with their patients and if they have already shared information. After viewing the patients, the provider will have the option of viewing and managing the information on specific disease pages relevant to the patient. For example, the provider will be able to view the Diabetes status of their patient. When they view the information, they will be able to make recommendations and changes as necessary; once the provider chooses to save the changes, a message will be sent to the user as well as a successful message returned to the provider. The things that the provider will be able to manage and update will be dependent on the disease of the respective patient they are viewing. When the provider is done tending to the patients, they will then close the application, which will direct them to the respective screen on their phone or tablet. Figure 11 is also based on the corresponding state diagrams for the providers since the actions they are able to perform are depicted in both diagrams. In Figure 11, the sequence or order of the actions the user is able to perform are displayed to show the progression the provider will follow when using the application to care for their patients.

Figure 11- Sequence Diagram for Provider using Med App