Chapter Two
Stop Hunting Unicorns and Start Building Teams and Know The Data

People often ask us what it takes to create clear and compelling displays of health and healthcare data that people love to use, and which raise awareness and move people to take action. The answer is paradoxically simple. It requires strong teams of experts in the highly complex disciplines of health and healthcare, statistics, data, technology, accessibility design, data visualization, and user experience testing-teams who appreciate the unique skills, experiences, and expertise each person brings to a project and the ability to work collaboratively.

Because here is the secret you already know. The idea that any lone person will ever have every single bit of expert knowledge and skill in health and healthcare, technical applications, and data visualization and design required to deliver beautiful and compelling dashboards, reports, and infographics is sheer lunacy. That's why organizations have to stop hunting unicorns and commit to building diverse teams who bring the expertise required and the ability to communicate and collaborate.

With that in mind, here is a summary of tips for building great data-analytics, reporting, and data visualization teams.

Search for Characteristics and Core Competencies

It is imperative to understand what characteristics and core competencies are required to complete the work. Here's where to begin:

• Curiosity. When teams are curious, they question, probe, and inquire. Curiosity is a crucial impetus for uncovering interesting and relevant stories in our health and healthcare data. Above all else you need a team of really, genuinely inexhaustibly curious people!
• Health and Healthcare Subject-Matter Expertise. Team members with front-line, boots-on-the-ground, clinical, quality, operational, policy, financial, research, and public health experience and expertise are essential for identifying the questions of interest and the decisions or needs of the stakeholders for and to whom data is being analyzed and communicated.
• Data Analysis and Reporting. Without exception, at least one member of your team must have math, statistics, and data-analysis skills. Experience with data modeling is a plus if you can find it; at a minimum, some familiarity with the concept of modeling is beneficial. The ability to use data analysis, reporting, and display tools and applications is also highly desirable, but another more technically trained IT team member may be able to bring this ability to the table if necessary.
• Technical: IT and Database Expertise. Often, groups will confuse this skill area with data-analysis and reporting competence. Data and database architecture and administration require an entirely different set of skills from those needed for data analysis, so it's important not to conflate the two. You'll need team members who know how to extract, load, and transform (ETL) and architect data for analysts to use. And while you may sometimes find candidates who have both skill sets, don't assume that the presence of one means a lock on the other.
• Data Visualization, Accessibility, and User Experience Testing. Knowledge of best practices and awareness of current research is required to create clear, useful, and compelling dashboards, reports, and infographics. But as you will learn in this book, these skills are not intuitive; they are based on research into human vision and cognition and must be learned and honed over time. And although it's not necessary for every team member to become an expert in this field, each should have some awareness of it to avoid working at cross-purposes with team members employing those best practices. (That is, everyone should know better than to ask for 3-D red, yellow, and green pie charts and other do's and don'ts you will learn in this book!)

We do wish that data-analysis and reporting unicorns were real! Life would be so much simpler. But they aren't and never will be, so we let go of that fantasy long ago and have found tremendous success in training and building great teams with the different skills that are required. We encourage you to do the same.

Get to Know the Data

The term data governance has become pervasive in the health and healthcare data environment. However, at present, any efforts at creating full-fledged data governance standards and associated documentation are at best nascent and more often nonexistent. Therefore, to perform correct analysis and create useful displays of data, analysts and data visualizers must establish discipline and process to learn and understand-and get to know-health and healthcare data.

Classifications, Intent, Purpose, and Lineage

Powerful data analysis and visualizations require subject-matter expertise about health and healthcare, and knowledge and understanding about the data being captured and reported. Whether it is a survey instrument, electronic health record, billing system, or the classification systems used to organize them and the databases to store them, diligent inquiry and research must be performed to ensure that the available data are fully understood. This discovery includes but is not limited to learning:

• How the data are categorized (classified) and relate to each other.
• Whether the data are part of a widely recognized and accepted classification system such as ICD10 Codes or a custom, unique system created for one particular project.
• Why, for what intent and purpose, a set of data is collected in the first place, such as medical claim payment, clinical research, patient care, public health initiatives.
• Moreover, and as necessary, how the data may have changed over time, their lineage.
• What the data definitions are.

For example, the HEDIS measure set was created in 1991 (version 1) and originally stood for the Health Maintenance Organization (HMO) Employer Data and Information Set. In 1994 version 2 was renamed the Health Plan Employer Data and Information Set. In the original design, HEDIS measures provided consumers and regulators with information to reliably compare competing managed care health plans. The focus was on how they were paying out premium dollars to providers for services. HEDIS was a marketing tool for HMOs to demonstrate that they were providing the most benefit to subscribers as compared to all other HMO plans.

A fundamental change occurred in 1997 when the National Committee for Quality Assurance (NCQA) adopted the HEDIS measure set as a way to measure and report about Medicare beneficiaries' quality of care. That is, the type of services delivered to specific cohorts of patients, such as mammograms for women, were used as proxies for quality care. At the same time, the NCQA also announced that the HEDIS acronym would be changed to stand for Healthcare Effectiveness Data and Information Set. Commercial insurers quickly followed suit, using HEDIS compliance targets in contract and payment negotiations with providers.

In some ways, it may be logical to use the HEDIS measure set as a proxy for the quality of care provided. For example, if the evidence supports that women of a certain age would benefit from an annual mammogram, and the number of eligible women receiving them can be reliably measured, then it may be that providing a mammogram is a reasonable proxy for quality care. However, as anyone who works in the health and healthcare profession knows, HEDIS falls short as a comprehensive measure of quality care because it does not capture the various outcomes that are important to clinicians, patients, researchers, and payers.

In other words, WYSIWYG (what you see is what you get) does not always (or even usually) apply to health and healthcare data. Therefore, it is crucial to take time to research the structure and categories of classification systems, and the primary purpose of a dataset, and how it may or may not be able to be reliably used for analysis and reporting.

Deciding on a set of terms (terminology) that accurately represent a system of concepts, creating a vocabulary with definitions of those terms, and arranging and organizing related entities into a classification system or database would appear to be a fairly straightforward (if long and detailed) task. Well, as the old joke goes, if you want 12 different opinions, put six people in a room and go around twice. (If they are experts in the field, the total will be closer to 24 different opinions.) Reaching consensus on how to define and classify health and healthcare information is tough. Evidence changes; treatments, procedures, and patients metamorphose; stakeholders define terms differently based on ever-shifting goals and objectives.

All these transformations mean that teams must dedicate time to research and consider the underlying classification systems of data definitions, and the intent, purpose, and lineage of health and healthcare databases. Starting here will save much frustration and wasted time later on and increase confidence about the ability to create valuable dashboards, reports, infographics, and other displays of health and healthcare data.

In addition to understanding the intent, purpose, and lineage of health and healthcare data, a fundamental understanding of data types, scales/levels of measure, and data relationships is required to create meaningful displays of data.

There is a wealth of books, publications, and blog postings on this topic,...