Research

Top-Down Implementation Process for Rapid Data Governance Adoption

By Benson Hsu, MD, MBA, Doug Nowak, MBA, Mark Wheeler, Jul 12, 2017

This case study was originally published by NEJM Catalyst on July 5, 2017 

Putting a solid data governance structure in place is challenging, but Sanford Health, a large integrated health care delivery system spanning six states, describes how to accomplish the task quickly using a top-down process.

KEY TAKEAWAYS

  1. Senior corporate leadership must prioritize the need for data governance.

  2. There is no single “correct” method for any aspect of data governance: the key is to define what is right for your organization and standardize that view.

  3. Defining a term — a key task of data governance — is infinitely easier than standardizing the process or practice in support of that definition.

  4. Avoid doing data governance piecemeal to accommodate specific initiatives or projects. Do a comprehensive data governance policy first, to accommodate all future projects.

The Challenge

Data is virtually useless without proper governance — that is, agreement on what terms mean and how they are structured. Something as simple as an admission can be expressed in several ways, and there can be multiple ways to both define and express complex metrics like length of stay. Lack of data governance is a major barrier in the application of data and analytics. At Sanford Health, we needed to establish solid data governance in order to unlock the value in our data.

The Goal

Sanford Health sought to implement data governance rapidly, to smooth our transition from a fee-for-service reimbursement system into one driven by value.

The Execution

The primary drive for a strong data governance structure originated from the top of our organization, and the backing of corporate leadership was instrumental in making data governance a priority.

“Even with a centralized team and robust data warehouse, we lacked a common language: a consistent way of defining and gathering each piece of data across multiple data sources.”

Sanford Health had already worked to centralize a team of more than 60 data scientists. (This restructuring is covered in more detail in another paper.) The centralized data and analytics arm reported to the chief financial officer and was given access to all data sources with the charge to establish the “One Source of Truth,” a data warehouse that could pull from all sources and combine data as needed to answer questions and produce insights for the organization. However, even with a centralized team and robust data warehouse, we lacked a common language: a consistent way of defining and gathering each piece of data across multiple data sources.

Our mission was complicated by our electronic health record (EHR) vendor, which provided analytics tools intended to help us measure our performance. As we explored these tools, we discovered that certain data elements had multiple definitions even within the EHR, making it impossible for us to rely on the accuracy of the analysis. In other words, lack of data governance was built into our EHR.

“We defined and standardized more than 100 terms in the first 6 months, more than 150 by the end of the first year, and more than 650 by the end of the second year.”

Our solution was to create a data governance team with seven senior executives. Its goal was to build a data governance foundation for growth, to prevent a piecemeal or project-by-project approach. The team started by defining the most basic data elements that we needed for virtually every analysis: inpatient, outpatient, admission, and provider. The team then defined other key terms such as primary care attribution and length of stay. Disagreements on definitions were resolved by the data governance team, and all decisions were final.

We knew that defining terms would be easy compared with standardizing processes and practices to match. Thus, the majority of the initial governance was based on source standardization (ensuring that the data extracted were consistently from the same place in a record) followed up later, if necessary, by operational standardization (ensuring that data are inputted consistently). For instance, the data governance team first defined which field would be standardized for extracting operating room (OR) start time (source standardization).

“Before the implementation of the governance process, meetings often ended in a dispute over the ‘accuracy of the data,’ which was in essence a dispute over definitions. However, by the end of the first year, these disputes had virtually disappeared.”

Later, we worked with staff to ensure that they used the field in a consistent way, recording the time that the surgeon started the procedure rather than when the patient arrived or when lights were turned on in the OR (operational standardization). Ultimately, this governance flowed to our EHR as we evaluated the vendor’s dashboards and metrics. Those that were inconsistent with our governance were changed to align. If they couldn’t be changed, the dashboard was turned off.

The Team

Consisted of seven senior executives representing the care teams, operations, quality, health plan, legal, privacy, information technology, and finance. Leaders of the centralized analytics team were non-voting members.

Metrics

The data governance team measured its success primarily by the number of discrete terms defined and standardized. We defined and standardized more than 100 terms in the first 6 months, more than 150 by the end of the first year, and more than 650 by the end of the second year, representing the most important pieces of information for measuring financial, clinical, and operational performance.

“Know that data governance will be difficult and fraught with landmines. You will never find the perfect time, the perfect team, or the perfect process.”

Additionally, the centralized data and analytics team started to notice a dramatic shift in the organization’s attitude toward data and analytics. Before the implementation of the governance process, meetings often ended in a dispute over the “accuracy of the data,” which was in essence a dispute over definitions. However, by the end of the first year, these disputes had virtually disappeared: users of the data had come to trust that definitions were consistent and they were getting accurate information. This trust would never have been possible without a strong and authoritative data governance team.

Where to Start

  • Top corporate leadership support

  • Governance team with diverse views of the organization

  • Small team with ability to make rapid and final decisions

  • Centralized data and analytics teams to reinforce definitions

  • Unified data warehouse to standardize data extracts

Lessons Learned

  • Know that data governance will be difficult and fraught with landmines. You will never find the perfect time, the perfect team, or the perfect process.

  • Senior corporate leadership must take the lead to prevent the process from being sabotaged by competing interests.

  • There is no perfect definition. Often, organizations get bogged down in trying to find the right answer when multiple answers are right. The governance team must simply choose the best answer for the organization.

  • Too much structure slows the process. The data governance team developed the initial definitions themselves, rather than delegating the work. Once our organization accepted that terms must be governed and that there can be only one definition for each, the data governance team was able to assign many terms to be defined by “data stewards” (individuals who worked frequently with a given term), allowing for layers of complexity and ownership of data definitions.

  • Delay as long as possible purchasing any software products or platforms that use the data for which you are developing governance. Identifying a platform beforehand forces a vulnerable team to adopt the vendor’s practices and protocols, which may not be the best fit for the organization’s needs. Once you have a basic governance structure in place, you can look for products that are consistent with it or that can be adapted.

  • Don’t forget your EHR. If its analytics tools don’t use the definitions specified by your data governance policy, they must be adapted to do so, or turned off to prevent confusion.

  • Data governance should aim to build a foundation for all analytics and not in support of specific projects. For instance, a sepsis project might require a definition of patient that includes observation patients, post-operative recovery patients, and regular inpatients. A readmission project might define patient as only the traditional inpatient. Without strong data governance, the organization would end up with two definitions of the term patient, and the data from the two projects would be incompatible. With data governance, each project would be able to identify the pieces of data that it needed, without having to create its own definition, and the resulting databases could later be combined, if desired, to do further analyses.

This case study was originally published by NEJM Catalyst on July 5, 2017 

About the authors

Author photo

Benson Hsu, MD, MBA Vice President, Enterprise Data and Analytics, Sanford Health, Sioux Falls, South Dakota


Author photo

Doug Nowak, MBA Senior Executive Director, Enterprise Data and Analytics, Sanford Health, Sioux Falls, South Dakota


Author photo

Mark Wheeler Director, Enterprise Data and Analytics, Sanford Health, Sioux Falls, South Dakota


Tags