1. Script for Group 6 – PMR-Droid
• Project Overview (Kurt)
o Our application provides a personal medical record that you can view and
comment on right from your Droid.
o Allows you to have your medical record with you at all time
 Go to doctors
 Emergency
 Look up medications and dosages
 Check your follow ups
• Overview of Features (Kurt)
o Easy way to store and navigate through you entire medical record
 Touch screen
 Keyboard
 Tabs for every major group where you can then navigate into for
the details
o Basic Info page
 Contains basic info
• Name
• Age
• Height
• Blood type
 Good for emergency
 You will be able to hide whatever information you don’t want
easily viewable
o Allows you to update your PMR
 As long as you have Internet access you can update your latest
PMR from a central database where your doctor uploads your
medical record.
o Comment or upload image
 When you comment on your medical record it is flagged to
maintain data integrity
 Upload an image of your medical condition
o Backup PMR to computer
 You can store a backup on your computer in case you ever need it
 You can comment on your PMR on your computer as well
• Domain Research (Kurt)
o We had to research the Android 2.0 API and emulator
 Basically just java with limited functionality
o Our prototype is made from this API and emulator
o The constraints for our project are:

2.  Only works on Droid running the Android 2.0 operating system.
 Memory constraints for storage on the phone so we do not store
large files, like images, on the phone
 We do have the ability to select an image to download if you know
it is important and it would be something you would want to see
bigger.
• Risk Analysis (Tom)
o Medical records often contain extremely sensitive information
o We’ve identified a handful of risks related to security
o Main concern is the security of data in the database
 Multilayer firewall approach allows us to separate data, and place
the most sensitive data behind multiple firewalls
 Access to database should be restricted by IP to limit potential
attacks
o Physicians and patients will be required to enter a password to access our
program’s data
o Data needs to be encrypted before being sent over the Verizon network,
and whenever it is passed between users and the database
o A secure authentication protocol must be used to protect the encrypted
data being sent to the server by physicians
• Use Case Diagram (Joe)
o Login/Logoff: Doctor to the doctor side and patient to the patient side
o New Record: doctor registers the patient, allocates space in the database
for a new medical record, and inputs any initial info. The record has
contains the patient's name, SSN, and other id info, and medical record
entries.
o Edit Info: The doctor can and edit any entry, then send it to the database.
The info is frozen for the patient to edit
o Add Image: doctors and patients can add an image as an attachment to
any medical entry. When uploaded to the database, it will be flagged as
either patient or doctor uploaded
o Comment info: the patient cannot edit the text information (its frozen), but
can comment on any part of an entry
o Sync: Sync is where information is updated on the database. When a
doctor syncs, it adds and updates any entries and images to the db. When
a patient syncs, it updates the entries with the patient's comments and any
new patient added images, and downloads to the phone any new or
updated entries and images put in by the doctor.
o Backup: The patient can plug the phone into a desktop or laptop computer,
and the copy of the PMR stored on the phone (in encrypted xml form) will
copy to the computer.
o Display: Display is what the patient does most. It parses the xml input
from the database, and displays the data on the phone one entry at a time.

3. For images, it displays a link that you can click on to download the image
to view.
• Class Model (Tom)
o The first portion of our class diagram shows the users of our system
 Health care providers and patients are both able to modify the data
in our database
 Health care providers can have a number of patients, and patients
can be associated with a number of providers
 A patient can also backup his/her data to a separate computer
o Our database stores all of our medical records
o (next slide)
o Each medical record is made up of a number different types of information
 Basic info stores the patient’s basic information, such as name,
date of birth, social security number
 Not pictured under basic info are family history, insurance
information, etc.
 All of a patient’s medical history is stored as a series of “entries”
 Entries include medications, medical procedures, medical
conditions, etc
 Not pictured are allergies, vaccinations
 “Result” is how we store test results and lab results
 Entries can also be associated with images, which can be images of
test results, scanned documents, or anything else that may be
relevant
• Sequence Diagram (Joe)
o This is the sequence diagram for the doctor adding a patient
o First the doctor logs in.
o He creates a new record and fills in the fields for the patient’s basic info.
o He adds a new medical entry and fills in the fields. He does this as often
as needed to get all the patient’s medical history as the doctor wants to
enter.
o If he needs, he can upload images that relate to the specific entry
o After the doctor finished doing everything, he updates the contents of the
database by syncing it.
o The doctor can edit existing info for a record
• State Diagram (Tom)
o Our state diagrams are shown for two of our main classes, “Patient” and
“Health Care Provider”
o Patient:
 Initially, a patient logs in to the system on his/her phone, entering
the “logged in” state
 From here, information can be grabbed from the database using the
sync() function

4.  Information is displayed on the screen using the “display()”
function
 A patient can also upload an image or make a comment on any
piece of medical information at this stage
 When a patient’s info is changed, it’s flagged as such, entering the
“local patient info changed” state
o From here a patient can sync the changes back to the database (where they
remain flagged), or can log off the system, and the changes remain local
on the device but not on the database
o Health care provider:
 HC provider initially logs into the system
 From here, provider can add a new patient, display the patient’s
info, or log off
 If the provider begins to edit a medical record, the provider enters
the “editing info” state
 Once the editing is complete, the record is synced back to the
database
 When the provider is done using the system, he or she logs off
• Prototype (Mike)
o Talk about the ability to click into the basic information button, to view
data
 Notice that SSN is not displayed currently; in the actual application
there would be a feature to select which categories you want
displayed
 Talk about the inability to edit information
o This is the same case with emergency contact information
o All other categories are locked out until the user has logged in
o Once logged in the user is able to access all features of the prototype
o Return to basic information:
 Notice the edit button is now enabled.
 The SSN is now viewable also
o Now in edit, all fields are editable
 Once done editing going back to basic info and the color is now
red
 In the finished application the user will not be able to edit all
information, but will be able to comment under certain fields and it
will show up in the database as such
 If returned with unchanged notice all fields that had been changed
are now back to normal
o Go through all other fields
o Once in lab results, show that there is a picture that is downloaded along
with information about that.

5. o In fully implemented application you will be able to zoom in on the
picture/test
o Same goes with the Test results field
• Sample Scenario (Jacob)
o Doctor’s Scenario
 (Go on the website -> Prototype -> form)
 This is meant to represent what physicians or doctors would do.
 Doctors will see this form.
• They can fill out the information
o (Fill out the basic information)
o (Make a mistake on my name.)
• To add each category such as medication taken or lab
results, other than the basic information the doctor will
have to click on “Add (Category)” after inputting the data.
o (Fill out the medication)
• After everything is done, click on “Submit All” to save all
the info to the output file.
• This is what the output file would look like. This is an
XML file.
• (Copy the result to sample_xml.xml)
o Patient’s Sequence Diagram
 (Show the patient’s sequence diagram)
 When the patient first start up the program, the patient will have to
login
• When the patient logs in, the login() function gets called
and get the information from the server.
 After the patient logs in, sync function gets called to automatically
update the info on the phone.
 Basic info and Entry are inherited from Medical Record. To
display info, the phone calls display function to medical record and
Medical Record calls display function on basic info or entry class
to display the information on the phone
• To display image, downloadimage function in Entry gets
called and download the image from the server
 If the patient wants to comment on the data, the phone will call
commentInfo() function to comment on basic info or entry. It
works similar as display function
 If the patient wants to backup the data, backup info gets called to
back up the data to the computer
 When the user logs off, it tells the database that the user is logging
off
o Patient’s Scenario
 This is meant to represent what a patient would do.
 The patient will want to log in, look through the information, and
edit any wrong information on the phone.

6.  First a patient will log in to see their information.
• (Log in)
 After logging in, the patient can look through their information by
going through each section
• Go to basic info
 In the screen, the name is wrong. Then the patient can click on the
Edit button to edit the name
• (Change it to the right name)
 When you edit the data on the phone, the patient can see it what
was edited as red.