In an industry where costs are soaring and payer reimbursements are declining, the prosperity, and sometimes survival, of a hospital can depend upon the availability of quality information. Now, more than ever, accurate, timely and detailed information is needed to comply with external reporting requirements (e.g., ARRA-HITECH, meaningful use, comparative effectiveness, etc) and to make better informed strategic, tactical, and operational decisions. For example, since sub-standard care often leads to higher costs due to longer hospital stays or unnecessary, repeat hospital visits, insurers are capping payments for services or denying payment altogether unless healthcare providers can prove that the care they provide is consistent with recognized standards for quality. While this move toward pay-for-performance is helping to reduce costs to insurers (and ultimately to patients), it is also driving down revenue to healthcare providers at a time when the costs of care are increasing.

To combat these kinds of challenges, hospitals across the country are asking hard questions. They are looking for ways to maintain or even improve operating margins, as well as qualify for ARRA-HITECH and other government incentives and grants. They want to know which procedures generate the highest contribution margins and how they can increase the margins for less profitable procedures without compromising (and hopefully increasing) the quality of care. Unfortunately, all too many hospitals maintain a myriad of systems and domain-specific data stores making their data inaccessible and unstructured for analysis and to answer critical questions.

The key to data-driven care provision is having high-quality comprehensive data that can be easily accessed and manipulated. This has led to many health systems initiating large scale clinical data warehouses, and/or reporting and analytics projects that seek to integrate disparate data regarding outcomes, safety, operational, quality, and financial measures. This trend has been accelerated by federal grants totaling $31 billion from CMS in addition to increasing demands from private insurers.

Ultimately, in order to attain the subsidies and avoid the future penalties mandated by CMS, all hospitals will need to demonstrate reporting/ analytics capabilities to attain EMR Meaningful Use. In addition, such capabilities will further enable the health systems to achieve their strategic imperatives, such as attaining superior outcomes in centers of excellences (orthopedics, cardiovascular, oncology, etc.) or reducing readmissions or length of stay, as well as increasing provider productivity and satisfaction.

HARKENDATA, a proven company helping leading healthcare organizations bring together financial, clinical, operational, and quality data into a common repository to support analytical reporting, identifies the following ten factors as most critical to success in building comprehensive data warehouses and analytic systems.

• 1. Executive Sponsorship and Timely Decision-Making Processes. Hospital data warehouses are too frequently considered “technical” projects and turned over to IT organizations to plan and execute. While undeniably there is a high degree of technical content and expertise required to execute these projects, they must be fully integrated with both government-mandated and strategic initiatives, in addition to enabling greater workflow efficiency. A key condition for these projects to be successful is clinician executive sponsorship – a clinician executive with the willingness to expend political capital to ensure that the project receives appropriate visibility and resources to achieve its objectives and to ensure that the use of the warehouse and its data is fully institutionalized within the organization. Additionally, this executive should insist on a participatory approach to the project that engages all major stakeholders across the institution.
  There is a key distinction between a participatory approach to a project with strong leadership and leadership by committee. The former ensures that all constituencies are represented and that the multiple functional areas needed to successfully build a hospital data warehouse are brought to bear. Yet, there is a deliberate decision-making process with an ultimate decision-maker. The latter approach tends to result in delayed decision-making, politically based decisions, and lack of true accountability for results. Also, delays in decision-making invariably increase the cost and timeframe for projects. This would be part of plan for Data Warehouse Governance, encompassing Program Management, Data Governanace and Stewardship, and Infrastructure.
• 2. Reporting and Analytics for strategic initiatives and Measuring Outcomes Drive the Project. Ideally, hospital data warehouse design and development should be driven by how the data is going to be used. Strategic inquiry is one of the first steps to building a hospital data system that meets the institution’s growing data needs. What data and analysis can best inform strategic imperatives, be responsive to mandatory (e.g.: CMS, Joint Commission) reporting requirements, meet the information needs of the clinicians and ensure sufficient management oversight of programs? Answering these questions is not trivial since there is a strong temptation to simply replicate the reports and analyses that are currently produced, albeit much more easily and with greater integrity. However, such a bounded analysis overlooks many of the enhanced capabilities that substantially increase the value of a hospital data warehouse. This is particularly true with respect to analytics – a field that is expanding rapidly with respect to techniques, and cause and effect relationships.
  In reality most institutions approach these projects from a different yet effective direction, that of data availability. Essentially, they identify the operational data systems that will feed the warehouse such that the contents of the warehouse are defined as the aggregation of data elements from the feeder systems (e.g.: EMR, ancillaries, revenue cycle, etc.). The intent is to meet as many reporting and analytic requirements as possible subject to this data limitation. This is a reasonable approach in that it expedites the creation of a first release of a data warehouse, which in turn, provides a set of capabilities that demonstrate the value of the warehouse. The wealth of data that becomes available and the relative ease of use represent a significant improvement over past practices. This conversion of data availability to data usability is achieved most efficiently through a powerful reporting and analytic software tool.
  Over time, there is a need to reconcile the near term data warehouse goals, defined by data availability, and the long term data warehouse goals, defined by the full reporting capability to meet the analytical and management needs of the organization. This is best achieved by formulating a hospital data warehouse strategy. This strategy defines the ultimate set of desired reporting and analytic capabilities, the gaps relative to the first release of the data warehouse and the second release, the succeeding sets of operational systems that should be made available to increase the robustness of the warehouse, and finally, key data elements that do not currently exist in any feeder systems and which, over time, potentially could be added to those systems. A longer term strategic road-map is essential to ensure that in the long term the full value of the investment in a hospital data warehouse is realized.
• 3. Adopting a Robust Technology Solution That Supports Long Term Needs. Typically, it can take many years until an institution reaches full maturity with respect to a hospital data warehouse. This is because most hospitals’ primary data sources consist of several disparate operational systems, requiring institutions to address data (and workflow) inconsistencies while working under budget constraints, and often lacking experience in robust analytics that measure outcomes and isolate true cause and effect relationships. As a result, may institutions embark on a limited initial project – with the expectation that they will expand the system over time.
  The problem that many institutions have encountered is reconciling short term budgets with long term needs when selecting a technology solution. Specifically, sustaining a comprehensive hospital data warehouse requires a dynamic technology solution (e.g., commercialized databases and models, storage, reporting and analytical tools) to support expansion of data to cover more entities, to enable the loading and storage of enormous volumes of data from many sources, and to provide data access to many constituencies with varying levels of sophistication. These activities are typically much more extensive than those required to execute the initial project of modest scope.
  An institution may be tempted to choose a seemingly simple technology solution that meets the short term project needs as a means of controlling near term expenditures. In most cases this choice bears a false economy because the lower-cost short term solution frequently cannot scale, thereby limiting the ability to meet long term requirements. Remedying that problem can entail expensive custom enhancements or complete technology replacement. Therefore, in terms of full system life-cycle cost and management of risk, it is most often preferable at the outset of the effort to obtain an “industrial strength” technology solution that will provide a strong and scalable foundation for a 5-8 year period. That said, conventional wisdom would say that the price of such a strong and scalable solution would come at a high premium. However, today best-in-class data warehouse appliances and solutions are now available to meet most if not all health care systems needs. The key point here is implement the best available solution that can grow and scale in a linear fashion, as the demand for actionable data increases across the health system. Finally, where mature data warehouses have been implemented, strategies and technologies have developed to manipulate the data in-database (users are brought to the data), instead of data being distributed to users. As a result, performance improves and new capabilities can emerge, like better data mining, trending and more precise predictive analytics.
• 4. Reliance on Fully Commercialized and Supported Technology Components. Typically, in constructing information systems there is a continuum of architectural approaches from developing completely custom software to acquiring turnkey packaged solutions. The former can produce precisely the system (e.g., features and functionality) that the organization desires, but with high cost and high execution risk. At the other extreme, cost and risk are minimized, but the organization must live with the baseline features and functions supported by the systems. In approaching hospital data warehouses a key decision is selecting the optimal point along this continuum that responds to the organization’s preferences for functionality, cost, and risk, and that realistically reflects the solutions available in the market. Another key message here is to start with a small project, and incrementally build over time. We have seen too many projects stall or fail because they tried to “boil the ocean,” or the started the project too large and broad. Also, best in class data warehouse and analytical solutions will enable the ability to re-use existing data for other purposes. This concept is called “load data once, use it many times.” Overtime, this will stabilize (if not reduce) the total cost of ownership, while at the same time increase business value and operational efficiency to users and executive leadership.
  Typically, hospitals find that the best approach is one that relies on proven commercial products designed or tailored for healthcare data warehouses and reporting solutions. Data warehousing and analytics application are sufficiently common that software and tool vendors have brought to market excellent products which provide a solid, low-risk technology foundation. For example, there are excellent data repositories with very robust data models for healthcare. Similarly, there are dynamic business intelligence (reporting and analytics) products that support virtually all of the needs of healthcare institutions.
  In selecting the set of products which together will provide the technology foundation for a hospital data warehouse, four factors are of paramount importance. First, each product should be a very good fit with the institution’s current and future needs – such that the institution will receive what it needs at a reasonable price. Trying to make a bad fit into a good fit is never economical. Second, each product must be fully commercialized – that is, it must be licensed, installed and used in a number of sites. This is the best means of ascertaining that the product “works”. Third, each product must be well supported and sustainable – that is, there is a regular schedule of upgrades and new releases and assurance that the vendor will continue to offer the product to the market for an extended period of time. Finally, the various products (e.g., database, business intelligence tools, and ETL tools) must be demonstrated to work well together as best evidenced by the combination of products functioning well together in a production environment. Essentially, institution should select proven commercialized products to diminish technology risk.
• 5. Educating the User Community. As noted above, hospital data warehouse systems provide substantially more data than members of the user community have had historically, coupled with much greater ease of manipulation and analysis. However, many institutions do not receive full value from their investment in data warehouses because the user community fails to utilize many of the systems’ capabilities. There is a tendency to use the reporting and analytic tools to perform tasks previously performed, albeit in a much more efficient manner. Much of the functionality that seemed important when requirements were specified is not utilized.
  One of the many reasons for this unrealized functionality is that the user community receives “training” rather than education when new data warehouses go into production. The distinction is that all too often training addresses only the features and functions of the system–how to make it work. However, there is evidence that the user community will truly benefit from an education program that addresses how to make it work and what to do with the information. Such a program includes the basic concepts of business intelligence (applied to an healthcare system), data analysis techniques, and the application of analytics as well as features and functions training. In some cases, competency testing is a means of ensuring that all users have the capacity to effectively utilize the warehouse so that the power of the hospital data warehouse can be fully utilized It is ironic that in most major data warehouse projects only about 5% of a multi-million dollar budget is allocated to user education. HARKENDATA’s experience with healthcare systems mirrors observations from other industries that build and deploy data warehouses: the yield from a marginal dollar invested in educating users is much higher than that associated with more data elements, reports, and pure system features.
• 6. Investing in a Data Quality Program to Ensure Reporting and Analytic Integrity. The guiding axiom in data warehousing is that the reports and analytics generated by a hospital data warehouse cannot be any better than the data on which they are based. Virtually all data in institution data warehouses comes from operational systems (e.g., EMR, Lab, Pharmacy, etc.) that act as “feeders” into the data warehouse. While ETL (extract, transform, and load) software can make the transfer of data efficient, it generally does not guarantee the quality of data loaded.
  Too often, hospitals make the assumption that data from the feeder systems is absolutely “clean” – that all the editing has been done in those systems so that data with high integrity can be transferred to the warehouse with few additional quality controls. Yet, invariably it turns out that many data quality problems exist. The sources of these problems include but are not limited to insufficient data integrity and quality control in feeder systems, inconsistencies in data definitions across systems, and data gaps that limit aggregation and statistical analysis. This era of increased institutional accountability rooted in performance data underscores the need for data warehouse projects to include a data quality assessment process and, as part of an institution’s data quality processes, to attain sufficient data quality to ensure the integrity of the reporting and analytics that are generated by the system. As additional data sources are “fed” into the data warehouse the needs to address data quality expand exponentially (e.g.: how does the ETL tool handle duplicate data, incomplete data, etc).
• 7. Retaining a Highly Qualified Business Intelligence Integrator to Conduct a Joint Project. Two important conditions in most institution make it common and advantageous for hospitals to retain business intelligence (BI) integrator to execute hospital data warehouse projects. First, hospitals generally are not experts in building large scale healthcare data warehouses using contemporary tools. While a hospital’s IT organizations may be well staffed and competent, data warehouses are different than the types of transaction processing systems that support operations. Second, operating the warehouse and enhancing its capabilities is an ongoing process. To decrease cost and maximize control, hospital IT staff should take on these responsibilities over time and not be dependent on contractors. Undertaking data warehouse development projects as a joint team of hospital and contractor staff benefits a hospital by allowing its IT staff to confidently crest the learning curve over time, enabling them to assume full responsibility for ongoing operations and enhancements.
  There is a further logical implication of the team approach. Hospitals should select a business intelligence integrator that has executed similar projects as a means of ensuring greatest efficiency and least execution risk. From the outset, the contractor will have an excellent understanding of the problems to be encountered along the way and how to mitigate them, as well as how to best leverage the experiences and artifacts produced in other hospitals (See Critical Success Factor 9). A number of hospitals were early adopters of healthcare data warehouses, resulting in more than enough experienced firms to ensure a high level of competition in formal procurements. A hospital no longer needs to assume the risk of being a proving ground for an integrator that wants to break into the market, without having already completed high-quality data systems projects. While there are many good BI integrators and many good healthcare systems firms, the combination of a BI integrator who has built large scale healthcare data warehouses for hospitals yields the greatest value added.
• 8. Retaining a Business Intelligence Contractor on a Time and Materials Basis. The terms of a contract with a BI integrator establish the business relationship and the incentives and consequent behaviors of both parties. A common error that hospitals make is in prescribing a firm fixed price contract form. Firm fixed price contracts are desirable when purchasing things that are commodities or can be described with great specificity. The reality is that comprehensive hospital data warehouses do not fall into either category. There are important decisions made through the development process which affect what will be built, how it will be built and when it will be built. The firm fixed price contract creates a zero sum situation; hospitals seek as much as possible from the contractor, while the contractor fights hard to limit scope so as not to lose profit by performing more work than anticipated. It can become an adversarial relationship which deteriorates every time a “change order” must be negotiated. Ironically, the primary purpose of a fixed price contract – guaranteeing price certainty – is rarely achieved.
  The time and materials form is more conducive to a healthcare data warehouse project. It encourages a more cooperative environment, which is particularly important when the project is executed by a joint team. (See Critical Success Factor 7). It provides the hospital greater flexibility in modifying the scope and direction of the project based on informed decisions at key stages of the life-cycle (e.g., requirements definition, system architecture, proof-of-concept, etc). There is no evidence that it increases the ultimate cost of warehouse systems. Finally, time and materials is a business term that will attract the most highly qualified firms to compete for the contract.
• 9. Reconciling Hospital Uniqueness and the Ubiquity of Healthcare Data Warehouse Projects. The reality of healthcare data warehouses is that while there are some characteristics and needs that are unique to each hospital, most are the same across hospitals. The challenge is to meet hospital-specific needs while taking advantage of other hospitals’ efforts to reduce cost, timeframe, and risk. There are three ways to leverage the experience of other hospitals and it is desirable to consider the value of each in planning and executing the warehouse project. First, as noted above the successful use of specific products and architectural solutions by other hospitals is a valid indicator of commerciality and ability to control risk. Second, there may be artifacts from other hospitals that can be partially reused. For example, data testing strategies, data education materials, and potentially report templates can be reused or at least identified as quality exemplars. Third, the experience of other hospitals that are farther along in the process allows a hospital to anticipate, and address proactively project issues and program opportunities.
• 10. Pervasive Risk Management. As noted earlier, the track record of hospital data warehouse projects is mixed with successes and failures. Data warehousing systems are inherently risky with many opportunities for risk mitigation. It should be noted that the risks are political, budgetary, and organizational, not simply technical. Risk management must encompass all of those aspects of the project environment.

One important aspect of risk management is building formal risk management processes into every life-cycle methodology. This procedural approach presumes that if every step is followed risks will be systematically identified and mitigated. That is a desirable safety-net which can be applied to the development of any type of computer application. It is necessary, but not sufficient, to control cost as well as mitigate risk.

An equally important aspect is experience. Every type of application, by its nature, has certain inherent risks and an overall risk profile. The risk profile for business intelligence systems is different than that of large scale clinical systems, real time data acquisition systems, and large scale models and simulations. Further, the inherent risks related to hospital data warehouses are somewhat different than risks of other data warehouses. For example, there are specific issues related to data privacy, the definitions and metrics associated with Meaningful Use, the relationships between entities (e.g., patients, nurses, doctors, and hospital administrators) that must be represented in the data model, and portals and interfaces to support a very wide range of users and levels of sophistication. Therefore, there is exceptional value in anticipating the specific risks associated with healthcare data warehouse projects and the specific actions to be taken to mitigate those risks.

In summary, there is now substantial experience among hospitals building healthcare data warehouses such that critical success factors have become clear. In planning such projects, it is useful to ascertain the degree to which the factors which drive success are in place for your hospital or will be put in place in the early stages of development.