Data teams need to speak the same language. Often they don’t.
In any organization, the people touching the data need to be speaking the same language. That doesn’t refer to what programming language they code in. That can be important, but it’s usually accounted for in the hiring process. An issue that’s harder to control is that business rules need to be implemented in similar ways by anyone contributing to the code base. Things work better, much better, when that happens.
But often, it doesn’t happen that way.
It’s easy to think “that’s what data governance is for”. But the fact is, data governance as an activity is poorly implemented all over the place, all the time. The main reason is that no one has the job of governor. And simultaneously, everyone does.
Organizations that have faced data governance challenges know that good data governance, as well as the ability to develop code in a consistent way that can be easily and reliably interpreted by big data teams, requires more thought and creativity than slapping a “you should” directive on data handlers. The best systems will find ways to ensure, not just hope, that common coding practices and standards are followed.
Background and Challenge
A large digital transformation project for New York Presbyterian Hospital fully revamped a back-end quality metric application, with no disruption to weekly reporting. During that work, it became clear that there were dozens of capable staff among the data teams who could be contributing to the quality metric code base. However, up until then, only one gatekeeper monitored the application and was responsible for creating all new metrics.
This was negatively impacting the hospital’s ability to create and manage new quality measures that were critical to monitoring clinical quality improvement initiatives. Yet no one had thought about how to activate these data team members to be a part of that process. Up until then, the culture had dictated one gatekeeper overseeing the code base for quality metrics. No one could conceive of how that could be a shared process.
Solution
The new approach to the back-end application took this into consideration. It was intentionally designed as a system that any SQL programmer, from beginner to advanced levels, would be able to use. A metric template permitted for any analyst to develop whatever algorithm necessary to draw data in from the over 100 databases in the hospital’s servers, applying whatever inclusion and exclusion criteria were necessary to write the metric. Content area experts were consulted for this step to ensure the correct clinical definition was applied.
The next step in the process transformed the analyst’s work into a standardized format using an enterprise-approved function the analyst did not have to worry about writing. From there, standard rules could be applied to aggregate all metrics in a uniform way, according to the more generalized data governance rules.
Results
The expansion of data team capacity to write metrics for NYP was perhaps even more significant to this organization than the new application itself. After five superusers were initially trained on the new system, within a matter of months NYP expanded its core set of weekly reported quality metrics from about 30 to over 100. Some of these metrics had been awaited by clinical teams for months or even years.
Clinical quality metric writing is a detailed process; it is also essential data work in a hospital, a task that hospitals rely on from data teams in order to be able to monitor and inform quality improvement work. It is in many respects a core function of hospital quality data teams. Ideally, everyone can chip in on the development of these metrics. This project ensured that NYP’s quality data teams could do exactly that, now and for years to come.
Delivered:
Want more solution inspiration? Return to the gallery to read more.