top of page

HST - Interactions between Patient Portal and eChart 

Duration 

My Role

Team

August 2019 -  November 2019

Lead Product Designer

Product Manager, Business Analysts, Engineering and Design

Scroll Down

Design Problem

HST’s new patient portal will have several responses entered by the patient for every visit to the surgical center. Clinicians who use eChart need to perform several workflows to interact with the patient’s data supplied from the patient portal into eChart.

My Role

End-to-end product designer responsible for all design process in addition to scoping, gathering design requirements and coordinating with stakeholders at every stage and iteration.

Team

I collaborated in a team of Product Manager, Business Analyst, Engineering lead and developers. Conducted usability tests and feedback sessions with the client representative from the one of our primary customers. 

Design Problem

Background Research

 

As the designer, I first got an in-depth understanding of the user scenario from the Product Manager, who the end users are and what their goals are. The overall user scenario is illustrated below

Current Scenario: Clinicians or nurses verbally interact with the patients either on phone or in-person during their visit to the surgery center to get their health information and enter in eChart before the surgery.

Envisioned Scenario: The new design is to enable the clinicians validate patient's responses coming from the portal before supplying them into eChart workflows.

Duration: Sept 2017 -  Dec 2017

pp diagram.png
Background Research​

High-level Design Objectives

Clinicians:

1) Load patient's responses entered in the portal into eChart.

2) Review and correct the responses from by the patient in the portal.

3) Submit the corrected responses into the main workflow of eChart.

User Persona

Since nurses form the primary users amongst the clinicians who would be using this experience, it was important to understand the persona. I got the necessary background information to create the persona from in-office employees from nursing background and who have been power users of eChart.

User Persona
Artboard 2.png

Interaction Points

Next,I created a high-level journey map and mapped out all the interaction points across the different stages.

Interaction Points
interaction map5.jpg

Initial Wireframes

Based on the background information obtained from the Product Manager and the interaction map, I started with some intital wireframes of the whole experience.

Design Approach 1

Initial Wireframes
OR_eChart-by-HST-Pathways.png

Existing BLOC module based workflow

Pros:

 

  • Similarity to existing BLOC module-based workflow in eChart

  • Less development effort - engineers can utilize existing modules

Cons:

 

  • Excessive scrolling

  • Content overload in a single screen

Design Approach 2

1b.png

Pros:

  • Less scrolling

  • Stage-wise feedback to users on progress

Cons:

  • Excessive development effort

  • Total deviation from existing eChart module-based design

2b.png

Feedback from Stakeholders and User testing

 

- Design approach 1 is preferred due to the nurses familiarity on the module-based sequence.

- Consistent with other workflows in eChart.

- Saves a lot on development effort.

Adopted Approach: Design Approach 1

 

Technical Considerations

- Data from the portal can be loaded only once as a JSON for the entire workflow and not separately for each module.

- Validated data should be supplied to main workflow as a whole JSON for all modules.

Mid-fidelity Iteration

Based on the feedback gathered from the initial wireframes, I got a clear direction by looping in the PM and nurses. Also, involving the engineers early on helped identify technical constraints.

 

Major Changes: 

1)  All modules now part of a larger module called 'Adjudication/Validation' (For data receiving and submitting as a whole). 

2)  Now, the user first has to load the data into the workflow just once with the 'Load' button at the top which populates the entire workflow with the patient data (Saves several clicks)

3)  For allergies and home medications, patient data is maintained as read-only in it's own table.

Mid-fidelity Iteration

Duration: Sept 2017 -  Dec 2017

Duration: Sept 2017 -  Dec 2017

Feedback from PM and User testing

 

User Testing

1) Trouble making visual distinction between the different grid types.

2)  Users had trouble understanding the button for pushing data from one grid to another. "It seemed like a 'download' button. I had no idea"that you can copy data".

4)  "In the validation table, I need to know the source for reference purposes."

5)  "I should be able to know the patient's inputs, their status so far before I can fiddle with their data."

PM:

1) Users can only import DoseSpot data if the patient has provided electronic consent. If not, they can call patients to obtain verbal consent and report it on eChart.

Hi-fideltiy Iteration 1

Based on the feedback gathered from the mid-fi stage, I made the following design changes to address the requirements:

Hi-fideltiy Iteration 1

Final Hi-fi Design

 

For the final stage of iteration, all the requirements were met, and it was about improving usability wherever possible. Hence I went forward to conduct a final detailed round of usability testing.

Final Hi-fi Design​

User Testing Results

 

On testing the entire workflow, the Patient Information, Height/Weight/BMI and Questions Modules were very clear to the participants that they have to tweak the responses once they become editable, however, the problem lied in Allergies and more specifically, the Home Medications modules, since they required a series of tasks to be performed in sequence.

What was causing confusion

all-hm2.png

Users had difficulty understanding the sequence they need to go through. Even after explaining once, they had difficulty retaining just by looking at the design. Hence, was a serious matter of concern.

In Home Medications module, since the complexity is even more requiring the user to more steps in between, the confusion was greater

Additionally, it wasn't clear to the user that responses from the patient and DosSpot grids can be added to the 'Adjudicated Data' section independently.

Solving the usability issue

To address the issues, I redesigned 3 options of the modules and conducted further testing:

Option 1

Frame 8.3.png

A common 'Add' button for both patient and DoseSpot data

Option 2

Frame 8.3-2.png

Separate 'Add for Validation' button for patient and DoseSport data

Option 3

Frame 8.3-1.png

Option 2 + Individual 'Add' buttons for ever row, and an 'Add All' button at the end of grid.

✔  Preferred option

Clearer to the users that data from the 2 grids can be added independently

More intuitive and saved clicks when moving data.

user test log-1.jpg

Usability Test Data-logging and Assessment

Final Design

Complete Flow Illustrated

Adjudication BLOC.png

Outcome

 

This feature was released along with HST Surgical Scheduling (Patient Portal) that benefited in multiple ways:

• Accuracy in records is maintained as every response is mapped to a medical term in the database before going into the Patients record. Furthermore, Immediate drug/drug and drug/allergy checking can be done.

• Multiple users can access and chart on a single patient simultaneously with LiveEdit™ technology to visualize and communicate changes made by all users with chart access.

• Clinicians can do their job more efficiently without waiting on someone to release the record.

• Patient safety is improved when clinicians can make immediate procedure or treatment changes.

bottom of page