eCR Viewer
Creating a user-friendly tool to make viewing complex public health data simple
Overview
DIBBs (Data Integration Building Blocks) is part of the Pandemic Ready Interoperability Modernization Effort (PRIME), a multi-year partnership between CDC and USDS that began during the COVID-19 pandemic to address critical gaps in pandemic-ready public health technology. The COVID-19 pandemic revealed that public health departments' current technology to ingest data from health care providers was not able to handle the volume of data coming in during a pandemic.
The DIBBs team was formed to develop CDC-offered products to help public health departments strengthen and modernize their data ingestion infrastructure. DIBBs has a large team with parallel efforts under the project umbrella (3 work streams as of Jan 2023), and I was primarily been a part of the Streamline eCR team from June 2023 to September 2024. The Streamline eCR team focuses on using the DIBBs building blocks and pipeline to make eCR (electronic case reports) more usable for public health departments through the eCR Viewer.
👩🏼💻 My role: Product Designer, User Researcher
👥 Team: 1-2 Product Designers, 4-5 User Researchers, 1 Content Designer, 2 PMs, 10-12 Engineers/Data Scientists
💼 Client/Partners: CDC, USDS
🕰️ Timeline: I have been on the DIBBs project since Nov 2022 and left the team in September of 2024
Project 1: Improved eCR Viewer
Context
Electronic case reporting (eCR) is a relatively new data standard introduced to public health. eCR enables real-time, automated reporting of detailed medical record data to help provide public health with more timely and complete data to track infectious diseases and outbreaks. eCR is meant to save healthcare providers time by replacing manual case reporting and provide more complete and timelier data to public health departments.
The implementation of this new data standard, however, has been extremely challenging, especially for public health departments. When public health staff receive eCR, it's often includes a patient's entire medical record. Trying to find the relevant data for their job is like trying to find a needle in a haystack. Public health staff dislike using eCR so much that many health departments have been extremely slow to adopt eCR despite increasing pressure from the CDC.
Sample eCR message with formatting offered by APHL
Challenge
The CDC asked our DIBBs team to create a solution to make eCR more usable to save time processing eCR for public health staff, as well as improve perception and increase adoption of eCR.
We were also asked to create a solution that would easily integrate with the surveillance system offered by CDC, called NBS (NEDSS (National Electronic Disease Surveillance System) Base System) - yes that's an acronym in an acronym. We also had a year to get to an MVP and pilot.
My role
I was the only designer on this team, and I collaborated closely with the user researcher on the team. Our full team also included a PM and a team of about 7 engineers. As the product designer, I was responsible for taking our learnings from research to design and scope an MVP solution to make eCR more usable.
Research
The researcher on the team conducted semi-structured interviews that included some concept testing with 17 public health staff from 7 different states/territories to understand their processes for case reporting and gather feedback on eCR. I helped to plan, facilitate, and analyze the research, but it was lead by the researcher.
This research not only gave us invaluable insight into public health staff's end to end workflows in processing case reporting data, but it showed us where the biggest pain points were with integrating eCR into their existing workflows.
Our biggest learning was that one of the most significant blockers to integrating eCR into their workflows today was not that the data was unhelpful, but that the presentation of the data was so confusing that it made the data source itself unusable. When eCR was created, so much of the focus was on saving time for healthcare providers, but not much thought was put into designing the output to be usable for the public health end users.
It was so hard for public health staff to make sense of the data they were looking at that they preferred to just not use it. Some of the biggest challenges were that different pieces of data showed up in different spots with every eCR they opened, different data would be available on each eCR with no explanation, some eCRs would have basically an infinite scroll with hundreds of lab results attached, and key pieces of data never even made it into the human-readable view.
I created this workflow diagram to communicate how eCR fits into the case reporting process to stakeholders and our team
Prototyping
From our research, I came up with the hypothesis: if the presentation of eCR data was designed with the needs of public health users in mind, would it be easier to use?
While we were still conducting our research, I put together an initial concept to start getting feedback from to test this hypothesis.
Screenshot of the low fidelity concept design I put together for user feedback. One of the key value propositions was adding the most relevant summarized information right at the top so the user could avoid scrolling through a very long document to find the information they needed.
Screenshot of exercise I conducted to come up with an initial information architecture. As I looked through various data standards, medical records examples, and sample eCR, I made stickies for all different data fields and then started to group them into different categories and order them over multiple iterations.
From the feedback we received in the research sessions, I was able to further refine the concept design and eventually produce an first version of a high fidelity design.
Refined concept design on the left and first version of high fidelity designs on the right
Validate
While our team received really positive feedback from user research sessions on the concept designs, our team and our stakeholders wanted to get enough validation on the idea before agreeing to develop an MVP to pilot with public health departments. We also needed a viable pathway to implement the solution with jurisdictions without adding too much implementation burden.
We used the following steps to get the necessary validation to move forward with building the tool:
-
We showed the concept designs to a group of 100+ public health staff from across the country in an eCR workgroup meeting. We got overwhelming positive feedback an excitement from this group, which got our stakeholders very excited, especially since it is hard to get that group excited about anything eCR related.
-
By studying the NBS app, I proposed a clever solution to easily integrate the eCR Viewer directly into NBS. This was determined to be technically feasible for our team and the NBS team, and allowed the eCR Viewer to be introduced into users' workflows with zero disruption to existing processes.
-
We presented the concept designs to the two main CDC stakeholders for eCR to get their buy in and approval for the idea, since they are the main subject-matter experts in the space.
-
Our stakeholders wanted us to get at least 3 states to agree to pilot out the tool with us to prove that people actually wanted the solution enough to invest time into testing and developing it.
These four steps gave our team enough confidence to move forward with developing an MVP product to pilot.
Designing the MVP
I collaborated closely with the product manager and engineers to scope the MVP for the eCR Viewer. It involved looking in depth at medical records, eCR data standards, and tons of sample data in xml and html. I also worked closely with the user researcher to integrate user feedback into the MVP.
The main value propositions of the eCR Viewer included:
-
eCR Summary: The eCR Summary displays key information in a summary at the top of the eCR document to help users understand the data at a glance.
-
Consistent information architecture: The eCR Viewer displays the same fields in the same order no matter what healthcare provider sent the eCR.
-
Easy navigation: Users can utilize the side navigation to skip to any section with an eCR.
-
Collapsible sections: The main sections in the eCR viewer are collapsible so users can hide sections they don't need to see. All lab results are also collapsed by default to reduce the vertical length of eCRs.
-
More data available: The eCR Viewer pulls out more data fields from eCR than what's currently available by default in the human readable eCR files.
-
Unavailable data: The eCR Viewer has a section at the bottom listing out the unavailable data fields for any given eCR so the user doesn't have to wonder what data wasn't available from the provider.
-
Search: The user is able to search across the whole eCR using a search bar at the top to more quickly navigate to the information of interest.
-
Fixed patient banner: The patient information is fixed at the top of the eCR Viewer so that users can always tell who an given record is for if they leave the file open and come back later.
Screenshot of an earlier version of the MVP design in Figma.
Outcome
I left the project in the midst of our pilot implementation, so I wasn't on the team to see the end impact of the tool. As of June 2025, the team is still working with 6 public health departments across the US to pilot the eCR Viewer (Maine, Philadelphia, Chicago, Colorado, Tennessee, and New Mexico), and new jurisdictions regularly reach out to learn how to adopt the eCR Viewer.
The main impact I was on the team to witness was the successful development of the MVP and beyond, as well as the successful integration of the tool into NBS. These were huge wins on their own for the public health space since new tools often mean just another new tool to add to already complex and burdensome workflows. The end users of the eCR Viewer wouldn't even necessarily know they were using a totally new tool because the integration is so seamless for end users.
Before I left the team though, I worked to lead the development of a Theory of Change and Measurement plan to help define and communicate the purpose of our pilot and ensure our pilot metrics correlated with our outcomes. These are still in use for the team today as they work through the pilots. The measurement plan will be used to measure the impact of the eCR Viewer when in use.
Our main outcomes were that with adoption of the eCR Viewer:
-
Surveillance and disease teams spend less time and manual effort understanding and taking action on eCRs
-
Surveillance and disease teams better utilize the data within eCRs in their workflows
The theory of change and measurement plans I lead the development of for the team. We had many workshops to land on this final artifact and to get buy in from stakeholders.
