Prototype 1

6-3-5 Brainstorming Session Results:

HMW Question Asked:

How might we help our end users transition into self-reporting tools rather than waiting on specific reports to be developed?

Answers Provided:

  1. Participant 1
    1. Provide education and training about add value
    2. Offer financial discounts
    3. Offer user friendly documentation
  2. Participant 2
    1. App reminders to ping users to record data
    2. Ask for data points to be provided during times when end user must input data, reducing friction
    3. Beta test application that creates a running ledger of user data
  3. Participant 3
    1. Provide cash incentives
    2. Develop basic area tests and ways to find helpful information
    3. Use I pads and I watches and I phones to help monitor
  4. Participant 4
    1. Creating a web platform that semi automate generating report
    2. Create digital application for end users to ask all the questions required to generate a specific report
    3. Create a web application with different plans to customize # of data points required to create their own dashboards
  5. Participant 5
    1. Using block chain in an application to keep track of self reported medical issues
    2. Additions to applications such as MyChart to allow for self reporting; voluntary reporting
  6. E the Viking
    1. Develop custom reporting solutions tailored for specific users
    2. Offer weekly training and customizations based on feedback
    3. Look for early adopters who are excited to use new tools

To help approach the end goal of trying to get users to engage with Self-Reporting I have built a prototype of the solution I’d like to go with. This prototype is geared specifically towards the Emergency Departments and early adopters from this area who have some experience with reporting and are engaged to help flush out this experience. I do have 2 other prototypes built, but this example will just demonstrate one.

It should be noted that because of the sensitivity of the data I will be blocking out details, but I will show enough to give a good feel for the experience. To start though I will show the behind the scenes before giving a few screenshots of the finished prototype.

What is a Cube?:

A cube is a database that’s designed using SQL Server Analysis Services. The cube itself is built to allow for online analytical processing (OLAP) and data mining by end users. It’s creation allows end users to self-report off of data in the cube in which valid relationships between all of the data points have been established. This allows users to use the cube without worrying about the relationship complexities of the tables and columns of a database. This allows data stewards to put large curated data sets in front of their end users who have a better understanding of how the system collects data.

On top of knowing how to build a cube, a cube builder must have a deep understanding of the data model in question. Because I have both areas of experience I’ve opted to create customized cubes based on our application areas. The cube demo’d here relates to the Emergency Department, though I have two more also in progress related to the Labs and Hospital Billing areas specifically. 

Below are a few screenshots of the behind the scenes construction:

This screenshot shows the Data Source View (DSV) behind the data contained in the Emergency Department Cube. Each box represents a unique query run against a database and each has a range of columns returned, some of the larger queries with 50+ points of data. The lines represent the relationships between each query and the screenshot below the DSV graphic image shows the further configuration that is made to explicitly define how everything is related together.

When these relationships are defined correctly it ensures that users can report on one piece of data from one query and have it accurately related to any other query/data point contained within the cube. This has allowed me to put together around 1000 points of data, specifically collected against Emergency Department encounters, that end users can easily use to report from. This list can easily be expanded (or shrunk) based on the end users needs. 

The greatest strength of the cube is it’s ability to group data across different queries for reporting. There are 2 basic forms of data when accessing a cube as an end user, Measures and Attributes.

Measures include anything that has a numeric value that you want to analyze. These measures can be configured to count, sum, average, and other basic mathematical functions so that further analysis can be done. One example of a use might be a count of all encounters, another might be to give the % of patients who left without being seen, and yet another could be the standard deviation of time it takes for the patient to go from arriving at the ED to actually being seen by a provider. 

The second form of data, attributes, represents contextual points of data that you might be interested in seeing. For instance, our Health System has 8 Emergency Departments, so in order for our end users to distinguish the total encounter counts of the system to the encounter counts of a specific ED, the Emergency Department Attribute ‘ED Name’ is included to identify this set of data. 

For the end user, accessing and pivoting this data is fairly simple. A cube can be directly connected to using Excel, Power BI, and other tools Because Excel is such a prevalent tool in all industries, most users are comfortable using it, and introducing them to how to use pivot tables if they have not done so before is fairly straight forward.

Below is a screenshot of some of the measures (first) and attributes (second) that Emergency Department end users will see: 

Users can interface with these pivot table data points by using the check boxes or dragging/dropping their data points into the grid displayed below to give them the results they are looking for. The layout below will display the number of ED visits aggregated by the arrival date and chief complaint of the patient.

Here is an obfuscated example of the report displayed:

You may notice the + sign next to 2018. These represents expandable hierarchies within the cube. An end user can just click the + sign to expand the display list. In this case, I expanded twice and you can see data for 2018, quarter 3, July. Expanding again will give you a day by day breakdown.

Because the cube integrates with excel, end users can take advantage of Excel’s pivot features including the easy to use Chart feature. The chart below shows a graph of the Chief Complaints that had greater than 5000 ED visits during a fiscal year:

There is a lot more that can be demo’d with this cube however I feel this gives a quick overview of what is offered. The value of the cube is coming with the interaction with the end users to evaluate what data they like, what is missing, and help train them in how to use the cube properly in order to 1) approach the problems they are trying to answer correctly and 2) teach them how to use the tools in Excel that they may not be familiar with yet. 

This particular prototype has been live in the field with 4 end users for 4 weeks now. We have been having weekly sessions for training and feedback and the system seems to be going well. Though I have confidence that these end users will become great users of the cube, in order for the full affect of self-reporting to be felt within the organization, they will need to advance to the point where they create the content they want their departments to see and we maintain the cube/context within which they get the data. 

Should be fun!