Flatiron Health: Group Inboxes

Background

What is Flatiron Health and how does it work with oncology clinics?

Among many other things, Flatiron sells an electronic medical record (EMR) called OncoEMR (like Epic or Cerna, but oncology-specific). An EMR is the software that doctors use to get their work done at oncology clinics – storing and accessing patient records, ordering drugs and labs, etc.

What was the impetus for this project?

OncoEMR is great at some clinical workflows (the work doctors and nurses do), like choosing and setting up a round of chemotherapy, but we get a lot of negative feedback about how OE handles the operational tasks necessary to keep a practice running (e.g. scheduling appointments, calling insurers to confirm they cover a drug, etc).

Task management became a top priority as we started selling to large practices, especially after we signed 3 of the largest in the US in late 2016. When this big practices reviewed how we did task management (after they had already bought our software), we found it really broke down because:

1. OncoEMR was originally designed for smaller practices with workarounds that didn’t scale
2. Practices were moving from another EMR, Mosaiq, that had a buggy but much better task management system
3. These practices had rigorous, centralised processes with layers of management and control that we didn’t support

Initial Research

When I joined the project, there was a bit of existing research that PMs had done during with the 3 big practices. The PMs had confirmed that the big practices cared about task management for 2 workflows in particular:

1. Prior authorisation – to avoid unnecessary drugs being given, most insurers require clinics to submit info showing that a patient needs a drug before they’ll agree to pay for it. Failing to do this can leave clinics in the hole for drugs that cost $1000s, or can delay a patient starting treatment.
2. Scheduling – More obviously, it’s an admin, not a doctor, who schedules when a patient can actually come in for treatment. This includes setting up appointments at outside facilities.

My first job was to understand the workflows in detail and where these big customers had problems. Another key question was if the workflows were similar enough to fit into single framework. I began by interviewing the PMs, admins and doctors at big practices, and those at a few smaller practices who had complained about task management before.

Findings

I found that admins responsible for tasks like scheduling needed to look at all scheduling tasks across the practice. However, OE’s existing way of showing this was for a user to initiate generating a static report - basically a list - of every order without a scheduled time. This was a problem for several reasons:

• Reports took a long time to run (multiple minutes) for big practices
• They were static, so tasks didn’t drop off them as they were completed, and new high-priority orders to schedule didn’t show up in them
• Performing some tasks required going back into the EMR and clicking to several pages to gather relevant info

I also confirmed our theory that the different types of task had a common format, which meant the solution could be a framework to support all of these actions –

1. Event occurs in the EMR (e.g. chemo ordered)
2. It should generate a task and route it to the relevant person (e.g. task to schedule the chemo goes to the scheduling team)
3. The relevant person(s) prioritises their list and completes the task – maybe by pulling info from the EMR and using it externally, or taking an action in the EMR

With this info, I took a first pass at defining the requirements for a solution:

1. Update live as actions took place in the EMR (new order) or the list (task marked done)
2. Organise tasks in a way that they went to the right person or team
3. Bring relevant info together into the task itself to save time hunting for it

Early Designs + Feedback

I sketched some ideas, got a little internal feedback, and put together a rough prototype to get feedback from 5 operational staffers and 3 practice admins and see if it was on the right track:

• A task list for each type of task would be set up, and tasks would automatically be generated to them when an action occurred in the EMR
• A user would assign themselves or get assigned by a manager to a set of tasks
• They’d start at the top, open the sidebar for the first task for supporting info, complete it, and change the status of the task (if it was completed outside our EMR), or get linked to the place in the EMR to complete the task and it would automatically drop off the list

I also showed a second layout that looked more like an inbox.

Findings

1. Practices had clear divisions of work (e.g. Janet only does prior auth for insurer X, Steve does it for insurer Y). I could cut a step by dropping the concept of assignment entirely.
2. Decided to switch to a second UI that was more like an Outlook inbox because every task has to be completed in turn, so the sidebar would always be open. Users also preferred it and said it “felt more efficient”.
3. Also confirmed that they can’t take actions on multiple tasks at once, so batch actions were unnecessary.
4. I missed some key patient info used in prior authorisation, and got feedback on a better format for how to display it. Otherwise, users loved having all the info in one place.

Overall though, it seemed like the solution was on the right track – they needed centralised tasks in a live, shared list of work. Automatically generating the tasks was a huge lift over their previous EMR's task management, which required doctors to remember to check boxes as they ordered drugs. They had been trained to do this, but it was often bumpy getting new doctors acclimatised to the workflow.

Design Iterations

I continued iterating on the design based on that feedback, and also set up user testing with other practices already in the network that the Account Managers suggested. This led to further refinements in functionality and the UI:

• Permissions were set at the inbox level by a super-admin – the engineering team said this would be the simplest, and managers were comfortable as long as teams responsible for each type of task couldn’t accidentally mess up each other’s work
• While we originally didn’t have saved ‘views’ for each inbox because we thought sticky filters on a per user basis would be enough, we discovered that managers found it useful to quickly spot check how their reports were doing
• Users suggested new filters, like dates and order types for other practices who split their work differently.

We also explicitly decided to keep several features out of the MVP because they were less essential, and would allow us to get the feature out sooner to refine any bugs we couldn't catch until the feature was in use:

• Commenting on tasks – occasionally, admin staff need info from clinical staff before they can complete a task, and attaching their questions to the task would be useful for tracking purposes and to share context. However, we found it would be a hard sell to get clinical staff to check the administrative inbox, and we didn’t have the bandwidth to integrate it into the existing clinical task inbox immediately, so we convinced users to stick with using IMs and phone calls for now.
• Audit logging – managers wanted to be able to follow-up when someone messed an authorisation up.

Final Product, Next Steps

We ended up building the group inboxes in a different order than originally planned – the scheduling inbox was built before the prior auth inbox.

We shared progress on the scheduling inbox as it was being built with live demos and feedback sessions. Because of delays to the project, when I left Flatiron in June 2018, it was in beta with 10 practices. The overall feedback was very positive, and we caught and responded to a few refinements:

• Rescheduling appointments was a common case we didn’t account for – needed to be prioritised by the earliest date they were previously scheduled for to make sure patient was informed in time.
• Relative date filters would be better than explicit dates so they don’t need to be constantly updated (should have been more obvious).

When I left, the prior auth inbox was a few sprints away from being completed. We also discovered some refinements based on early demos:

• Auths were often for multiple treatments – ability to set future tasks for the same drug for the same patient to “authorized” at once would save time.

The engineering team also developed the framework as a service, and we discovered teams with 2 new use cases that can use it, in clinical trials and benefits verification.

Video of the almost-beta version. (This isn't the beta version; this is an older version on a Flatiron dev site. I can't share a live beta because it contains patient data.)