A Model of Data Maturity to Support Predictive Analytics

A Model of Data Maturity to Support Predictive
Analytics
Session 19, February 20, 2017
Daniel O’Malley, Director, Data Operations, University of Virginia Health System
1
Speaker Introduction
Daniel O’Malley, MS
Director, Data Operations
University of Virginia Health System
[email protected]
2
Conflict of Interest
Daniel O’Malley, MS
Has no real or apparent conflicts of interest to report.
3
Agenda
• Introduction
• Problem Statement
• Industry Standards / Current Literature
• University of Virginia’s Data Model and Architectural Design
• Implications for Practice
• Questions
4
Learning Objectives
• Describe the data maturity progression that an organization undergoes as it
becomes data-driven
• List the data architecture activities that support the data maturity progression
journey
• Recognize the various benefits that are achieved as an organization
progresses toward agile analytics
5
An Introduction of How Benefits Were
Realized for the Value of Health IT
Satisfaction – Greater access to timely data
Treatment/Clinical – Real-time extraction (hourly) supports
various unit dashboards which include clinical data for
rounding
Electronic Information/Data – Moving organization to
data-driven modes of operation
Patient Engagement/Population Management – The
architecture is increasing in its role for our ACO and
population health initiatives
Savings – Allows clinicians to focus on care, instead of the
data production/gathering work
6
Introduction
• Use of data within an organization follows a maturity progression:
– Operational / retrospective -> Strategic / prospective
• Foundational components must be present before advancing, including:
– Data warehouses / data marts / reporting tables
– Analysis cubes
– Intra-day data extraction
– Advanced data modeling
7
Problem Statement
The journey toward data use maturity
requires expert support and an advanced
data infrastructure that increasingly must
deliver real-time analysis.
8
Operational Use Cases
• Hourly Throughput Dashboard
• Infectious Disease Dashboard
• CEO Daily Volumes Dashboard
• NICU Dashboard
• Decompensating Patient
9
Operational Use Cases
10
Industry Standards / Literature
There are many, many maturity models. Just about every major vendor has a
maturity model. Some exemplar articles include:
• CMMI (Capability Maturity Model Integration) – Carnegie Mellon / CMMI Institute
• Sen, A., Ramamurthy, K., & Sinha, A. P. (2012). https://doi.org/10.1109/TSE.2011.2
• Danciu, I., Cowan, J. D., Basford, M., Wang, X., Saip, A., Osgood, S., … Harris, P. A. (2014).
https://doi.org/10.1016/j.jbi.2014.02.003
• Yoo, S., Kim, S., Lee, K.-H., Jeong, C. W., Youn, S. W., Park, K. U., … Hwang, H. (2014).
https://doi.org/10.1016/j.ijmedinf.2014.04.001
11
UVa’s Data Model and Design
• Our model and architecture:
– Developed organically (3 stages of data tier maturity)
– Based on the realities of our reporting requests
– Time (latency) is a major dimension / consideration
12
UVa’s Data Model and Design
Time, time, time…. (Or, should I say,
latency, latency, latency)… Why is it so
important?
• Data has an expiration date
• Clinical environment / urgency
**The architectural design must
accommodate and deeply integrate the
time dimension
13
UVa’s Data Model and Design
• Clinical data
• Financial data
• Various other domains of
data
• Various data types and
constructs
14
UVa’s Data Model and Design
• Complex design
• Multiple data models
• Multiple data refresh latencies
15
UVa’s Data Model and Design
• Multiple refresh rates are complex to
manage, hard to conceptualize
16
UVa’s Data Model and Design
• Daily processing increases
rapidly
• It is harder today than
yesterday
• Complexity increases over
time
17
UVa’s Data Model and Design
• Complex scheduling needs
• Need to monitor key data
processing control limits
• Intervene when processes are
outside of control limits
• Proactive monitoring
18
UVa’s Data Model and Design
• Three distinct stages
• Each stage builds upon the
previous stages
• Change in focus from past to
present to future
19
UVa’s Data Model and Design
• 600 hours of senior database
administrator/data engineering
support
• Data model understanding of the
business unit or service line
• Reporting tables and/or data mart
creation to support required
performance
• Analysis cubes that provide drill
down and pivot-style interactive
analysis
20
UVa’s Data Model and Design
• 300 hours of senior database
administrator/data engineering
support
• Creation of a business unit or
service line ODS
• Optimization of the data pipeline
to support a rapid data refresh
rate and the data subset
• The formation of basic data
governance processes and
management
21
UVa’s Data Model and Design
• 100 hours of senior database
administrator/data engineering
support
• Data format and structure
changes to support advanced
data modeling
• Custom development to support
advanced data techniques
• Advanced data governance
methodology utilizing MDM
software
22
UVa’s Data Model and Design
• Data maturity progression is
cumulative
• Collaborative initiative
between customers, data
engineering team, and
reporting team
• ***Estimates are only the data
engineering team’s effort
23
Our Successes
• Rapid access to clinical data from electronic health
record
• Flexible data tier
• Helped to foster the organization’s shift to data-driven
decision-making
• Customer demand
24
So What? Why is this important?
•
•
•
•
•
•
Clinicians and leaders need this data and will get it somehow
Spreadsheets are not your friends
‘Analyst’ can have many meanings from department to department
Unified organizational view?
Metadata management?
A reliable data tier is rapidly becoming imperative
25
Implications - Recommendations
• Focus on the quality of the data pipeline first
– As data becomes more and crucial, users must learn to first trust the
data
• Data production pipeline stability
– Accurate data is not useful if the users cannot access it
• Strive for data model extensibility
– Plan for changes to the data architecture—this is one sign of success!
26
Implications - Recommendations
• Focus on matching the source systems’ data, even if they are wrong!
– The data warehouse should not be the place where ‘dirty’ data is fixed
• Begin profiling your data and tracking it over time.
– Key to understanding your data quality current state and progressing
to higher quality data
27
Implications - Recommendations
• Do the hard work of data modeling first
– Take time to model your data and use cases in order to fully
support your customers
• Don’t just create rapidly refreshing copies of source systems
– A system-agnostic data model will save time in the future (e.g.,
system changes/vendor changes)
28
Implications – Difficulties
•
•
•
•
•
Victim of our own success?
Highly dependent on source systems (and their availability / uptime)
Complex data transformations, with a large number of steps
Nuanced reporting problems (data mismatch)
Many of the most important reports need to be ready early in the
morning, when there is the least amount of processing capacity/time
29
An Introduction of How Benefits Were
Realized for the Value of Health IT
Satisfaction – Greater access to timely data
Treatment/Clinical – Real-time extraction (hourly) supports
various unit dashboards which include clinical data for
rounding
Electronic Information/Data – Moving organization to
data-driven modes of operation
Patient Engagement/Population Management – The
architecture is increasing in its role for our ACO and
population health initiatives
Savings – Allows clinicians to focus on care, instead of the
data production/gathering work
30
Questions?
[email protected]
31
Please use blank slide if more space is
required for charts, graphs, etc.
To remove background graphics,
right click on selected slide,
choose “Format Background” and check
“Hide background graphics”.
Remember to delete this slide, if not needed.