This SharePoint Intranet website helped Providence caregivers find Clinic providers, locations and specialties in Oregon.

Oregon's Providence Medical Group (PMG) staff had problems answering basic questions about clinic resources, because three different departments hosted their data on three different platforms in three different formats.

The hunt for answers consumed at least four staff-hours a day. If an Excel spreadsheet didn't have the information, the hunt would move on to a document file on a shared drive or a SQL database. Predictably, data was often missing, wrong or inconsistent. They sought a single authoritative place to look up Clinic provider, location and specialty information.

Locations, clinicians and specialties

After waiting over seven years for help from Information Services, PMG Oregon decided to build their own solution by leveraging the out-of-the-box capabilities of their new SharePoint 2010 intranet website.

They brought a team together that included PMG leaders and users in the design, development and implementation process. This approach kept business requirements clear, provided constant product usability feedback and inspired volunteers to photograph all the clinics in the field so the interface would look complete.

The work linked together all data and documents into SharePoint lists and libraries that could be authored separately by two different departments. Responsibility for maintaining facilities data, for example, was in the hands of the Real Estate and Property Management, while responsibility for maintaining medical group data was given to PMG's subject matter experts.

In this case, avoiding a SQL database raised data quality by engaging more staff in the maintenance process. Application development was focused and efficient, because the business was fully engaged throughout the entire process to resolve form and fitness problems early.

Since SharePoint 2010 search was awful, the app used a simple JavaScript search box was used instead.

The app grouped location, specialty or clinician content into separate pages navigated with horizontal tabs for navigation. Each page returned result cards for each clinic, and on the right side of each page, a list of filters encouraged refinement. Each filter and tab click was stored as a browser cookie, so users could pick up where they left off when they returned to the site.

Clicking on a result card opened a customized SharePoint Display Form that aggregated data from four separate lists - Facilities, Clinics, Clinicians, and Specialties.

Results

The product completed on time, on budget, and in better shape than anyone expected. The data was limited to the Oregon region, but it was available anyone in the enterprise with access to SharePoint. Data remained current and accurate, because the interface for making updates was familiar to the subject matter experts closest to the data.

PMG had no benchmarks for measuring success, but the move to SharePoint was widely viewed as a major time and hassle saver. The required minimal maintenance and lasted until 2021.

As product developer from concept to code using out-of-the-box parts and client-side development, I carried product through SharePoint 2007 to 2010 upgrade and ongoing improvements.

I developed the app as a single HTM file containing HTML, CSS styles and JavaScript code. Storing the file in a "scripts" document library on the site along with jQuery Core and SharePoint Services libraries, I deployed the app from a Content Editor Web part on the home page of the PMG site.

I customized the SharePoint Display Form with XSL and XSLT code, and I used Inkscape to create the handful of images that supported the look and feel of cards and navigation.