Different Models in Healthcare (data warehouse ones at that! hehe)
So, we’ve taken a few weeks looking into data warehouse and what it consists of, let’s finish out with the different kinds of data warehouse models that there are!
One of the first concepts to understand that these models differ primarily with how data is “bound” or aggregated from the source systems to a standardized column of values as well as business rules. In a healthcare sense, it’s how to take the information from the EHR and associate it with the correct SNOMED/ICD-10 diagnostic code. Sure the dropdown menu usually tells you, but the entered information is typically different and there is a background process that parses and inputs the expected information. Depending on the data warehouse model used, optimizing data and aggregating them into specific areas can be different in analysis. These models in healthcare bind data at different times in the process, and for healthcare it appears that binding later may be the more appropriate model due to its volatility of information and data.
Health Catalyst Primary Source
The Big Bad Typical Mode – Enterprise Data Warehouse (EDW)
So as we’ve discussed before, EDW is essentially a cluster**** of information. It takes in information from a variety of different sources, and as a result it requires a mechanism or method that can help aggregate and organize all of the incoming information. One of the models in healthcare, this is considered a top-down approach that is the most common. However, some obstacles are that it requires the databases to be “perfect” or at the very least already optimized from the outset, as a result, it requires the person implementing the data warehouse to have a good understanding of the metrics, measured outcomes, and satisfaction results to be measured in order to “mold” the database accordingly. In most cases, data warehouses are something that are decided at the beginning of the implementation process, something new, something without prior databases. However, in most cases of healthcare systems, they are implemented after the initial database architecture has already been established. It is implementing a second system that aggregates all of the disconnected electronic sources of data and as a result, can often take a long time to implement well because there is a lot of needed adjustment in aggregating the necessary value of data from each source. With this delay in mind, that’s already one of the downsides of the model. In addition, other drawbacks are that the data is bound very early on, thus it is difficult to alter the data as necessary afterwards to be used in different cases. It is difficult and time-consuming to make the changes into the schema, business rules, use cases etc. Say patient vitals are used in reporting in medical purposes, but after the time that is used to implement it into reports and business intelligence, maybe we also need patient vitals in financial reports in cases of lawsuits? Now it needs additional time to copy and convert that information to another use.
Now Tack On The Data Marts!
Although the data marts are built off of the enterprise data warehouse model, it requires a different implementation because instead of the data warehouse being the main source of data, it is built around these individual and specific data marts as they are needed. First implement the data marts that aggregate the necessary information for Financial, then Administration, then Medical and a variety of other sources like that. It allows for more specific analysis and thus data marts can be built to help add additional options to these models in healthcare. However, some of the drawbacks are that they create these isolated database, and thus you don’t always necessarily have the idea of a “data warehouse” when everything is divvied up like that. Unfortunately, the data marts add another layer of updating and processing as they have to constantly query the original data warehouse for information to feed these data marts. Once again, the data is bound quite early and can thus be mapped into a predefined data model, making it difficult to creating new models or shifting them for different purposes. The purpose of data marts are to give different groups access to the data they need to make their own analytical decisions. Fortunately, a security concern is also answered by limiting the amount of information and data that each department is able to access (coughcoughHIPPAcough). By allowing the departments access to the data warehouse, it’s essentially a large scale EHR system, you have access to information, a majority of which isn’t even relevant to your own use! (Take that ADMINISTRATION). Additionally, by using data marts they can be tailored for specific interests, data can be analyzed as needed with the department’s own formulas and business intelligence tools. That doesn’t mean that data warehouses aren’t used, they’re just more of a supporting resource by containing all of the information while the data marts can be used to address specific needs for each department.
Using the analogy of grocery shopping, let’s say you’re baking cookies. The recipe indicates that you’ll need four eggs, two cups of shortening, etc. You go to the store and buy exactly what you need, pulling four eggs out of the carton, opening containers of shortening and measure with your measuring cup…efficient for you…for now. Later, you need to bake a cake. Guess what that means? Back to the grocery store you go to get three cups of flour. You get the idea.
Late Binding! How it can help!
Meant to be adaptive and a pragmatic model for healthcare, by binding data late, this is one of the models in healthcare that can provide an approach that will rapidly change business rules and metrics measured as quickly as the healthcare environment changes as well. Typically using the ETL method, extract, transform, load, by binding late it will bring the data directly to the source marts allowing the user to manipulate the data however needed, without the transformation. By keeping the data as raw as possible, it allows minimal data obstructions… one such example would be to keep the patient name structure the same and not manipulated to the formats requested by the data mart or the user. The data is only remodeled when required in the analytic use case. The data is bound ONLY when necessary. Although the resources consumed may be more, this “right-before” binding allows the user to hammer out a data model quickly and for the cases as necessary. The data is transformed for the requested case.
This new approach was based upon two radically new concepts: (1) Writing code in smaller modules or objects that were modeled after processes and services in the real world that the software was designed to support, and (2) binding these software objects at run time, not compile time, and only when those objects were needed to support the services they reflect.
Understanding the Differences!
The Kimball and Inmon approaches (of both books that I have been reading through) essentially are early binding, they require that the incoming data be mapped to predefined columns and rows, in a process called conformance and normalization. For analytics, the data is run through a series of business intelligence tools, rules, and use cases — which can be used to help with transactions, queries, and other simple processes where the mechanics and use cases are relatively consistent. However, the variability in medicine also leads to variability in use cases and each report in healthcare. It can be difficult to take the time to map and transform the data into specific data models, all to be run at “compile-time” instead of being called in “run-time”.
Things To Keep In Mind For Success!
Although a data warehouse can provide some great benefits, it is important to take the implementation like any other project. Management is key in order for it to be a success. Short and simple. KISS. Some things to consider when implementing a data warehouse in a healthcare organization is to have a CLEAR business imperative and goal for the implementation. There has to be a clear understanding of the financial and clinical needs and a plan on how a data warehouse will be used to solve those problems. By doing so, it allows the organization to define the necessary additions as well as inform the team what the technologies will be used for. Many times the frontline users are not consulted which can lead to some difficulties and disconnect in discussion, by doing this, it allows the users to have their input to develop a well-balanced data warehouse. Know the reasons, stay on track (scope, resources, and money) and constantly consult with those who would be using the EDW the most!
TOP-DOWN. TOP-DOWN. I know how difficult it can be to work with the upper level management, and often times you think that grassroot movements are the most effective. And to a certain extent, I will agree, but when it comes to processes that require time and money, if you don’t have an executive or upper level champion working with you, you’re screwed. The strategic importance of the EDW needs to be stressed, and the best way to get upper level management on board is discuss the $$$ monehhhh. Do a risk analysis, cost-benefit, TALK MONEY to get the support that you need. You need that support, you need the resources, and you need the approval to get the most potential and speed in the implementation process otherwise you’ll have some executive doing whatever they can to ixnay the project simply because they didn’t feel included in this important business decision.
Working in the IT area, the biggest complaint is “Why isn’t it done yet?” … isn’t technology supposed to make everything faster? Why isn’t it done yet then? First off, ignore them, and continue trucking away. As long as your goals are SMART, then continue to identify each marker point and work towards them. There are many things to consider and it should not be rushed, data is expensive, and a lifetime of data from someone’s lifetime (see what I did there?) is just too vital.
Choose an area, and work on whittling costs while improving quality. Identify similar cases and do case studies on them to learn from mistakes as well as implement greater emphases on things that were shown to have worked. I realize there is a need to “future proof” for data collection, but depending on the model used, only implement something that will collect enough data to manage and measure clinical processes effectively. Nothing can be perfect, governance especially. The organization and its oversight will not see quick answers, it takes time and patience to really see improvements and the needed answers. Additionally, important to consider the models in healthcare and how they can be used for your own purposes!
These principles include data literacy, data stewardship, and data exploitation. Data literacy should include programs to increase user understanding of the data and ways for users to practice with the data. Data stewardship is the process of identifying and mobilizing the appropriate business or clinical steward of the various data domains. A data steward’s responsibilities are concerned with the authorization and quality of their respective data sets. Data exploitation policies should err on the side of getting data into the hands of knowledge discoverers trained to mine and interpret information.
Building a data warehouse is a very difficult project, ensure its success by having a clear goal in mind in its implementation. Have the entire organization from the “C-men” to the frontline users consult and provide insight on what is needed. Not only that, but allow those that actually mine and analyze the data the chance to have a voice in what processes can be done and when it can be made available. Provide the analysts with the data so that it doesn’t hinder the usability of that data. BE SMART WHEN PICKING FROM THE MANY MODELS IN HEALTHCARE.