Healthcare Toolkit: Unified User Interface
Gerlinde Utsch, Liwen Tian, Rahat Azhar
Mechanical, Industrial and Manufacturing Engineering
Dec 6, 2013
IE 545, Dr. Ken Funk
Oregon State University
HEALTHCARE TOOLKIT: UNIFIED USER INTERFACE
Content
1. Introduction .............................................................................................................................................. 1
1.1 Background ...................................................................................................................................... 1
1.2 Overview .......................................................................................................................................... 1
2. Task Analysis (IDEF0 model) ...................................................................................................................... 2
2.1 Purpose ............................................................................................................................................ 2
2.2 Process and Model Summary .......................................................................................................... 2
3. Detailed Task Analysis ................................................................................................................................ 4
3.1 Purpose and Process........................................................................................................................ 4
3.2 Summary of findings ........................................................................................................................ 4
4. Requirements ............................................................................................................................................ 4
4.1 Process ............................................................................................................................................. 4
4.2 Requirements summary .................................................................................................................. 5
5. Final Design ............................................................................................................................................... 6
5.1 Summary of the design process....................................................................................................... 6
5.2 Description of the system ................................................................................................................ 6
6. Evaluation .................................................................................................................................................. 9
6.1 Procedure and Methods .................................................................................................................. 9
6.2 Results.............................................................................................................................................. 9
7. Conclusion ............................................................................................................................................... 10
References ................................................................................................................................................... 11
Appendix...................................................................................................................................................... 11
Appendix A: IDEF0 Model .................................................................................................................... 11
A1: A-0 diagram ........................................................................................................................... 11
A2: A1, A2 and A4 diagrams ........................................................................................................ 12
Appendix B: Detailed Task Analysis ..................................................................................................... 15
HEALTHCARE TOOLKIT: UNIFIED USER INTERFACE
Appendix C: Requirements .................................................................................................................. 17
Appendix D: Design Prototype Images ................................................................................................ 18
Appendix E: Evaluation ........................................................................................................................ 27
E1: Questionnaire ........................................................................................................................ 27
E2: Results............................................................................................................................................ 28
HEALTHCARE TOOLKIT: UNIFIED USER INTERFACE
1
1. Introduction
1.1 Background
An electronic medical record (EMR) is a concept defined as a systematic collection of electronic health
information about individual patients or populations (Gunter & Terry, 2005). The implementation of this
concept of digital records by hospitals and medical offices brings about many positive changes compared
to former practices. Up to date information on each patient is available at a click, without the
complications of lost or illegible forms, reports, and paperwork.
The EMR possesses promising features for healthcare practice worldwide. However, since the EMR stores
a vast amount of information in a complex and confusing way, its performance in terms of usability may
suffer at times. Different project groups have already developed product concepts for the idea of an
integrated Healthcare Toolkit (HT), but they mostly focused only on one or several parts of the various
subsystems that represent the elements of a medical encounter.
In the light of the lack of integration and consistency of the subsystems, we want to design a unified user
interface for the Healthcare Toolkit which is in accordance with human factors principles. This tool shall
act as a bridge between the EMR and the user containing all the elements of a medical encounter. Such a
connection simplifies the interface for the user and improves usability and effectiveness since it reduces
the complexity of the interaction process with the EMR as well as provides a step-by-step task
progression. The system should prevent or reduce medical errors while facilitating a fast input of data.
One more very important goal was to make the system self-evident and user-friendly, so it is easy to
understand and use because there is usually not enough time for an initial training for new employees.
1.2 Overview
This report describes in sequential detail the various processes and analyses that have contributed to our
final design. Section 2 explains the process of the Task Analysis using IDEF0 modeling language. This
model allowed us to conceive the patient-physician encounter as a process with several inputs, outputs,
mechanisms, and controls interacting with each other. Section 3 further elaborates the Task Analysis
using Detailed Task Analysis, which is a tabular form of processing tasks or activities. The task analysis
helped us develop the requirements for our Healthcare Toolkit, which are listed and discussed in Section
4. In Section 5, we present the design process as well as a complete description of our interface mockup
fulfilling the established requirements and keeping in compliance with human factors design principles.
An evaluation of the HT user-interface is performed by collecting feedback from potential users (Section
6). Lastly, we finish with the conclusion including further recommendations.
HEALTHCARE TOOLKIT: UNIFIED USER INTERFACE
2
2. Task Analysis (IDEF0 model)
2.1 Purpose
In order to better understand the patient-physician encounter, we needed a modeling language that
captured the complexity of the entire process, yet presented the findings in a simple and intelligible
manner. We used the modeling language IDEF0 which includes boxes, arrows, and relevant labels to
convey the relationship between the elements. Each diagram also has the potential to be decomposed
into ‘child diagrams,’ which allow a more detailed analysis of the subtasks. An important aspect of the
IDEF0 modeling language is that the processes shown are not necessarily sequential. In fact, with the use
of both forward and backward arrows, processes that happen concurrently and interdependently may
also be depicted.
2.2 Process and Model Summary
At first, we developed the Top-Level Context Diagram or A-0 diagram, which is the fundamental starting
point of the IDEF0 model (see appendix A1). The box is titled ‘Conduct Medical Encounter’ since it is the
primary activity being analyzed and all other sub-activities stem from this fundamental activity. During
the designing process, we examined several factors from real patient-physician encounters to better
understand the dynamics of the whole process.
Since the status of patient, physician and EMR are changed by the encounter process, the A-0 box
includes diseased patient, EMR and uninformed physician as inputs while “patient under medical
treatment", updated EMR, informed physician, and follow-up plan are released as outputs. Since the
process is performed or supported by the physician, nurse, EMR system, and medical equipment and
tools, these entities were incorporated as mechanisms. The process is also constrained and influenced by
some objective elements like medical guidelines, environmental factors, physician’s factors, and patient’s
factors. These elements act as controls over the medical encounter.
The single process in the A-0 diagram is then decomposed into subprocesses and modeled in the A0
diagram (see figure 1). This diagram shows the five main activities that are performed during the medical
encounter. These include “Collect Patient’s Information,” “Examine Physical Condition,” “Diagnose the
Patient’s Condition,” “Determine the Patient’s Treatment,” and “Plan Follow-up.” In the diagram, there
exist feedback loops that connect some activities. An example would be the influence of “Unanswered
Questions” resulting from the diagnosis that acts as a control over the “Examine Physical Condition”
activity. This particular feedback makes it evident how the shown activities are not necessarily sequential.
HEALTHCARE TOOLKIT: UNIFIED USER INTERFACE
3
Figure 1: A0 diagram
In order to proceed further with our task analysis, we developed our IDEF0 model and added more detail
to it. Some activities of the A0 diagram were deemed the most appropriate candidates for having child
diagrams. We concluded that a lot of information and subtasks were summarized especially in the three
activities “Collect Patient’s Information” (A1), “Examine Physical Condition” (A2), and “Determine the
Patient’s Treatment” (A4). Therefore, these tasks appeared to be best suited for having their own child
diagrams, since they carried lots of detail within themselves (see appendix A2). A video of a typical
patient-physician encounter helped us to identify the specific subtasks. The child diagram A1 consists of
four activities which include assessing the patient’s EMR and interviewing the patient about his/her
complaints, medical history, and behaviors in everyday life. The child diagram A2 describes the process of
examining the physical condition of the patient. A difficulty in the modeling of the child diagram A2 was
that some examinations are not taken during the depicted physician-patient encounter. We addressed
this issue by the assigning these as two separate activities namely order tests and review previous test
results. Basic examination and further examination of the nature which is influenced by the type of
disease the patient has are the other two subprocesses. The child diagram A4 describes the different
actions that have to be taken to find an appropriate treatment for the patient. Possible treatment plans
are devised and then discussed with the patient. Considering the feedback of the patient, the plan is
customized to suit the patient’s needs and comfort. Lastly, the final treatment plan is prescribed and
implemented. Definitions of the relevant terms used in the model were added to a glossary.
HEALTHCARE TOOLKIT: UNIFIED USER INTERFACE
4
3. Detailed Task Analysis
3.1 Purpose and Process
After finalizing the IDEF0 model, we started the Detailed Task Analysis of some of the major subtasks,
namely A11, A21, A41 and A43 (see Appendix B). This analysis takes all aspects of a task into
consideration, and helps in understanding the needs and requirements for our user-interface design.
To analyze one specific task, we reflected the whole process step by step. At first, we faced some
problems determining the start cues or stimuli for particular activities. We overcame this difficulty by
role-playing that particular subtask of a medical encounter. We then identified what information was
required to make the decision, and which actions were eventually taken to perform the subtask.
Moreover, we assessed the frequency of the activity during the medical encounter and the general
environmental conditions. As a result of better understanding the demands of the subtask, we were able
to identify the factors that influence the activity and may lead to errors.
3.2 Summary of findings
By performing the detailed task analysis of the above mentioned four tasks, we were able to arrive at
significant conclusions and potential risks for each of them. For the activity A11 (Assess the Patient’s
EMR), we concluded that the physician must read the right information and not inadvertently access the
wrong EMR. During the activity A21 (Take Basic Examinations) there is a possibility of missing a particular
vital sign during the examination or recording values of vital signs that are influenced by a temporary
abnormal condition of the patient. Analyzing activity A41 (Devise initial treatment plans), we found that
there was a risk of not exploring all the available treatment options or that the possible treatments
devised were based on an incorrect diagnosis. Lastly, for activity A43 (Customize chosen plan to suit
patient’s medical history and comfort) there is the risk of an incompatibility between the devised plan
and the patient’s needs. This detailed information about the subtasks helped us to develop more
requirements which will be explained in the following section.
4. Requirements
4.1 Process
Developing requirements is important because it guides the direction of the whole design process. In
order to create a user-friendly interface for the Healthcare Toolkit (HT), considering human factor
principles and comprehensive requirements are necessary. Our goal was to integrate all the steps of a
medical encounter in the interface without making it too complex.
At first, we created requirements ensuring that the system provides all necessary functions for the
medical encounter processes such as access and modification of EMR information, providing forms and
navigation through the procedures. In addition, we wanted to design an intelligent system that assists the
physician to diagnose and determine the treatment as well as warn the physician if the entered data are
incorrect or missing. The system shall also be able to identify the user and to prevent the loss of data, as
HEALTHCARE TOOLKIT: UNIFIED USER INTERFACE
5
well as display information such as time and charge status of the battery. Moreover, some requirements
comprised important visual factors to facilitate the handling of the device, and to prevent misuse or
dissatisfaction of the user.
After that, we developed more requirements based on the performed task analysis. In order to perform
each task more efficiently, we came up with more requirements. Meanwhile, we altered several previous
requirements. We redesigned some requirements that had ambiguous terms, and replaced a
non-attainable requirement with a more feasible one. Finally, we reviewed our requirements through the
IDEF0 model and task analysis. We went to the Oregon State University Student Health Center to ask for
more details of the medical encounter process and the functions and challenges of the medical system
interface. Then we carefully checked whether or not the requirements included all necessary functions.
We also checked the necessity, verification, feasibility, and clarity of each requirement. Eventually, 27
final requirements were settled down for our HT user-interface design considering all functions, controls,
and displays.
4.2 Requirements summary
Based on the identified needs for the HT, we established 27 final system requirements (see appendix C).
The first five requirements include the most fundamental functions of the Healthcare Toolkit, such as
identification of physician and patient, as well as access and updating of information in the Electronic
Medical Report (EMR) system. Requirement 5 is particularly important, which states that “the HT shall
prevent the loss of changed data.” This requirement refers to the ability of the system to automatically
save the data entered, without any extra effort on the part of the user. The HT will save any changes in
the EMR. With this function, the physicians can pay more attention to the patient rather than being
preoccupied with manually saving every input they make into the system.
Requirements 6 - 9 are supporting functions which make the encounter more convenient for the
physician. Requirement 6 - “the HT shall provide means to highlight important information” is especially
supportive in keeping track of significant findings. Compared with traditional methods, this function is
helpful when physicians want to mark some information and retrieve it in later processes of the
encounter. The HT system contains a lot of information, and it may be difficult to remember what the
most important or unusual findings were. The remark function helps the physicians to find the marked
information quickly, and reduces the overload on working memory.
Requirements 10 - 19 direct at some specific processes of encounters and requirement 20 - 25 are related
to the layout design with the focus on user-friendliness. We designed most of them with the help of the
IDEF0 model and the detailed task analysis. For example, it is possible that data are missing, incorrect
data are entered or correct data are entered in the incorrect fields. To overcome this, we added the
requirement that the Healthcare Toolkit shall have the means to alert the physician if there is missing
information or if the entered information does not fall within the accepted value range for that particular
parameter. Requirement 26 - 27 are requirements regarding font and button size ensuring that the
system is easily readable and usable.
HEALTHCARE TOOLKIT: UNIFIED USER INTERFACE
6
5. Final Design
5.1 Summary of the design process
After having performed the task analysis and finalized our requirements, we started to design the
mockup which should follow the IDEF0 model, be able to perform all the detailed tasks, and meet the
final requirements. We decided to use Microsoft Visual Basic to create the prototype application. There
are six main form windows as the six top level diagrams in the IDEF0 model (A0): EMR information,
interview, examination, diagnosis, treatment, and follow-up. According to requirement 1 and 2, we added
two more form windows: the physician and the patient login page. We also added one more form
window (home page) for convenience. Based on the lower level diagrams, we built tab pages in different
form windows to implement more detailed functionalities. Then we went through the detailed task
analysis and designed the components on each page. In the design process, we simulated medical
encounters in mind, and tried to create an application following physicians’ mental model by arranging
the subsystems and contents in the order of a typical encounter.
5.2 Description of the system
To explain the system and how it works as well as how the requirements are met, we include some
example pages of the interface in this section. All the pages can be found in appendix D. The application
can be displayed on a tablet or a fixed computer. Button and font size were designed to make it legible
and easy to click as dictated by our requirements.
To execute the application, a physician needs to log in first and then enter the patient’s identity
information. This prevents unauthorized access of patient’s data and identifies the physician conducting
the medical encounter as well as the treated patient. The physician can fill in either the patient’s name or
ID. If two or more patients have the same name, the physician will be asked to choose the right patient
from a list.
After that, the physician will be directed to the home page which shows the main menu and from where
the physician can go to each step of the medical encounter. These directing buttons are located at the
same place on the left side of each form. We considered this location to be convenient and easy to reach
regarding the frequent use of the menu buttons. Important information like the name of the patient is
displayed in the top left corner on all pages. In the top right corner, date, time, and battery status will be
shown.
Aside from the home page, there is a Print and an Email button on the top of each page, so that the
physician can print or email the depicted information. The physician can change all the text box, check
box and radio button values which will be automatically saved to the EMR system. The physician gets the
feedback that the entered data are saved via the label “all changes saved” on the top of the page which
will show up as soon as something is added or modified. With this, the requirement that the loss of data
is prevented is met as well as the human factor principle of providing feedback. On the bottom left side
of each page is a microphone button in case a physician prefers to enter information with automatic
speech recognition. Further comments can be noted at the end of each page (except the EMR
information page).
HEALTHCARE TOOLKIT: UNIFIED USER INTERFACE
7
Figure 2: EMR information page example
The physician can highlight any important information in all forms which can be retrieved later. For
instance, if the physician wants to mark the main symptom in the interview form, (s)he just needs to click
the label “main symptom.” The label and the related content will become blue. If (s)he clicks it again, the
color will change to red which means that the information is not only important but also contains serious
problems. The physician can cancel the mark by clicking it one more time.
The EMR information form (see figure 2) serves to retrieve information about the patient that was
recorded previously. On the form, there are three tab pages for basic information, the patient’s medical
history, and past encounters’ information. The button belonging to the current form is always disabled.
The interview form serves to record the patient’s complaints, the medical history, and the daily behavior.
If there is information from past records, they will already show up in the corresponding places, and the
physician can add or alter them during the encounter.
On the examination form, there are four tab pages: basic examinations, further examinations, order tests,
and past test results. Here, the physician can also take pictures by clicking on the camera button. If the
physician wants to leave the examination page without having filled in all the required information, a
message box will pop up to remind him/her that all the fields have to be filled in. In the message box, the
default button is set to go back to the current page but the physician also has the choice to go to another
page. If the entered values fall outside the normal ranges, a window will pop up saying that a correct
value has to be entered. Like most of the other features we implemented (or suggested), this element
also fulfills one of our requirements (requirement 14).
HEALTHCARE TOOLKIT: UNIFIED USER INTERFACE
8
On the diagnosis page, the first three text boxes will be automatically filled with abnormal or unusual
information from the interview and the examination. In the diagnosis text field, a list of possible
diagnoses will show up according to the findings from which the physician can choose. The physician can
also exit the list and type the diagnosis in the text box. Only diseases that exist in the database will be
accepted.
Figure 3: Treatment page
Then, the physician can go to the treatment form (see figure 3) and fill in all the information about the
medication and how/when to take it. If (s)he enters a medication that is in conflict with a specific allergy
or another currently taken medication, a message box will pop up saying that this treatment cannot be
prescribed. Otherwise, the physician can print the prescription for the medication as well as print the
information about how to take it for the patient.
The last form is the Follow-up form that allows the physician to note the following procedures and plans.
HEALTHCARE TOOLKIT: UNIFIED USER INTERFACE
9
6. Evaluation
6.1 Procedure and Methods
To test and evaluate our interface for the Healthcare Toolkit, we asked several people to try out our
application, give feedback and fill out a questionnaire (see appendix E1). Because you need to have a
specific knowledge if you use the interface, we asked only physicians and nurses. Our test participants (4
in total) were one physician and two nurses at the Oregon State University Student Health Center as well
as one German physician. We did not have the means to reenact a real physician-patient encounter and
measure time or accuracy, but as our participants were familiar with these proceedings, they quickly got
an idea of how they could use the HT. At first, we showed the application and explained how the system
worked. Since our application was not fully functional, we told them about functions we could not
implement and what would happen if they clicked different buttons. We answered the questions the
participants had, and gave them time to try out the system by themselves. At the end, they had to fill out
a usability questionnaire providing 6 statements they had to rate using a Likert Scale as well as 5 open
usability questions including further comments. We tried to keep the questionnaire short while asking all
important questions because the staff working at the Healthcare Center was available for a limited time.
The usability criteria which the participants had to rate included overall ease of use, complexity of the
system, integration of functions, inconsistency, helpfulness for a medical encounter, and time to
understand the functions of the system. One example of a provided statement is “I needed a long time to
understand all the functions of the HT” which had to be rated on a scale from 1 to 5 with 1 meaning “I
strongly disagree” and 5 “I strongly agree.” The answers of the open questions gave us feedback about
positive and negative things of our interface as well as further comments and recommendations.
6.2 Results
The overall feedback of the participants regarding our unified user interface was very positive and
encouraging. The aggregated evaluation results can be found in appendix E2. The main advantage
appeared to be the user-friendliness. All the users strongly agreed that the HT is easy to use and listed
this fact as a point they liked most about the HT. They also strongly agreed that the HT is not complex and
that they did not need a long time to understand all the functions. All of the users could imagine using
the HT every day. Furthermore, the participants agreed that there was not too much inconsistency in the
HT, that the functions were well integrated, and that the interface helped them to conduct a medical
encounter. Positive remarks besides the ease of use were the ease of navigating between pages, the
different colors of the buttons and backgrounds, the warnings (for example before leaving a page if
information was missing, inconsistency between allergies and treatment, etc.), and the ability to highlight
significant findings. Negative comments were that they sometimes felt boxed to click certain choices, and
that they did not always find space to free type. However, we think that these specific problems can be
resolved easily when the content of the pages is more developed and adjusted. Recommendations were
to change some of the terminology, to show main information (gender, age, allergies, etc.) under the
name on each page, to be able to retrieve all the previous encounters together, and not only separately
as well as to have an additional main menu button for previous test results and “subbuttons” to be able
to directly go to each tab on each page.
HEALTHCARE TOOLKIT: UNIFIED USER INTERFACE
10
7. Conclusion
In order to design a unified user interface for the Healthcare Toolkit, we needed to understand all the
different steps that are carried out during a medical encounter. With the help of questioning physicians
and nurses, IDEF0 modeling as well as detailed task analysis, we identified not only the important actions
and relevant information for each step, but also developed requirements for the design. Finally, we
compiled a mockup of the interface which fulfilled all of our requirements. To test the usability of our
design and functioning, we asked physicians and nurses to evaluate our interface (not all of the functions
were fully implemented but explained to the participants). The feedback was all in all very positive and
especially the ease of use as well as the alerts warning the user of missing or incorrect information was
highlighted. Even if our mockup is simplified and not fully functional, it appears to be a promising start.
Besides the implementation of all of the functions, we recommend that further work includes the correct
medical terminology, adjustment of checkboxes and free-type space, the development of the content,
the main menu buttons, and the important information about the patient on each page.
HEALTHCARE TOOLKIT: UNIFIED USER INTERFACE
11
References
Gunter, Tracy D & Terry, Nicolas P (2005). "The Emergence of National Electronic Health Record
Architectures in the United States and Australia: Models, Costs, and Questions".Journal of Medical
Internet Research 7 (1): e3. doi:10.2196/jmir.7.1.e3
Appendix
Appendix A: IDEF0 Model
A1: A-0 diagram
HEALTHCARE TOOLKIT: UNIFIED USER INTERFACE
A2: A1, A2 and A4 diagrams
A1
12
HEALTHCARE TOOLKIT: UNIFIED USER INTERFACE
A2
13
HEALTHCARE TOOLKIT: UNIFIED USER INTERFACE
A4
14
15
HEALTHCARE TOOLKIT: UNIFIED USER INTERFACE
Appendix B: Detailed Task Analysis
Modeling
Task Analysis
Process/Function/Task/Activity
Start Cue
Information
Patient's
Appearance
Patient's
Name & ID,
EMR access
Information
Decision(s)
Actions
Select the
right patient
Open the
document,
Read the
patient's
records
Frequency
& Duration
Environmental
Conditions
Potential Errors &
Risks
Remarks/
Comments
Usually
once,
5-10 mins
Standard room
lighting & indoor
temperature,
quiet
surroundings
Selecting the
wrong patient,
opening the wrong
document or no
access to EMR
Make sure the
physician reads
the right
information
A0: Conduct Medical Encounter
A1: Collect Patient's Information
A11: Access the Patient's EMR
A12: Interview about Complaints
A13: Interview about Medical History
A14: Interview about Behaviours in
Everyday Life
A2: Examine Physical Condition
A21: Take Basic Examination
A22: Take Further Examination
A23: Review Test Results
A24: Order Tests
A3: Diagnose the Patient's Condition
Need for
knowledge
of the
current
physical
condition of
the patient
Patient's
Name & ID,
interview
results,
patient's EMR
Decide
examination
types
Prepare
patient,
perform
examination, Usually
record
once,
results
10-12 min
Miss some
examinations,
record wrong
results, get
Standard room incorrect results
lighting & indoor (e.g. patient is
temperature,
excited when
quiet
blood presure is
surroundings
measured)
Take
appropriate
examinations,
pay attention
to patient's
abnormal
conditions,
add
examinations if
needed
16
HEALTHCARE TOOLKIT: UNIFIED USER INTERFACE
Process/Function/Task/Activity
A4: Determine the Patient's
Treatment
A41: Devise Initial Treatment plans
Start Cue
Information
Decision(s)
Actions
Frequency Environmental
& Duration Conditions
Concluding
with a
diagnosis
Judge severity
Patient's EMR,
of disease,
physician's
select possible Outline
medical knowledge treatment
treatment
base
options
procedure
Patient's
evident
need for
customized
treatment
Access and
read the
patient's
EMR,
Patient's EMR,
Decide among interpret
patient's concerns, various
EMR,
available
approaches to discuss with
treatment options, customization, patient,
any known
rule out
customize
Usually
allergies or
incompatible treatment
once,
medication
options
plan
10-12 min
Usually
once,
10-12 min
Potential Errors
& Risks
Remarks/
Comments
Standard room
lighting &
indoor
temperature,
quiet
surroundings
Treatment based
on incorrect
diagnosis,
choosing an
ineffective
treatment
Ensure that
the
treatments
are in line
with the
actual disease,
avoid missing
out possible
treatment
options.
Standard room
lighting &
indoor
temperature,
quiet
surroundings
Incorrect
treatment,
missing
information,
incorrect
interpretation of
patient's medical
history and
concerns
Make sure the
customized
treatment is
consistent
with the
patient's
condition
A42: Discuss Plans with Patient
A43: Customize chosen Plan to suit
Patient's Medical History and
Comfort
A44: Prescribe final Treatment Plan
A45: Implement final Treatment Plan
A5: Plan Follow up
HEALTHCARE TOOLKIT: UNIFIED USER INTERFACE
17
Appendix C: Requirements
1. The HT shall provide a user log-in to identify the physician.
2. The HT shall provide a patient log-in to identify the patient.
3. The Healthcare Toolkit (HT) shall provide the function to retrieve data from the Electronic Medical
Report (EMR).
4. The HT shall provide the function to change and update the EMR.
5. The HT shall prevent the loss of changed data.
6. The HT shall provide means to highlight important information.
7. The HT shall provide the option to share the patient’s data with specialists or other medical
facilities.
8. The HT shall provide the function to take and display colored pictures.
9. The HT shall provide the function to recognize speech automatically.
10. The HT shall provide an encounter form to note down information about the patient’s problems.
11. The HT shall provide a form to note down information from the interview.
12. The HT shall provide a form to note down physical examination results.
13. The HT shall provide means to alert the physician if there is missing information in the basic
examination records.
14. The HT shall provide means to alert the user if entered data fall outside the accepted value range
for that particular parameter.
15. The HT shall provide means to show previous test results.
16. The HT shall provide a tool to *assist* the physician to make the diagnosis.
17. The HT shall provide a tool for prescription writing.
18. The HT shall warn the physician if prescriptions are incompatible with patient’s records.
19. The HT shall provide a form to note down a follow-up plan.
20. The HT shall be*simple and easily comprehensible* to the user.
21. The HT shall provide the opportunity to reach every page of the application by no more than two
clicks.
22. The HT shall display the patient’s name at the same location on the top of every page.
23. Buttons with the same function shall be placed at the same location on the screen.
24. The HT shall display the time at the same location on every page.
25. The HT shall display the battery’s state of charge at the same location every page.
26. The font size of the HT shall be at least 12.
27. The button size of the system shall be at least 0.5cm x 1cm.
HEALTHCARE TOOLKIT: UNIFIED USER INTERFACE
Appendix D: Design Prototype Images
Physician Log In Window
Patient Log In Window
18
HEALTHCARE TOOLKIT: UNIFIED USER INTERFACE
Home Page Window
EMR Information Window - Basic Information Tab Page
19
HEALTHCARE TOOLKIT: UNIFIED USER INTERFACE
EMR Information Window - Personal History Tab Page
EMR Information Window - Previous Encounter Tab Page
20
HEALTHCARE TOOLKIT: UNIFIED USER INTERFACE
EMR Information Window - Another Past Encounter Tab Page
Interview Window - Complaint Tab Page
21
HEALTHCARE TOOLKIT: UNIFIED USER INTERFACE
Interview Window - Medical History Tab Page
Interview Window - Daily Behavior Tab Page
22
HEALTHCARE TOOLKIT: UNIFIED USER INTERFACE
Examination Window - Basic Examination Tab Page
Examination Window - Basic Examination Warning Message Box
23
HEALTHCARE TOOLKIT: UNIFIED USER INTERFACE
Examination Window - Further Examination Tab Page
Examination Window - Order Test Tab Page
24
HEALTHCARE TOOLKIT: UNIFIED USER INTERFACE
Examination Window - Previous Test Results Tab Page
Diagnosis Window
25
HEALTHCARE TOOLKIT: UNIFIED USER INTERFACE
Treatment Window
Follow Up Window
26
HEALTHCARE TOOLKIT: UNIFIED USER INTERFACE
Appendix E: Evaluation
E1: Questionnaire
Explanations: HT – Healthcare Toolkit, 1 – strongly disagree, 5 – strongly agree
1. I think the HT is easy to use
1
2
3
4
5
2. I could imagine using the HT every day
1
2
3
4
5
3. I found the HT is unnecessarily complex
1
2
3
4
5
4. I needed a long time to understand all the functions of the HT
1
2
3
4
5
5. I think there was too much inconsistency in the HT
1
2
3
4
5
6. I found the various functions in the HT were well integrated
1
2
3
4
5
7. The system helps me to conduct the medical encounter
1
2
3
4
5
8. What are the three things you like best about the HT?
9. What are the three things you like least about the HT?
10. What changes of the HT would you recommend?
11. Other Comments:
27
HEALTHCARE TOOLKIT: UNIFIED USER INTERFACE
28
E2: Results
1.
Easy to use: 5, 5, 5, 5
2.
Use every day: 5, 5, 5, 4
3.
Complex: 1,1,1,2
4.
Long time to understand: 1,1,1,1
5.
Inconsistency: 1,2,2,2
6.
Functions well integrated: 4,4,4,4
7.
Help to conduct the encounter: 4,4,4,4
8. Positive:
-
easy to use (2x), user-friendly, ease of navigating between pages
-
Ease of finding patient info
-
Reminder if not completed (2x)
-
Colors (2x)
-
Ability to highlight significant findings
-
Clean and clear
9. Negative:
-
feel boxed in to click certain choices
-
not always place to free type in regards to the points complaints and symptoms
10. Recommendations:
-
Change some of the terminology
-
Retrieving previous test results should be accessible by a main menu button
-
previous encounters to be searched by all past, not just date
-
age, gender, allergies and important things always shown on each page under the name
-
menu subbuttons on each page to be able to go directly to another tab of another page
11. Comments:
-
Basic design is very functional with no glaring deficiency
-
a bit simplified at this point but a fantastic start, great
-
strong foundation to work with
-
great job