Script for Group 6 – PMR-Droid
- Project Overview (Kurt)
- Our application provides a personal medical record that you can view and comment on right from your Droid.
- 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)
- 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
- 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
- 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.
- 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
- 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)
- We had to research the Android 2.0 API and emulator
- Basically just java with limited functionality
- Our prototype is made from this API and emulator
- The constraints for our project are:
- 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)
- Medical records often contain extremely sensitive information
- We’ve identified a handful of risks related to security
- 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
- Physicians and patients will be required to enter a password to access our program’s data
- Data needs to be encrypted before being sent over the Verizon network, and whenever it is passed between users and the database
- A secure authentication protocol must be used to protect the encrypted data being sent to the server by physicians
- Use Case Diagram (Joe)
- Login/Logoff: Doctor to the doctor side and patient to the patient side
- 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.
- Edit Info: The doctor can and edit any entry, then send it to the database. The info is frozen for the patient to edit
- 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
- Comment info: the patient cannot edit the text information (its frozen), but can comment on any part of an entry
- 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.
- 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.
- 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. For images, it displays a link that you can click on to download the image to view.
- Class Model (Tom)
- 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
- Our database stores all of our medical records
- (next slide)
- 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)
- This is the sequence diagram for the doctor adding a patient
- First the doctor logs in.
- He creates a new record and fills in the fields for the patient’s basic info.
- 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.
- If he needs, he can upload images that relate to the specific entry
- After the doctor finished doing everything, he updates the contents of the database by syncing it.
- The doctor can edit existing info for a record
- State Diagram (Tom)
- Our state diagrams are shown for two of our main classes, “Patient” and “Health Care Provider”
- 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
- 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
- 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
- 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)
- 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
- This is the same case with emergency contact information
- All other categories are locked out until the user has logged in
- Once logged in the user is able to access all features of the prototype
- Return to basic information:
- Notice the edit button is now enabled.
- The SSN is now viewable also
- 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
- Go through all other fields
- Once in lab results, show that there is a picture that is downloaded along with information about that.
- In fully implemented application you will be able to zoom in on the picture/test
- Same goes with the Test results field
- Sample Scenario (Jacob)
- 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
- (Fill out the basic information)
- (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.
- (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)
- 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
- 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.
- 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.