- Without clean, standardized data that can be manipulated, translated, and exchanged when needed, an analytics program has no hope of getting off the ground. After bringing clinical and financial information in to a system through EHRs and practice management software, data needs to be deposited in a warehouse that will allow analytics professionals to call upon it and mold it in a simple, streamlined, accurate way. There are several different ways to build a data warehouse. Which one is best for your organization’s needs?
Enterprise data model
The enterprise data warehouse is a top-down approach that seems appealing for organizations that know what they have and what they want to do with it. Data elements are assigned to specific categories, and algorithms are built around these categories to produce actionable reports. The enterprise model is simple, structured, and comprehensive – which also renders it extremely inflexible if new data enters the system but doesn’t fit into existing data sets.
“In all my years in the healthcare analytics space, I’ve never seen a project using this approach bear much fruit until well after two years of effort,” writes Steve Barlow, former CEO of Health Catalyst. “In the reality of healthcare, you’re not building a net-new system when you implement an enterprise data warehouse. You’re building a secondary system that receives data from systems already deployed. Extracting data from existing systems and making it all play well together in a net-new system is like trying to transform an apple into a banana. With patience, the right skills and a bit of magic, it’s possible, but it is incredibly time-consuming and expensive.”
Healthcare data is just too complex to take advantage of this data model, and analytics is changing too quickly for a health system to know everything it will ever want to do with its information right now.
Data mart model
If you’re not going to build one big system, how about building many smaller systems that work together? Building “data marts” based on the needs of an individual department or area of research has its appeal, as the projects are easier to contain and produce more immediate results.
Data marts draw information from a superset of clinical and financial data into an individualized application based on the requirements of the radiology department or the pharmacy or the ED. While this approach counts on a repository free of limiting data silos, it may create new ones unintentionally.
Data marts built individually might fall prey to the same interoperability problems plaguing EHRs on the front end. Every data set has its own unique quirks, and developers who sacrifice uniformity for necessary workarounds could be setting the system up for failure once the individual databases, which downloaded and transformed the superset of data to meet its specific needs, try to talk to each other.
Late-binding data model
The problem with both of those models is the “binding” of the data. Sorting data elements into discrete categories before using them for anything limits the usefulness of the information, says Dick Gibson, Chief Healthcare Information Officer at the 32-hospital Providence Health and Services system. Early binding makes it more difficult to incorporate other vendor systems. “If you have an early-binding model, your model has been disrupted. So the advantage of a late-binding model is it’s more flexible,” he notes.
“Too often, data warehouses are built on the assumption that they won’t need to change,” says WhereScape CEO Michael Whitehead. “Too often, there is a belief that there is a perfect design that users have agreed will meet their requirements now and into the future. Yet everything changes: users, requirements, data, source systems, technology stacks.”
Late-binding data, which keeps information in a more fluid format before it’s needed to plug in to a certain problem-solving scheme, seems to be a useful middle ground. “Rather than trying to hammer out a data model up front when you can only guess at what all the use cases for the data will be, you bind the data late in the process to solve an actual clinical or business problem,” Barlow says. “You don’t have to make lasting decisions about your data model up front when you can’t see what’s coming down the road in two, three or five years.”
All three models have their uses, depending on the size of the organization in question and the depth of the analytics that organization wishes to perform. But as technology changes and population health management becomes more central to the financial health of providers and hospital systems, deeper analytics will require more agile infrastructures. Planning ahead for your organization’s needs is vital when choosing a data warehouse model, and anticipating the unexpected will help your analytics program grow and change with the evolving healthcare landscape.