CCM Medications Project

According to the Office of Disease Prevention and Health Promotion, Adverse Drug Events (ADE) account for over 3.5 million physician office visits, an estimated 1 million emergency department visits, and approximately 125,000 hospital admissions each year. The large majority of these ADEs are preventable, and accurately tracking a patient’s medications is important and challenging part of solving this problem. (1)


After 5 years of neglect, quick fixes, and minor updates, our legacy medications module was in a terrible state. This is how we learned we were trying to solve the wrong problem, overcame investment in our initial assumptions, and pivoted to a smarter, better solution.

The Crimson Care Management (CCM) medications module allowed a care manager to document and reconcile a patient’s medications, accessible to other CCM users involved in that patient’s care. Medication reconciliation (2) is valuable in an ambulatory setting because it allows the care manager to verify a patient is taking their medications properly, note possible drug interaction issues or allergies, and share that information with relevant parties, after that patient leaves the hospital.

It is also one of the modules that had received the least focus and the most complaints over the years.

“This is so clinically horrid and violates every medications safety rule ever.”

“I’ve worked in patient safety for the last three years, and this is the kind of thing that leads to medication errors.”


My role was lead designer, and along with the product manager I was in charge of strategy and design for a total module overhaul with a team of over ten people both local and remote. This included discovery, interviews, wireframes, prototypes, and user testing, while also closely coordinating with our remote data team.


The baseline proposal was a “Total overhaul of the medications module to bring functionality and usability in line with [Electronic Health Record (EHR) systems] as a baseline.” The module should allow easy and accurate reconciliation, limit or prevent input errors, call out high risk medications and conflicts with allergies, while utilizing modern standards and best practices. It should also sensibly integrate with other parts of the application (Gaps in care, Allergies, Risk, and Alerts) as necessary.

As with most things, what wasn’t explicitly stated was potentially far more challenging than the proposal itself. While EHRs need to integrate with data sources that would be useful for their clients, they are not generally required (or motivated) to integrate with other EHRs. We had to be able to connect agnostically with the EHR(s) our clients used along with the data feeds we currently ingested, and allow for potential new data sources. All of this data would then have to be handled in a meaningful way.

It was immediately apparent that this was an enormous project.

The Setup

Our initial understanding was that there were obvious usability issues that could be addressed that would have immediate positive impact for our users. Before diving in to address those issues, we wanted to establish a baseline in three areas: existing competitive solutions, current best practices, and (perhaps most importantly) how our own users were using the current module.

How have others approached the difficulties of medication reconciliation? Direct experience with larger EHR solutions is very difficult if you are not a client, so we shadowed care managers and interviewed care managers to increase our knowledge there. We also researched apps and free online EHR solutions to see how they had approached the problem.

“This module should be as robust as any EHR meds module.”

“There’s not a lot of research that needs to be done, this has already been done for decades by EHR systems.”

Research & Best Practices
We looked into whatever medication reconciliation research we were able to find online. Having access to subject matter experts (typically former doctors or nurses) we interviewed and consulted them on current best practices. They were also able to provide direct feedback on the shortcomings in the current module, and it was an appreciated reality check on how important it was for a healthcare application to get medications right.

How was the existing module was being used, and who was using it? We aggregated over four years of feedback and outstanding issues on the module to get a baseline understanding of the issues. We knew from previous user shadowing that medication entry was awkward and slow, and many fields utilized non-standard terminology or allowed free text input.

We pulled metrics for all of the medications data in our system. Looking at the existing data we could determine generally how difficult a possible data migration might be. We arranged interviews with those clients with the highest utilization to gain more insight, and establish a possible collaboration.


One of our biggest concerns was an enormous proposed scope and the limited resources we had at our disposal. Large EHRs are focused as a company on a single product, whereas we had a relatively small team in a company with dozens of products. This was also not the only part of our application needing attention, and overextension is what led to much of these issues of neglect in the first place.

Could we improve upon existing solutions with a tenth of the resources? Was there a way to add value without competing directly? These were all open questions.

Stakeholder Buy-in
We knew that patience among existing clients was declining, resulting from slow fixes, delayed response time, and stagnant unpolished features. Medications hadn’t really seen any significant updates since it was implemented 5 years before, and the number of issues accumulating in the tracking system reflected that.

We decided to partner with three distinct clients that were interested in an overhauled module. Because these partners were representative of different types of health system organizations, proposed solutions would (in theory) be robust and flexible. We committed to regular bi-weekly check-ins to give progress updates, present designs, test prototypes, and gather feedback. We hoped that involving them in the design process as much as possible would result in both patience and enthusiasm, resulting from better visibility into the work and thought that goes into designing module this complex. It also had the benefit of validating early design direction with experts, and we would have access to real data as soon as possible in the design process.

Along more pragmatic lines, how would a drastic revamp impact existing clients, implementations, and data? The age of the codebase and the level of integration of the existing module made both updates and testing any changes to the current module time consuming and difficult. We decided to leave the current legacy module in place and create a new module from scratch. This would have the least impact on existing clients who could then be transferred over as needed, and would not require a data migration or restructuring old code, with the downside of maintaining the existing module.

Design & Technical Challenges
Exporting data from an EHR is a high effort, high cost issue. Interoperability between EHRs is a relatively new and ongoing process, and standards are still emerging. In order to be valuable, our application needed to:
Improve upon, or be of comparative value to, existing EHR solutions
Export medication data from various EHR sources
Import and process that data into our system in a flexible, standard format
Match differently coded medication data, possible semantic matching for unencoded data (3rd party solutions?)
The complexity of handling differences in the data such as dosage, prescription information, data formatting differences, entry variations, generic vs. brand, errors, etc. from various sources at various times and no particular order in a meaningful way.

Letting Go

Initially our prototypes were very well received. We had addressed many of the complaints of the current system, and we had refined the reconciliation process to be quick and easy, and feedback was very positive. However, as we kept pushing our designs further we began to notice some patterns.

Health workers are required (or even legally obligated) to reconcile medications in their respective EHRs. Even creating a module with perfect EHR feature parity, best case scenario would mean double documentation in an already error-prone process. Clients were using our application not primarily to reconcile meds, but as a way to help inform reconciliation in their own EHR, using out of network information their own system didn’t have access to. This was a message we heard repeated by all of the clients we interviewed.

With that in mind we decided to pivot on our original design. Instead of creating a module that aggregated medication information from various connected sources in order to reconcile them in our system, we shifted to a design that presented this aggregated info in a way that would assist and inform the user while they reconciled in the system of their choice.

This required revisiting how we had been thinking of things, and letting go of what we had thought was an elegant solution.It was soon obvious that by being willing to let go of preconceptions, we had incidentally also found the solution to our resource and competition problem. We were able to pivot to a solution that added value to any EHR without directly competing, and it reduced the scope of the feature to something that was actually possible, and more importantly, useful.

Lessons & Thoughts

  • Don’t become overcommitted to your own designs.
  • Make sure you’re solving the right problem, and be wary of tunnel vision. It’s easy to forget to ask if the the things you know are easy to fix are the things users actually need fixed.
  • Try to add user value at every stage of the release process, this most often does not mean a “feature.”
  • Incorporate real data as soon as possible in the design process, this ensures you’re on track with your solutions, quickly reveals real world design problems, and it’s easier for users to understand without getting stuck on “lorem ipsum” or other nonsensical data in a prototype.
  • If you are stuck, it usually means you don’t have enough information. Putting a prototype in front of a user usually clears things up very quickly.
  • “Minimum Viable Product” (MVP) does NOT merely mean functional. Viable includes the idea of a positive user experience.


With actual EHR data being ingested and our partners testing the module, feedback was very overwhelmingly positive, in regards to the module itself, our interactions with the clients, and their close involvement throughout the design process. Problems that appeared were minor, and more importantly things we expected to see when we started using actual data across clients with distinct data sources. For such a complex feature, there were no apparent structural design issues, and the extra effort and patience put into the front of the design process had paid off.

Sadly, the overall product was sunset shortly after the module began live testing, but that doesn’t diminish that this was one of the more interesting, complex, challenging, and rewarding features I’ve been part of.


  1. (2017, June 16), Retrieved June 16, 2017, from ttps://
  2. (Return)

  3. Medication reconciliation: Making sure the list of medications for a patient matches what they are actually taking. This is usually done in-person by a doctor or nurse during a transition in care (e.g. leaving the hospital), but in population health is usually performed by a care manager over the phone.
  4. (Return)