Healthcare organizations are turning to the enterprise data warehouse (EDW) as the foundation of their analytics strategy. But simply implementing an EDW doesn’t guarantee an organization’s success.
One obstacle organizations come up against is that their analytics team members don’t have the right skills to maximize the effectiveness of the EDW.
The following six skills are essential for analytics team members: structured query language (SQL); the ability to perform export, transform, and load (ETL) processes; data modeling; data analysis; business intelligence (BI) reporting; and the ability to tell a story with data.
Smart healthcare organizations are turning to the enterprise data warehouse (EDW) as the foundation of their analytics strategy to improve their care delivery and the cost of care. However, purchasing a sophisticated EDW doesn’t guarantee an organization’s success to lower cost or improve care delivery. To fully leverage the EDW investment, you need to have the right people with the right skills—strong health data analyst skills.
A common obstacle organizations run into is that their technical team may not be equipped with the right skills to take advantage of the EDW. This shortcoming can be overcome. Skills can be taught or acquired to better support a data-driven organization.
The overwhelming majority of healthcare workers will never directly interact with an EDW. That is, most staff members won’t directly query databases, write reports, or analyze data looking for trends. Instead, they will rely on someone else to pull data from the EDW, analyze it, and then produce a report. This report conveys meaningful information around a workflow over which the report requestor has some accountability. Let’s classify this group of people that receive the information in the form of reports as consumers. In contrast, the technical staff members tasked with data capture, analysis, and reporting are producers of information.
Consumers develop opinions of the EDW based on their ability to act on information found in reports generated by producers. It is not uncommon for a health system to invest millions of dollars and a handful of years into a data warehouse but still have consumers who are dissatisfied. How can such a significant investment result in dissatisfaction? It is sometimes the case that consumer dissatisfaction is a function of producers not having the right skills to generate the analysis and information consumers need. In fact, producers may not even know what they don’t know.
If the team responsible for generating a return on investment from their EDW lacks the skills to manage and leverage the EDW, it can create real problems for a health system’s enterprise-wide analytics strategy. Clearly, this isn’t the result you want from your analytics efforts. By making sure the analytics team has the right skills, you can avoid these kinds of problems.
For a healthcare organization to effectively leverage an EDW to support sustained outcomes improvement, I submit there are six skills that need to be operational among staff members (either analysts or architects) tasked with analytics work.
Let’s explore each of the domains in greater detail.
1. Structured query language. An analytics team member needs to be able to talk directly to and manipulate databases through structured query language (SQL). Recognizing there are various dialects of SQL, I refer generically to the ability to speak to and manipulate databases through code. He should be able to write SQL code without a dependency on an intermediary, guided interface (e.g., a drag and drop tool). Many analysts rely on tools like Microsoft Access or Crystal Reports GUI interfaces to generate SQL for their reports. In doing so, they attain a rudimentary understanding of querying. SQL offers users fine-grained control of the data being pulled. It also provides a powerful way to explore data that isn’t filtered through a predefined data set or model, as is the case with a business intelligence (BI) tool. Teams that can’t query the data with SQL are beholden to whatever information is pushed to them from another source. Using a BI tool to generate SQL on your behalf is a good starting point.
There are a couple potential downsides to using auto-generated queries from BI tools, though. First, these tools usually underperform because they are poorly constructed (behind the GUI interface). Second, and far more prevalent, is the way these tools mistakenly make assumptions about the data and manipulate the data without the user being aware of the underlying logic. This is dangerous because he may not understand the query generates duplicate result sets (i.e., tables), or excludes some patients that should be included in the result set, or a host of other “I didn’t realize it was doing that” scenarios.
If your query feeds a report, and the report provides information people will act upon, you need to be sure you really understand the logic embedded in the underlying query.
2. Export, transform, and load (ETL).The health data analyst needs to be able to perform export, transform, and load (ETL) processes. Simply put, he needs to take data from one system and put it into another. In an EDW, a user pulls data from disparate systems that don’t talk to one another. For example, you may have an EMR system, a patient satisfaction system, and a costing system that don’t interface directly. Making a copy of the data found in each of these systems and pulling the data into the warehouse will allow integration of data from the various systems. This movement of data is accomplished through the ETL process.
3. Data modeling. Data modeling is a fancy way to say that an analyst can write code that models real-world processes and workflows. Let’s consider a common healthcare scenario: a hospital admission. What information do I need to capture to model that workflow? In this example, you’d need some demographic information, such as the patient’s name, data of birth, gender, and complete address. You’d likely want to pull insurance information, such as the plan name, copay amount, and effective coverage date. Clinically, you would want to know some history. Is this patient new to the system? Do we already have a medical record number for the patient (indicating we have seen her before)? What is the admitting diagnosis? Who is the attending provider for the admission? Did the patient come through the emergency department or some other venue? A good data model captures all of these data elements and relates them in a meaningful way to reflect the actual workflow.
4. Data analysis.An analytics team member needs to be able to make sense of the data once it is in the EDW. There is so much information produced in healthcare, and not all of it is relevant for an analysis to drive improvements. A good analyst has the ability to sift through data to extract pertinent insights. This requires some complex thinking around set theory and the ability to do his analysis through SQL, a statistical reporting tool, or a combination thereof. In healthcare, there is a lot of attention to the management of diabetic patients. Diabetes is a chronic condition that affects the patient’s quality of life, and if not well managed, can be lethal. From a financial perspective, diabetes is extremely costly if mismanaged.
An analyst may be part of clinical improvement team tasked with managing diabetics within the health system. But if diabetes is a clinical condition, what possible value could an analyst bring to the team? Consider this:
A health system may be managing a large population of diabetics that may be stratified into low, medium, and high-risk stratifications. Clinical markers called out by physicians determine the classification of patients into one of these three categories. But what if the health system wanted to know more, such as its total number of diabetic patients? How many of these patients are in each category of risk? What is the movement of low to medium risk on a year-over-year trend? How about the trend of movement from medium to high risk?
An analyst will be tasked with mining the available data to answer these questions and will add tremendous additional value if he can highlight potential reasons that explain the “why.” Why the movement from low to medium? What statistical correlations can be drawn and then effectively tested? A health data analyst fills that role for the team.
5. Business intelligence (BI) reporting.An analytics team member needs to be able to present data in a way that’s intuitive to nontechnical users. The visual representation must be simple to interpret by a lay audience. While this sounds simple, this skill is difficult to execute well. It separates an average analyst from a stellar one.
In a real sense, this is akin to being an interpreter. An interpreter hears words spoken in one language and then speaks a different language to the target audience. Without a strong mastery of both languages, translation is difficult, if not impossible. Apart from the mechanics of words, language rules, and semantics, there are embedded nuances, such as metaphors or idioms that further enrich the communication experience. An excellent interpreter demonstrates the ability to perfectly convey meaning, not just words.
Likewise, the data expert needs to translate database speak—that is mining data to find meaning—into simple graphics that perfectly convey the meaning, all while avoiding potentially ambiguous conclusions.
6. Telling the story of the visualizations.The analytics team member must be able to effectively communicate stories embedded in the data. Think of it this way: BI reporting gives you contextual meaning in bits and pieces, or a micro view. Telling the story, however, means providing a logical flow to tie together lots of meanings to create a big picture view. Let me further illustrate with an example.
Research indicates that one of the clinical best practices for diabetic patients is to perform a hemoglobin A1C (A1C) test on a patient’s blood on a yearly basis. Other best practices include getting a yearly eye exam, foot exam, and a blood pressure evaluation.
A data expert tasked with reporting on A1C testing, eye exams, foot exams, and blood pressures gives meaning to the data elements capturing these measures. The analyst scours databases to find all the possible ways that A1C results are represented in the EDW. The same exercise is done to find eye exam, foot exam, and blood pressure data. The skill of BI reporting helps clinicians and care managers identify patients that have care gaps (e.g., patients missing eye exams, foot exams, A1C testing). These are meaningful measures, but are really just part of a bigger picture.
Telling the story in this example means helping the organization see how well it is managing its diabetic population through evidence-based medicine. Telling the story takes into account all of the measures (e.g., A1C testing, blood pressure testing, eye exams) across the entire managed population and finds where the system is doing well, or where there is variation in care delivery. Telling the story also means looking at clinical and financial outcomes. Just because a system is really good at delivering care, doesn’t necessarily mean all outcomes are optimal. At what cost is the care being delivered? Perhaps the clinical outcomes scores are noteworthy but not financially sustainable. Telling the story means calling this out and using data to suggest ways to reduce cost without sacrificing quality.
In summary, an analytics team member who is adept at telling the whole story (both technical detail and big picture thinking) understands the business she supports. This is an extremely valuable skill.
As a former data architect and analyst, I operated within a generalist staffing model. There was an expectation for me to have proficiency in all six skills mentioned above. My assignment was to support a primary care clinical program, and it fell to me to cover everything from data procurement to reporting and analysis. Admittedly, I was stronger in SQL, ETL, and data modeling than the other skills. I had some valuable analyst peers to help improve my BI development and visualizations.
In a combination of self-applied learning and dumb luck, this approach allowed me to get to know the business users I was supporting, develop code for ETL, model real-world business problems, and use SQL for set analysis and data mining. The breadth of exposure to the business problems we were solving was rewarding. It also allowed me to simultaneously grow my technical skills and my understanding of the business of healthcare.
A generalist model may seem impractical to large organizations that already have specialists in some of these areas (e.g., data architects, ETL developers, data modelers, and data analysts). I am not suggesting specialization is bad. The important thing is competency across all of these skills within the team. For organizations steeped in a specialist approach to skill management, it’s important to ensure there is a good working relationship between the specialists in each domain. Smooth handoffs between each of these team members are essential for successful outcomes.
Both generalist and specialist staffing models can work as long as 1) the skill is covered with a high degree of expertise, and 2) coordination and handoffs between technical team members are seamless.
Teams of individuals equipped with these six skills within a healthcare organization will be highly valued assets for the company. Ensuring coverage of all of these skills will help any organization get the most value out of their EDW. Most importantly, it enables the organization to truly unlock the potential of its data. Turning data into actionable information is what good analytics is all about: unlocking data to drive meaningful, sustainable change.
Do your health data analysts have these six skills? If not, what problems have you encountered as a result? Are there any data skills you would add to the list?
Would you like to use or share these concepts? Download this presentation highlighting the key main points.
https://www.slideshare.net/slideshow/embed_code/46053161
