A Few Scratches: Paper Prototyping an Accommodating Patient Chart System

Sam Essenfeld
16 min readFeb 5, 2023

--

As a student of Emory’s Human Computer Interaction class, we have been challenged in the past three weeks to explore an area related to personal health data and assess for needs, gaps, and/or significant problems in that field. I chose to explore the domain of patient charts.

https://thenounproject.com/icon/medical-chart-2251658/

In summary, I found that doctors face problems interacting with patient charts due to how a lot of information is squeezed onto the screen at once, or how it requires several clicks just to get information they should have had when they opened the electronic program. I also found that patients, while mostly neutral on the issue, would like to have an easier time getting feedback on their test results, either by asking their doctors in person or by clarity of charts. If you would like to read the full article, you can do so here.

In the meantime, I have developed and tested a paper prototype of an electronic patient charting system, which I would like to share with you in this article. Ironic, isn’t it?

DISCLAIMER: No names or information included in this prototype are real and any resemblances are purely coincidence.

My Intentions

From my need finding assessment, I have gathered a few assumptions that I used when creating the designs and prototype. While I got feedback from both doctors and patients, this new design is intended to be for doctors, and potentially nurses. The following is the list of assumptions:

· Doctors move fast
· Doctors want simple interface with most relevant information
· Patients want clear graphs for their test results
· Patients do not visit doctors very often- total number of appointments vary
· Patients with chronic illnesses may have more visits

My main goal is to achieve speed and efficiency with information presentation.

Keep these assumptions and goal in mind when we explore the feedback from my classmates, they may be confirmed…

My design intends to improve on the accessibility with both depth and breadth of the current experience doctors have with patient chart systems. In this case, “depth” means how many times they are clicking to get around, and “breadth” refers to the information being presented on the current screen. I want to give them access to data without an overflow of interactions to get there resolve the screen real estate issue by having clear boxes, especially horizontal ones when a longer amount of text is included. In my mind, a doctor should not have to go through more than four or five clicks to get to all relevant information, and they were ability to edit should be quick they have to move very quickly throughout the day.

20 Little Storms: The Brainstorming Session

When beginning to think about this design, we were asked to come up with at least 10 ideas on how to design each screen or aspect of our experience. In my mind, a doctor should have access to their patients’ medical history and test history. Medical history includes critical notes about the patient, current and past medications, and notes from the doctor and/or nurse who oversaw each appointment. In total, I had 20 different sketches to choose from for this design, and added extra components afterwards to support my choices.

Please refer to the numbers on the righthand side of each picture when necessary

I decided to combine the 10th sketch from each page and turn them into my paper prototype. These sketches felt like they could balance the screen reading efficiency with the ability to still click in some cases the most.

The Initial Prototype

The Two Main Pages

Medical History Components

  1. “Criticals”: For notes on a patients critical information, such as recent events, family anecdotes, or allergies. This section is expandable.
  2. “Medications”: For a list of medication history of the current patient. Includes name, dosage, and duration. This section is expandable.
  3. Doctor Notes: Notes by the doctor(s) who conducted the visit. Selecting the dropdown will give the user the ability to skip directly to a different doctor’s notes, or the user can scroll when the mouse is in this section.
  4. Nurse Notes: Notes by the nurse(s) who conducted the visit. Selecting the dropdown will give the user the ability to skip directly to a different nurse’s notes, or the user can scroll when the mouse is in this section.
  5. Diagnosis: A kind of “Too long, do not have time to read everything” bar where the gist of the current appointment is bulleted.
  6. Current Patient: In the top left corner the user can see the current patient, or click here to pull up a view of the day or week of patients to switch between them. A profile picture of the patient is included as a friendly reminder to the doctors and nurses.
  7. Appointment Dates: Imagine the selected date of information being bolded on the left-hand column. When changing appointment dates, the “Criticals” and “Medication” sections stay static, but the doctor and nurse notes sections change for that day. Hitting the flip button will switch the left column to view surgeries/emergencies.
  8. Tabs on the Bottom: To get back and forth between the two pages; shading means that it is selected.

Test History Components

  1. Name: The name of the test conducted. This section can be filtered alphabetically, or in reverse alphabetical order.
  2. City: The city the test was conducted in. This section can be filtered alphabetically, or in reverse alphabetical order.
  3. State: The state the test was conducted in. This section can be filtered alphabetically, or in reverse alphabetical order.
  4. Result: Primary results can be listed numerically, ordinally, or binarily. This section can be filtered in all three ways by continuing to click the filter button in the Result header.
  5. Graph: A preview of the primary graph used to plot this result. Clicking on it will reveal a pop up window with more details and notes.
  6. Notes: This is for short notes by the user of the system.
  7. Current Patient: In the top left corner the user can see the current patient. The same functions apply here from the Medical History page.
  8. Tabs on the Bottom: To get back and forth between the two pages; shading means that it is selected.
Auxiliary Designs for (from left to right): The patient calendar, medical history, and test history

The left picture includes what the initial pop-up window looks like when clicking on the patient in the top left corner.

The middle picture includes a “highlight” box for dates, tabs of different patients that can be viewed, columns for viewing both surgery and emergency dates, a generic expanded section for either “Criticals” or “Medications,” a generic patient appointment/surgery/emergency viewing page, a secondary nurse notes section when adding a new nurse, a drop down bar, and a secondary diagnosis bar for variety. It should be noted that the notes section for surgeries and emergencies will consist of doctor and nurse notes from those who oversaw the surgery or emergency.

The right picture includes additional rows for tests, a pop-up window with graph information that includes download and send buttons, and an email template. In the email template, the user can physically write in the email and name of the doctor, nurse, or office they are sending information to. Then, the system will auto-generate the name of the test and name of the patient in the body of the email. A PDF of graph information is already included as an attachment to save the user time.

Testing the Prototype: My Friends E, N, and T

https://www.javatpoint.com/ent-full-form

After making my prototype, I went to go ask my classmates to pretend they were doctors in order to test it out. This is not very hard for some people at Emory. I talked to three classmates, who I will refer to by the first initials, “E,” “N,” and “T”. During each session, I initially let my classmates interact in ways that came naturally to them while providing explanations when questions were asked. By the end of each session, I was talking them through my thought processes and showing them features that they may have missed during their interactions . This way I got a balance of their raw thoughts and feedback on my own.

Before beginning each session, I laid down 3 grounding principles:

· You are a doctor
· You are encouraged to tap anything and everything
· Shading = Selection

I met with “E” first in the library.

The first thing “E” noticed was the flip button from appointments to surgeries/emergencies. Since it was not labeled, she was confused on its functionality. Brief exploration in this area was followed by a switch to John Smith’s test history, including a graph inspection and adding a new test to his history.

”Fab, I love that.” — “E,” when opening the graph interface

The most impactful moment from this interview came when “E” wanted to switch patients. As she opened the full week’s view, she asked if she was only allowed to see patients from the current week, or if there was a way to see all patients. Well shoot, you make a good point “E.” Now I knew I had to make some changes in this regard. She suggested I make a new homepage with an extensive search function, one that shows all of a doctors patients when the doctor opens up the application. “E” told me her father also happens to be a doctor, and he gets a ton of phone calls every day from a wide variety of patients. He needs to be able to look up their information very quickly while on the phone with them. So, I took this under heavy consideration following the next two interviews.

“E” Top Feedback:

· Likes

  • Graph window in test history
  • The ability to flip back and forth between appointments and surgeries/emergencies in the medical history section

· Dislikes

  • The appointment <-> surgeries/emergencies button, function is unclear
  • Title format in graph window
  • Lack of full patient search abilities

· Does it achieve speed and efficiency with information presentation?

  • “Definitely… for sure… very speedy…very efficient… very self explanatory”

I met with “N” second, also in the library later that evening.

“N” was immediately drawn to pushing every button he could find on the medical history page, then exploring the patient schedule in the top left corner, and then wrapping up with the test history. On the medical history page, “N” enjoyed how one could skip the whitespace between the notes from different doctors or nurses, but was confused about the button to switch between appointments and surgeries/emergencies. He thought it was a refresh button. When “N” explored the test history, he made a good point about the listings. Doctors should be able to view a full report of the tests by clicking on them.

“The email feature is nice and simple. It’s easy but people don’t do it.” — “N”, inspecting the email template from the graph page

“N” Top Feedback:

· Likes

  • Email Template from the Graph window
  • The flipping feature from appointments to surgeries/emergencies
  • Dropping down to each different doctor’s notes to skip the blank space
  • Not too cluttered

· Dislikes

  • Initial confusion from the first screen he saw
  • Could not tell if the top left corner was a patient or himself as a doctor
  • Not the most detailed system, but the essentials are there

· Does it achieve speed and efficiency with information presentation?

  • “I think so”

After making some minor adjustments from the feedback of “E” and “N”, I met with “T” in my apartment.

These minor adjustments included writing “Add Here” next to the plus button for appointments and surgeries/emergencies, clearer schedule expansion and retraction buttons, and an expansion button next to the graph icon on test history. Let’s call this version 1.5.

“T” began inspecting the prototype, and asked a lot of intricate questions. He asked if clicking on a patients appointment on the scheduling calendar would bring up their specific appointment in the medical history page. That made the most sense to me, so I agreed. Conversely, he asked what would happen if he was viewing a past appointment from a long time ago and then opened the calendar. Would it be on the current week’s schedule or open at the time of the appointment being viewed? My decision was that the calendar would go back to the current day and weeks schedule.

Oh boy! What fun!

When looking at the medications in the medical history section, “T” questioned what would happen to medications prescribed during past appointments when viewing a future appointment. I had not thought about it before. I decided it would be smart to add date ranges to the listed medications. “T” then tried to click on the diagnosis section to expand it, but this was not a feature I had included. I did not think it was necessary to expand this section since I intended for it to be a place where doctors can glance and understand the appointment in less than 5 seconds.

The last aspect “T” noted was about viewing multiple patients at the same time. At first he suggested pulling up multiple pop-out windows for multiple patients, but we both agreed that the screen could become cluttered very quickly. In keeping with the tabular format of the medical history and test history, he then suggested I make multiple tabs at the bottom for viewing multiple patients, like you may see at the top of the browser you are reading this on right now. I thought that this was a quick and space-efficient solution, and a necessary feature to add.

“It’s pretty much perfect” — “T”

“T” Top Feedback:

· Likes

  • The calendar system; it’s a very familiar layout and system to him
  • Immediate viewing of criticals and medications
  • Ease of sending a reference through the graph window

· Dislikes

  • Difficulty in navigating through specific patient appointments and patient calendar
  • Undated medication information

· Does it achieve speed and efficiency with information presentation?

  • “Yeah for sure, yeah.”

With those final feedback and tips from “T,” and had much left to do to improve on the prototype. I got to work.

My friends “E”, “N”, and “T” proved to be great ears for hearing my ideas, nose to smell out the flaws, and throat to voice their opinions.

What’s New?

From my own experience guiding each of the review sessions with “E,” “N,” and “T,” and from their feedback, the following is a list of pain points that I decided to improve upon in the 2.0 version of the patient charting system:

· “E”- Patient overview system, adding dates to the test history page, a movable plus button for adding new tests into the test history

· “N”- Full test results when clicking on a test

· “T”- Medication date listings (current and expired), Patient tabs for viewing multiple patients

Now users can click on a test!
Left: Now users can add patients to the tabs at the bottom. Right: We might want to know if a patient is still on their medications or not.
Welcome to the Patient Overview page!
The user can also user specific filters for finding past or future appointment dates.

A Big What If: Designing a More Complete Evaluation Plan

If there was no problem accessing the necessary resources, how would we evaluate our design on a larger scale?

Given the limited feedback we as a class were able to gather during this assignment, we also need to think about the bigger picture. If I had sufficient time and resources to truly evaluate this new system I am prototyping and proposing, I would reach out to a variety of different doctors across the country, get a mix of supervised and unsupervised interaction sessions, then collect very brief forms regarding their experiences.

First, I would work with governing medical bodies such as the American Medical Association (AMA) or the Federation of State Medical Boards (FSMB) to reach out to two randomly selected groups of physicians. In the first group, I would randomly select 50 offices who primarily rely on paper patient charting systems. In the second group, I would randomly select 50 office who primarily rely on electronic patient charting systems and have been doing so for more than two years. The time specification is to ensure that doctors are familiar with their own current system with enough experience to evaluate a potential new one.

https://techcrunch.com/2015/04/29/the-art-of-giving-feedback/

The interaction sessions would consist of two parts. Initially, doctors will be guided through three short use case scenarios where they will get to explore a majority of the basic functions of the system. There will be one use case for each of the medical history, test history, and patient navigation main pages. Afterwards, doctors will have the opportunity to freely explore the rest of the system as they please. They will be encouraged to navigate the system as if they were using it for their patients in the past week so that they can have a more grounded idea of the comparisons.

All of these instructions will be prompted to the doctors by the application, with the exception of 10 randomly selected doctors from each group. These 20 doctors will go through their interaction sessions while being observed by a member of my hypothetical application team so that they can field questions in real time, give instructions when necessary, and take notes on reactions. This observation will be done via video conference calling and screen sharing.

All doctors will be asked to fill out a short survey with short answers for their thoughts, ranking scale questions for different features (happy to unhappy, effective to ineffective, or N/A if didn’t use that feature, etc), and then a section for additional questions. The team would follow up with a video conference call or phone call for doctors who have those additional questions.

https://www.smabears.org/survey/

After collecting data from all 50 doctors, I would reincorporate edge cases and feedback into the system and perform one more round of evaluation with fewer doctors. Most likely, I would randomly select 10 new doctors who were not previously interviewed for the electronic group and 10 for the paper group.

The End! How do we feel?

All in all, I think it is suffice to say that I did a pretty solid job at coming up with a patient charting system. This was a very extensive process, but I had a lot of fun talking to everybody and coming up with all of the ideas.

Based on my own judgment and the feedback from my friends, was I able to come up with a space efficient and readable system? I believe I have.

While there are many features included already, I know that more can be added if I were to continue working on this project. If I were to go back out there and interview more doctors, or patients, I am confident that they would not only complement the current design comma but continue to have meaningful contributions as well.

Thank you for reaching the end and reading this article! I hope you were able to gain some insights and can think about usability and appeal of your patient information available to you next time you go visit your doctor, or talk to a patient.

Gallery

My Initial Notes

Please refer to the numbers on the righthand side of each picture when necessary

ENT Interactions

Initial Components

The Two Main Pages

Patient Overview, and other New Features

--

--