Monday, August 13, 2012

Deploying analytics in a healthcare world flooded with data


We live in a society with too much data.  In the field of market research, the deluge of data is cited as one of the top challenges leaders face as they search for actionable insights hidden in the data.  Healthcare is no different.  Information content increases with the amount of data that surrounds us, but so too does the noise.  And, unfortunately, noise often overwhelms and obscures information as the volume of data grows.  Add to that the operational issues we introduce in managing the flood of data, and we oftentimes spend the majority of our attention focused on the problems of the data rather than the problems of the customers – and that is a risky place to be. 

The discovery and communication of meaningful patterns in data (i.e. analytics) is rapidly becoming an indispensable capability to healthcare organizations as the explosion in data continues and the affordability of computing power grows.  Analytics can make hot-spotting, total population health management, readmissions programs, clinical quality performance monitoring, improving hospital operations finance, or any number of other data-driven initiatives in healthcare work better.   

Today’s post is oriented towards companies who are new to analytics or are interested in a refresher.  I am not talking today about companies who have an enterprise model of analytics, although most of these basic concepts apply there as well.   

How to get the most out of analytics and avoiding common pitfalls:
  • Start with business needs to define the scope of analytics and data
  • Focus data resources on supporting an analysis-ready database
  • Start small and build on successes




Start with business needs to define the scope of analytics and data

It is all too common to focus on the squeaky wheel, like the strain of the IT infrastructure under the weight of the data.  But, it would be a red herring to focus on the data problems first.  The better approach is to focus on the customer and business needs and use that perspective to prioritize and tackle the data challenges. 

Articulating clear business needs enables people to speak about analytics and data in terms that make business sense.  Many people struggle to appreciate the nuances and structures in analytics and data – analytics and data are hard to visualize due to their intangible nature.   A failure in articulating clear business needs often results in issues like wasting efforts on tangential analytics and data re-work, or making decisions based on flawed data and analytics.    

Setting business needs first establishes guidance on what functions the analytics must support.  This in turn enables the analytics team to determine the appropriate data sources and the parameters for the data quality.  Only then should the data elements be designed and implemented to support the business.  If this makes sense, good.  If this sounds simple, take a deeper look – many companies do not get this right.

In a well-designed system, getting reliable and valid answers to questions essential to the business need should be at one’s fingertips.  If it takes weeks or months to get these answers, or business leaders have trouble getting valid and reliable answers, then a major analytics problem exists.

Example

Business need:
  • We need to identify high priority patients for clinical interventions in a 30-day readmissions program

Current situation:
  • Data validity problem: A fraction of skilled nursing facility encounters are inconsistently categorized as hospitalizations because of the different clinical data systems I am pulling from across my network
  • Data timeliness problem: Program requires impact within a 30 day time window post-discharge but we have a two week data lag issue and it takes an additional two weeks to run the analysis to find the right discharged patients for intervention

Sample Analytic solutions:

  • Create standard definitions for hospitalizations across the book of business by working with internal data leaders and external data vendors
  • Create a core data stream that contains data elements specific for this program and arrives within a few days of the discharge event, bypassing the standard processes within the company
  • Create an alert that triggers an automated algorithm that identifies “high priority patients” within hours of clean data confirmation vs a batch analysis that is scheduled to run every week or a manual review process
  • Set all of the above as data quality and analytics parameters and monitor their performance as management metrics

Design flaws also show up when analytics don’t take into account operational factors (including workflows and processes).  This can be particularly frustrating when teams do a lot of deep analytics work and yet see little to no productive business results.  One sign that this problem may exist is that the analytics team is siloed from the operations team. 

Example

Business need:
  • We need to intervene with high risk patients who have fragmented care (example, Dual Eligibles) for a care coordination program.  We use analytics to target the most likely patients who will benefit from proactive care coordination interventions

Current situation:
  • Patient outreach problem: Analysis delivers 20 prioritized members per clinician to focus on, but 6 members have wrong phone numbers and 3 more members have wrong addresses
  • Patient engagement problem: The content management system is not linked to the analytics programs, and clinicians do not know what triggered today’s clinical encounter.  Clinicians spend crucial time scanning clinical records to assimilate the information and develop a plan while the member is waiting on the other end

Sample Analytic solutions

  • Restrict analytic models to members to where good outreach data exists as a short-term solution; Run campaigns to acquire contact information from members, health plans, and providers as a  medium-term solution
  • Push a timely prioritized summary to the clinician through the content management system that is linked to and based on the results of analytic models
  • Define patient connectivity and engagement metrics and monitor performance over time 
  • Measure the degradation of operational performance across the delivery value chain – intervene when the variance between design targets and actual performance exceeds established thresholds


Focus data resources on supporting an analysis-ready database

Analytics relies on an analysis-ready database to support the timely delivery of valid and reliable insights.  A key sign that an analysis-ready database is lacking is that the analytics staff spends the majority of their time gathering, fixing, or arguing about the numbers, sometimes spending as much as 80-90% of their time on data, not analytics.  An analysis-ready database requires source data, which can come from a data warehouse or directly via data streams. All three (analytics, analysis-ready database, and data) require investments, with the designs of all being driven by the analytics needs (which in turn are driven by the business needs).    

When business and analytics needs are clearly established, data quality can also be better established: timeliness, standardization, accuracy, completeness, and definitions make the most sense when elements of data quality are framed by business and analytics contexts.  Once data quality parameters are established, then the hard work of creating and maintaining data can begin.  Companies that compete successfully in analytics spend a lot of time and resources on data management, but most importantly they understand how to focus data management to support the business needs.

Example
  • Historically, claims data systems were built for financial transactions purposes.  We are now trying to adapt those systems for use in driving clinical analytics applications.  The business needs are different, and therefore the analytics needs and the data needs for the two types of applications are quite different.  An analysis-ready database for managing payments in financial transactions cannot be easily adapted to be an analysis-ready database for clinical analytics applications.   Not only that, but these systems can often be competitive – if the same technology people are serving both business needs, who gets the resources? 
  • Making a large investment in claims data (or a data warehouse) with data management quality controls and processes that work for paying healthcare claims is not a good investment for or well-suited to the types of analytics work that is increasingly in demand today. 


Start small and build on successes

We are on the leading edge of what should be a very innovative period in American healthcare, yet building large elaborate analytics and IT systems before we know what we want from them is inefficient.  So, where to begin?

For companies dipping their toes in analytics, focusing analytics to work within a specific market and a well-defined business environment is probably the right first step.  In a well-defined space, analytics can more easily make products and clinical programs work better, faster, and cheaper. 

A few suggestions on getting started down the analytics path:
  • Start small and show short-term wins to build momentum within teams
  • Have business leaders side-by-side with analytics and data leaders
  •  Identify a program where you can develop an operational value delivery model
  • Identify an area where you can implement change or easily gain access to data without a long process or large budget requirements
  • Clarify the business objectives and the business needs as much as possible, and do your best to explicitly link the analytics and data to support them
  • Determine how you will measure progress and success over time as you work towards the goal
  • Remember that success can be elusive at first - focus on empowering teams and building processes that help to build a longer-term foundation for success



Creative Commons License
This work by Recon Strategy LLC is licensed under a Creative Commons Attribution-NonCommercial-NoDerivs 3.0 Unported License.
Based on a work at blog.reconstrategy.com.