Insights were used to collaboratively sketch concepts with my design colleague, and iterated based on continual feedback from the monthly panel of experts, as well as weekly feedback from core team members and our primary doctor SME whom was also a clinical informaticist.

I made the search of CDS tools highly flexible, while being personalized to the clinician and their practice.

I took this approach as doctors did not always know the exact CDS tool they were looking for. The challenge was that doctors may be looking from the perspective of types of conditions, latest guidelines, type of tool, or medical specialty. The search interaction had to take all perspectives into consideration, leading me to design multiple ways of exploring the set of CDS tools.

Doctors can search CDS tools using tags surrounding specialty, medical service, conditions, or clinical guidelines.

Quick jumps to relevant areas organized by clinical domain and keywords.

Search autocomplete from several categories of content.

Tree diagram search focused around clinical guidelines.

Tree diagram search concept, applied to a CDS tool page.

Customize the organization of CDS tools to fit doctors mental models.

Similar to YouTube playlists, “Topics” are created groupings of content under which CDS tools can be organized, whether they be under a certain patient population, condition, a specific published guideline, or a new grouping which uniquely fits for a type of practice or clinical situation.

Once a doctor enters a CDS tool page, they can explore what the tool does, how it should be used, and any evidence that is driving the content.

Incorporate transparency driven interactions within the experience of exploring CDS tools.

Evidence-driven medicine is of utmost importance to doctors. Therefore, to build trust, my colleague and I designed multiple ways of showing how a CDS tool evolved from creation, to where it is today.

In earlier designs, this started from showing the authors of the tool. The doctor could then explore information on the guideline or source driving the tool, as well as its status for readiness of use.

After sharing this apporach to the panel of 15 clinicians and health informaticists at AHRQ and CDC, I found that information on the source and status for readiness of use was far too important to be hidden behind additional clicks.

To further push transparency, early versions included concepts displaying data on use of the tool by doctors over time. This also had the added benefit of using social data to demonstrate efficacy and trust in the tool.

Community based feedback on CDS tools.

Another way to drive transparency was to display examples of how it might look within their EHR system once implemented.

These concepts, despite receiving highly positive qualitative feedback from doctors at AHRQ and CDC, had some key issues:

• Pushback from engineering due to what would be a severe lack of user data for showing usage history in the short term.
• Showing an example of how the tool looked in practice could be misleading to doctors expectations for EHR implementation, as it could be vastly different depending on health organization and EHR vendor.

I scaled back these features in later versions to a more implementable text area, from which doctors could provide written accounts of CDS tool use, and removed the example implementations section.

Concepts like displaying data on use of the tool, was saved in the design documentation to be implemented at a longer term date.

CDS Connect, a national web repository for implementable clinical decision support (CDS) tools to aid doctors decision making.

CDS Connect onboarding

CDS tool exploration