PHA Background
Background on PHA Classes
The Java Classes in the PHA are organized into a number of different categories as given in the zip file
for PHA that are in the following categories: the edu.uonn.model directory which contains the main
classes that are all aligned, designed, and implemented to support the staging of information back and
forth into Microsoft HealthVault (MSHV); the edu.uconn.pha directory which contains the set of classes
that correspond to the various parts of the graphical user interface (screens) of PHA; the
edu.uconn.server.client directory which contains the set of classes to manage the interactions between the
client (PHA) and the server (MSHV) to allow information to be retrieved, stored, and in some cases,
deleted; and, the edu.uconn.listerers directory that is used for PHA to listen for input from the user via the
PHA screens. To begin, Figure 1 contains a UML diagram for the classes that are most relevant for this
project, namely: HealthItem, Demographic, Medication, Weight, Height, ODL, Person, etc.). The classes
Role, Permission, and Policy are for access control purposes and the class ODLQuery is to allow
information on ODLs to be stored; neither of these four classes are relevant for this assignment. Note that
the naming of these classes aligns to similar naming in MSHV. Note that Appendix A at the end of this
document contains the class declarations (attributes and methods).
Figure 1. Class Hierarchy of HealthItem and Descendants.
The next set of classes in the directory edu.uconn.edu are intended to manage all of the information
associated with the PHA screens that involves both the gathering and display of the information for
medications, allergies, etc. All of these classes make use of the Android public class Activity
(http://developer.android.com/reference/android/app/Activity.html) that is used to represent the actions
that a user can do, ranging from creating a window to lower level actions.
Initial Design Project Statement
The class hierarchy headed by HealthItem is relatively restricted in its structure and modeling to mirror
the corresponding classes in MSHV to allow information to be staged from MSHV into the PHA for use
by the client. As a result, the HealthItem hierarchy is not able to capture all of the information need by
PHA in terms of demographics (identity, height, weight), medications, ODLs, and chronic disease
profiles. The intent of this project is to construct a new initial design that is more aligned to the
1
PHA Background
application domain needs of PHA and the data input/display of the mobile screens that are used, including
screens that exist, and new screens that must be added.
Defining the Scope of Data to Model
While the HealthItem class hierarchy contains some of the information needed for PHA, it is not
sufficient to capture all of the information needed to track medications and chronic diseases. However,
you can use the data defined in those classes to assist in you defining a new PHA class library that
consists of multiple class hierarchies. Note that in the discussion below, there are initial thoughts and
discussion of the domain and its breadth, but do not assume that each of the domain categories are
complete. At a high level, some of the potential class libraries could be:
1. A class library that tracks a person and his/her demographic, height and weight. This may be separate
hierarchy not linked to a HealthItem parent. How would you organize the information? How do you
potentially need to track multiple heights (for children that grow) and weights (for individuals who
may be dieting or exercising) with timestamps in order for PHA to be able to graph a patient’s
progress in either category?
2. A class library that tracks information on a patient’s exercise regime, which have a need to track
multiple sessions per day (again, necessitating time stamps). There are many potential characteristics
to track on an exercise regime. For example, the type of exercise can be varied, including: walk,
treadmill, jog, run, bike, stepper, swimming, weight lifting, tennis, golf, other sports, etc. Each of
these exercise types may have a different way to track their duration; some may be time oriented,
some may be distance oriented, etc. In some cases, there may be need to record the pulse and/or blood
pressure both before and after exercise. At a higher level, some of the classes related to Exercise may
also need to interact with the Chronic Disease classes. By tracking all of this information, graphs and
charts can be generated for both patients and providers.
3. A class library that tracks information on a patients diet and nutrition, which can be very varied and
be structured in different ways. One approach might use carbohydrates, calories, and fat. Another
approach may user servings in broad categories (fruit, vegetable, meat, fish, grain, dairy), be more
fine grained: beef, lamb, chicken/white, chicken/white/no skin, etc., or be targeted to have a patient
track something like calcium and vitamin D if the person has osteoporosis (bone loss).
4. A class library that combines observations of daily living (ODLS) as given in Figure 6 on page 12 of
http://www.engr.uconn.edu/~steve/Cse2102/Cse2102SemProjBack.pdf that included sliders for
energy, happiness, comfort, etc., with the information needed to for chronic disease management. The
intent is to rigorously collect this information on patients in order to support clinical decision support
that can generate graphs and charts for patients and providers, and in the case of a disease like
diabetes, perhaps identify a trend (glucose too high or too low) that can be addressed before it needs
hospitalization by sending email to a provider or updating the patient’s electronic health record.
Next, the different chronic diseases are reviewed to highlight the information that needs to be tracked for
patients (entered by patients). Note also that you may need to do some web searching on the chronic
diseases in order to fully explore the domain requirements.
Diabetes:
Diabetics must measure their glucose using glucometers (http://en.wikipedia.org/wiki/Glucose_meter ) on
a regular basis. These values are used to denote different things based on their interpretation. For
example when the fasting values (glucometer taken with no food for last 8 hours) are below 40mg/DL for
women and 50 mg/dL for men, these are considered too low. Also, a patient may be diagnosed with
Diabetes and have high glucose levels if glucose level at any time is >= 200 mg/dL or if a fasting glucose
is >= 126 mg/dL. Diabetes patients try to keep values above low value level and below the high value
level. This issue could be addressed by tracking glucose values over time via decision support software
for patients that a). yo-yo from below the low and above the high b). are always too high, and c). are
2
PHA Background
always to low. Part of our work for later in the semester will be to potentially design and implement an
algorithm that considered the low/high glucose values in conjunction with type of test (fasting, casual,
etc.) over some variable time period, and graphing for paitents/providers or sending email alerts. The
data that must be tracked includes, but is not limited to:
1. Time stamp for the entire entry entered by patient
2. Type of test: Fasting (no eating for at least 8 hours), 2 hours after eating, casual (any time during day)
3. Glucose Level measured in mg/dL taken from meter
4. Insulin taken (value comes up from the meter after testing)
5. Carbohydrates
Other info that may be needed is when was the insulin taken, which is often 30-60 minutes before eating.
Congestive Heart Failure/High Blood Pressure
Patients with congestive heart failure or high blood pressure need careful monitoring. Blood pressure
values such as 120/72 measure the systolic pressure in mm Hg – upper number, and the diastolic pressure
in mm Hg –lower number. In terms of values, values (systolic/ diastolic) are: Normal is less than
120/less than 80, Prehypertension 120-139/80-89, High Blood Pressure Stage 1 140-159, 90-99, High
Blood Pressure Stage 2 160 or higher, 100 or higher, Hypertensive Crisis 190 or higher, 110 or higher.
Again, if this information is tracked over time, then it can be correlated to determine if a patient is
running too high or too low and may need to get in to see a physician for a medication adjustment. Data
that must be tracked includes:
1. Time stamp for the entire entry entered by patient
2. Pulse
3. Blood Pressure (systolic mm Hg – upper number, Diastolic mm Hg –lower number)
4. Respirations per minute
5. Pulse Ox – out of 100%
6. Peak Flow Meter PERF L/min (adults http://www.peakflow.com/pefr_normal_values.pdf and
children http://www.peakflow.com/paediatric_normal_values.pdf)
Food intake may also play a role, if the patient is on a salt-free or low fat diet, or if a patient is on a blood
thinning medication which requires avoidance in foods that are high in vitamin K (which causes blood
clotting in high amounts).
Asthma
Asthma requires careful monitoring of patients pulse, respiration, etc., to insure that a patient is manaing
their condition. There is always the potential for asthmatics to have environment or allergic reactions that
have the potential to cause a life threatening condition. The data that must be tracked includes, but is not
limited to:
1. Time stamp for the entire entry entered by patient
2. Pulse
3. Respiration
4. Pulse Ox – out of 100% (now available on mobile phone – see
http://www.ncbi.nlm.nih.gov/pubmed/22954855 )
5. Peak Flow Meter PERF L/min (adults http://www.peakflow.com/pefr_normal_values.pdf and
children http://www.peakflow.com/paediatric_normal_values.pdf)
Note that there may also be the need to carefully track the inhalers and other pulmonary devices
(nebulizer). A provider may want a patient to enter in when they are taking their medications on a daily
basis, since there is a potential correlation with medications and pulmonary health. Also, if they have to
use a rescue inhaler, that should be tracked.
Obesity
Most of the information tracked for obesity is weight and diet/nutrition related. Weight will likely not be
entered on a daily basis (since weight can vary day to day and within the same day), but there may be
3
PHA Background
some set schedule that is required. Data on diet and nutrition might be collected, including calorie totals.
A patient may be on limited calories in order to manage weight. The data that must be tracked includes,
but is not limited to:
1. Time stamp for the entire entry entered by patient
2. Weight (entered daily? Weekly? Set differently for different patients?)
3. Blood pressure
4. Calories/Diet (How do we gather this information? What is available out there already?)
5. Pulse and Blood Pressure after exercise
Note that there may be a link from Obesity related classes to other classes (like exercise) that are defined.
Note also that a patient may have multiple chronic conditions; in this case, PHA would need to try to limit
the input of duplicate information.
New Class Declarations
The class library for PHA is organized into three logical categories: the tracking of patients and their
chronic conditions, ODLs, and medications; the tracking of information on exercise regimes and the
actual exercises being done by each patient; and, the tracking of information on food and nutrition. Note
that class declarations with protected data (attributes) and public methods are provided, but it is up to each
student to determine if all of the necessary information (attributes and methods) has been provided.
Classes for Patients, Conditions, ODLs, and Medications
The first set of classes in this category involves miscellaneous classes related to information that is
referenced by multiple classes, including a number of enumeration types, as shown in Figure 1. They
include MyTimeStamp, Weight, Height, BloodPressure, and Vitals. MyTimeStamp makes use of the
Java1 classes Date and SystemClock, and has multiple constructors to allow different types of time
stamps. The Weight class tracks weight by MyTimeStamp in kilograms, which is chosen since all
medication dosages are based on kilograms; the Height class tracks a patient’s height. BloodPressure
tracks the Systolic and Diastolic values (110/70), while Vitals tracks pulse, respirations, pulse
oxygenation (pulseox), and BloodPressure.
Figure 1. Classes (top row) and Enumeration Types (bottom row).
public class MyTimeStamp {
protected Date currentYearMonthDate;
protected SystemClock currentTime;
public MyTimeStamp() {};
public MyTimeStamp(int yr, int mo, int da) {};
public MyTimeStamp(int yr, int mo, int da, int hr, int min) {};
public void setCurrentYearMonthDate(Date currentYearMonthDate) {}
public Date getCurrentYearMonth() {return null;}
public void setCurrentTime(SystemClock currentTime) {}
public SystemClock getCurrentTime() {return null;}
}
1
For all documentation on Java see: http://docs.oracle.com/javase/7/docs/api/
4
PHA Background
public class Weight {
protected static final double CONVERSION_VALUE = 2.20462262185;
protected String weightValue = "";
protected MyTimeStamp weightDayandTime;
public Weight() {};
public String getWeightValue() {return null; }
public void setWeightValue(String weightValue) {}
public String getLbsValue() {return null;}
public void setweightDayandTime(MyTimeStamp weightDayandTime) {}
public MyTimeStamp getweightDayandTime() {return null;}
public String toString() {return null;}
}
public class Height {
protected String heightValue = "";
protected String when = "";
protected MyTimeStamp heightDayandTime;
public Height() {};
public String getHeightValue() {return null;}
public void setHeightValue(String heightValue) {}
public String getWhen() {return null;}
public void setWhen(String when) {}
public void setheightDayandTime(MyTimeStamp heightDayandTime) {}
public MyTimeStamp getheightDayandTime() {return null;}
public String toString() {return null;}
}
public class BloodPressure {
protected int Systolic;
protected int Diastolic;
public BloodPressure() {};
public void setSystolic(int Systolic) {}
public int getSystolic() {return 0; }
public void setDiastolic(int Diastolic) {}
public int getDiastolic() {return 0;}
}
public class Vitals {
protected int Pulse; // integer value
protected int Resps; // integer value
protected int PulseOx; // percentage
protected BloodPressure myBloodPressure;
public void setPulse(int Pulse) {}
public int getPulse() {return 0;}
public void setPulseOx(int PulseOx) {}
public int getPulseOx() {return 0;}
public void setResps(int Resps) {}
public int getResps() {return 0;}
public void setBloodPressure(int Systolic, int Diastolic) {}
public BloodPressure getBloodPressure() {return null;}
}
There are a number of enumeration types defined below, to keep track of the type of Condition being
tracked, the category of Medication, the type of ODL, the diabetes test that the patient took as a basis to
5
PHA Background
calculate the insulin value, and the types of meals that a patient eats. All enumerations types are stored in
the Enum class.
public enum Conditions {
Diabetes, Asthma, CHFandHBP, Obesity, Other;
}
public enum Medications {
Prescription, OTC, Supplements, VitMin, Other;
}
public enum ODLs {
energy, happiness, comfort, mobility, appetite, Other;
}
public enum DiabetesTest {
Fasting, TwoHrsAfter, Anytime;
}
public enum MealTypes {
Breakfast, Lunch, Dinner, Snack;
}
public enum DietTypes {
Fruit, Vegetable, Meat, Fish, Grain, Dairy;
}
As part of the design process, there is a need to distinguish between the different Conditions, ODLs, am
Medications that are tracked for each patient at a high level, versus the actual data that is input by each
patient and stored for data analysis purposes at a low level. At the high level, we define the TrackedItems
class that is utilized to track the Conditions, ODLs, and Medications for a patient in terms of the time
periods that each have been tracked. The involved classes are shown in Figure 2.
Figure 2. TrackedItems Parent and Child Classes.
TrackItems has a MyTimeStamp for “from” that represents when the tracking started and for “to” that
represents when the tracking finished. For example, a patient may have monitored diabetes in the past
(from Jan 1, 2012 to June 30, 2012) . When defining a Patient (see below), there will be a list of
TrackedItems instances. For example, a patient may have monitored diabetes in the past (from Jan 1,
2012 to June 30, 2012) and is also monitoring it now (from August 1, 2013 to present where “to” is null).
Continuing the example, in addition to the diabetes tracking until June 30, 2012, the patient may also be
tracking a current diabetes (from August 1, 2013 to present where “to” is null) and would have two
diabetes TrackedItems has two instances of the myCondition class (enum Conditions=Diabetes for both),
an instance of the myMedication class for the insulin they are taking (enum
myMedications=Prescription), and two instances of the myODL class – one for energy (enum
myODLs=energy) and one for appetite (enum myODLs=appetite). The key distinction here is that the
data that is being captured for the Conditions, ODLs, and Medications represents what is being tracked at
a high-level. The actual values for a condition, an ODL, and the time/date a medication is taken are
tracked in a separate class hierarchy.
public class TrackedItems {
6
PHA Background
protected MyTimeStamp from; // When did it start?
protected MyTimeStamp to; // null if ongoing
public void TrackPatientData() {};
public void setfrom(MyTimeStamp from) {}
public MyTimeStamp getfrom() {return null;}
public void setTo(MyTimeStamp from) {}
public MyTimeStamp getTo() {return null;}
}
public class MyConditions {
protected MyConditions aCondition;
public void myCondition() {};
public void setACondition(MyConditions aCondition) {}
public MyConditions getACondition() {return null;}
}
public class MyODL extends TrackedItems {
protected MyODL anODL;
public void myODL() {};
public void setAnODL(MyODL anODL) {}
public MyODL getAnODL() {return null;}
}
public class MyMedication extends TrackedItems {
protected MyMedication aMedication;
public void myMedication() {};
public void setAMedication(MyMedication aMedication) {}
public MyMedication getAMedication() {return null;}
}
The next eight set of classes track the instances of the conditions, ODLs, and medications that are actually
being taken by each patients. For conditions and ODLs, there is data to be entered by a patient multiple
times per day as they provide the required information for each condition or ODL. For example, recall
that for diabetes, it is necessary to track: the myTimeStamp for when data entered, the type of test
(Fasting, TwoHrsAfter, Anytime), the glucose level, the carbs eaten, and the insulin taken. These values
are entered multiple times per day by a patient, and separate instances need to be recorded so that data
analysis and clinical decision support can be attained. To begin, the TrackPatientData class below
captures the MyTimeStampl and other common data that is required by most (but not all) chronic disease,
namely, myVitals.
public class TrackPatientData {
private Timestamp currentYearMonthDate;
private Vitals myVitals;
public Timestamp getCurrentYearMonthDate() {return currentYearMonthDate;}
public void setCurrentYearMonthDate(Timestamp currentYearMonthDate) {
this.currentYearMonthDate = currentYearMonthDate;
}
public Vitals getMyVitals() {return myVitals;}
public void setMyVitals(Vitals myVitals) {this.myVitals = myVitals;}
}
With TrackPatientData in hand, the next five classes are specified to capture information on each of the
four different conditions, as shown in Figure 3.
7
PHA Background
Figure 3. TrackPatientData and Person Class Hierarchies.
There is a parent Condition class that uses the Conditions enum type to define myCondition (set to
Obesity, Diabetes, Asthma, CHFandHBP, or other). There are four subclasses of Condition for each of
the conditions. Note that Diabetes has the type of test (Fasting, etc.) and integer values for glucose level,
carbs, and the insulin taken. For the Asthma and CHFandHBP classes, a PeakFlowValue (integer) is
provided, and for both of these conditions, per the Project 2 Initial Design assignment, vital signs are
recorded (which are in the TrackPatientData class). For the Obesity class, the types of meal and calories
are tracked.
public class Condition extends TrackPatientData {
protected Condition myCondition; // //From enumerated type Conditions
public Condition() {};
public void setMyCondition(Condition condition) {}
public Condition getMyCondition() {return null;}
}
public class Diabetes extends Condition {
protected DiabetesTest myTypeofTest; // From enumerated type DiabetesTest
protected int myGlucoseLevel = 0;
protected int myInsulinTaken = 0;
protected int myCarbsIngested = 0;
public Diabetes() {};
public void setmyDiabetes(DiabetesTest myTypeofTest) {}
public DiabetesTest getMyDiabetes() {return null;}
public void setMyGlucoseLevel(int myGlucoseLevel) {}
public int getMyGlucoseLevel() {return 0;}
public void setMyInsulinTaken(int myInsulinTaken) {}
public int getMyInsulinTaken() {return 0;}
public void setMyCarbsIngested(int myCarbsIngested) {}
public int getMyCarbsIngested() {return 0;}
}
public class Asthma extends Condition {
protected int myPeakFlowTest = 0;
public Asthma() {};
public void setMyPeakFlowTest(int myPeakFlowTest) {}
public int getMyPeakFlowTest() {return 0;}
}
8
PHA Background
public class CHFandHPB extends Condition {
public CHFandHPB() {}
private int myPeakFlowTest = 0;
public int getMyPeakFlowTest() {return myPeakFlowTest;}
public void setMyPeakFlowTest(int myPeakFlowTest) {
this.myPeakFlowTest = myPeakFlowTest;
}
}
public class Obesity extends Condition {
protected MealTypes myTypeofMeal; // From enumerated type MealTypes
protected int myCaloriesPerMeal = 0;
public Obesity() {};
public void setMyTypeofMeal(MealTypes myTypeofMeal) {}
public MealTypes getMyTypeofMeal() {return null;}
public void setMyCaloriesPerMeal(int myCaloriesPerMeal) {}
public int getMyCaloriesPerMeal() {return 0;}
}
The ODL class extends TrackPatientData and is used to track one of the five possible ODLs (e.g., energy,
happiness, appetite, etc.) with a value from 0 (poor) to 10 (excellent). Note that if a patient is tracking all
five, there would be five instances of the ODL class each time a patient uses PHA to enter the
information.
public class ODL extends TrackPatientData {
protected ODLs myODL; // Tracks one type of ODLs, e.g., energy, happiness,
protected int myODLvalue = 5; // Ranges from 0 to 10
public ODL() {};
public ODL(JSONObject jo) throws JSONException {}
public JSONObject toJSONObject() throws JSONException {return null;}
public void setMyODL(ODLs myODL) {} // From enumerated type ODLs
public ODL getMyODL() {return null;}
public void setMyODLvalue(ODLs myODLvalue) {}
public ODL getMyODLvalue() {return null;}
}
Lastly, the Medication class extends TrackPatientData to track detailed information on the medication.
For this version of PHA, we are only tracking the medication by information on the prescription itself; we
are not tracking the times of day that each patient is taking the medication (medication diary not
supported). A future enhancement of PHA would track when patients took which medication, in order to
attempt to determine if patients are compliant in taking the medications as prescribed at the appropriate
times; for now, we defer this.
public class Medication extends TrackPatientData {
protected Medication myMed; // Tracks OTC, Supplement, etc.
protected String name = ""; // medication name
protected String strength = ""; // what is the dosage
protected String dose = ""; // amount of drug, e.g., 500mg
protected String howTaken = ""; // oral, shot, inhaled, cream
protected String frequency = ""; // times per day, etc.
protected String prescribed = ""; // is prescription or not
protected String note = ""; // reason for taking medication
public Medication() {};
9
PHA Background
public
public
public
public
public
public
public
public
public
public
public
public
public
public
public
public
public
public
public
public
public
public
public
public
Medication(JSONObject jo) throws JSONException {}
JSONObject toJSONObject() throws JSONException {return null;}
void setmyMed (Medications myMed) {} //From enumerated type ODLs
Medications getmyMed () { return null;}
void setName(String name) {}
String getName() { return null; }
void setStrength(String strength) {}
String getStrength() { return null; }
void setDose(String dose) {}
String getDose() { return null; }
void setHowTaken(String howTaken) {}
String getHowTaken() { return null; }
void setFrequency(String frequency) {}
String getFrequency() { return null; }
void setPrescribed(String prescribed) {}
String getPrescribed() { return null; }
void setDateStarted(MyTimeStamp dateStarted) {}
MyTimeStamp getDateStarted() { return null; }
void setDateDiscontinued(MyTimeStamp dateDiscontinued) {}
MyTimeStamp getDateDiscontinued() { return null; }
void setNote(String note) {}
String getNote() { return null; }
String toString() { return null; }
boolean isPrescribed(){ return true; }
}
The final two classes for supporting Conditions, ODLs, and Medications are for the Person class and its
Patient subclass, as was also shown in Figure 3. Person tracks information that would be shared among
Patients, Providers, etc.; note for now, we are not defining a medical provider, but this could be done in
the future and that is why the patient information has been separated into Person/Patient classes.
public class Person {
protected String firstName = "";
protected String lastName = "";
protected String birthDate = "";
protected MyTimeStamp myCreationTime;
public Person() {};
public void setFirstName(String firstName) {}
public String getFirstName() { return null; }
public void setLastName(String lastName) {}
public String getLastName() { return null; }
public void setBirthDate(String birthDate) {}
public String getBirthDate() { return null; }
public Date setDate() {}
public Date getDate() { return null; }
public void setmyCreationTime(MyTimeStamp myCreation) {}
public MyTimeStamp getmyCreationTime() { return null; }
public String toString() { return null; }
}
The Patient class is the repository for all of the information tracked in terms of Conditions, ODLs, and
medications. (from MSHV and OpenEMR),.This means tracking all of the instances of medications,
conditions, and ODLs that have been entered over time. In the Patient class, the TrackedItemsListMSHV
contains a list of the Conditions, ODLs, and Medications for a patient; these are what have been tracked
in the past, recall the prior example of a patient monitored diabetes in the past and currently, is currently
10
PHA Background
tracking energy and appetite, and takes insulin. The actual medications that a patient are taking can come
from two sources, the MedicationListMSHV from MS HealthVault and the MedicationListOpenEMR
from OpenEMR. Similarly, there are the list of the actual Condition instances from MSHV,
ConditionsListMSHV which track all of the data entered multiple times per day per patient on whatever
conditions are being monitored, with ODLListMSHV doing the same for ODLs.
public class Patient extends Person {
protected String race = "";
protected Height myheight = new Height();
protected Weight myweight = new Weight();
protected String gender = "Unknown";
protected String bloodType = ""; //Values of A, B, AB, O: omit +/- for now
protected List<TrackedItems> TrackedItemsListMSHV = new
ArrayList<TrackedItems>();
protected List<Medication> MedicationListMSHV = new ArrayList<Medication>();
protected List<Medication> MedicationListOpenEMR = new
ArrayList<Medication>();
protected List<Condition> ConditionsListMSHV = new ArrayList<Condition>();
protected List<ODL> ODLListMSHV = new ArrayList<ODL>();
public Patient(){}
public void setBloodType(String bloodType) {}
public String getBloodType() {return null;}
public void setRace(String race) {}
public String getRace(){return null;}
public void setHeight(Height height) {}
public Height getHeight(){return null;}
public void setWeight(Weight weight) {}
public Weight getWeight(){return null;}
public void setGender(String gender) {}
public String getGender(){return null;}
public List<TrackedItems> getTrackedItemsListMSHV(){return null;}
public void setTrackItemsedListMSHV(List<TrackedItems> TrackedItemsListMSHV)
{}
public List<Medication> getMedicationListMSHV() {return null;}
public void setMedicationListMSHV(List<Medication> medicationListMSHV) {}
public List<Medication> getMedicationListOpenEMR() {return null;}
public void setMedicationListOpenEMR(List<Medication> medicationListOpenEMR)
{}
public List<Conditions> getConditionsListMSHV() {return null;}
public void setConditionsListMSHV(List<Conditions> conditionsListMSHV){}
public List<Conditions> getODLListMSHV(){return null;}
public void setODLListMSHV(List<Conditions> odlListMSHV) {}
}
To provide a pictorial view of the content of a Patient instance for the patient “George”, Figure 4 displays
the contents of the instance, where there is one Condition (Diabetes) being tracked at two times (current
diabetes, past diabetes), one OTC medication in MSHV (Prilosec), one medication in OpenEMR (insulin)
, and no ODLs. Notice the par1 instance that contains the information inherited from Person (per1), the
basic data defined in the Patient class (race, gender, bloodType, myHeight, and myWeight). There are
three lists of data: TrackItemsListMSHV that contains two myCondition instances, one for a past tracking
of diabetes and one for a current ongoing tracking; the MedicationListMSHV which has Prilosec; and,
MedicationListOpenEMR which has Insulin.
11
PHA Background
Patient Instance: pat1
Person Instance: per1
firstName:
“George” lastName:
myCreationTime:
race: “White”
gender: “Male”
bloodType: “A”
“Jones” birthDate:
MyTimeStamp Instance: mts1
Date:
“09162013”
myHeight: Height Instance: h1
heightValue: “5.10”
“06251966”
SystemClock: 1315
myWeight:
Weight Instance: w1
heightValue: “150”
TrackedItemsListMSHV:
myCondition Instance: mc1
from: “01012012”
to: “06202012”
aCondition: Diabetes
MedicationListMSHV:
myCondition Instance: mc2
from: “09012013”
to: “”
aCondition: Diabetes
MedicationListOpenEMR:
myMedication Instance: mm1
name: “Prilosec”
strength: … etc…
myMedication Instance: mm2
name: “Insulin”
strength: … etc…
Figure 4. The Patient instance for “George”.
Classes for Exercise
The next category of classes tracks information on a patient’s exercise regime, which have a need to track
multiple sessions per day (again, necessitating time stamps). There are many potential characteristics to
track on an exercise regime. For example, the type of exercise can be varied, including: walk, treadmill,
jog, run, bike, stepper, swimming, weight lifting, tennis, golf, other sports, etc. Each of these exercise
types may have a different way to track their duration; some may be time oriented, some may be distance
oriented, etc. In some cases, there may be need to record the pulse and/or blood pressure both before and
after exercise. At a higher level, some of the classes related to Exercise may also need to interact with the
Chronic Disease classes. By tracking all of this information, graphs and charts can be generated for both
patients and providers, offering a significant level of clinical decisions support. The top-level class for
exercise is TrackExerciseData, which parallels the TrackPatientData class.
public class TrackExcerciseData {
protected MyTimeStamp myTimeofDay; // When was data collected in one place
protected Vitals myVitalsBefore;
protected Vitals myVitalsAfter;
public void TrackExerciseData() {};
public void setmyTimeofDay(MyTimeStamp from) {}
public MyTimeStamp getmyTimeofDay(){return null;}
public void setVitalsBefore(Vitals myVitalsBefore){}
public Vitals getVitalsBefore(){return null;}
public void setVitalsAfter(Vitals myVitalsAfter){}
12
PHA Background
public Vitals getVitalsAfter(){return null;}
}
One approach to supporting the tracking of different kinds of exercises would be to develop different
subclasses of TrackExerciseData, e.g., one for TrackWalking, TrackJogging, TrackGolf, etc. However, in
order to simplify the approach, we will instead define a number of enumeration types to capture different
types of exercises, and have a combined TrackExerciseData; while this may not be ideal for a production
solution to PHA, it will suffice for the purposes of the assignment. In practice, the TrackExerciseData
class would need additional modifications to allow all of the various exercise and weight devices to be
hooked into PHA and store data in MSHV.
public enum ExerciseType {
walk, treadmill, jog, run, bike, stepper, swimming, weights, tennis, golf,
Other;
}
public class TrackExcerciseData {
protected MyTimeStamp myTimeofDay; // When was data collected in one place
protected Vitals myVitalsBefore;
protected Vitals myVitalsAfter;
protected ExerciseType myExerciseType;
protected int myExerciseTime;
public void TrackExerciseData() {};
public void setmyTimeofDay(MyTimeStamp from) {}
public MyTimeStamp getmyTimeofDay(){return null;}
public void setVitalsBefore(Vitals myVitalsBefore){}
public Vitals getVitalsBefore(){return null;}
public void setVitalsAfter(Vitals myVitalsAfter){}
public Vitals getVitalsAfter(){return null;}
public void setmyExerciseType(ExerciseType myExerciseType){}
public ExerciseType getmyExerciseType(){return null;}
public void setmyExerciseTime (int myExerciseTime){}
public int getmyExerciseTime(){return 0;}
}
In addition, please add the following and associated methods to the Patient class:
protected List<TrackExcerciseData> TrackExerciseListMSHV = new
ArrayList<TrackExcerciseData>();
public void setTrackItemsListMSHV(List<TrackedItems> TrackItemsListMSHV) {}
public List<Medication> getTrackItemsListMSHV() {return null;}
Interactions of Proposed New Classes and Existing HealthItem Hierarchy
The existing HealthItem hierarchy still remains in PHA, but is now focused on operating as a server side
representation and as a vehicle for information to be passed in and out of MSHV. The new sets of class
hierarchies in Figures 1, 2, and 3 represent the client side information that is needed, and is used to stage
information to/from the user from the GUI/App into the new classes. As shown in Figure 5, the intent is
for the new set of classes to be ones that directly interact with the PHA app in order to be able to: 1. Take
information for a new ODL (for TrackedItems) and store in MSHV via the HealthItem hierarchy; 2. Take
data collected on an ODL, Condition , or Medication and put into the respective class in the
TrackPatientData hierarchy; and 3. Pull data from MSHV to populate information to the PHA. The
implementation of the methods of the TrackedItems and TrackPatientData hierarchies will call the
13
PHA Background
HealthItem MSHV REST API methods (shown in the bottom right of Figure 5) in order to retrieve/store
information from/to MSHV through the HealthItem classes and into the new classes. Note for this project
the concentrate on the left two thirds of Figure 5, focusing on the application side (PHA) and the classes
utilized to store/display the information. There will be NO integration to MSHV or OpenEMR for this
project; that will be deferred until Project 3.
Figure 5. From the PHA Android App through New Classes to HealthItem Hierarchy to MSHV.
Project 2 Final Requirements
In order to design and code the screens for conditions, exercises, and ODL, you can see the Background
on Semester Project PDF at: http://www.engr.uconn.edu/~steve/Cse2102/Cse2102SemProjBack.pdf.
There are some sample screen shots for diabetes. In addition, the code for PHA for this project includes
the new following screen where you see buttons for: Conditions, Medications, ODLs, and Exercise. The
emphasis for the project is to focus:
1. Designing and implementing new screens for Conditions and Exercise. This will include two
possible scenarios: a. screen(s) to allow a patient to create and track a condition and b. screen(s)
to allow a patient to input data on a condition being tracked.
2. Modifying, if necessary, the ODL and Medication screens that already exist.
3. Hooking the current ODL and Medication screens so that information is stored in the new classes.
14
PHA Background
Figure 6. Need for Higher-Level Organizationally Oriented GUI Screen.
In the case of Conditions, a patient will decide to track his/her condition (Diabetes, Asthma,
CHFandHPB, and Obseity). This will require them to create a new Condition with a start date and end
date(may be null), which will cause the creation of a TrackedItems instance of type MyConditions to be
inserted into the TrackedItemsListMSHV of a Patient instance. This represents the Condition being
tracked at what time. For ODLs, the patient will decide to track one or more of (energy, happiness,
comfort, mobility, appetite, Other), while will create a new ODL with a start and end date (may be null)
which will cause the creation of TrackeItems instance of type MyODL to be inserted in the
TrackedItemsListMSHV of a Patient instance. The previous discussion causes the creation of a condition
or ODL to track, and you need to define screens that will allow a new Condition or ODL to be created. In
addition, you must also design a screen to allow the information on a specific Condition or for an ODL to
be entered by the patient, to record at a date/time stamp the information associated with each Condition
(or ODL); this will be stored in the ConditionsListMSHV (ODLListMSHV) list of the Patient Class.
There are sample screens for the different conditions in the PPT for the semester project. The same
situation exists for exercise; first define the exercise being tracked and then have screen(s) to allow data
to be entered.
Finally, in support of the project, a new PHA archive is in filelocker (https://web2.uconn.edu/filelocker/
at UConn and has been shared to all of you via your NetID. Download PHA4v2.zip and extract to a
specific directory. The archive contains the code structure for PHA, with a directory created for the new
classes as shown in Figure 7. Notice that in the src directory, a new subdirectory
edu.uconn.newclientmodel has been added which includes all of the classes defined in this document.
You should use this as a basis for your implementation.
15
PHA Background
Figure 7. PHA Code Hierarchy for Project 2 Final Design.
Project 3 will focus on taking the common solution (in Filelocker titled PHA4v3.zip) and using this as a
basis to complete the functionality of the server along with its interactions with the server and MSHV.
Note that the project emphasis is on fully integrating the screens for medications, conditions, ODLs, and
exercise to use the new class library which interacts with the HealthItem class hierarchy which in turns
interact with MS HealthVault as shown in Figure 1. The solution provided in PHA4v3.zip contains an
implementation of all of the screens that are linked to the new class library. Note that there is also a new
logon screen that requires you to log on to MSHV before the PHA application fully starts. This is a new
important authorization step that will allow PHA to interact with MHSV programmatically via our server.
Your focus for this project is to focus on the interactions of the new class library with the HealthItem
hierarchy which in turn interacts with the MSHV server via the REST API and using JSON messages.
16
PHA Background
CLIENT SIDE
SERVER SIDE
Figure 1. From the PHA Android App through New Classes to HealthItem Hierarchy to MSHV.
In the current architecture the HealthVault system can be accessed through two REST service API or the
web browser. Your PHA application will use the REST services APIs 1 and 2 to get, update, or add
information into HealthVault (see Figure 2 below).
https://account.healthvault-ppe.com/
HealthVault
System
http://cicats9.engr.uconn.edu:14080/help
REST Service API 1
JSON
New Services
http://cicats9.engr.uconn.edu:14081/Health/help
REST Service API 2
JSON
Old Services
Figure 2 - HealthVault Architecture
1 Explanation and Interoperation of Existing Code:
This section details code level interactions between classes in the HealthItem hierarchy
(src/edu.cconn.model), classes in the (src/edu.uconn.pha) code for various activities, and classes in the
17
PHA Background
(src/edu.ucconn.serverclient). First, you need to understand the ServerConnection.java code that is in
the src/edu.uconn.serverclient directory. This code is utilized to form the JSON to MSHV. To begin,
consider the code segment below that builds a string that contains the publicId and recordId that are
both used to make queries to MHSV.
private static String generateGetPubRecParams()//String publicId, String recordId)
{
StringBuffer sb = new StringBuffer();
sb.append("publicId=");
sb.append(publicId);
sb.append("&");
sb.append("recordId=");
sb.append(recordId);
return sb.toString();
}
For example, in the method addMedicationInfo from the ServerConnection class given below, you can
see that there is an action that is defined "/Medications/Add/?" which is combined with params to
form
the
request
that
is
then
posted
to
MSHV
via
the
call
ServerConnectionHelper.serverRequestPost. This action is accomplished in combination with the
ServerConnectionhelper.java class. Note that the entire servcerconnection.java file contains similarly
structured code to handle ODLs, medications, person info, etc., including the actions of add, get, update
and delete. These various methods all utilize the classes defined in the HealthItem hierarchy.
public static void addMedicationInfo(Medication med)//String publicId, String
recordId)
throws JSONException
{
String action = "/Medications/Add/?";
String params = generateGetPubRecParams();
Log.v(TAG, med.toString());
String response = ServerConnectionHelper.serverRequestPost(action + params,
med.toJSONObject());
med.setKey(ServerConnectionHelper.toJSONObject(response));
medicationList.add(med);
}
The linkage from this process to other portions of the PHA source code is through the src/edu.uconn.pha
directory of activities. Specifically, in the RxOTcActivity.java file a segment of code for the getRxOTc
method is:
private void getRxOtc() {
// generate the medications list
rxOtcList = null;
try {
rxOtcList = ServerConnection.getMedicationsJSON();
} catch (JSONException e) {
Log.e(TAG, "Error :: JSON Exception", e);
}
// create data objects to store and map the data to the multi-column list view
itemList = new ArrayList<HashMap<String, String>>();
Iterator<Medication> i = rxOtcList.iterator();
index = 0;
where an rxOtcList is created by a ServerConnection.getMedications JSON call. Notice that in the
code for the RxOtcActivity class, there is private data defined for Medication (the Medication.java file
18
PHA Background
of src/edu.cconn.model). As a result, there is a clear association among the RxOtcActivity,
Medication, and ServerConnection clasess.
If you review all of the code from the edu.uconn.pha (the activities), the edu.uconn.model (the
HealthItem hierarchy) and the edu.uconn.clientserver (ServerConnection) you will see the associations
that are present among the various activities (alarms, allergies, medications, wellness/ODLs, etc.) and the
classes from model an serverclient that are defined and utilized.
2 UCONN Microsoft Healthvault Server
The Microsoft Healthvault server at the University of Connecticut is a middle layer between mobile
devices and Microsoft Healthvault. The main function of the server is to:
 .Provide mobile user authentication.
 Add/Update/Delete/Get Health Record Items of (HRI) from Microsoft Healthvault.
Schema Objects
Every schema object Healthvault supports can be passed to the server. These schema formats are found
at:
http://developer.healthvault.com/pages/types/types.aspx
End Points
The update/add/delete operations carry the xml-scheme information in the body of the request. HRIs
supported are listed at the server’s help page:
http://cicats9.engr.uconn.edu:14080/Help
GET OPERATION
/api/Health?TypeId={TypeId}&RecordId={RecordId}
UPDATE OPERATION
/api/Health/Update?TypeId={TypeId}&PublicId={PublicId}&RecordId={RecordId}
Devoe--‐2
ADD OPERATION
/api/Health/Add?TypeId={TypeId}&PublicId={PublicId}&RecordId={RecordId}
DELETE OPERATION
/api/Health/Delete?TypeId={TypeId}&PublicId={PublicId}&RecordId={RecordId}
Notice that the format above corresponds to the composition of the various components into one string in
the prior example from the serverconnection.java code. Specifically:
String action = "/Medications/Add/?";
String params = generateGetPubRecParams();
This matches the format:
/api/Health/Add?TypeId={TypeId}&PublicId={PublicId}&RecordId={RecordId}
Authentication
To make requests to the MSHV server you will need a PublicId and a RecordId. These two Ids are for
authentication purposes only. You can get personal Ids by visiting the following link and signing in to
MSHV:
19
PHA Background
http://cicats9.engr.uconn.edu:14080/Default.aspx
JSON REST API Calls and Documentation
All of the details of the REST API calls can be found at: http://cicats9.engr.uconn.edu:14080/Health/help
Note that if you are outside of UConn, you need to be connected to the VPN with http://vpn.uconn.edu.
As an example, consider the add/get/update calls for Medications:
ADD - http://cicats9.engr.uconn.edu:14080/Health/help/operations/SetMedicationInfo
GET - http://cicats9.engr.uconn.edu:14080/Health/help/operations/GetMedicationInfo
UPDATE - http://cicats9.engr.uconn.edu:14080/Health/help/operations/UpdateMedicationItem
EXAMPLE JSON REST API Calls
Example GET Request:
http://cicats9.engr.uconn.edu:14080/api/Health/GetExercises?PublicId={PublicId}&RecordId={RecordId
}
Example POST Request
http://cicats9.engr.uconn.edu:14080/api/Health/AddExercise?PublicId={PublicId}&RecordId={RecordId
}
The body of a POST request must include the corresponding JSON object you are adding (use content
type ‘application/json’):
{
Title: "Rope jumping"
Distance: "3218.688"
Duration: "20"
When: "2013-10-07T00:00:00"
}
Example DELETE Request
http://cicats9.engr.uconn.edu:14080/api/Health/Delete?PublicId={PublicId}&RecordId={RecordId}&Ke
y={Key}
Where Key is the object’s key to be deleted.
RAW REST Api Calls
All data types can also be returned as RAW XML from Healthvault.
Example GET Request:
http://cicats9.engr.uconn.edu:14080/api/Health/Get?PublicId={PublicId}&RecordId={RecordId}&TypeI
d={TypeId}
Where ‘TypeId’ is any type id from http://developer.healthvault.com/pages/types/types.aspx
20
PHA Background
Example POST Request
http://cicats9.engr.uconn.edu:14080/api/Health/Add?PublicId={PublicId}&RecordId={RecordId}&TypeI
d={TypeId}
The body of a POST request must include the corresponding XML object you are adding (use content
type ‘application/xml) NOTE: body match xml format refer to what is returned from get:
<thing><thing-id version-stamp="4847da7f-e1e8-4759-acc4-793925155bcf">03960229-fcce-4388-b2d806384de47dac</thing-id><type-id name="Exercise">85a21ddb-db20-4c65-8d30-33c899ccf612</typeid><thing-state>Active</thing-state><flags>0</flags><eff-date>2013-10-07T00:00:00</eff-date><dataxml><exercise><when><structured><date><y>2013</y><m>10</m><d>7</d></date></structured></w
hen><activity><text>Rope
jumping</text><code><value>RopeJumping</value><family>wc</family><type>exerciseactivities</type><version>1</version></code></activity><distance><m>3218.688</m><display
units="mi"
unitscode="mi">2</display></distance><duration>20</duration><detail><name><value>Steps_count</value
><family>wc</family><type>exercise-detailmes</type></name><value><value>300</value><units><text>Count</text><code><value>Count</valu
e><family>wc</family><type>exerciseunits</type><version>1</version></code></units></value></detail></exercise><common
/></dataxml></thing>
Example DELETE request
***Same as JSON REST API Delete call above
Project 3 Final Requirements
3.1 Initial HealthVault Account and Data Entry Setup (One time step).
1.
2.
3.
4.
The first time you sign into PHA it will redirect you to the HealthVault sign-in page.
Create an account through the PHA
Go to https://account.healthvault-ppe.com/ sign in using your new HealthVault account.
Manually enter test one sample value for allergies, conditions, medications, weight, and blood
pressure through the web site. Note that currently in order to perform a successful get request
HealthVault must have values stored. Therefore, before you perform a Get operation, make sure
you make an Add operation.
3.2 Review both REST API services.
The set of methods that you need to use in order to get/update/add data from your PHA application to
HealthVault are located in two locations (see Figure 2). Some methods are available on both service
locations (eg. Conditions), some are only available REST Service API 1 (eg. Exercise, Vitals, etc.) and
some are only available in REST Service API 2 (eg. ODL). You have to choose the correct web service
for your methods. Note, that currently REST Service API 1 by default returns XML and not JSON. If you
prefer to exchange data using JSON, set the content type request to 'application/json'.
3.1 Linking PHA’s new services with HealthVault.
21
PHA Background
The project can be accomplished using two different design approaches based on whether the HealthItem
hierarchy is utilized and extended, or replaced by embedding its functionality into the new class
hierarchy.

Extend HealthItem hierarchy: In this approach, the Healthitem hierarchy is extended to capture
the four different conditions (Diabetes, Asthma, CHFandHBP, and Obesity) along with Exercise.
In this, case, the existing functionality and code of the HealthItem hierarchy can be used as a
template to implement new classes for conditions and exercise that connect into the HealthItem
hierarchy. Then, you will need to link the new TrackPatientData hierarchy (Person/Patient and
associated classes) so that the information that information can transition from the GUI to
TrackPatientData to HealthItem to Rest API JSON calls.

Eliminate HealthItem hierarchy and reuse the code by Integrating into the new TrackPatientData
hierarchy. In this case, your objective would be to move the functionality that currently exists in
HealthItem into the new TrackPatientData hierarchy. This would require you to change all of the
Activity related classes to now interface to TrackPatientData rather than HealthItem. This may
also require changes elsewhere. This would eliminate layer of classes.
As a result, the emphasis for the project can focus on a subset of the following activities.
4. Extend the HealthItem Hierarchy as necessary to store information on chronic diseases and
exercise, implement the new code for the HealthItem hierarchy to store/retrieve information
to/from MSHV, an fully integrate the new TrackPatientData hierarchy (and associated classes)
with
the
existing
HealthItem
hierarchy.
OR
Eliminate the HealthItem hierarchy by integrating its functionality into the new TrackPatientData
hierarchy (and associated classes).
5. Fully test your prototype using your MSHV account. Write a testing document that includes
screen shots from your executing PHA that shows the progression of: logging on; creating a new
medication, ODL, each of the four chronic conditions, and exercise; and, entering a day of data
for each chronic condition and an ODL, using PHA throughout one day in order to demonstrate
that the time stamp is working correctly. You should also take screen shots of MSHV before you
start the testing process, and after you are done to show the changes in the medications that are
tracked by the addition of at least one new med during the day of testing and data collection.
The working prototype that you develop should be fully integrated with our MSHV server and be able to
allow a user (patient) to enter, store, and view information related to medications, ODLs, chronic
conditions, and exercise. A new PHA archive is in filelocker (https://web2.uconn.edu/filelocker/ at
UConn and has been shared to all of you via your NetID. Download PHA4v2.zip and extract to a specific
directory. The archive contains the code structure for PHA, with a directory created for the new classes
as shown in Figure 1. Notice that in the src directory, a new subdirectory edu.uconn.newclientmodel has
been added which includes all of the classes defined in this document. You should use this as a basis for
your implementation.
Additional steps that you should consider in case you encountered an issue.
1. REST Service Accessibility
a. Internet connection required
b. If you are outside the engineering network, make sure to use VPN (vpn.uconn.edu)
2. Health Vault Account Setup
22
PHA Background
a. Create an account here: https://account.healthvault-ppe.com and sign in.
b. Open a new browser tab using http://cicats9.engr.uconn.edu:14080/Default.aspx and
check if the record ID and the public ID are loaded.
3. Android Virtual Device (AVD) configuration
a. Open your Android Developer Tools (ADT)
b. Install and check android 4.2.2 (see below)
c.
d.
e.
f.
Restart your ADT
The configuration below works, but you can use your own configuration or actual device.
The first time when the new AVD is loaded be patient it takes about 5 minutes.
Upon login when it asks you to remember your username/password, click “Remember”
4. REST Client Tools
a. Download this tool https://chrome.google.com/webstore/detail/advanced-restclient/hgmloofddffdnphfgcellkdfbfbjeloo?hl=en-US to test the REST service before
linking it up with the PHA code.
23
PHA Background
b. Go to http://cicats9.engr.uconn.edu:14080/Default.aspx to get your public ID and record
ID.
c. Open the rest client located at chrome://restclient/content/restclient.html
d. Go to headers and add Content-Type: application/json
e. Change method to POST
f. Sample Exercise Add Requst:
i. URL:
http://cicats9.engr.uconn.edu:14080/api/Health/AddExercise?publicId=c13c6a32
-ac34-4b98-8b1a-a5014993e747&recordId=3b50901b-e0b2-4753-bce26a47b447074b
ii. Body: {"Title": "Running","Distance":"3218.688","Duration": "20","When":
"2013-10-07T00:00:00"}
g. http://cicats9.engr.uconn.edu:14080/Help shows you the list of all REST services
5. PHA Source Code Comments
a. edu.uconn.pha.LoginViewActivity is the first Activity that gets loaded (see Android Manifest file)
b. Upon login into HealthVault you may need to restart the PHA application
c. Upon restart it will go to edu.uconn.pha.SplashActivity to load all data from HealthVault before
starting the first Activity (TabsActivity.java) where it loads the HomeActivty.java.
d. Android does not allow you to download/upload data on the internet on the main process.
e.
Therefore you must do the REST service requests using a new thread in the background. For an
example, look at the:edu.uconn.serverclient.post.MedicationPostRequest
Activity (green border) flow diagram
6. Server Model
a.
b.
Exercise
i.
public string Title;
ii.
public string Distance;
iii.
public string Duration;
iv.
public DateTime When;
Weight
24
PHA Background
c.
d.
e.
f.
g.
h.
i.
j.
k.
i.
public String Value;
ii.
public DateTime When;
Vital
i.
public String Title;
ii.
public String Unit;
iii.
public String Value;
iv.
public DateTime When;
Person
i.
public String FirstName;
ii.
public String LastName;
iii.
public DateTime BirthDate;
iv.
public List<Height> Heights;
v.
public List<Weight> Weights;
vi.
public Demographic Demograph;
Medication
i.
public String Strength;
ii.
public String Dose;
iii.
public String HowTaken;
iv.
public String Frequency;
v.
public DateTime DatePrescribed;
vi.
public DateTime DateStarted;
vii.
public DateTime DateDiscontinued;
viii.
public String Note;
Height
i.
public String Value;
ii.
public DateTime When;
HealthItem
i.
public String Key;
ii.
public String TypeId;
Emotions (ODL)
i.
public String Mood;
ii.
public String Stress;
iii.
public String WellBeing;
iv.
public DateTime When;
DiabeticProfile
i.
public string Description;
ii.
public string InsulinAmount;
iii.
public DateTime When;
Demographics
i.
public String Gender;
ii.
public int BirthYear;
iii.
public String Country;
iv.
public String PostalCode;
v.
public String State;
Condition
25
PHA Background
i.
public string Name;
ii.
public string StopReason;
iii.
public DateTime StartDate;
iv.
public DateTime StopDate;
Project 4 will focus on taking the common solution (in Filelocker titled PHA4v4.zip) and using this as a
basis to make a number of changes and enhancements including:
1. Update Prescription Screen with OpenEMR Integration and FDA Daily Meds Access: This
enhancement involves changes to the current prescription screen and the introduction of a new
screen that summarizes the medication interactions (see enhancement two below). In the process,
you will need to gather information from both MSHV and OpenEMR, and provide a link to FDA
Daily Meds for each prescription drug.
2. New Medication Reconciliation and Interaction Checking Screen and Algorithms: Design,
develop, implement, and test medication interactions for PHA which includes access remote
repositories and putting together the resulting interactions on one or more screens that summarize
the interactions for the patient. This that will pull medications from both MSHV and OpenEMR.
TEAMS: Students must work in teams of three individuals in order to partition the work among team
members. Please send email to steve@engr.uconn.edu and Solomon.Berhe@uconn.edu with your team
names, emails, and netIDs. Solomon will finalize teams in the CSE2102 labs on Wednesday. Please note
that you can work across labs with any student in the class. Since there are 53 students in the class, we
will have 17 teams of 3 and 1 team of 2.
Update Prescription Screen with OpenEMR Integration and FDA Daily Meds Access
In Figure 1, both the current medication screen (left side) and Medications screen (right side) for
prescriptions is shown. Note that in the figure, non-prescription meds were shown since the test account
used for the screenshots did not have any prescription drugs.
Figure 1. Current Medication Summary Screen and Prescription Drug Screen.
The screen on the right needs to be modified to have two categories under My Prescription Drugs –
Microsoft HealthVault and OpenEMR. Then, under those two categories there needs to be the
26
PHA Background
medications that are found in MSHV and OpenEMR for the patient listed in the same format as they are
currently shown.
An enumeration of changes for this first enhancement are:
 Integrate OpenEMR using the new REST API for getting medications to make those medications
accessible for a patient and listed in read-only manner on the new medication screen. This will
require you to retrieve the medications from OpenEMR. To accomplish this, please see the
course
web
page
for
the
file:
http://www.engr.uconn.edu/~steve/Cse2102/MSHVandOpenEMRAccess.pdf. Note that you will
be using a shared version of OpenEMR running on cicats9. This is due to the fact that the REST
API needs an IIS server to be running would be difficult for you to set up on your own computing
environment. The instructions in the PDF contain the reference to the REST API for OpenEMR
at ciciats9.
 Create a revised Medications Screen to include the HealthVault and OpenEMR categories.
 For each medication, currently clicking on the medication brings up the screen for the medication
itself. You need to have two options available for each medication: 1. Pull up the medication as
current working; and 2. Pull up a new screen that links a medication to FDA Daily meds so that
for each medication the patient can see detailed drug information. Note that for OpenEMR meds,
there are not allowed to make any modifications to the medications, since these are never stored
back.
 Add a button somewhere on the revised medication screen for “Check Interactions” which upon
selection does a number of actions (see enhancement 2 below) that results in a new screen with a
colored code list medication interactions.
Note that the DailyMed RESTful API is a web service for accessing current Structured Product Labeling
(SPL) information. It is implemented using HTTP and can be thought of as a collection of resources
http://dailymed.nlm.nih.gov/dailymed/help.cfm#pharmamappings with the web services listed at the site:
http://dailymed.nlm.nih.gov/dailymed/help.cfm#webservices For example, you can search for
AMOXICILLIN a common antibiotic at: http://dailymed.nlm.nih.gov/dailymed/advancedSearch.cfm and
get back a list of meds from which you can select one from that list, say:
http://dailymed.nlm.nih.gov/dailymed/lookup.cfm?setid=de69eafe-b9d3-4dd3-915d-ff2edafc14f4 . For
the project you want to programmatically display this information on the PHA app when the patient does
a search.
New Medication Reconciliation and Interaction Checking Screen
Design, develop, implement, and test medication interactions for PHA which includes access remote
repositories and putting together the resulting interactions on one or more screens that summarize the
interactions for the patient. This enhancement has two main parts:
1. Design and implement a new screen to show the medication interaction results.
2. Working with varied REST APIs in order to pull information about medications and their
interactions from external sources.
Figure 2 illustrates both of these parts.
27
PHA Background
New External Sources
XML
MS
Health
Vault
Middle-Layer Server
With REST API
NDF-RT
ASP.Net API
RxNorm
JSON
XML
OpenEMR
XML
JAVA APIs
XML
JSON
RxTerms
FDA
Daily
Meds
Personal Health Assistant (PHA)
Patient App
•
•
•
•
Medications
Allergies
Procedures
Demographic
Provider List
Security Policies
Proivder App
•
•
•
•
Medications
Allergies
Procedures
Demographic
Patient List
Authorization by Role
New
Interaction
Checker
Screen
Figure 2. Expanding PHA Architecture for Project 4.
In terms of the new screen for medication interactions, consider the example shown in Figure 3, which is
designed provide the alert information to the user in a quick and easily recognizable fashion, geared
towards simplicity in order to serve a wide range of patients and to be easily portable to mobile devices.
The main application screen, is currently divided in two tabs, visualizing MSHV and the OpenEMR.
Patients can switch between the tabs to see the list of medications stored in each record. The Reconcile
Medications and the Find Medication Interactions buttons perform on-demand reconciliation and
interaction searches. If any of the entries interact, the severity of interaction is indicated by a yellow
(significant interaction) or red (critical interaction) background. Entries for which no interactions are
found are displayed with a neutral background color. There are up to three buttons located next to each of
the medications: View Interactions, Details, and Remove. Since a patient cannot modify the information
located in the provider’s EMR, the only button visible in this tab is Details. View Interactions presents
the user with a listing of cross-interactions between the specified medication and any other reconciled
entry. Details presents information of the medication ingredients, generic names, and the dates when the
user started and stopped taking the medication. Note that this was designed for a web-based setting which
may not be suitable for a mobile platform.
28
PHA Background
Figure 3. Sample Interactions Checking.
The second part of the project as indicated in Figure 2 (right hand side) has to do with accessing varied
database and web repositories. The process for interaction checking begins with a retrieval of the sets of
medications from MSHV and OpenEMR. Remember that the Patient class in Project 3 final design had a
protected variable for keeping OpenEMR medications that wasn’t used in Project 3 but will be in this
project.
Once all of the medications have been loaded in PHA from MSHV and OpenEMR, the next step involves
iterating through those medications in order to identify each of them. There are three webs sites of note to
assist in this process for RxNorm (“RxNorm provides normalized names for clinical drugs and links its
names to many of the drug vocabularies commonly used in pharmacy management and drug interaction
software”), RxTerms (“RxTerms is a drug interface terminology derived from RxNorm for prescription
writing or medication history recording”), and NDF-RT (“NDF-RT is a concept-oriented terminology, a
collection of concepts, each of which represents a single, unique meaning”):
 http://rxnav.nlm.nih.gov/RxNormAPIs.html#
 http://rxnav.nlm.nih.gov/RxTermsAPIs.html#
 http://rxnav.nlm.nih.gov/NdfrtAPIs.html#
Note that each medication has a unique alphanumeric identifier called NUI that is a identifier for the drug
in the NDF reference terminology (http://evs.nci.nih.gov/ftp1/NDF-RT/NDF-RT%20Documentation.pdf).
The NUI can be found by doing a concept search using the NDF-RT RESTful API
http://rxnav.nlm.nih.gov/NdfrtAPIREST.html#uLink=Ndfrt_REST_findConceptsByName.
Alternatively, you can use RxNorm and RxTerm to make sure you have a proper name/search criteria, get
the RxCUI (an identifier from RxNorm and RxTerm), and then do a search over that specific identifier:
http://rxnav.nlm.nih.gov/NdfrtAPIREST.html#uLink=Ndfrt_REST_findConceptsByID. Note that two
significant objectives of this project are: one, working with a teammate and dividing your responsibilities;
and, two, learning to work with external databases and services where you have limited support in house
(e.g., from Solomon).
For experimental purposes, the following list of medications would be as below; we will be entering these
meds into OpenEMR. You can enter other medications in MSHV that will be utilized to search for
interactions.
1. Zithromax (Azithromicin)
2. Angiozem (Diltiazem)
3. Azilect (Rasgaline)
29
PHA Background
4. DayQuil (Acetamiophen)
5. Avinza (Morphine)
6. Rifadin (Rifampin)
Note that we may provide you with additional medications for you for testing.
For those of you interested in an entire article on our medication interaction checking and reconciliation,
please see: http://ieeexplore.ieee.org.ezproxy.lib.uconn.edu/stamp/stamp.jsp?tp=&arnumber=6470243; if
you copy and paste the link into a browser, you will be asked to log on via your netID and then it will
access the PDF of the paper.
Helpful Suggestions:
 Java Test Program for APIs: In order to learn about and use the various APIs (RxNorm,
RxTerms, NDF-RT, FDA) programmatically, we suggest that you consider writing a straight
Java-based program (non-Android) that will allow you to get experience with using the API
outside of the overhead of having it work in the Android environment. The key issue is to
understand what the calls expect (parameters) and what they return (data format – XML vs.
JSON). By doing so, you can get all of the calls to the APIs that you need working correctly,
tested and debugged prior to incorporating the code into PHA.
 Distribution of Work: The use of a test program for the APIs also gives each team the
opportunity to partition the work. You could have one teammate do the RxNorm, RxTerms,
NDF-RT APIs in preparation for their use in identifying drugs and interaction checking. You can
have another teammate work on the changes to the medication screen and perhaps adding in the
FDA Daily Meds link. You can have a third teammate work on the new checking interactions
screens that the displaying of the results which shows the level of severity of the interactions.
These are essentially three different components that a team can plan around rather than trying to
put everything into PHA at once.
Remember, one objective of the project is for your team to experiment and learn the new technologies by
leaning on each other, the other is to get used to working in a team and work somewhat on learning the
different ways you can partition the project into components.
Document Version and Source Code Control: github (http://about.github.uconn.edu/.) will be used for
the final project to allow all of the code to be shared and reliably backed up for each Team. You need to
log on to github with your NetID to become a user of the system. Once this is done, one of the team
members can create a project (that both of you can write) and share using the NetIDs of all members.
Each team should share also with Solomon (sob05001) and Prof. Demurjian (sad02010). Please make
sure you keep local copies of documents and code on your own computers for backup purposes. For using
git with Eclipse, please see the following link: http://wiki.eclipse.org/EGit/Git_For_Eclipse_Users
Project 4 Final Requirements
 December 5th, 2013, 12 midnight: All students mail their teams to steve@engr.uconn.edu and
Solomon.Berhe@uconn.edu. Remaining students will be assigned partners.
 Revisions to Medication Screen: Changes to medication screen in order to organize drugs
according to MSHV and OpenEMR.
 Additions to Medication Screen: For each medication, still allow a display of its data, but in the
case of OpenEMR, this must be read-only since they cannot be changed (not written back).
30
PHA Background

FDA Daily Meds: Each medication on the new screen should also have the ability to call the web
services for FDA Daily meds and show the resulting information in a new screen.
 New Medication Checking Screen: This can be initiated off of the revised medication screen
and will take the combined list of meds (from MSHV and OpenEMR) and return a list of meds
and their interactions.
 Usage of External Web Services: Utilize web services for FDA Daily Meds, RxNorm,
RxTerms, and/or NDF-RT as relevant to your specific needs and approach.
Note: Expect emails and information in both the lab and the lecture over the remainder of the semester.
31
PHA Background
Appendix A: Class Declarations of edu.uconn.model
public class HealthItem {
private static final String TAG = HealthItem.class.getName();
private static final String BLANK = "";
protected String key = "";
public HealthItem() {};
public HealthItem(JSONObject jo) throws JSONException {}
protected String jsonNull(String input) {}
public void setKey(JSONObject jo) throws JSONException {}
public String getKey() {}
public void setKey(String key) {}
public JSONObject toJSONObject() throws JSONException {}
}
public class Weight extends HealthItem { // Patient weight in kilograms
private static final double CONVERSION_VALUE = 2.20462262185;
private String weightValue = "";
public Weight() {};
public Weight(JSONObject jo) throws JSONException {}
public JSONObject toJSONObject() throws JSONException {}
public String getWeightValue() {}
public void setWeightValue(String weightValue) {}
public String toString() {}
public String getLbsValue() {}
}
public class Height extends HealthItem {
private String heightValue = "";
private String when = "";
public Height() {};
public Height(JSONObject jo) throws JSONException {}
public JSONObject toJSONObject() throws JSONException {}
public String getHeightValue() {}
public void setHeightValue(String heightValue) {}
public String getWhen() {}
public void setWhen(String when) {}
public String toString() {}
}
public class DemographicInfo extends HealthItem {
private String gender = "Unknown";
public DemographicInfo(JSONObject json) throws JSONException {}
public JSONObject toJSONObject() throws JSONException {}
public String getGender() {}
public void setGender(String gender) {}
public String toString() {}
}
public class Person extends HealthItem {
private String firstName = "";
private String lastName = "";
private String birthDate = "";
private String bloodType = "";
private String race = "";
private Height height = null;
private Weight weight = null;
private DemographicInfo basicInfo = null;
public Person() {};
public Person(JSONObject jo) throws JSONException {}
public JSONObject toJSONObject() throws JSONException {}
public void setFirstName(String firstName) {}
public String getFirstName() {}
public void setLastName(String lastName) {}
32
PHA Background
public
public
public
public
public
public
public
public
public
public
public
public
public
public
String getLastName() {}
void setBirthDate(String birthDate) {}
String getBirthDate() {}
void setBloodType(String bloodType) {}
String getBloodType() {}
void setRace(String race) {}
String getRace() {}
void setHeight(Height height) {}
Height getHeight() {}
void setWeight(Weight weight) {}
Weight getWeight() {}
DemographicInfo getBasicInfo() {}
void setBasicInfo(DemographicInfo basicInfo) {}
String toString() {}
}
public class Medication extends HealthItem {
private String name = ""; // medication name
private String strength = ""; // what is the dosage
private String dose = ""; // amount of drug, e.g., 500mg
private String howTaken = ""; // oral, shot, inhaled, cream
private String frequency = ""; // times per day, etc.
private String prescribed = ""; // is prescription or not
private String dateStarted = "";
private String dateDiscontinued = "";
private String note = ""; // reason for taking medication
public Medication() {};
public Medication(JSONObject jo) throws JSONException {}
public JSONObject toJSONObject() throws JSONException {}
public void setName(String name) {}
public String getName() {}
public void setStrength(String strength) {}
public String getStrength() {}
public void setDose(String dose) {}
public String getDose() {}
public void setHowTaken(String howTaken) {}
public String getHowTaken() {}
public void setFrequency(String frequency) {}
public String getFrequency() {}
public void setPrescribed(String prescribed) {}
public String getPrescribed() {}
public void setDateStarted(String dateStarted) {}
public String getDateStarted() {}
public void setDateDiscontinued(String dateDiscontinued) {}
public String getDateDiscontinued() {}
public void setNote(String note) {}
public String getNote() {}
public String toString() {}
public boolean isPrescribed(){}
}
public class ODL extends HealthItem {
private int energy = 0;
private int happiness = 0;
private int comfort = 0;
private int mobility = 0;
private int appetite = 0;
private String date = "No Date Specified.";
public ODL() {};
public ODL(JSONObject jo) throws JSONException {}
public JSONObject toJSONObject() throws JSONException {}
public void setEnergy(int energy) {}
public int getEnergy() {}
33
PHA Background
public
public
public
public
public
public
public
public
public
public
public
void setHappiness(int happiness) {}
int getHappiness() {}
void setComfort(int comfort) {}
int getComfort() {}
void setMobility(int mobility) {}
int getMobility() {}
void setAppetite(int appetite) {}
int getAppetite() {}
void setDate(String date) {}
String getDate() {}
String toString() {}
}
34