As a health-care organization that provides quality care to many current and prospective patients, the ability to easily navigate thousands of physicians to find one that is “just right” is critical. Physicians are their product! Recently, we worked with a large health-care client with an existing physician-finder tool that was beginning to show its age. The tool functioned well, but it dropped the user into an experience that was often quick to overwhelm.
Meet the New Guide
Rather than drop the user into a sea of physicians, the new approach was to replace the landing page with a launch pad to a guided search (fig. 1) that took the user through the most important filters before landing on a more manageable and relevant results page. One of the biggest changes was that when users got to the results page via the new guide, only physicians who were accepting new patients were displayed. In some cases, this effectively filtered out over one thousand physicians who weren’t relevant to the patient.
Data Integration with Sitecore
During this project, we were also faced with the challenge of how to get physician data from the client’s back-end systems onto the website since the REST API they created for us was not intended to be consumed in real-time. Previously, data was downloaded from the API and directly inserted into four different Lucene indexes which had to be rebuilt often to keep data in sync. This was an expensive, time-consuming operation that was ready for an overhaul.
Our approach was to create an import agent that would run nightly and import all the physicians and their related filters into Sitecore as bucketed items. The process was simple – hit the API and grab the data in bulk, and then perform an “upsert” on the appropriate bucket in the Sitecore tree. This procedure can also be kicked off on-demand to support data updates during the day (fig. 2). With the data being persisted as Sitecore items, it is now indexed by Sitecore’s default mechanism allowing us to work more efficiently using the native Sitecore API.
An Application Within an Application
A common design pattern with ReactJS is to create a Single Page Application (or SPA) where the entire app is one page and “virtual pages” with relevant content are loaded on-demand with the help of a router. Because our client’s existing website was not an SPA, we essentially needed to create an SPA for the guide experience that existed inside of the larger non-SPA, the website itself. As a side note, because the guide was not required to be indexed by search engines (only the physician detail pages had this requirement), we did not need to create this app using Server-Side React Renderings.
Once we had a breakdown of UX design pieces that warranted their own React component, we created a map that explained each component’s props and child component hierarchy, sliced them into product backlog items, and planned out our sprints.
Because this was our team’s first foray into React, there were a few growing pains and lessons we learned along the way. We were not initially able to utilize Webpack, so we ended up using a combination of Gulp, Babelify, and Browserify to transpile and bundle our code. Another issue we faced was prop-drilling. As our component structure was sliced rather thin for reusability, we ran into issues getting data from higher-level components into deeper child components, requiring us to create pass-through props for components in the middle-tiers. Future releases will likely rely on more focused component composition or the Context API. Furthermore, this functionality was written before React Hooks started to become a standard, and thus would likely transition to utilizing Hooks in the future. As previously mentioned, we will look to utilize Webpack in future releases.