Content analysis: opportunities for data extraction & display

Question: What data is coming in via these documents, and what data elements are actually useful for clinicians to see outside the document?

The first challenge I had to deal with was making sense of the millions of clinical documents that came into patient charts each month. The lead Product Manager sent me a dashboard that let me find examples of real faxes; after de-identifying them, I started an Object-Oriented UX (OOUX) exercise to establish the following for each document class:

Through this process I was able to lean on my own knowledge of clinical workflows and internal initiatives to define the opportunities within the space.

OOUX gave me the opportunity to balance the attributes of each document class with data needed for other initiatives, or for specific clinical workflows.

While I did this, I started creating a Markdown file documenting what I was seeing in the documents themselves, which the team could then use to inform the work they were doing on the classification and labeling models.

Documenting what I was seeing in the documents gave the team insight they could incorporate directly into the software they were building.

I also used a tool called Cogulator to calculate the time it would take an experienced user to complete the workflow we were talking about automating in seconds. By calculating the seconds per document against the volume of documents received by fax or internal adding, we were able to demonstrate the potential time savings we could create for our users by pursuing each opportunity.

By multiplying the time per document with the number of documents received per year, we could provide an estimate of time savings for each opportunity.

This exercise gave us an extensive set of opportunities that we could start negotiating with partner teams.

Opportunity Validation

Question: Given our catalogue of opportunities, what resonates most with clients?

Once we had the first wave of opportunities identified, I worked with the team to determine which would benefit from additional user validation. We chose six in total, which I validated with an advanced Qualtrics concept survey. After participants suggested which of several jobs was most relevant, they were shown 1-2 concepts related to that job, and asked to rate them across several standard dimensions. The average score received gave us a sense of how valuable this opportunity would be to our users. Free-text comments also gave us a sense of how the concept could be improved.

Our survey gave people the opportunity to provide feedback on a small number of six total opportunities; the resulting scores helped us further prioritize the work.

For each concept we validated, I created two artifacts: a single slide in our Evergreen deck that the team could present from, and an Insight Report in Marvin, athena’s research repository, that went into more detail.

Each slide had a corresponding Insight Report that went into more detail, including how to expand the opportunity’s value further.

Determining how Manually Added Documents fit in

Question: How can we reduce the burden of manually added documents? Are there any opportunities we’re exploring that could also be applied to these document types?

Shortly after we identified our most promising opportunities with external faxes, leadership presented us with another challenge. Each month, clients add 20 million documents to the system, each of which has to be manually classified and labeled by the client. This added up to a tremendous amount of administrative burden, which our document processing work didn’t even touch.

I was surprised to learn that the volume of manually added documents actually exceeded the number that come in through fax each month.

To break down this problem space, I worked with the team to do:

The outcome of that research was a clear understanding of who, how and why documents are added manually, and how that information feeds into the larger picture of a practice’s daily workflows.

The research we did gave us a baseline knowledge of who, how and what was being added to the chart manually. This was essential for figuring out what, if anything, could be automated.

Understanding the different methods by which these things were added gave us insight into what we could fold into our existing automation queue. It also made it clear where we needed to move predictive suggestions into the scan/upload workflow itself, to speed up the process for users. Finally, it revealed that for several of the most important document types clients were adding manually, there was no appropriate document class — which exacerbated an already heavy findability issue.

I worked with the team to come up with a proposed roadmap, as well as some visual articulations of the approach we needed across different channels.

Unpacking the problem of duplicate documents

Question: How do we address the issue of duplicate documents coming into the system across all these different sources?

Now that we were starting to get a solid picture of how we could reduce the burden of unstructured fax/image-based documents across athenaOne, leadership came to us with yet another challenge: duplicate documents. As interoperability has become more common, clients complained about receiving multiple versions of the same information across every possible channel. This was such a pervasive problem that we even heard about it in our research on other topics.

The topic of duplicates came up independently in each of the research projects I’d done previously with this team.

In a tightly compressed three-week timeframe, the team and I were challenged to conduct a workshop across multiple business units and functions, and complete a site visit with one of our largest clients in the middle of the country.

We were given an aggressive three-week timeline to do a ton of research and vision work.

Fortunately, I had a treasure trove of insights to start with, and several interviews scheduled when this request came in. I was able to dig into that prior research, with help from Marvin’s AI-enabled search, to start identifying the types of duplicates that people were seeing, and the circumstances by which they came in. I called these “dupe cases” and wrote them up as user-driven stories for participants to reflect on during the workshop.

Presenting each dupe case as a story brought them home to workshop participants, leading to better conversations as we collaborated.

Once we had the stories together, we pulled together 23 people across divisions and teams to start talking through the space. We started by laying out the problem space, including an overview of each incoming channel. Then we assigned breakout groups to brainstorm specific aspects of the problem space.

After laying out the problem space, we did three breakout groups that let people brainstorm a particular facet of the overall problem.

The following week, I brought six of the workshop participants out to Illinois to visit one of our larger clients, who had been active in the space. We observed workflows across several of their offices, and learned directly from clinicians and staff about the issues these duplicates created across their organization.

Once we were home, I compiled notes from across all the different studies to create an initiative Confluence home, including a deep dive on each of the Dupe Cases, with examples. I also worked with a data science specialist to structure analytics dashboards that dug into the different types of duplicates.

Once we had all the data, I collated it into a comprehensive set of Confluence documentation that the team could continue working from over the life of the initiative.

Outcome

After almost nine months of working together, I completed over ten research projects with the Document Services team, which required organizing resources, information, and ideas across three separate divisions and multiple teams. The resulting corpus ended up feeding the work of not only Doc Services, but other teams working on issues related to interoperability, care coordination, and the Clinical Inbox.

This work also gave a group of incredibly technical folks unique insight into how our users behave and think about the work that they do, something I heard first-hand from our lead architect in a post-mortem: 

I feel like I learned more domain knowledge in 3-6 months than I’ve learned in most of my projects at athena.

As of this writing in 2026, the team is still working through the extensive backlog of insights we generated together.