Providence Health Plan (PHP) in Oregon reversed a downward trend in insurance claim processing by developing this high functioning SharePoint Intranet web site and web application for health plan content that aggregated, organized, and leveraged the tribal knowledge of numerous staff, managers, analysts and subject matter experts into single web application.
Knowledge of complex plan and insurance claim processing information depended solely on the personal experience of numerous employees and subject matter experts supporting the business. No single information source spelled out the plan's products, so the truth varied among call center staff and managers, which meant consumers were getting different information depending on who they talked to. When employees left the team, so did their years of information. Onboarding was costly, because knowledge transfer took months.
Intending to improve sharing and collaboration, PHP setup a SharePoint platform, but the initiative only made things more difficult by spreading information farther and wider. Although this slowed everyone down, the SharePoint platform at least provided the starting point for a web application that became known internally as PHP's Knowledge Management System - or KMS.
Home
PHP's KMS web app was the result of a relatively short design and development initiative which addressed a myriad of barriers getting in the way of both information maintenance and front end findability.
The back-end of the web app organized content into 100+ SharePoint 2010 lists and libraries. Content could be entered or updated through forms by any non-specialized staff, while workflows, lookup columns, and integration with SharePoint's Term Store unraveled the complexities of the company's Plan products through interrelated Topics and Pends - a "pends" roughly meaning resolution information for different kinds of pending claims.
The front-end of the web app provided quick visual access to all the content through a dozen tightly coupled web pages. At the center of the KMS was an A to Z menu which simplified navigation. It led to one of two ‘Snapshot” pages which pulled together all related content from the multitude of lists and libraries around a specific combination of user input.
(1) On the home page, a tab interface provided a traditional way to access content. Tab names could be added or removed through a list on the site, allowing changes to be made without a developer.
(2) Each tab provided a framework of web part zones for arranging a variety of SharePoint web parts.
Topics Snapshot
Topics presented information around the Plan's terms and concepts.
(3) Page Layout - organized content around on its URL string, which made sharing possible through email or messaging. Dialog box helped users grab the address.
(4) Triple Navigation - three menus combined dynamically from three SharePoint lists. Specific combinations of menu selections determined page content. The Pends Menu was a drop menu with type-ahead feature which presented a list of five character codes that highlighted character combinations as typed. The Topics A to Z Menu activated a drop list of titles on hover. The Products Menu presented a small, static set of Health Plan products.
(5) Dynamic Title - page titles displayed the combination of menu items selected along with their related owner and last reviewed information.
(6) Content Cards - showed general content on page. The heading of each card link referred to a list/library of content - "Overview" content in the image below. A related list of terms and phrases appeared in this card as well. On hover, these terms would display a tooltip containing a preview of term's definition. When clicked, the link opened the full definition in a modal dialog that returned to the original page when closed.
(7) FAQs - if any frequently asked question associated with a result, it would appear as a card on the page.
(8) Table of Contents - the Topic or Pend snapshot pages were only one of several ways KMS content could be explored. This Table of Contents widget listed all the other available options.
(9) Heading Bars - the display of "what to do when" content was handled with heading bars that toggled to expand or collapse. These bars could be numerous, so page cookies tracked each toggle state and returned users back to where they left off reading on each Topic or Pend, even if the browser had been closed.
(10) Related Documents - these cards displayed a list of documents related to the particular Topic or Pend being displayed.
(11) Scoped Search - this provided a direct connection to a search results page that crawled and returned only KMS system content.
Pends Snapshot
The word "Pends" was an internal term referring to specifically coded claims resolutions in the claims processing pipeline. In many ways similar to Topics, each Pend related to one or more Health Plan products. They also had headings with collapsable content, overviews, FAQs, and related documents. But where Topics were general concepts, Pends showed specific ways to resolve a claim.
(12) Typical to the Topic and Pends pages, an edit button appeared for authorized staff, so content updates or corrections could be made on the spot (at one stage of the product development at least).
(13) Contacts and resources connected users to authoritative sources for the content.
(14) A Yes/No decision tree Pends Help section showed on the page when a SharePoint list was found with the same name as the Pends Resolution.
(15) Choosing a selection along any branch of the decision tree expanded and highlighted the associated Pend Resolution below the decision tree card, which often involved more than one way to resolve a problem.
Search page
When a specific concept or code was unclear, grazing for Topics or Pends on snapshot pages was useless. There were also times when only a deep search for content in documents would satisfy research. An out-of-the-box Search page took care of those scenarios.
(16) SharePoint search box and page was scoped to the site's lists and libraries.
(17) Lookups to a hierarchical SharePoint Term Store taxonomy controlled the list and document tags that drove search facets.
(18) Search results opened Topic or Pends snapshot pages in the same window, or they opened documents in a separate window.
Results
PHP's KMS significantly reduced the time and effort required to input, maintain, and find relevant Health Plan knowledge. It also kept all employees on the same message across all parts of the organization, which led to measurable improvements in call metrics, claim processing turnaround times, and positive customer experiences related to insurance claims. Not only did the site increase user satisfaction and improve employee engagement, but it also spread knowledge to more individuals than anticipated and shortened new staff onboarding from several months to less than a week.
Product design gave high priority to long-term support, ease of use, and agility in developing new features. It modeled a prototype on a SharePoint Pilot server and built/updated directly on a SharePoint Production server. The production platform cached all CSS and JS files, so they ended up inside the HTML file. This made development fast, and non-developers could understand the code enough to tweak it from a simple text editor like Notepad.
Designer and developer working alongside a Product Manager and Solutions Architect. Built product from end to end over a six month period in only 200 development hours using out-of-the-box parts and client side code. Responsible for website pages, lists, libraries, display forms, web parts, term store and search experience. Kept product alive and well from concept through hand over to operations phases.
2011
The first release of the product required only minor updates. I setup the SharePoint 2010 site with a whole bunch of lists and libraries and integrated the app into SharePoint 2010 as a single HTM file which displayed the documents when called from a Content Editor Webpart on the home page of the site. This HTM file contained all the web part's HTML, CSS styles and JavaScript code, and it resided in a "scripts" document library on the site along with images and jQuery Core, Tools and SharePoint Services library files. I built and maintained icons as a sprite using Photoshop.