Team 2

From Cmsc434_s10
Jump to: navigation, search

Team 2 Team Members: Brian Ramnarain, Adam Stephenson, Jason Covey, & Mihir Patel.

Team 2 Group Photo : Feb 17, 2010

Team2GroupPic.jpg


Team 2's Project Proposal

Catchy Name

Doctor Robot

Descriptive Name

Interactive Management of Childhood Illness Clinic Treatment Tool.

Users and tasks

Target Users

Minimally trained Health Personel in rural areas of 2nd and 3rd world countries.

Expected age: 18+

Resonsible for diagnosis and record keeping with little to no training.

Need easy to understand instructions and program flow.

Supported Tasks

  • Select symptoms of child
  • Receive a diagnosis
  • Decide medication needed
  • Save information about child and diagnosis
  • Update the database of diseases and symptoms

Existing solutions and their limitations

Current Technicle Method

Currently, women in these developing villages are trained for 2 weeks. They are trained to use a 40 page flow chart to attempt to diagnose illnesses in children. The flow charts go from symptoms to diagnoses, and then to treatment.

Advanatages of Web App Solution

The 40 page flow chart is limited. It is hard to update the flow chart and get it out to remote villages all over the world. Also, it can take time to go through the flow chart to diagnose a child. A web application would be much faster than the current 40 page flow chart.

Meeting notes

Brainstormed Ideas

Computerized Medical Records

Interactive Childhood Illness Monitor

Emergency Room Priority Queue System

Data Base of Patient Sickness for 3rd world government record keeping

Insurence Policy Finder

Excercize tracker

Calorie Input Manager/Tracker

Physical Therapist/Trainer Helper Program

Whiteboard Photo

WhiteboardTeam2.jpg


User and Task Analysis

Three Applicable Techniques

Technique 1: Interviews

We could conduct an interview with Prabu Selvam, the person that presented the project to our class. We could take to him about what he is looking for in the final product. He also knows the user groups fairly well. He could answer questions on behalf of the users. Questions to ask Prabu:

  • How literate is the user group?
  • How computer savvy is the user group?
  • Do they have anyway of getting on the internet?
  • How long will you have to train users?

Tech 2: Studying documentation

Prabu sent us copies of the flow chart that the users currently use to diagnose childhood illnesses. We could try and interpret from the flow chart information about our user group.

Tech 3: Questionnaire

We could send out a questionnaire to users of the current flow chart. We could ask them basic questions about themselves and also ask them questions about how they feel about the current system. Since reaching actual users may be impractical, we could try and reach people that train the users.

Chosen Technique to Carry Out:

Chosen Technique # 1: Interview

We chose to interview Prabu Selvam, who is a user representative. He gave a presentation on the users, tasks, and past implementations of IMCI. We were able to ask questions like did he want a smart phone or desktop app. He also told us about the basic information he wanted to be stored in the database. He explained that their would be at least 2 user groups. The women that would be using the program and also doctors that may be auditing the system. He laid out a long list of tasks the user would need to be able to do.

Distinct User Classes

User Class 1: Nurses

  • Age: 18-30
  • Education: Literate, 2-3 week training program on how to use program
  • Job: diagnose children
  • Computer Skill: very little
  • Computer Experience: very little
  • Location: small village in a developing nation
  • Motivation: help sick children
  • Social Context: women are not normally treated with as much respect
  • Usage Pattern: everyday


User Class 2: Health Department Worker

  • Age: 20+
  • Education: College degree
  • Job: get information from database
  • Computer Skill: moderate
  • Computer Experience: years
  • Location: office in United states
  • Motivation: find out most prevalent diseases in village
  • Social Context: wants to help by seeing where more medication needs to be sent
  • Usage Pattern: monthly or yearly


User Class 3: Government worker

  • Age: 22+
  • Education: High school,maybe college
  • Job:update software
  • Computer Skill: moderate
  • Computer Experience: years
  • Location: office in Developing nations
  • Motivation: update outdated software
  • Usage Pattern:monthly or yearly

Distinct User Class Personas

User Class 1 Persona: Ashley is a 19 year old girl from a small village in India. She can read and write but has not gone to school formally. She has very little computer experience, but is a fast learner and is confident she can learn to use IMCI in 3 weeks. She hard working and really wants to be able to help children in her village. She uses IMCI at least once a week to help diagnose a child.

User Class 2 Persona: Kevin is a 20 year old intern at the health department in Washington D.C.. He is a junior at the University of Maryland. He has a lot of computer experience. His boss wants him to pull up statistics on how many children in India died of cholera last year. He uses IMCI once a month to do research for his boss.

User Class 3 Persona: Rohan is a IT specialist who works for the government in India. He graduated from college and has a lot of experience with computers. His job is to update the IMCI software with new files that maps new symptoms to new diseases. He performs an update to IMCI every month.

Non-User Stakeholders

Stakeholders: U.S. health department, government officials in developing nations, people working on E-IMCI, children being diagnosed

Tasks

Task 1

Name: Log in

Goal: Obtain the users profile, either a stored patient list for a specific medical worker or an empty list for a guest profile.

Preconditions: Program started and running.

Sub tasks: Type in user profile name or guest. Click Enter to proceed.

Complexity:simple


Task 2

Name: Protocol Selection

Goal: Choose how to view, use, and modify your profile data from a list.

Preconditions: Have entered a user profile or guest profile.

Sub tasks: Select a protocol from a list. Click Next to proceed

Complexity: simple

Task 3

Name: Use Protocol

Goal: Allow user to utilize protocol to view or add patients or to view, process, and record patient illness diagnosis.

Preconditions: User profile obtained and appropriate protocol selected

Sub tasks: Implement protocols to manage patient lists and patient diagnosis records.

Complexity: high

Design Sketches

Most Important Tasks

1. Registering a patient 2. Putting in the symptoms 3. Selecting what treatment to give the patient

Scenario:

Nadira is a young 19 year old woman from small village in India, who is a nurse using our system. A young patient named Kevin is brought in with the symptoms of vomitting, muscle cramps, dehydration, and diarrhea. So Nadira logins into the application on her computer. And then she picks the protocol (one of the major symptoms), for diarrhea. Then a list of other symptoms come up, then she has to check off from the list of symptoms, the ones which Kevin is experiencing, so she picks vomitting, muscle cramps, and dehydration from the list. Then, a list of diagnosises comes up, ranking from the most likely to the least likely. She now has to choose the disiease that fits the situation of Kevin. She accidently chooses flu from the diagnosis menu and must hit back in the treatment menu to get back to the diagnosis menu. Now she chooses Chollera from the diagnosis menu, and the detailed view comes up with the list of treatments. She examines the list to find the one which would be easiest to apply given her situation. She picks the treatment antibiotics. She applies the chosen treatment to the patient, Kevin, and then she proceeds to register Kevin's personal information into the computer for the case and then she submits it and the computer returns to the home screen with a list of protocols for the next patient that comes in.

Conceptual Storyboard

Design Sketches

Team2 design sketch1.jpg Team2 design sketch2.jpg

UI Storyboard

Team2 ui storyboard1.jpg Team2 ui storyboard2.jpg

Paper Prototype

Write Up Part 1

Risk assessment

The home button, selecting incorrect treatments, not filling out all symptom questions, and the emergency protocol are considered risky. The home button is tested during each scenario. Incorrect treatment selection testing happens during the treatment selection scenario, and symptom question testing during the symptom questioning scenario. The emergency protocol is tested with the emergency protocol log in scenario.

Prototype photos

Log in & Protocol select scenarios:

Team2paper1.jpg


Symptom Questionnaire & Diagnosis scenarios:

Team2paper2.jpg


Treatment Selection & Patient Treatment Information scenarios:

Team2paper3.jpg

Briefing

Users were told they were a medical worker that must use our program to diagnose and treat a patient, which was a thirteen year old boy named Billy. Billy has symptoms of the protocol 1 category and is experiencing symptom two. To begin using the program you log in with your doctor name and password and then follow the steps.

Scenario Tasks

1. Log in

2. Select Protocol

3. Fill out Symptom Questions

4. Select Most Likely Diagnosis

5. Select Best Treatment

6. Enter Patient information to obtain treatment dosages & specifics

7. Save the patient's diagnosis and treatment data

Observations

A little confusion occurred during testing was due to the fact that we designed an abstracted prototype with numbered choices for protocols, symptoms, diagnoses, and treatments as we will be implementing the framework for the program leaving the medical jargon to the doctors. These aren't really user errors as they won't happen in the final prototype that has pictures on the buttons.

The home button should perhaps be renamed log out, or a home screen added, either way the home button should be moved to a corner so users don't accidentally hit it and lose any entered information.

Write Up Part 2

Prototype iteration

We changed the placement of buttons, namely the risky home button to more appropriate locations and also changed the name of 'home' to 'log out' as it takes the user to the log in page. Upon pressing log out a comfirmation box appears asking the user "log out?" with yes/no buttons.

Incorrect next buttons were removed as the program should move to the next screen upon clicking a diagnosis or treatment without needing a 'next' click.

Observations

Real users were guided through the prototype very easily as the selectable number of symptoms, diagnosis, and treatments is very small. We are now concerned about user errors that will occur when the lists are filled with the medical information.

Risk resolution

The home/log out button still seems risky as it logs the user out and loses any data entered. Data loss can be very frustrating for users. It's new location in the top left corner makes it difficult to press accidently and the confirmation box makes it almost impossible to lose data by user error.

Having the user choose a diagnosis and treatment from a list is risky as user errors can have heavy consequences, this issue will have to be handeld by the medical personel by providing effective descriptions and requirements for a diagnosis treatment combo.

Computer Prototype

System Requirements

  • Browser: Chrome or Firefox
  • Platform: Windows or Mac
  • Screen Resolution: Any

Starting Up Instructions Media: Dr.Robot.swf

Fidelity You can log in under any username password combination as long as there is some text in both fields. For the protocol you can click on any protocol other than emergency, that has not been implemented yet. The symptoms screen has been implemented and so has diagnoses and both treatment screens. You should be able to save and return to log in screen. All back and logout buttons should be working.

Comparisons

Team2paper1.jpg Team2cp1.jpg

                          Team2cp2.jpg

Team2paper2.jpg Team2cp3.jpg

                          Team2cp4.jpg

Team2paper3.jpg Team2cp5.jpg

                          Team2cp6.jpg

Experimental Design

Brian Ramnarain

Competing System

We would compare our IMCI implementation with the other 2 IMCI implementations

Hypothesis: Which tool allows you to diagnose a patient the fastest?

Independent: The IMCI implementation used

Dependent: Speed of Diagnosis

Controls:

  • Computer used: the same computer would be used for each experiment
  • Training given in IMCI: same amount of training given to each participant
  • Patient information: same patient information used in each test for each participant

Task: Diagnose a patient

Between Subject experience in each program may lead to increase in speed

User population: Who: College Students How: Get students from our class not working on IMCI It would be difficult to get our actual target audience to do our test. Fellow HCI students may be able to take the perspective of our target audience.

Null Hypothesis: All implementations are equal in speed

Alternative Hypothesis: Our implementation is the fastest

Pedro Ferreira

Competing System

We would compare our IMCI implementation with the official IMCI chart booklet.

Hypothesis: Which tool allows you to diagnose a patient the fastest?

Independent: Using Dr Robot vs Using the IMCI book.

Dependent: Speed of Diagnosis

Controls:

  • Computer used: the same computer would be used for the computer tests.
  • Software Used: All computer tests would use Dr. Robot.
  • Booklet Used: Since a physical booklet is not readily available, same stapled printout would be used.
  • Training given in IMCI: same amount of training given to each participant.
  • Patient Characteristics and Symptoms: Patient age, gender, location, and symptoms would be the same for both tests.

Task: Diagnose a patient

Between Subject Low overall computer knowledge could lead to slower results when using Dr. Robot.

User population: Who: College Students, Friends, and Nearby Family. How: Get students from our class not working on IMCI

It would be difficult to get our actual target audience to do our test. Fellow HCI students may be able to take the perspective of our target audience.

Null Hypothesis: Both methods are equal in speed

Alternative Hypothesis: DR. Robot is faster.

Mihir Patel

Competing System

We would compare our IMCI implementation with the other 2 IMCI implementations and measure ease of usability

Hypothesis: One IMCI implementation out of the 3 tested will be rated the most usable by the users

Independent: The IMCI implementation used

Dependent: Usability Rating

Controls:

  • Computer used: the same computer would be used for each experiment
  • Training given in IMCI: same amount of training given to each participant
  • Patient information: same patient information used in each test for each participant

Task: Diagnose a patient, then take usability survey

Between Subject experience in each program may lead to increase in speed, user preferences may skew usability ratings

User population: Who: College Students How: Get students from our class not working on IMCI It would be difficult to get our actual target audience to do our test. Fellow HCI students may be able to take the perspective of our target audience.

Null Hypothesis: All implementations are rated the same in usability

Alternative Hypothesis: One implementation stands out as the most usable

Adam Stephenson

Competing System

We would have our system compete for overall ease of use against the other IMCI systems.

Hypothesis: Our system will be the easiest to use by the users population.

Independent: The IMCI implementation being used

Dependent: Rating of ease

Controls:

  • The computer the test is being performed on
  • The person testing
  • The complexity of the task

Task: Diagnose a patient, choose a treatment, and enter the patient's information

Between Subject As the controlled tester tests more, the easier it seems

User population: Who: Young women How: Young women will be the closest thing to our user population that we can find. We can find such women all over the campus that can help us.

Null Hypothesis: All implementation have the exact same level of ease.

Alternative Hypothesis: Our implementation is the easiest implementation.

Jason Covey

Competing System

We can compare overall usability against popular online medical diagnosis tools such as www.diagnose-me.com and webMD.

Hypothesis: Our system will be rated top in usability

Independent: The diagnosis tool being used

Dependent: Rating of usability

Controls:

  • platform web browser is run on
  • monitor web browser is run on
  • input devices web browser is tested with
  • information given to tester
  • correct diagnosis (unknown to tester)

Task: Obtain a diagnosis and treatment suggestion from the web application

Between Subject Controlled Tester's usability performance increases relative to time spent with app

User population: Who: freshmen community college students in biology or medically related fields

How: contact local community college to send out all biology/health field related faculty wide email requesting assistance in our study. Offer to come at convenient times for classes and work with teachers to provide overview education lecture on the diagnosis tools available on today's inter-web.

Null Hypothesis: All web apps have the same usability

Alternative Hypothesis: Our diagnosis application is top rated in usability thus showing it's superiority


Final Implementation

Plan

UI: Must have

  1. Allow data retrieval in UI from patient xml [Mihir]
  2. Allow data retrieval from the IMCI xmls
  3. Allow data retrieval in login xmls [Mihir]
  4. We need have working login [Adam]
  5. Automated add data to existing patient [Jason]
  6. Working logic for diagnosis

UI: Nice to have

  1. Allow for user creation [Pedro]
  2. Search for patient [Brian]
  3. Edit patient data [Brian]
  4. Change visual design [Adam]

Server: Must have

  1. Implement server side functionality [Mihir/Brian]
  2. Implement a users xml
  3. Implement xmls for the IMCI flow chart
  4. Implement a patient xml [Mihir/Brian]
  5. Implement the whole IMCI flow chart into the IMCI xmls

Server: Nice to have

Execution of the Plan

  1. Allow data retrieval in UI from patient xml [Mihir] Mihir implemented
  2. Allow data retrieval in login xmls [Mihir]
  3. We need have working login [Adam] Adam implmented
  4. Automated add data to existing patient [Jason]
  5. Allow for user creation [Pedro] Pedro implemented
  6. Search for patient [Brian] Brian implemented
  7. Edit patient data [Brian] Brian implemented
  8. Change visual design [Adam] Jason implemented
  9. Implement server side functionality [Mihir/Brian] Mihir/Brian implemented
  10. Implement a patient xml [Mihir/Brian] Mihir/Brian implemented

Final Implemenation: Media: dr_robot_final_implementation.swf