Group Health (now Kaiser Permanente) was a prominent health insurance carrier and healthcare provider network in the Pacific Northwest. The organization utilized Epic MyChart electronic health record (EHR) software for appointment scheduling, secure messaging between patients care team, sharing lab results, and many other important functions. The software was integrated with Group Health’s standalone website, and was heavily customized to adhere to branding and style standards.
Challenge
Because Epic continually enhanced features and improved the MyChart product, Group Health typically needed to perform product upgrades one to two times per year. With each upgrade, the development team made customizations to the front-end code in order to meet brand standards, manipulate the behavior of UI elements, and modify page layout.
Over the course of many years of upgrades and changes made by a dynamic team of developers, the list of customizations had become long and difficult to manage. Applying these customizations could take weeks, slowing down the release process. What’s more, some of the customizations could cause problems like broken page layouts if not implemented with extreme precision. The goals of my analysis were to identify customizations that could be simplified or were no longer needed, and to revamp the upgrade process documentation for future reference.
Process
I began by gathering multiple documents that had been created by other developers over the years. These were largely duplicative, and located in different sections of the intranet site. In addition, I collected the release notes provided by Epic for the latest version of MyChart.
First, I created a spreadsheet that consolidated the customizations from all the developer documents, omitting any duplicates. Next, I downloaded an standard (non-customized) package for the most recent MyChart install, as well as a copy of the customized package, in order to compare the code. Finally, I opened the staging instance for the latest MyChart installation, and located each customized feature one by one. For each, I inspected the page markup, CSS and JavaScript.
I asked the team’s product owner when I had questions about use cases or business needs, and I asked our Epic representative when I had a product-specific question. At times, I consulted senior developers when the reasoning behind a customization solution was unclear. Throughout this process, I continued to refine my spreadsheet, making note of any customizations that had become obsolete, or could be approximated by standard configurations.
Solution
Once I had concluded my analysis, I had found simpler solutions for more than half of the customizations documented. I created a new process document with detailed instructions for each of the customizations we had decided were still needed. I then archived the previous process documents, and made sure the new document was in an intuitive location on the intranet site, accessible to all development team members.
Since many customizations were still deemed necessary, my teammates and I would need to keep modifying and refining the document with each upgrade, as part of our continuous improvement initiative. But for upgrades in the near future, developer time would be reduced by nearly two full weeks per release cycle. The upgrade process was more efficient, the organization saved FTE budgeting hours, and developers had more time for other critical work.