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.

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

There were several fantastic points of feedback we received during the Heuristic Evaluation session, here we highlight the ones we felt were most useful and the corresponding design fixes to our interface.

Issue 1: Users could not sort patients by those needing the next dosage.
Design Fix: We added this functionality by allowing various sorting options in the UI.

Issue 2: Our color indicators and accompanying text 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: We changed the wording of the interface from "ago" to "overdue" to address this concern.

Issue 3: There was no easy way to sort prescriptions.
Design Fix: Prescriptions are now displayed in alphabetical order.

Issue 4: No auto-complete when prescribing medications.
Design Fix: We implemented auto-complete fro the nonprescription.

Considered Design Alternatives

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. 

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:

General Feedback: When we performed this user test, we observed that our user struggled the most at the administration of the dose. Otherwise, the user completed the tasks quickly and efficiently. When asked what their general impression he was generally complimentary about the design and utility of the interface, but felt it needed some more work to maximize it's efficiency in an ICU setting. Here we will present the usability problems and solution we might implement to address the issues brought up in this usability interview.

• [Major] There is no search bar when a clinician can look for specific patients.
• [Minor] In the prescriptions menu, the user didn't like that bogus units could be entered.  
• [Minor] In the prescriptions menu, the user suggested moving the "now" button to the top and making it more prominent . 
• [Minor] In the prescriptions menu, suggested allowing multiple formats of entry: "I want to give 10 tablets, one every n hours." 
• [Minor] In the main menu, If you click the red indicator on the right of the patient, it should link you to the administration screen. 
• [Cosmetic] The overview information should be moved to the sidebar, and the prescriptions/ administration information should remain where they are.

What we would plan to address: 
We agreed with several of the usability problems that User 1 pointed out. In the next cycle of our iterative design process we would likely incorporate all of his feedback into the next version of the interface.

User 2:

Dr. X is a young radiologist who often works in ICU, and has very good IT skills.

General Feedback: We first gave a very brief explanation of the scope of the application to Dr. X, then let him use the application without interfering, simply writing down his remarks. Dr. X found the application is straightforward to use. Within a few minutes he had understood how it works, both from the physician and from the nurse standpoint. He gave us a few advice/remarks:

• [Major] In order to to assess patient Mohammad, the user wants to see the previous observations on the patient. This issue is inherent to the fact that we have narrowed the scope of our application.
• [Minor] The user dislike having to scroll down the right information box. The user would prefer that the application had hidden some non-important information such as the patient's address, so that he can focuses on the most useful information.
• [Feature request] In the vital signals, it would be good to display the patient's temperature. As the temperature isn't taken regularly, it should go along with the time at which it has been taken.
• [Minor] The patient's photo is nice shouldn't appear by default as it is not frequently used.
• [Major] The user found a bit surprising that the application maintains two different list of medications: other medications vs. prescriptions. In the ICU, most patients are able to medicate themselves so it would probably makes more sense to add the other medications within the prescriptions.
• [Major] When adding a new prescription, the physician has to indicate in which units the dosage is expressed. This could lead to dangerous typo (e.g. g instead of mg).
• [Minor] Related to the previous point, usually the dosage is indicated within the drug's name, e.g. "Aspirin-100" stands for aspirin 100 mg.  Not only does this prevent typos, but it also allows the physician to prescribe drugs that are available in the hospital's drugstore. For instance prescribing Aspirin 150 mg would be difficult to administer if only Aspirin-100 and Aspirin-200 are available. 

What we would plan to address: 
Dr. X pointed out some very interesting issues, which we would definitely take into account in the next release of the application.

User 3:

Dr Y. is a young ICU physician, working in France.

General Feedback: General Feedback: We first gave a very brief explanation of the scope of the application to Dr. Y, then let him use the application without interfering, simply writing down his remarks. Like Dr. X, he didn't have any blocking issue when using the application. . He gave us a few advice/remarks:

• [Minor] In the right box, having the Patient History is much less interesting than the patient's immediate history.
• [Major] When adding a new prescription, the 'dosage' should be compulsory. Right now we can add a new description that have no dosage, which doesn't make much sense.
• [Minor] When adding a new prescription, we can specify a start date which is posterior to the end date.
• [Cosmetic] In the administration panel, it is very unlikely to undo a drug administration that has been performed a long time ago. It might be useful to add a confirmation message.
• [Major] When adding a new prescription, the frequency should be more flexible, perhaps by adding a custom text if needed. E.g. It is commonplace to prescribe a drug for the morning and the evening.
• [Feature request] The dosage can sometimes be variable, either increasing or decreasing over the time, depending on the evolution of the patient. Even more intricate but also commonly used, it is sometimes up to the nurse to decide what dose to administer to the patient. For instance, if the physician has prescribed more fine for a patient, the physician might simply say to the nurse to apply the usual protocol when administering morphine, which gives the nurse flexibility on the dose, and also the patient is given a morphine pump that he can use to medicate himself according to how much pain he feels (obviously such a device is limited so that a patient cannot put his life into danger).

What we would plan to address: 
Dr. Y pointed out some very interesting issues, which we would definitely take into account in the next release of the application.

Reflection

As with many project-based classes, there is always a tradeoff between starting a project too early (which risks locking onesself into decisions without enough knowledge or experience) and starting too late (which risks not being able to follow through on a great idea). As a group we tried to balance these two aspects, and we were generally successful at applying the design skills from the course to the project without pushing everything to the last minute. That said, we were hesitant to throw away good work which we had done previously, which may have hindered our ability to be creative and innovative. During the paper prototyping, we designed a variety of possible interfaces, and our final design ended up very closely resembling one of those paper interfaces. Our user testing and evaluations seemed to indicate that we had chosen well, but if we had encountered serious usability problems with that design, we might have had trouble letting it go and starting over from a different idea. 

One change which might have helped us ensure that we were not locked into a single design would have been to develop and test paper prototypes for several of our initial designs, rather than focusing on one. Allowing users to interact with two or three different paper designs would have given us a great deal of new information about the usability of different aspects of our designs, and would also have allowed us to explore a broader set of possibilities without the commitment of a functional computer interface. 

That said, we are all proud of the design we have produced and the work that went into it, and our users seemed pleased with the results as well.