Build vs. Buy a Healthcare Enterprise Data Warehouse: Which is Best for You? (Webinar)
Enterprise Data Warehousing in Healthcare – Build vs Buy considerations (Transcript)
Good morning. This is Christina Galoozis with Modern Healthcare. Welcome to today’s discussion, Build versus Buy: a Healthcare Enterprise Data Warehouse, which is best for you? This one-hour webinar will explore the technical and organizational pros and cons of building versus buying, as well as a third approach you may not have even considered.
Now, I would like to introduce today’s speaker, Mike Doyle. Mr. Doyle joined Health Catalyst in May 2013 as vice president. He has been connected with the Health Catalyst Senior Leaderships teams since 2006. Prior to Health Catalyst, Mike led the Enterprise Data Warehouse Program at Allina Health as director of Healthcare Intelligence. He helped Allina grow its Enterprise Data Warehouse program from an amazing clinical improvement initiative to an enterprise-wide strategic asset. Prior to his work with Allina, Mike led the Analytics and Systems Integration team at Northwestern Medical Faculty Foundation.
Okay. Thanks very much. So building versus buying an Enterprise Data Warehouse is something that is near and dear to my heart. The topic for this webinar came from a blog or an article that we worked on at Health Catalyst to try and bring some of the considerations involved in terms of implementing a data warehouse into the discussion. And so, we’re very excited for your questions and eager to hear what you have to say and we’ll try to address as many of your questions at the end as possible.
I’ve been fortunate myself in addition to working at a couple really awesome organizations with just fantastic internal capability. I’ve seen data warehouses be successful and successfully implemented in at least two different ways. At Northwestern, I got to be part of a fantastic team where we built an Enterprise Data Warehouse from scratch. In addition, I was at Allina for four years and worked with just a fantastic group of individuals there where we implemented Health Catalyst Solution and then further extended it with just some terrific internal talents around analytics and data warehousing.
So, I’m excited to share what I’ve seen, what I’ve learned. I don’t expect this to be the be-all and end-all of build versus buy conversations or Enterprise Data Warehousing discussions, but we think we have gathered a lot of good points for you to consider as you’re making that decision.
Another thing about the title, which is best for you, we’re probably not going to try to recommend a specific solution, we won’t advocate for any particular position. We hope that we can aid in your decision-making process and we’re very much interested in this being a bi-directional dialogue.
Context for this topic
When we consider a simplified version of the software development life cycle, an organization will likely look at their current state to assess, do we have the tools to use data to help transform care delivery and streamline operations? If they decide that they don’t have the current capability to do that, if it’s harder than they expect to be able to use the data they’ve been putting into medical record systems, into patient experience systems, to the surveys, into financial decision support systems, they may decide, you may decide to engage in the design process. And not all the processes are going to be as formalized like this but you might end up going through these stages as your organization thinks about what would that future state look like. At that point, you’ll select an approach. And for the purposes of this presentation, we’re going to assume that you’ve selected an Enterprise Data Warehouse or a data warehousing approach to integrating your data to create that single source of truth from multiple disparate systems. You’re likely interested in facilitating Triple Aim Reporting and you’ll proceed to either implement to a vendor solution or to build from scratch a data warehouse. Either solution will need to get tested and deployed, and organizations will choose to deploy in an iterative fashion and roll out across the organization. It works especially well for larger organizations or those that have many locations and potentially different cultures.
The topic for today is really that inflection point or that decision point between the design and implement phase where we ask ourselves, we have some options here, should we try to build it from scratch? Should we look towards a vendor to partner with us and buy that solution? Are those my only options? And we’re going to discuss the third or a hybrid option or we can do a little bit of both. Ultimately, the decision is up to you. We want to provide some of the things that can help factor into your decision-making process.
The agenda today is fairly straightforward. We’ll examine each of those options starting with the build option, followed by the buy option and we’ll talk about that hybrid solution. We’ll have a few polls scattered throughout that and see one in just a moment to help gauge your interest in data warehousing and help focus some of the discussion that we’re going to have.
So we’re going to start with a poll question.
What is your experience with data warehousing?
Great. Alright. The poll is closing. And then we are sharing the results.
Great. So we have…most organizations look like they’re falling into the, we have some basic capabilities, followed by we have advanced capabilities, and there’s two groups around we’ve not yet begun and we’re just beginning. Excellent. Well that’s great information. So thanks for participating in the poll.
Building an EDW
Alright. So first we’re going to talk about building an Enterprise Data Warehouse, and building an Enterprise Data Warehouse is a pretty big effort. It’s a large project. It doesn’t have to start large. It can start small. We’ve seen it done a couple different ways at Health Catalyst in terms of what our customers have done prior to working with us and we’ve all, many of us, been connected in some way with Healthcare Data Warehousing and seen organizations both succeed and potentially fail to meet the expectations building a data warehouse.
Let’s go to the next slide and talk a little bit more about what this is.
What is an EDW?
So, to sort of leverage that on what an Enterprise Data Warehouse is, this is the Health Catalyst architecture but that’s not really material. We’re going to talk about just at a high level an Enterprise Data Warehouse is a way to bring data from multiple systems into one common shared environment where it can be integrated and indexed and provide a single source of truth for the organization in healthcare, at least, to better understand quality and affordability, streamline operations and help basically manage the business and the clinical operations and the clinical performance of the organization.
So these are likely components of an architecture in any approach in “build it” approaches, in “buy it” approaches, things such as ETL or loading scripts that move the data in. There will be data marts that store data in some way and then you’ll see some layer of applications. In this case, we’ve got the green boxes there which we call subject area data marts, other solutions deployed a little bit differently. But that’s pretty much the general concept. Underlying all that would be things like metadata, security, and auditing. So these are things that are common to most Enterprise Data Warehouses.
Why choose to build an EDW?
So why would you choose to build an Enterprise Data Warehouse? And the ‘why’ here applies a little bit to why you might buy one as well. The benefits of the data warehouse, and we call this the pie test, includes Performance, Integration, and Ease of use. So what do that mean, those are pretty high level general terms.
By performance, we mean that if we you are not to deploy a data warehouse and you are to look to bring data from your medical record system and you’re going to pull data from your financial decision support system and you’re going to pull data from your patient experience system and do that on the fly, there’s a couple ways that you’re going to encounter some performance issues.
Generally, those systems are designed to put data in their data collection systems, and medical records like Epic and Cerner are just fantastic at deep views of patient data and looking deeply into one patient record and providing all of that material into the clinician’s hands quickly and effortlessly. It becomes a little more difficult when you want to look across patients. The database just isn’t optimized and indexed the way you may do that in a data warehouse solution. And so, performance happens that way. It affects data analyst query performance. You also have the potential to impact performance on those finances and as you’re running those queries in real time, well other users are trying to use the system for patient care or for the financial operations of the business.
So without a data warehousing approach, and I’ve heard it referred to in the past as almost a symptom, it’s a symptom of the problem that you can’t report on those same data structures myriad efficiently, as if you brought them together, you integrated them upfront, and you provided your analyst with an easy-to-use resource. And that’s what we mean also by integration, the data are pre-integrated where it’s possible, and it’s easy therefore for a data analyst or a data consumer to use to see across the business and understand that single source of truth.
Historically, the pioneers of healthcare data warehousing, folks like Intermountain, Northwestern, Banner, PeaceHealth, those organizations have found there to be a dearth of proven solutions for healthcare. There have been vendors since the 1990s that have had success in other industries, industries like retail, and manufacturing, and they have brought products to market that become adapted to healthcare. But there really wasn’t a lot of success. And healthcare as an organization, as a market, and as an industry, looks to what others are doing, how others are succeeding.
Many companies will look to build something small internally and then grow it. A lot of these early pioneers also had built other software components or other infrastructure components within their organization. Intermountain Healthcare, for example, was the leader in medical record development. They developed they own medical record. Other organizations did that as well. Getting about it today, the EMR market has evolved so much and become so mature that it’s probably very unlikely for somebody to begin a project today that would develop their own EMR from scratch.
Historically, pioneers in healthcare data warehousing also needed to demonstrate the value prior to a larger initiative or funding for a larger project. They started small. For example, at Intermountain, they started with just a couple areas or a couple clinical domains and they built from that and they’ve sort of integrated on that. That can be a very successful approach if you’re building in. It tends to take a little more time because a bottom up effort like that can take time to spread throughout the organization, unlike a strategic initiative, for example, which is more of a top-down decision. So those are some reasons why you might choose the “build it”.
Considerations: Building an EDW
Some of the considerations or risks to building an Enterprise Data Warehouse, or any data warehouse project or large BI initiative is a risky proposition. Gartner found that over 50% of data warehousing projects fail and there’s a link there to that Gartner study. I advise you to take a look at it if you’re interested.
We’ve also published based on that and sort of as a Health Catalyst for the further discussion there, one of our co-founders, Steve Barlow published an article on our website around some of the things that are keys to success and some of the things that are keys to unsuccessful data warehouse builds, things like a solid business imperative is missing or executive sponsorship and engagement is missing.
Or particularly important for building an Enterprise Data Warehouse, if you’re building it from scratch and you can’t benefit from how others have worked with your data before, you really need to involve a lot of your frontline users to help understand how to translate what goes into the medical record or what goes into your GL system or your cost accounting system into meaningful analysis for users that are left familiar with that and turn that into information.
Many groups that build a successful data warehouse project then find that ongoing success can be difficult. Most healthcare IT groups aren’t prepared, they aren’t developed to function like a software company. They’re optimized to purchase software, implement it, integrate it, and potentially extend it. But in terms of true software development, best practices around things like agile development, exposure to multiple programming languages, understanding of data structures, things like version control and continuous integration of things like this, release management, are just not skill sets that a lot of healthcare IT groups are focused on because they really don’t need to. It’s about serving the clinicians and the operations and the leadership within the organization and ensuring that excellent support is provided and that operations are always available.
Finally, one of the main risks is that you’re going to have limited opportunities to learn lessons. Other folks will have made similar mistakes, they will have misjudged the difficulty around a certain data source or misunderstood how to use a specific set of data to calculate a metric. If that happens enough times, it’s unfortunately easy for the leadership of many companies to say we’re putting a lot of money into this specific initiative. It has a lot of resources and as revenue changes and as healthcare changes and we look to different areas to potentially reduce that, it’s one of those areas where it’s harder to continue to realize the value. Internal IT groups might have a fantastic product and I’ve seen this before, but they really don’t often have the ability to engage in the marketing and the sales internally of their product to your organization. And they shouldn’t. It’s not a skill set. They should be building terrific software but that becomes difficult and a bit of a pain point when financial resources are questioned by others.
Pros/Cons: Building an EDW
Alright. So to wrap up the building an EDW section, some of the pros and cons.
Pros. If you’re building an Enterprise Data Warehouse, you get to customize it infinitely. You can take as long as you’d like, you can deploy as many resources as you have available and you can absolutely get a solution, which is 100% customizable to your data sets and to your metrics.
On the other side, another pro is that if you just need something, you can often build something in terms of a pilot project, which may be good enough for now. It might be people that answer the questions that are being asked today and support the need of a specific strategic initiative or within a specific domain. We see this a lot where there’s interest in a clinical area, say cardiovascular disease. There may be additional funding for data analyst help and many data analysts will gravitate to the solution of what’s integrated in our cardiovascular data around this area and develop some reports to help write grants, or to do quality studies, etc. Going along with that is if you built it yourself, there’s a certain pride of authorship, an ownership of that asset that you’ve helped to develop. You can talk about it by publishing it, you can get recognition from your peers which is an important consideration for a lot of organizations, especially academic medical centers.
Some of the cons. Whenever you’re going to build something, you’re shifting some of the costs from a technology cost to a labor cost. So your labor cost, the number of staffing resources internally that you’ll need to develop, will likely be larger in a situation where you’re building it completely from scratch.
You’ll also find, like many organizations, there’s a shortage of qualified resources. By qualified, we don’t necessarily mean folks that have a lot of specific technical experience. Skills can be learned, and there are great training programs for a lot of the ETL tools and data modeling. But it is difficult to fine people that can really work directly with clinicians speak the language of clinicians, physicians and nurses and leadership and understand what’s important to measure and manage in healthcare.
There are differences in the ability of not-for-profit organizations to attract the same level of talent just because of financial resources. This is a lower concern. I’ve worked in not-for-profit healthcare and we hired just fantastic resources. We always find that the folks that are willing to commit themselves to that mission and that culture are delivering excellent care, are the folks that we wanted anyways but it really does make the screening process for employees take a lot longer.
You’ll also be re-learning lessons. If you’re building it from scratch, there are some communities out there, like HDWA that can help you to understand what other organizations have found to be successful. But you’ll likely make a lot more mistakes, maybe twice as many mistakes as if you had help from somebody who could say we did that, we tried that, here’s why it didn’t work, here’s what we settled on that’s a little bit different.
The last two are interrelated. “Skunkworks”, which you may have heard of, was I a division within Lockheed Martin. This is an aerospace company that built the U-2 and the SR-71, really high performance planes in the 50s and 60s and they were extremely successful in doing that under the leadership of a guy named Kelly Johnson. He was so good at leading this group and focusing on just the thing that mattered in terms of the design and the execution and the implementation, that they’ve built what today are still some of the most incredible planes ever, and I guess you can I’m a little bit of a plane nerd. But that’s a difficult thing to pull off within a healthcare organization. If you don’t have a large organization, like Lockheed, where you can really physically cordon off these people, the cultures are going to intermix. And if one group is allowed to play by different rules and the rest of the IT group with the rest of the culture, inevitably, there will be a little bit of rub between those groups, which can hamper the widespread distribution and utilization of your data warehouse asset, which is unfortunate. It’s just part of human nature.
And then finally, sometimes you’ll find project management challenges. A waterfall approach to project management can work fantastically in things like construction projects, or implementing completely packaged software. However, if you’re using your data for the first time, you’re pulling it out of your systems and integrating it for the first time, a lot of times, leaders, clinicians have never seen the way these data fit together before in this way and you need to go and do it a few times and say, “Is this close? Am I getting closer?” And a lot of times that can frustrate or hamper the traditional project management approach. So that’s where building it within the framework of a more PMO-centric organization or organizational structure is potentially challenging. Many organizations have done just a fantastic job there but we’ve seen it the other way as well.
Buying an EDW
And we’ll talk about buying an Enterprise Data Warehouse.
Why might someone buy an EDW?
So why might someone buy an Enterprise Data Warehouse? First, because it’s probably easier today to buy something. There are more vendors out there that have been able to demonstrate success specific to healthcare than there were maybe 10 years ago. So you have other options. We’re at a point in our industry where maybe the medical records were 10 years ago, where you could build it but there were also really good options. There were still at that point some risks, for example, in thinking about how to take a product like Epic and deploy at inpatient. But some organizations made that leap and Epic has blossomed and created a fantastic inpatient product.
The first one, developing well-engineered, custom software may not be your competency. Most healthcare provider organizations are focused on delivering excellent high quality care at the lowest cost possible with excellent patient experience. And the primary IT function is there to support all of those efforts and to ensure that all of the software is working and its optimally performing. But rarely do IT organizations carve out a group specifically for innovation. We’re seeing more of that. Northwestern, for example, has, I believe, a chief innovation officer now in the form of Lyle Berkowitz. We’re going to be talking with Lyle pretty soon. We worked together there at Northwestern and his role there is to facilitate innovative uses of their existing technology decisions. And we’ll probably see more and more of that but it’s still pretty rare.
Finally, support and maintenance agreements are a way to ensure longer success with a vendor and partner. Somebody is there to help you when things get challenging. Where through leadership transitions, you need to make sure that your systems are still running, most IT groups rely on some form of a support and maintenance agreement to ensure that they’re able to take upgrades and adjust to the changes in their source systems, to take advantage of new products that their vendor is developing and from the insights that their vendor is likely getting from their other customers.
Considerations: Buying an EDW
Many of the same risks in buying an Enterprise Data Warehouse that those you could find with any vendor relationship. If you’ve never worked with a vendor before, a specific vendor, there is an amount of trust that the vendor needs to earn from you. We’ve published an article about how to evaluate a clinical analytics vendor. It was authored by Dale Sanders. He’s one of our senior vice presidents and was instrumental in the development, co-architect of the Data Warehouse at Intermountain Healthcare, and also was a CIO at Northwestern and in the Cayman Islands. The evaluating analytics vendor paper talks about these things that you may want to investigate. So what type of vision does that company have and how does it align with your needs, how complete is that vision, what are the culture and values of your potential vendor, how well does that align with your company? Are you a mission-driven company? Does your vendor seem to be similarly organized?
Of course we have to look at what type of value does the vendor provide for the services being delivered, and how about their ability to execute. Where else has this vendor been successful? Will their approach work for my organization? And do they have expert resources? Do they have in-house or do they rely on a wide network of partners that may have limited expertise in healthcare or working within their specific implementation model?
Pros/Cons: Buying an EDW
Some of the pros and cons to buying an Enterprise Data Warehouse include that sometimes you can get the shortest time to value from a vendor solution. It’s not uncommon. For example, in our customer base, we see about 90 days to deploy an Enterprise Data Warehouse complete with your EMR data, of course at a financial data, and patient experience data. It’s very hard to build an enterprise wide asset from scratch in that same period of time if it’s the first time you’ve done it.
Vendors also can provide real world experience. So they know what works best in practice can bring a lot of those lessons learned to you.
They also provide an infusion of help. Now that can be a pro or a con. Assuming you partnered with a vendor that has folks that have done it in healthcare before and understand healthcare data, having a few of those folks to send in your organization, work with you, understand what your needs really are and say “I get it. I think you’re looking to do this” and then help take that ball and run with it can be a tremendous asset for you in terms of project success.
Oftentimes, a solution from a vendor can provide the lowest total cost of ownership. If you look at the 5-year cost in terms of how you might have to build that solution, ramp up all of your staff, the ability of a vendor to help you accelerate that process initially and then provide a way for you to transition over to your internal resources if that’s your goal, that can often provide the lowest total cost. You’ll have to take a look at some of the numbers yourself and I urge you to do that and calculate things like 3 to 5-year total cost versus potential return on investment. But that’s what we found from our experience and then from my experience as well.
In terms of cons, the initial cost can be high with any software purchase. There is likely a licensing component, potentially a professional services component and maybe even also a support maintenance agreement. Some vendors will offer to go to a subscription model or a way to defer payments or a payment process that works better with the way that you do accounting internally and can help mitigate that but that’s still something to be aware of.
Knowledge transfer, with any vendor, with any partner, consultant, anybody that you’re pulling in from the outside for a short period of time, including contractors, in order to retain the knowledge that they bring is important. So this external party likely brings knowledge of doing it elsewhere and a certain level of expertise, and you don’t want that to disappear when the project ends. You want to look for a vendor that has a clear strategy for education that has a way to build up the capability within your organization to become self-sufficient. Not every organization, provider organization, wants to do that but if one of your goals is to use a vendor to accelerate the process and then further continue with your internal resources, that’s something you want to consider.
Finally, with any purchase solution, there can be a tradeoff between a “perfect” fit that might take a long time to get to and an “extremely good” fit that you can implement rapidly. Most organizations apply some element of the Pareto rule or the Pareto principle or the 80-20 rule when they’re thinking about technology purchases. Most organizations, around 67% of organizations, are less than satisfied with their EMR purchase. EMRs do fantastic things. They have to cover a huge array of capabilities, and so it’s likely that you’re not going to be fitting your medical record to every person you need within the organization. There are going to be some gaps. But again, that’s a clear choice where you would absolutely choose to buy a medical record at this point, even knowing that it’s going to be an extremely good fit and maybe not a perfect fit.
We’re going to have one more poll question
Quick Poll: How important is data warehousing to your clinical improvement strategies?
Alright. Well we have a very clinically oriented, very pretty much performance improvement oriented audience today. So not surprising but it’s great to see that folks are thinking about using data and Enterprise Data Warehousing as a tool to achieve better patient care and not just – it feels great. So thanks very much for your answers on that.
Hybrid Build and Buy
Buying AND Building an EDW
So now let’s talk about a third option. We talked a lot about build versus buy. More often, these days, we’re seeing organizations select vendor to achieve certain goals in their technology strategy but leverage their internal resources to help extend or integrate or tailor or customize that solution for their environment. So in practice it’s more like a “buy and extend” strategy and examples include selecting a vendor to implement the data warehouse components to accelerate that initial lift and then integrate several high priority data sources – things, we’ve already talked about them that you know of, the common data sources around clinical, financial, operational, patient satisfaction.
Also, then they leverage internal resources to integrate additional data sources going forward – so looking for ways to bring in their cardiovascular registries, or ACC and STS data. They might have surgical data from NSQIP they want to bring in or manually collect the data or community health data. As time goes on, we find that there are just a number of uses for a data warehouse and uses for the ability to land data in one place and integrate it with others. There’s an article which we could point you to on our website about some of the unexpected benefits from using an Enterprise Data Warehouse and this ties to how willing, how interested is the organization on then picking up the data that they now have and using that asset to its fullest potential.
Many organizations, like Allina, choose to develop a robust library of analytic applications. There are just a host of really interesting dashboards, robust analytic applications that can be built on top of an integrated set of data.
And then finally, a lot of organizations look for ways to shorten the time between when you see the data and generate information and when you can affect patient care or operations. So there are ways to integrate data that exist in the warehouse with operational processes. We saw this at Northwestern, for example, in terms of facilitating research study recruitment. We would look at, you know, an IRB-approved manner to generate a list of patients that might be most applicable for a diabetic study, for example, and we would get that information through a combined query of who has been admitted or checked into the hospital or the physician group there, combine that with the overall patient profiles that we saw on the warehouse and generate a candidate list of folks that may fit the research study and may benefit from that.
So those are some of the ways that you might choose to buy and build.
Why choose to build AND buy?
So why would you choose to do this? You get some of the best of both worlds and you tend to mitigate some of the risks. So you can get a rapid implementation of that 80%. It can be as customizable as a purely build solution if you have a flexible agile vendor combined with a set of staffs that are coming up onto the same principles and can fully extend your warehouse. There’s also a higher potential for the return side of the investment. In either case, buying or building, you’re going to be making an investment in terms of some mix of people, process and technology. And many times if you can do a little bit of both, you’re setting yourself up for the greatest potential return.
As I mentioned, this solution or this strategy also helps to mitigate some of the risks. Some of the things that show up as risks within the “build it” category are mitigated by the “buy it” solution. And some of the risks from the “buy it” solution, in terms of vendor relationships and knowledge transfer, can be mitigated by having a set of core set of really committed, talented internal software development resources. And then finally there’s always the infusion of resources to help deploy and train across the organization.
A couple other considerations, I think we’ve now addressed the “buy it”, the “build it” and that hybrid solution. I want you to be aware of a few other resources. We have, as I mentioned, that article from Steve Barlow who is the director of Intermountain’s Data Warehouse Program for many many years and was the co-founder of our company. He talks about potential pitfalls for any data warehouse project. Some of the other ones include “trying to boil the ocean”, trying to achieve all of the potential success and design it all upfront in one big project.
Seeking governance “perfection”. We’ve seen as in my experience that governance evolves over time. As utilization of the warehouse is relatively small at the beginning of the project, you often need a certain set of very tactical leaders that can help make decisions then here and now. Over time, if you’ve been successful, we have an overwhelming demand for the data that exists when in the warehouse and overwhelming demand for the additional resources to help extend it and answering new questions. So governance can help at that point to set strategic direction for what the warehouse will try to achieve and what it won’t.
A rigid architecture in either “the build it” or “the buy it” solution can help hamper the utilization or the extension of the warehouse.
There’s a couple of Insights articles from our website. The original article from which this webinar was based is available for you. You get links in the presentation on slides here afterwards, as well as another article that compares different data warehouse architectures for healthcare, kind of to that rigid architecture concern.
Finally, a couple other resources. Healthcare Data Warehousing Association is www.HDWA.org. It’s free to join. If you’re a provider at healthcare, for example, I urge anybody who’s interested in either solution to join that group, if you haven’t already, you’ll just meet some fantastic people that are working in the trenches. The Data Warehousing Institute across all industries provides a great resource for folks to learn more about benchmarking, provides a way to compare your analytic capability and maturity there at your organization to others. And then finally the Health Catalyst Knowledge Center is a good resource. We have articles, blogs, webinars. For the most part, none of those require registration. If we do, it’s for things like webinars where we need to send you a link to log in and it’s generally free.
About Health Catalyst
Alright. Now we’ll get into the section about Health Catalyst. I’m really going to breeze through this so that we can get to your questions really quickly.
Health Catalyst Profile
Twenty seconds on our profile. Health Catalyst has been fortunate to work across different types of healthcare organizations, integrated systems, community hospitals, academic medical centers, children’s hospitals. We can certainly think we’ve affected or impacted about 25 to 30 million patients across all of the Health Catalyst instances deployed across the country in about 1400 different hospitals and clinics.
What does Health Catalyst offer?
What we offer includes a data warehouse platform, the Late-Binding ™ Data Warehouse that you see on the bottom that’s been developed through the lessons we’ve learned at organizations through the years, set of analytic applications and two types of services – installation services and care improvement services.
Here’s a quick view, and again this is mainly for you to take a look at afterwards. We’ve got three types of analytic applications that sit on top of that platform – the foundational applications that get broad access to data, discovery applications that let you find and seek opportunities for improvement within your organization that may exist within your data and advanced applications that help you focus on specific domains, clinical conditions, operational areas or patient safety.
Reduce Healthcare Labor Costs by using an EDW and Analytics
And I’ll leave these a couple success stories with you guys to review at your leisure. It’s not uncommon for us to partner with an organization that has a significant goal around helping to provide more efficient, more valuable and affordable care. In this case, we’ve worked with an organization to help reduce overall salaries by 2% without massive layoffs or anything like that. It was just looking at more effective staffing and using a combined set of data from multiple data sources. We helped them achieve about a 2% reduction in total salaries and benefits to date. It sounds like a pretty small number but in many organizations that can be between $10 and $15 million a year conservatively.
Questions and Answers
Alright. So that concludes my presentation. I’m excited to help answer additional questions. I’ll be at the booth at HIMSS if you want to meet face-to-face and I’m ready to hear what the audience wants to learn about.
Christina Galoozis: Thank you Mike. Thank you for your presentation today. We do have some great questions coming in from the audience, and if you have questions, please continue to send them in. Let’s see what questions we have. Mike, the first one is, what are the cost differences between building and buying?
Mike Doyle: Yeah, a great question and probably the biggest differentiator, we talked about it a little bit, but in my personal opinion, the cost differences are going to be mainly the type of cost. Over time, over that 5-year period, the cost might equal out but you’re going to see potentially higher costs in the staffing area for your “build it” solution and you’re going to see potentially higher cost in the technology area for your, in the software licensing area and professional services for a “buy it” solution. So just like any other build versus buy where it’s probably going to break out like that.
Christina Galoozis: Thank you. The second question we have is, who has implemented the “build it yourself” approach successfully?
Mike Doyle: Many organizations, and that was one of the reasons I wanted to point out HDWA. You’ll find within the membership of HDWA, it’s an organization started by Dale Sanders and Steve Barlow at Intermountain in the early 2000s, and it was really to help bring groups like Intermountain that built their own data warehouse, Banner, PeaceHealth, and then later Northwestern and many other groups have been successful at doing this.
Christina Galoozis: Alright. The next question we have is, can you define triple Aim Reporting?
Mike Doyle: Yeah. Triple Aim Reporting is the looking at the quality provided by healthcare organization, looking at the cost to deliver that care, and then the third one is looking at the patient satisfaction, so how generally are patients, how much are they satisfied by the car being delivered. And so Triple Aim Reporting is a challenge for many organizations to look at those three in total unless you can integrate the data upfront and query across it. It’s difficult, for example, unless you have an Enterprise Data Warehouse, to routinely look at which patient surveys are coming back, join those at the lowest level of potential data to your financial or you’re going to encounter data from your other systems (50:37) to that so that you’re not breaching patient confidentiality and look at how an organization is doing across those three axis altogether. I think it’s an IHI concept.
Christina Galoozis: Great. Okay. The next question is, what sort of precision should one expect initially from prediction models using data from an Enterprise Data Warehouse? And then give an example as a C statistic?
Mike Doyle: C stat of a really good predictive model I think is in the 0.75 – 0.76 range. Initially, you might expect to see more like 0.6 – 0.65. That’s, again I’m not a data analyst but that’s what I’ve seen.
Christina Galoozis: Great. The next one is, how does the availability of open source software impact the cost and practicality of the “build it” approach?
Mike Doyle: Great question. So when we’re looking at different business intelligence tools, for example, at Allina, we did a search process to look at what existed both from a vendor solution, as well as an open source solution. There are also open source tools that will be supported by a vendor. For example, there’s a company that has purchased the supports, the Mirth Match Enterprise Master Patient Index Software, and that can be a pretty powerful strategy as well. We sometimes found – I think when we look at just at your functionality differences, what we wanted to get at Allina and through our work at Health Catalyst, the types of projects that we were looking at were just, they were just a little bit more robust and feature complete in some of the vendor solutions. But absolutely if you’re on a limited budget and you have folks that are willing to support and partner with an open source company over the longer term, that can be a really good idea. Some of the difficulties there include an open source community, a true open source once is contributed to by developers oftentimes in their spare time at night. The community will change over time and you may be at risk for the community not being as strong in two or three years as it is now. Where in the vendor solution, you’ve got the ability to at least understand a little more about the vendor’s chances in terms of the business, how likely is it that they’re going to be there to support you in the future. So it’s a little bit of a tradeoff but definitely your initial cost can be affected positively by looking at some of the open source solutions. That’s my opinion.
Christina Galoozis: Thanks Mike. And as a reminder to all of the attendees, if Mike isn’t able to get to your question today, expect a followup after the presentation. It looks like we have a couple more questions here but we might have time for a couple more, so continue to send in your questions. The next one is, since an Enterprise Data Warehouse is an expense, how can you portray ROI value efficiency of reporting to leadership?
Mike Doyle: Oh that’s a great question. One of the things you need to do if you’re thinking about measuring ROI, and we hope that everybody who’s building or buying a data warehouse and solution is thinking about this these days, is you need to keep supporting good technology decisions, and it’s hard to do that unless we can show a positive return on investment. The first thing you need to do is to understand what the base level is of expense in that area and understand through some healthcare specific questioning and answering and assessing what does the baseline current state look like. And then you need to measure at certain points along the deployment and then after the deployment at certain phases those same metrics and better understand that.
Health Catalyst has a webinar online done by a couple of our financial experts, including Bobbi Brown. I urge you to check that out to look at what are some of the ways you can do that. There’s a tool you can download through that that will help you consider and think about ROI measurement going forward.
Wonderful. Thank you so much. Mike, thank you for your presentation. To everyone, that takes us almost at the top of the hour, so it’s time to conclude today’s presentation.