Streamlining the medication prescription process for providers with a responsive and interoperable web app

The Challenge

Design a responsive web app for providers who prescribe medications while minimizing human error and cognitive load

ePrescribe UI flow

The Project

As healthcare technology systems move towards interoperability, healthcare applications and products will dramatically improve. A large contributor to this movement is the adoption and implementation of the FHIR data standard, which features modern, interoperable data models for healthcare. The ePrescribe project was one in a series of medical apps being built to demonstrate the flexibility and usefulness of interoperable data systems in healthcare.

The app’s primary users are healthcare providers who are responsible for prescribing medication. It connects to any patient registry mapped to FHIR and an external medication database, enabling the app to be easily modified and white-labelled.

The user flow is, by design, very simple. The prescriber begins by searching for a patient in the registry, then has the option of viewing their patient profile or skipping straight to the prescription stage. The design of this prototype came out of secondary research on the traditional provider prescription workflow.

The purpose of the patient profile is to give the prescribing party an easily digestible view of the patient’s information and history. This helps them not only in diagnosis but in the medication decision-making process. What kinds, strengths, and quantities of medications should be administered to a patient relies heavily on variable information such as age, weight, active problems, current medications, and past encounters. Providers often see several patients in one day, each with hoards of unique information, so having this available at-a-glance throughout the prescription process is important.

Patient profiles are designed to be modular. The app renders their personal information, encounter history, and medication history from the dataset to the screen. If the patient has no active problems, the app simply displays the Active Problems (0) header instead of an entire null card, therefore reducing the amount of information on-screen. This serves to make the system more flexible giving how varying the patient’s dataset could be. The cards are also expandable, giving the user control over how much or how little information they need to see at one time.

Several details in the final design come specifically from the unique user experience called for by a prescription app. For example, rendering the patient’s birth sex using strict female or male icons is critically important when it comes to medication, even if the patient does not identify with their birth sex. In the future, as data standards catch up with social change, consideration should be made on better ways to more accurately present a patient’s birth sex and gender independently. This work will likely begin at the data model level.

Finding and prescribing medication are, of course, the most important functions. When searching for a medication, the list automatically matches typed. An automatic results filter is key to improving user experience - constantly searching and re-searching complex medication names is frustrating.

A future proposal for an app like this is to connect to or create a medication database which feature contraindication data. That way, the system could flag the prescribing party if a medication they’ve selected may interact with the chosen patient’s health information or other medications. It would be important that this does not take the form of a pop-up or other forced interaction. There are thousands of possible minor warnings that providers are already well-aware of, and forcing them to close a pop-up in every use cycle would be draining.

Close attention was paid to model the prescription form in a similar format to traditional prescription pad formats. Converting a workflow from paper to screen needs to take into account the long-standing habits of users, only forcing change where digital improvement makes that change significantly impactful.

For example, while the form looks like a prescription pad, it has the added feature of reducing cognitive load by doing quick math. If the prescriber is giving the patient 30 units per day, b.i.d. (twice a day), the obvious quantity output is 60 units. So a formula of [frequency x duration] is attached to the Quantity input field. In fringe cases where this isn’t the case, the user can simply click the lock to input their own Quantity calculation.

An e hiding in a Big Top
An e hiding in a Big Top


I was the sole user experience, user interface, and style designer on this project. I also styled the working prototype in HTML and CSS, which was built using Bootstrap and Angular 5. It was my responsibility to combine client expectations, secondary user research, and developer capabilities into an excellent product. There were a lot of challenges in this project that made it a great learning opportunity.

First and foremost was understanding a user experience entirely foreign to my personal experience. I used resources available to me to understand, as best I could, the workflow and concerns of a prescribing clinician. I used published studies on previous attempts to move traditional provider workflows to digital formats and reports on the problems surrounding medication prescription from the last two decades to help orient myself. The strongest flaw in this process was the lack of primary user research, which was planned to be inserted into the second round of iteration and design.

The second biggest challenge was working to unite the user experience and interface with its underlying data system. I had to do quite a bit of research into FHIR, both general and specific to the test data we would be using. This usually meant asking a whole lot of questions and doing personal study on integrated data systems. This saved time in the long-run, since the developer didn’t have to rethink the entire UI to get past functional assumptions made by the designer.

Sectioning out user story
Personal notes on app flow
Personal notes on prescription processes
Paper prototype section

This project took place during my Product Design internship at Smile Clinical Data Repository in the summer of 2018. Special mention goes out to Nadia Schutz, the incredible front-end developer on this project, as well as James Agnew and Duncan Weatherston. They, and the rest of the Smile team, are truly superstars of the healthcare technology world. Their patience and willingness to share their knowledge elevated and inspired me as a designer.