One of the key difficulties facing physicians in the age of EHRs is the balance of documenting and referencing patient information while still maintaining meaningful "face time" with that patient during their visit, all within in a 15-minute time slot!

As such, one of the key areas of focus for the Clinicals team was creating a way for medical providers to get up to speed on a patient's story before a visit actually began, reducing the need for them to consult the computer during the clinical encounter.

Patient Snapshot was my contribution to this project, a concept meant to sort through all of the clinical events that have occurred since the physician last saw her patient, and surface them in an easy-to-consume format — a sort of Physician's Digest ​on a per-patient basis.

By consolidating all of the information a physician might not know about a patient in one location, and giving them the ability to dig into it as they saw fit, we would strike the balance between giving physicians a full view of the patient's profile and giving them the agency to make intentional decisions. 

Additionally, Snapshot worked as a filter for clinical information; selecting an item filtered the patient's timeline down to only the information relevant to the chosen item.

Because clinical events often have connections with lots of other pieces of data, like medication orders, documents, and office notes, giving physicians the full picture of a selected event was an important part of solving this problem.

A patient's first encounter with clinical staff is typically with a Medical Assistant (MA) or nurse, who takes their weight, blood pressure, and asks some questions about their medical history and lifestyle.

In athenaClinicals, these historical and lifestyle questions are bundled into a section called "Social History." Because of significant technical debt and a bloated set of additional questions added over the years to meet client needs, Social History had become cumbersome for clients to use and difficult for us to improve.

Each question in Social History was an independent entity, and because the section had no built-in logic, questions that seemed like they ought to be related weren't, leading to confusion and unnecessary work.

For example, if an MA indicated that a patient had never been a smoker, they would still need to answer questions like "packs per day" or "years of tobacco use," despite the fact that they had logically already answered that question. The system wasn't helping our users here, and given how many different questions there were, the problem was getting severe.

As such, we began the process of revising and redesigning the Social History section, with the goals of creating a section that:

1. Responded to client input
2. Allowed them to more easily fulfill Quality measures (for reimbursement by Medicare), and
3. Permitted the team to more easily add and modify the list of questions available to clients.

In this new design, questions are grouped into topic categories which are connected by branching logic.

In this example, if the patient indicates that they smoke tobacco, selecting the appropriate answer opens up a new list of questions for the user to answer. This is important to meeting our goals of decluttering the section and making it more coherent by only present questions that are relevant, and hiding the rest that aren't.

Another key goal of this system was to permit users to complete "Quality measures" while they document patient information.

Quality measures are essentially requirements established by Medicare and other government entities that ask practices to complete certain processes with their patients every so often.

One such measure is making sure that a patient is asked about their smoking behavior every year. By incorporating these measures directly alongside their relevant questions, this design helps users easily remember and complete the measures as a part of their normal work with the patient.