Team 1

From Cmsc434_s10
Jump to: navigation, search

An application for diagnosing childhood illnesses in developing countries

Team members:

Amit Chauhan, Leyla Norooz, Kelly McDuffie, John Fan and Anand Shroff...the A-Team! Too bad Ben wasn't in it =(

Contents

Project Proposal: Diagnosis Automation Tool (D.A.T)

Current name of application: Diagnosis Automation Tool (D.A.T).

Users and tasks

  • Our target audience is undereducated young women (ages 16 and up) in developing countries such as Bangladesh who will have received about a week and a half of professional medical training by doctors and other health workers before being placed in medical centers in said countries where they will see patients, record their symptoms, develop a diagnosis and administer treatment.

Tasks we wish to support through a web application:

  • Allow users to input patient symptoms, speeding up the IMCI flowchart process.
  • Produce the most accurate diagnosis through user input of symptoms.
  • Display treatment options through both text and image.
  • Store patient information (name, age, gender, etc.) along with symptoms and diagnosis for follow-up appointments.
  • Allow users to save a text version of the data they input.

Existing solutions and their limitations

  • The current solution that exists is that the IMCI flowchart process is done by paper and pencil. Health workers flip through forty pages of questions and charts relating to their patient's symptoms. Depending on what the user answers for particular questions, a flow chart will designate them to the most likely diagnosis. Based on the diagnosis, users provide appropriate treatment.
  • One limitation on this solution is that users will not remember what question is on what page and thus must flip through page after page to find what they are looking for. Another one is that there is nothing stopping a health worker from skipping potentially important questions.
  • A web application would be more efficient, easier to use and less error-prone than the current solutions. Users would not have to flip through forty pages of material, but go through a form-like application that only involves inputting data and clicking on buttons/links. The application would automate the flowchart process, deciding on the best likely diagnosis rather than the user forced to follow the charts using their eyes and hands. Finally, the application would provide a easy-to-read final review page with the answers the user provided, so that they would only have to read one page as opposed to flipping through a packet.

Meeting notes

Ideas we brainstormed included:

  • A WebMD-like application where users check off symptoms and then are given a list of possible diagnoses
  • A form-like application where users answer questions about the patient then go on to the next page.
  • Application that acts like a self-building flowchart, dependent on user input.
  • An application that contains a database of patient records
  • An application could accept text or XML files that contain a list of symptoms and respective diagnoses so that it wouldn't be limited to just for IMCI purposes.
  • Have an option in the application for the user to save a text format of all the data they store.
  • For all applications ensure users cannot skip questions.
  • If symptoms appear too serious, then application will notify user to take patient to the emergency room.
  • An application where the user inputs their current location (i.e country) and the applications produces possible health problems based on location.

Our whiteboard pictures and a flowchart representation of how the application might work.

Team1 Ds1.png Team1 Ds2.png Team1 Ds3.png Our brainstorming diagram.png

User and Task Analysis

Data Gathering

Three techniques we believe would be applicable to our project:

Interview

Our group could interview Prabu Selvam, who would a user representative, since he had the most knowledge regarding the users of this application. Questions would include:

  • Would these health workers have any prior computer experience
  • Will the users have access to new laptops/netbooks?
  • How much English, if any, can the users understand?
  • How old, on average, will the users be?

Studying Documentation

Prabu provided us with the IMCI flowcharts and other documents explaining how the process works. We can analyze how the application should work and also how simple the application should be for our users, since it will be mimicking the flowchart process.

Researching Similar Products

D-Tree International initially created a PDA-based tool that mimicked the IMCI flowcharts. We could study the application to give us ideas and also to find potential problems that the developers faced before.

The Interview

Our group decided to interview Prabu, who was the user representative. Prabu was kind enough to host a meeting for all the groups working on the IMCI application. A few members from our group attended the meeting, where he gave us a handout that explained the users and their tasks in great detail. This answered most of the questions our group had prepared. Even then, Prabu answered questions such as: "What would be the specs of the netbooks these health workers would be using?" and explained some of the other tasks in detail to all the groups.

Users Classes

Three classes of users include:

Health Workers

This class of users will consist of women around 18 years of age. They will not have received proper education and as such will have low literacy. They will be at health centers in third world countries, where they will see young patients. The health workers will have had no experience using a computer. The workers will be using this application quite often. Workers are quite motivated because they are looking to gain the respect of their peers as well as helping children who may other wise suffer. Since the workers are women in third-world countries, they are often viewed as inferior and not given the same opportunities.

Trained Physicians

This class of users will consist of both men and women. Their ages would vary from possibly 30-50 years. These physicians would have received high quality education. Physicians may be at any location in the world, seeing patients. Physicians would have basic to advanced computer experience. Unlike the health workers in third world countries, the motivation of the physicians would be higher, since they are in better working conditions. Many physicians are seen as important people and are regarding much better then the health workers in third world countries.

IMCI Technician

This class of users will consist of both men and women. Their ages would be 21+. These users would have recently graduated from a university. Many of them would be located in the same health centers as the Health Workers, providing technical assistance and updating IMCI software. Technicians would have a high level of proficiency with computers. Technicians would have high motivation, because they would be in charge of ensuring the netbooks at the health centers work so that Health Workers could continue diagnosing patients efficiently. If any modifications are needed, they must take time to make sure that the Health Workers are able to use the software easily and that the correct information is being gather, interpreted, and diagnosis given.

Personas

Karen is an 18 year old girl from a village in Bangladesh who just recently became a Health Worker at the health center in her village. She received one and a half weeks worth of training from doctors and other personnel. While she can read and interpret numbers, she has not received a proper education. Her peers look down on her because she is a woman, but she hopes to gain respect of the community as well as helping her fellow people through properly diagnosing patients with the use of the IMCI software. At first the software will seem intimidating to her, but she will be able to quickly learn from it and hopefully find it much easier than using the paper packet. Karen will heavily use the software.

Gregory is a 32 year old man from the United States. He is a physician working at Johns Hopkins. He received a high quality education and is currently practicing medicine. He is very literate and good with numbers. Gregory is also proficient with computers and is not intimidated by software. He is well respected by his peers and his highly motivated to help diagnosis and treat patients. He will most likely use the software on a limited basis, mainly for record keeping and reinforcing what he already knows.

Vinod is a 23 year old man who graduated from a college in India. He became a technician at a health center in Bangladesh. He is very proficient with computers and is in charge of updating the IMCI software. He is seen as an integral part of the IMCI system, since health workers depend on the software he is in charge of updating. He will need a functional knowledge of medicine and must work closely with both Karen and Gregory to ensure that the software is providing the correct aid in giving children the health care they need.

Potential Stakeholders (Non-Users)

Other various health organizations in developing countries who face similar issues with diagnosing problems. Also, the very patients that the health workers see are stakeholders for the obvious reason that the software is meant to help the health workers find the most accurate diagnosis.

Tasks

  • Task: Enter patient information
    • Goal: Input patient information into a database that can be looked up later.
    • Preconditions:
      • User must know the patient's name, gender, approximate age and other attributes NOT related to symptoms.
      • User must have access to the IMCI software.
    • Subtasks:
      • User must log into IMCI software
      • User must enter information on Patient Info page.
    • Complexity: Low. All the user must do is input information and hit a button.
    • Frequency: Few times a day.
    • Potential Errors: User might misspell a name, input wrong gender, ignore other questions, etc.


  • Task: Develop a Diagnosis
    • Goal: User wishes to determine the most accurate diagnosis for the patient
    • Preconditions:
      • User must know the symptoms that the patient is suffering from.
      • User must have access to the IMCI software.
    • Subtasks:
      • User must log into IMCI software
      • User must answer questions regarding patient's symptoms.
      • User must confirm all symptoms are listed.
    • Complexity: Low-Moderate. First time users might be intimidated by the process, but the questions and steps will be simple to read. Images will be included for clarity.
    • Frequency: Few times a day.
    • Potential Errors: User might forget to answer a question.


  • Task: Look up Patient Information
    • Goal: Retrieve information about a patient from a database.
    • Preconditions:
      • User must know the patient's ID, which is assigned when they first input the patient's information
      • User must have access to the IMCI software.
    • Subtasks:
      • User must log into IMCI software
      • User must enter Patient ID in the Lookup Box..
    • Complexity: Low.
    • Frequency: A few times a week at most.
    • Potential Errors: User could input a non-existent patient ID or input patient ID of another patient by mistake.


  • Task: Get Quick Diagnosis and Treatment During Emergencies
    • Goal: Retrieve a treatment based on a diagnosis that is obvious and needs quick treatment.
    • Preconditions:
      • User must know the patient's symptoms and be able to recognize obvious sicknesses.
      • User must have access to the IMCI software.
    • Subtasks:
      • User must navigate to the "Quick Diagnosis" section of the webpage.
      • User must find the "Diagnosis" on this page and quickly find a treatment.
    • Complexity: Low-Moderate: user must search for the diagnosis during an emergency
    • Frequency: Depends on how often the clinic has emergencies.
    • Potential Errors: User might click on the wrong diagnosis.

Design Sketches

Scenario(s)

Scenario 1 - Main Persona: Health Worker

Amy, an 18-year-old girl from a village in Bangladesh, recently became a Health Worker at the health center in her village. She has been trained to use the new D.A.T. software to diagnose patients (PRECONDITION). On her first day, a boy John comes into the clinic with a myriad of symptoms (diarrhea, fever, vomiting) (PRECONDITION). Amy creates new patient chart (SUBTASK) for John and enters in his personal information (TASK). She then chooses a symptom category and answers yes or no for each specific symptom (TASK). After answering each individual question (except one) she tries to click the diagnose button (ERROR). A pop-up comes up and alerts her to which item she forgot to answer (ERROR RECOVERY). Amy answers this question and then presses the diagnose button (SUBTASK). The next page shows a list of a few diagnoses, with the most probable one highlighted. Amy chooses one, clicks it, and then describes the treatment plan to John (SUBTASK). She sends him home and requests that he return in two weeks for a follow-up appointment (SUBTASK).

Two weeks later, John returns for his follow-up. Amy logs him in (with his generated log-in) and confirms that he is healthy and that the diagnoses/treatment were accurate(TASK).

Scenario 2 - Secondary Persona: Physician

Amy, our 18-year-old trained physician, is at the clinic when a woman bursts into the room with a 10-year-old boy in her arms. The child has been burned in a house that caught fire (HIGHLY MOTIVATED). Amy rushes to the child and examines him. She sees that the child has several burns on his body (PRECONDITION). She quickly goes to her computer and navigates to the "Quick Diagnosis" section of our webpage (SUBTASK). She finds the "Fire Burns" section and clicks on it (TASK). She reads the "Symptoms and Treatment" section and hurries to treat the child (SUBTASK). After the child is fully treated, Amy creates a new patient chart and enters his personal information (SUBTASK). The information from the Quick Diagnosis page is automatically entered into the Symptoms section of the form. Amy sends the child and his mother home and tell them to return in two weeks for a follow-up.

Two weeks later, the mother and child return. Amy observes that child's burns are healing quickly. She logs him in (with his generated log-in) and confirms that the child is healing and that the diagnoses/treatment were accurate (TASK).

Scenario 3 - Secondary Persona: Physician

Amy, our 18-year-old trained physician, is at the clinic when a man and his 15 year old son walk in. The boy is has a fever and has been vomiting(MODERATELY MOTIVATED). As Amy begins to take the patient's information, the father comments that they had come in a couple years back when his son was diagnosed with dehydration(PRECONDITION). Not wanting to have multiple entries in the system for the same patient, Amy navigates to the ID look-up section of the website(SUBTASK). Here she enters the boys name and age to retrieve all relevant profiles currently in the system(SUBTASK). Once Amy has the boys ID, she can then enter the ID as an existing patient. The system would then lead Amy through the diagnosis procedure(TASK). Amy completes this task and successfully diagnosis the boy with pneumonia(TASK). Amy is able to give the treatment information to the family(TASK)!

The boy returns with his father three weeks later feeling much better. Amy logs him back into the system, confirming that he is cured! (TASK)

Preliminary (UI) Design Sketches for Scenario

Chauhan Design1.JPG Chauhan Design2.JPG

Conceptual Storyboard

UI Storyboard

Paper Prototype

Risk Assessment

1) The initial selection of the task -- The combination of all three scenarios tests this attribute

2) Recalling a previous patient's information. -- Returning Patient Scenario

3) Ensuring the program collects all necessary information correctly. -- The first scenario which diagnosis a new patient tests this functionality

4) Allowing the program to have the capability for an emergency diagnosis while still ensuring that the correct diagnosis is given. -- The scenario with the emergency patient tests this attribute.

Prototype Photos

Briefing

Our project is aimed to assist women in third world countries to diagnose children with simple diseases in an effort to save lives. Currently there is a paper manual in the form of a flow chart that these women are supposed to follow. Due to preconceived notions of women as well as literacy issues the correctness of this process is deteriorating. We are aiming to automate this process in an effort to ensure the accuracy and confidence of these diagnosis. The application will prompt the user to gather specific information about the child in order to be able to make an educated, accurate diagnosis of the child's illness. This application should be very easy to follow with aids to help people with low literacy skills gather the needed information. The application should walk a user through all relevant symptoms and provide a definitive diagnosis in a manner that is easy to understand.

Scenario Tasks

Scenario 1 - Walk through the process of diagnosis of a new patient

Amy, an 18-year-old girl from a village in Bangladesh, recently became a Health Worker at the health center in her village. She has been trained to use the new D.A.T. software to diagnose patients (PRECONDITION). On her first day, a boy John comes into the clinic with a myriad of symptoms (diarrhea, fever, vomiting) (PRECONDITION). Amy creates new patient chart (SUBTASK) for John and enters in his personal information (TASK). She then chooses a symptom category and answers yes or no for each specific symptom (TASK). After answering each individual question (except one) she tries to click the diagnose button (ERROR). A pop-up comes up and alerts her to which item she forgot to answer (ERROR RECOVERY). Amy answers this question and then presses the diagnose button (SUBTASK). The next page shows a list of a few diagnoses, with the most probable one highlighted. Amy chooses one, clicks it, and then describes the treatment plan to John (SUBTASK). She sends him home and requests that he return in two weeks for a follow-up appointment (SUBTASK).


Scenario 2 - A patient needs emergency assistance

Amy, our 18-year-old trained physician, is at the clinic when a woman bursts into the room with a 10-year-old boy in her arms. The child has been burned in a house that caught fire (HIGHLY MOTIVATED). Amy rushes to the child and examines him. She sees that the child has several burns on his body (PRECONDITION). She quickly goes to her computer and navigates to the "Quick Diagnosis" section of our webpage (SUBTASK). She finds the "Fire Burns" section and clicks on it (TASK). She reads the "Symptoms and Treatment" section and hurries to treat the child (SUBTASK). After the child is fully treated, Amy creates a new patient chart and enters his personal information (SUBTASK). The information from the Quick Diagnosis page is automatically entered into the Symptoms section of the form. Amy sends the child and his mother home and tell them to return in two weeks for a follow-up.


Scenario 3 - A return patient comes in with a new illness.

Amy, our 18-year-old trained physician, is at the clinic when a man and his 15 year old son walk in. The boy is has a fever and has been vomiting(MODERATELY MOTIVATED). As Amy begins to take the patient's information, the father comments that they had come in a couple years back when his son was diagnosed with dehydration(PRECONDITION). Not wanting to have multiple entries in the system for the same patient, Amy navigates to the ID look-up section of the website(SUBTASK). Here she enters the boys name and age to retrieve all relevant profiles currently in the system(SUBTASK). Once Amy has the boys ID, she can then enter the ID as an existing patient. The system would then lead Amy through the diagnosis procedure(TASK). Amy completes this task and successfully diagnosis the boy with pneumonia(TASK). Amy is able to give the treatment information to the family(TASK)!

The boy returns with his father three weeks later feeling much better. Amy logs him back into the system, confirming that he is cured! (TASK)

Observations on the Testing Day

  • Need pop-up status bar to make sure it saved
  • Need current patient name/id indicator on top of all screens
  • More instruction on each page. (Possible a help indicator for each link)
  • If the returning user information doesn't exist in the database we need to give feedback. (Currently doesn't)
  • Have new Patient / Returning Patient at start-up page instead of along the side. (Provide a distinction between return patient with a new illness versus a returning patient for a follow-up on a previously diagnosed issue.
  • Multiple treatment options needed on diagnosis page (currently just lists one)
  • Diagnosis page needs to have symptoms for each illness (so user remembers).

Prototype Iteration

There were a number of changes we made after the day in class. We changed out home page to be a selection between New Patient, Returning Patient, and Quick Diagnosis instead of sending the user to the New Patient page every time. More instructions were added throughout the system to help guide the user. These were simple sentences like "Select all symptom groups that apply to the patient." A symptoms section was added to the final diagnosis page to help the user remember what symptoms they had selected. An information bar across the top was added to display the patient name and id at all times.

Observations on the real users

User 1 (Another college student, psychology major)

  • She seemed to have an easy time using the system. Her suggestion was to have the major defining symptoms listed with the diagnosis on the quick diagnosis page.

User 2 (Male, 55 yrs, System Administrator, Computer literate)

  • username and password labels are formated the same way as the login button - confusing
  • alert if the personal information for a new patient is already in the system - error
  • Change the symptom group layout to be different from the symptom questions - confusing
  • summary of all information after the diagnosis page (confirmation page)

User 3 (Woman, 51 yrs, Office Manager, Not very computer savy)

  • Diagnosis page unclear (no direction)
  • the confirm button was general, not sure which illness she was confirming (make confirm button local to illness)
  • lost on quick diagnosis -- add simple general instruction

User 4 (Prabu) (Added most of the changes suggested by the first 3 users for Prabu)

  • Add optional fields for patient information including address, image, birth date.
  • provide a more information link for symptoms that will provide text, images, and videos to better describe the symptoms
  • Symptoms on diagnosis page driven by the user input
  • only one result on diagnosis page (flow chart will only provide one diagnosis)
  • no video for diagnosis page
  • have a more information page for treatment as well with text, images, and video
  • if multiple records are found for returning user, delete the diagnosis, but have the name link to the patient history page
  • add a protocol selection page before the symptoms page
  • Follow-up is a protocol (solves returning patient / follow up discussion)
  • Side bar isn't necessary (users should not be skipping around while diagnosing a patient)
  • add calculator / stop watch to the sidebar instead
  • add visiting patient option (no patient information but goes through the symptom page

Risk Resolution

The returning patient versus a follow up situation was hard to make clear. Luckily, follow up falls under a protocol so it should be clear then. The whole procedure was actually a little risky because we hadn't provided enough instructions for the user. A lot of test users would get to pages and not really understand what was expected of them at that section. Simply adding a sentence or two at the top of the page will be able to guide the users in the right direction. Gathering enough information from patients to distinguish between patients has been a point of risk. From the feedback, offering optional fields or even a picture of the patient should be able to reduce the change of identical records.

Computer Prototype

System Requirements

The system was most heavily tested in Chrome on Windows XP.

Starting Up Instructions

Go to http://whodatproject.heroku.com/DAT.html . username and password is both 'root'. The only scenario that is implemented is the new patient scenario with the Standard Protocol. All navigation within this scenario should work.

Fidelity

The full new patient scenario with the standard protocol is implemented. Fidelity lacks in the vertical nature. All information is statically driven. Nothing is being conveyed to a database. This will be implemented in the final implementation.

Screenshots

Main Task

  • Login Screen

Paperlogin.JPG DAT-computerprototype-Login.png

  • Screen for main selection (This was not implemented in the paper prototype.)

DAT-computerprototype-Homepage.png

  • Screen for New Patient Information

Paperpatientinfo.JPG DAT-computerprototype-Newpatient.png

  • Screen for Protocol Selection (This was not implemented in the paper prototype.)

DAT-computerprototype-protocol.jpg

  • Screen for Symptom selection

Symptom questions.JPG DAT-computerprototype-Symptoms.png

  • Screen for diagnosis result

Paper diagnosis.JPG DAT-computerprototype-Diagnosis1-1.jpg

  • Screen for Confirmation of all information (This was not implemented in the paper prototype.)

DAT-compterprototype-confirmation-1.jpg


Other Tasks

Experimental Design

John Fan

Competing System

We would compare our product, D.A.T., to the current paper-based system used by IMCI

Hypothesis: The D.A.T. system will more accurately diagnose patients than current protocols on average.

Independent: The diagnosing protocol/system used.

Dependent: The accuracy of the diagnosis.

Controls:

  • Training given in IMCI: same amount of training given to each participant
  • Clinician experience: same amount of experience working in clinic
  • Diagnosis difficult: same/similar illnesses attempted to diagnose

Task: Diagnose a patient and follow-up or use standardized patient

Between Subject if using standardized patients, seeing them again would confound results.

User population: Who: Clinicians How: Select clinicians who have gone through similar training and have different ranges of experience (~ equal amounts for each independent variable though)

Null Hypothesis: The two protocols/systems diagnose patients with equal accuracy.

Alternative Hypothesis: The D.A.T. protocol diagnoses patients with a significantly greater accuracy.


Leyla Norooz

Competing System

Hypothesis: The online system of diagnosis through our D.A.T. website is much more efficient to use and produces a more accurate diagnosis compared to the currently used paper system.

Variables

  • Independent: the D.A.T. website
  • Dependent: accuracy of diagnosis
  • Control:
    • Users' level of education and computer skills
    • Users' age (average 18 years old)

Target Population: Young women in third world countries, around 18 years of age, who are not very literate.

Protocol

  • Task: The users will be using the D.A.T. website to...
    • Produce a diagnosis for a new incoming patient
    • Produce a quick diagnosis for emergency situations
    • Find information on returning patients to either produce a follow up report or simply view past medical information about the patient
  • Condition: Between subject
    • Uses more subjects
    • Each person will have same controls
  • Measurement:
    • The accuracy of the diagnosis will be measured
    • The efficiency or level of difficulty to understand how to perform a task

Amit Chauhan

Competing System: We would compare our system (D.A.T) to the current paper version of the IMCI process.

Hypothesis: If college students use D.A.T, the time it takes for them to reach a diagnosis will be less than the time it takes for them to reach a diagnosis using the paper IMCI tool.

Independent: The kind of system used.

Dependent: The time to reach a diagnosis

Controls:

  • Number of diagnoses: Each system will have the same number of possible diagnosis.
  • Computer to use: All computers with D.A.T will have the same specs.
  • Patients: All users will diagnosis patients with similar symptoms.

Task: Diagnosis a patient.

Between Subject/Within Subject? Between, because the more the users use the software, the easier they will find it to be due to learning how it works.

User population: Who: College Students How: We would recruit students from a non-technical major (to try to replicate nurses in third world countries who do not any computer experience).

Null Hypothesis: If college students use the paper IMCI tool and D.A.T to diagnose a patient, then the time it takes to diagnosis the patient will be equal for both systems.

Alternative Hypothesis: If college students use D.A.T, the time it takes for them to reach a diagnosis will be less than the time it takes for them to reach a diagnosis using the paper IMCI tool.

Anand Shroff

Competing System

Our system would be compared to the current paper implementation of IMCI.

Hypothesis: The current implementation of D.A.T. is faster and more efficient than the paper implementation in terms of diagnosing patients.

Independent: The protocols used in the D.A.T. program.

Dependent: The time it takes the user to make the diagnoses.

Controls:

  • The same computer will be used for all the diagnoses.
  • Each individual who uses the program will have the same amount of training.
  • The patients will all have symptoms that correspond to what the program can diagnose.

Task: Diagnose the patient using the available protocols.

Between Subject Timing(s) of the diagnoses may vary based on the motor skills of the subjects using the program.

User population: Who: College students. How: Find students not working on IMCI implementation to ensure same familiarity.

Null Hypothesis: Both implementations take the same amount of time to make a diagnoses.

Alternative Hypothesis: The current D.A.T. implementation is the fastest in terms of making a diagnoses.


Kelly McDuffie

Competing Layouts

We've already gone through a number of different ideas for the best way to layout the process of diagnosis. This experiment would put some of the decisions we've made to the test.

Hypothesis: Our existing layout, based on inputs from many people, should be the most efficient.

Independent: Multiple layouts

Dependent: Learnability / quickness for user to complete the task

Controls:

  • Pre-knowledge of the project.
  • Existing medical knowledge.
  • Computer competence.

Task: Diagnose the patient using the system.

Between Subject Having gone through the process with one layout will give the subject knowledge of the process. I'm more interested in how a person with no knowledge of the process navigates the system.

User population: Who: 22 - 28 year old women with limited education and computer skills.

Null Hypothesis: Our previous layouts were easier to follow.

Alternative Hypothesis: The current D.A.T. implementation is the most effective in terms of learnability.

Implementation

Final Product: http://whodatproject.heroku.com/DAT.html

UI Functions (Must Have)

  1. Consistent Color Theme
  2. Log-in Page that requires a username and password
  3. Logout button/link
  4. Main Menu that contains links to three main functions
  5. New Patient Information Page
  6. New Patient Protocol Page
  7. New Patient Symptoms Page
  8. New Patient Diagnosis Page
  9. New Patent Confirmation Page
  10. Returning Patient Search Page
  11. Returning Patient Search Results Page
  12. Returning Patient Info Page
  13. Emergency Diagnosis Warning Page
  14. Emergency Diagnosis Diagnoses Page
  15. Emergency Diagnosis Confirmation Page
  16. Emergency Diagnosis Patient Info Page
  17. Upon Confirmation, resets back to Main Menu for all three functions!

UI Functions (Nice to Have)

  1. Calculator Widget
  2. Stopwatch Widget
  3. Ability to play video for treatment options.
  4. Images with symptoms
  5. Images with diagnoses
  6. Pharmacy Log
  7. "Patients Under 2" Protocol

Server (Must Have)

  1. Store User Info
  2. Store Patient Information (basic information)
  3. Look up Patients
  4. Allow updating of Patient Information
  5. Store Patient Diagnosis Information

Server (Nice to Have)

  1. Ability to upload XML of symptoms and diagnoses
  2. Database of all symptoms and diagnoses
  3. Database of all treatments.
  4. Database of pharmacy inventory.
  5. Simulate IMCI Flowchart Algorithm

Required UI Features we actually implemented

  1. Consistent Color Theme [Leyla]
  2. Log-in Page that requires a username and password [Amit]
  3. Logout button/link [Kelly]
  4. Main Menu that contains links to three main functions [Amit]
  5. New Patient Information Page [Amit and John]
  6. New Patient Protocol Page [Amit and John]
  7. New Patient Symptoms Page [Kelly]
  8. New Patient Diagnosis Page [Kelly]
  9. New Patent Confirmation Page [Kelly]
  10. Returning Patient Search Page [Amit]
  11. Returning Patient Search Results Page [Amit]
  12. Returning Patient Info Page [Amit]
  13. Emergency Diagnosis Warning Page [Kelly]
  14. Emergency Diagnosis Diagnoses Page [Kelly]
  15. Emergency Diagnosis Confirmation Page [Kelly]
  16. Emergency Diagnosis Patient Page
  17. Upon Confirmation, resets back to Main Menu for all three functions! [Kelly]

Optional UI Features we actually implemented

  1. Calculator Widget
  2. Stopwatch Widget [Anand]
  3. Ability to play video for treatment options. [Kelly]
  4. Images with symptoms
  5. Images with diagnoses
  6. Pharmacy Log
  7. "Patients Under 2" Protocol

Server features actually implemented

  1. Store User Info [Ben]
  2. Store Patient Information (basic information) [Ben]
  3. Look up Patients [Ben]
  4. Allow updating of Patient Information [Amit]
  5. Store Patient Diagnosis Information
  6. Ability to upload XML of symptoms and diagnoses
  7. Database of all symptoms and diagnoses(very basic) [Ben]
  8. Database of all treatments.
  9. Database of pharmacy inventory.
  10. Simulate IMCI Flowchart Algorithm (very basic) [Ben]


NOTE: Leyla and John contributed mostly to designing the poster and were very involved in the previous parts. Anand was sick for a good deal of the Implementation Phase but helped out during the other parts.

User Testing and Analysis