Let’s take the “village” concept from the previous blog post a step further—and here’s where it gets more controversial: to be an EDW that keeps up with the ever-quickening drumbeat of data needs and requirements in healthcare, we need to start enabling subject matter experts outside of the EDW team to actually help build the EDW. Not just create reports or even develop more advanced BI tools (semantic layers, dashboards, etc.), but actually help build the data at the most granular level of the data warehouse. Isn’t this just making more people data architects and therefore growing the EDW team? No, this is about adjusting the traditional roles of the EDW team and analysts outside of the team in a way that allows the people in each role to do what is most in line with their skills and abilities.
Here’s a real-world example: let’s say an organization wants to focus on reducing their preventable readmissions. To do so, a performance improvement specialist is leading a team of hospitalists, care managers, and nurses to evaluate current performance and look for improvement opportunities. Their methodology for identifying an inpatient admission as a readmission comes from a combination of national readmission definitions and their own clinical judgment. Who knows better about how to calculate the field that flags an admission as an official readmission: the EDW data architect or the clinical data analyst with a nursing background who sits on the readmission team? Obviously the latter, so does it make sense for the data analyst to try to translate the logic to the data architect or for the architect to provide the tools for the analyst to create the flag her/himself?
The step of the data analyst translating the readmission flag specifications to the data architect is really just waste, not to mention the fact that since the data architect lacks the context surrounding the data, there will likely be extra cycles in getting the flag right that the analyst wouldn’t have to do alone. So in an ideal world, we would take out the middleman and allow the data analyst to build the readmission flag. And this would need to happen at the lowest level possible in the EDW so the flag (or any other data element or measure) could be pulled from one place. Attempts to replicate business logic in multiple dashboards or reports might start out ok, but over time and despite best intentions the data elements and measures will get out of sync with each other. The problem needs to get tackled within the EDW at a table and column level.
So practically speaking, how do we crowdsource some of the development of the EDW? As we’ve alluded to above, unless you are going to force everyone to use the same BI tool (and good luck with that long-term), the creation of these data elements and measures will have to be done at the table and column level in the EDW, and this means there won’t be a nice user interface for data analysts to use. They will likely need to become comfortable with sql (structured query language—the common language for querying databases). Now once you stop laughing at how far-fetched this idea may seem, hear us out. We have seen analysts who have vowed to never learn sql come around to fully embracing and enjoying the benefits of knowing how to write sql code. Despite all the new tools out there, sql is still the basis for the vast majority of BI and EDW technology.
So how would this shake out in terms of roles and responsibilities?
| The analyst: | The architect: |
|---|---|
| Knows how to calculate the readmission flag | Knows how to “provision” the data; meaning how to pull together the data needed to calculate the readmission flag |
| Knows the ins and outs of the data and the “why” of the readmission flag logic | Employs tools in an optimal way to make the readmission flag logic easy to view; update and keep in sync in all the places it is used |
| Has sufficient context to be able to identify right vs. wrong data often just by looking at it | Can provide both summarized and detailed data to the analyst to monitor the measure and gauge accuracy |
| Keeps abreast of changes to the readmission flag logic and to the workflow inherent in the underlying data systems | Knows how to tune (optimize) the queries that pull the data to keep the whole process running smoothly and efficiently |
All we’re really suggesting here is getting the right work and responsibilities assigned to the people best able to take them on. Subject matter experts are responsible for metric and data content, data architects are responsible for designing data models, moving data, and optimizing EDW performance. In our final installment of this series, we will describe in more detail how the data architect and subject matter expert interact in building the EDW.
