Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Table of Contents

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.

...

As we went through this project there were several alternative designs that we considered implementing. For a complete depiction of these, please see the GR2 section of this wiki which includes storyboards that accompany what we believed were our strongest designs. Of the proposed design alternatives the one we considered most strongly considered was a smart-phone style interface which was functionally very similar to what we have implemented in our design above with the exception that it did not contain the information sidebar and the patient menu, once clicked, expanded to occupy the entire screen. Ultimately we decided against this design because we felt it required far too much navigation and didn't allow the clinical staff as much access to information at a glance, which is highly important in a critical care context.

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. 

...

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 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.

...