Health Plans KMS

  • 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.

  • Health Plans KMS home page

What do you know?

  • 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.

  • Prototyped on Pilot platform to win approval

  • Developed and maintained live on Production platform.

  • 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.

  • Home page

    Default page with tabs layout.



Topics Snapshot
  • Topics presented information around the Plan's terms and concepts.

  • Topics page.

    Topics page.

  • (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.

  • URL driven UI

    Web application content driven by URL.

  • (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.

  • Navigation bar

    Pends, Topics and Plans - all in one menu system.

  • (5) Dynamic Title - page titles displayed the combination of menu items selected along with their related owner and last reviewed information.

  • Page title

    Page titles were shown with associated Plan product, owners and content last reviewed date.

  • (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.

  • Content cards

    Overview content showing definition of term on hover.

  • (7) FAQs - if any frequently asked question associated with a result, it would appear as a card on the page.

  • FAQs

    FAQs showed up as a list. Each would open a modal dialog with the answer on click.

  • (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.

  • Table of contents

    The widget changed the content in the center of the page, but stayed in the same place for consistent browsing experience.

  • (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.

  • Heading Bars

    The toggle approach made it easy to graze through content when on the phone.

  • (10) Related Documents - these cards displayed a list of documents related to the particular Topic or Pend being displayed.

  • Search and Help features were a natural pairing.

  • (11) Scoped Search - this provided a direct connection to a search results page that crawled and returned only KMS system content.

  • Search and Help features were a natural pairing.



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.

Under the hood

  • 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.

  • SharePoint
    • Term Store
    • Scoped Search box, page and refinement panel
    • 2 site templates
    • 3 page layouts (tabs, columns, search)
    • 1 script library
    • 100+ lists and document libraries
  • Protocols
    • C#
    • JavaScript
    • jQuery libraries = Core, jQuery Tools, SharePoint Services
    • HTML
    • CSS
  • Design
    • Analysis, composition, and usability
    • Graphics (35 images/sprites)
  • Tools
    • SharePoint Designer
    • Notepad++
    • Inkscape
    • Photoshop