You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 9 Next »

Design

Final Design

Here we present several screenshots of our final design along with a discussion of our key design decisions along the dimensions of Learnability, Efficiency and Safety. It is important to mention up-front that we designed this interface with the idea of a tablet in mind as we felt that the portability of our user interface would improve it's usefulness to the clinical staff. Throughout this interface, we will demonstrate only the doctor's view. The reason for this is because the nurse's view is a subset of the doctor's view. The difference being that the nurse cannot prescribe medications.

Figure 1: EZ-ICU Main screen.
General Design Thoughts:
Given the user population and environment we were targeting - busy doctors and nurses in the ICU - we made our user interface as simple and intuitive as possible. It was particularly important to provide a comparable level of learnability and efficiency to what the classical whiteboard provides, without any of the safety pitfalls. Hence, the main screen of our interface was designed to provide clinical staff with an intuitive overview of the patient population and provide strong information scent on how to dig further into individual patient details. As we will discuss further into this section, we incorporated several simple, but informationally dense signifies on the page. 

Usability Considerations:

  • Learability
    • When a novice user first interacts with the UI, there is strong information scent that the individuals are clickable.
    • When no patient is selected, there are explicit instructions on the right of the screen informing the user that this action is possible.
    • The add patient button in the top right portion and color differently to enhance learnability
  • Efficiency
    • Patients may be sorted by name, by bed, or by the time of their next dose.
    • Off the right of each patient is displayed the time till their next dose, along with a color coded indicator that signifies if a dose is due (red) close to due (orange) or not due yet (green) 
    • The bed number of the patient is displayed prominently to the right of the patient's dosage information.
    • Similar kinds of information are clustered together on the screen. For instance - the number of patients in the ICU is displayed  next to the add patient button. 
  • Safety
    • The picture of the patient and bed are placed in proximity to one another, this feature was implemented to help prevent confusion, or mistreatment due to patients with similar names. 

Figure 2: Patient Information view

General Design Thoughts:
Once a user clicks on a patient tab, the tab opens to display an expanded set of information about the patient as shown in figure 2 above. This design allows the clinicians to maintain their overview of the breadth of patients in the ICU, even as they are seek more depth on a one specific patient. 

Usability Considerations:

  • Learability
    • The tab opens at the overview page to provide information on the current prescriptions, and upcoming administrations needed.
    • Allergy information is highlighted in red, which draws the novice users attention to it.
    • selected tab provides visual feedback by being a different color.
    • When a patient is selected the add-patient button is no longer highlighted in orange.
  • Efficiency
    • Detailed patient information is placed in the right hand panel. This allows the clinical staff to read more about the details of a single patient while keeping an eye of the indicators of the entire ICU population.
    • Pertinent information needed for the prescription of new medications, such as patient history, visit information and other medications are clearly listed on the side panel.
    • Summary of current patient vital information is displayed in the summary screen.
  • Safety
    • Patient dosage requirements are maintained, even as tab is opened.

Figure 3 A: Prescription Screen

 

Figure 3B: Prescription Screen


General Design Thoughts:

Once a user clicks on a the prescription screen, a general overview of the prescriptions is provided while maintaining at-a-glance information on other patients. Notice that prescriptions may not be edited, only canceled. This is to keep in line with regulations common in US hospitals where doctors issues new prescriptions for any change in medication.

Usability Considerations:

  • Learnability
    • Structure of the UI changes minimally as user navigates across patient tabs.
    • There is strong information scent that users can add new prescriptions. 
    • When adding new prescription, frequency is listed in linguistic terms that doctors typically use - every hour, every week, etc. 
    • Text input contained greyed out values communicating what should be inserted.
  • Efficiency
    • Summary information on all doses is displayed. 
    • when the start and end portions are clicked, a handy calendar pops us to help with selection of the start and end times. 
    • The medication utilizes auto-complete
  • Safety
    • Prescriptions may not be edited, only canceled and reissued with new values or dosing intervals.
    • Accidentally canceled prescriptions may be undone.  

Figure 4A: Administration Screen 
Figure 4B: Administration Screen:
General Design Thoughts:
Once a user clicks on a the administration screen, a list of time ordered dosages which need to be administered are shown. simply click the "done" button to verify that the dose has been given, and the user interface updates accordingly.

Usability Considerations:

  • Learnability
    • When the user clicks done - there is immediate visual feedback telling the user when the dose was given and the dosage indicator in this case went from red to green
  • Safety
    • Accidentally clicked  administrations may easily be undone.  

Important Design Decisions

Here we discuss design decisions we made which were motivated by the three evaluations we did

Paper Prototyping

*Issue 1:*Users couldn't see patient allergy information when prescribing new medication
Design Fix: Make patient information sidebar visible at all times, providing consistency and context

*Issue 2: *Users were confused by "Add Medication" button while performing the nurse task
Design Fix: Make the Overview screen role-dependent, and switch "Add Medication" to Administer Tab with simple indicators.

*Issue 3: *Users were unsure of the input format for "Frequency", "Start", and "End"
Design Fix: Provide richer controls to alleviate formatting issues: a drop-down for Frequency, and a date-time picker for Start and End

*Issue 4: *Users found the alert icons ambiguous.
Design Fix: Added text indicators along with the alert icons.

Issue 5: The prescribe medication was a pop-up menu which users found annoying as it blocked parts of the screen they wanted to observe - such as patient information.
Design Fix: We eliminated the pop-up and placed the prescribe portion within the main pane of the interface. 

Heuristic Evaluation

Issue 1: Users could not sort patients by those needing the next dosage.
Design Fix: We added this functionality into the UI

Issue 2: Our color indicators and accompany test were confusing users of the interface. The interface used to display a red indicator and say how many minutes ago the dose was due. users were confused about weather the "ago" referred to their own administration, or what was due.
Design Fix: 

User Testing

Considered Design Alternatives

Implementation

The EZ-ICU interface is designed to be a persistent, dynamic, client-side interface. Since we had no need for complex server-side logic or interfaces with other systems, we decided to create our entire application without a traditional backend. We chose the backbone.js library to handle data storage and the overal architecture of the program. Backbone allows us to be clear about specifying the models and views in our application, and allows persistence of those models. For testing purposes, we can use backbone to store patient information on the user's machine, using Local Storage, but backbone also supports synchronization to an external server, which might be necessary for future implementations of the project. 

The primary advantage of this decision is that absence of a centralized server means there is one less component which can fail when users interact with our application. Users can note the administration of medication and see patient status, even when offline, and they are never stuck waiting for a server response or dealing with internal server errors. On the other hand, the local storage method means that users on different machines will have no way to see one another's data. Full implementation of backbone.js synchronization to a server would solve this problem. 

We used several other recent web technologies to make development of our application easier. We chose coffeescript, a language which compiles directly to javascript, as our primary language for the application due to its cleaner syntax and support for modern programming paradigms like list comprehensions. Underscore.js provided functional programming tools and a templating system which allowed easier separation of our data from the presentation of that data. Sass gave us cleaner stylesheets with nested selectors and less repetition of information. Finally, moment.js provided easy handling of dates and times, along with natural language display of times such as "a few seconds ago" or "in 4 hours". 

Evaluation

To evaluate our platform, we interviewed three emergency care clinicians who were personal contacts of the group members. We believe that these users are representative of the target user population.We provided all users with a briefing and a set of tasks to be performed using our platform. This briefing is shown in the briefing section below. For each usability problem identified by the interviewee, we provide a severity rating and discussion of how this issue was address in the final implementation. 

Briefings 

User role 1: Doctor

You are a doctor at Massachusetts General Hospital, and you are making your rounds in the Intensive Care Unit (ICU). You move from patient to patient, analyzing their conditions, making appropriate diagnoses, and, when needed, prescribing appropriate medication based on the patients' status and treatment.

User role 2: Nurse

You are a nurse at Massachusetts General Hospital, and you too are making your rounds in the Intensive Care Unit (ICU). Like the doctors, you move from patient to patient. As a nurse, your focus is on checking vitals, monitoring patient condition, and administering prescribed medication and treatments.

Scenario Tasks

User Task 1: Doctor

  • You want to assess patient Mohammad and prescribe a medication
  • You need to prescribe 100mg Aspirin every hour for the next four hours
    • You need to make sure that the patient is not already taking aspirin
    • You need to remove any other medications that the patient is taking
    • You need to ensure that the patient is not allergic to aspirin
  • You need to verify that the task was accomplished

User Task 2: Nurse

  • You want to check in on patient Kamran and determine if he has any upcoming medications
  • You need to administer the medication to the patient
  • You need to indicate that the medication was administered
  • You need to verify that the task was accomplished

Usability Tests

Below we show the results of our usability test on the three users, severity scores include: cosmetic, minor, major or catastrophic and are clearly denoted. For each usability issue identified, we discuss our implemented solution. 

User 1:

Task 1:

General Feedback:
Usability Issue 1: [Critical] 

Solution 1:

Usability Issue 2: [Aesthetic] 

Solution 1:

Task 2:

General Feedback:
Usability Issue 1: [Critical] 

Solution 1:

Usability Issue 2: [Aesthetic] 

Solution 1:

User 2:

Task 1:

General Feedback:
Usability Issue 1: [Critical] 

Solution 1:

Usability Issue 2: [Aesthetic] 

Solution 1:

Task 2:

General Feedback:
Usability Issue 1: [Critical] 

Solution 1:

Usability Issue 2: [Aesthetic] 

Solution 1:

User 3:

Task 1:

General Feedback:
Usability Issue 1: [Critical] 

Solution 1:

Usability Issue 2: [Aesthetic] 

Solution 1:

Task 2:

General Feedback:
Usability Issue 1: [Critical] 

Solution 1:

Usability Issue 2: [Aesthetic] 

Solution 1:

Reflection

Discuss what you learned over the course of the iterative design process. If you did it again, what would you do differently? Focus in this part not on the specific design decisions of your project (which you already discussed in the Design section), but instead on the meta-level decisions about your design process: your risk assessments, your decisions about what features to prototype and which prototype techniques to use, and how you evaluated the results of your observations.

  • No labels