Healthcare Business Intelligence (HBI): Why an Enterprise Class solution when my EMR vendor delivers a BI Solution

There has been much discussion and much hype of late on healthcare organizations investing millions in growth for competitive strategies, e.g., optimum care delivery; developing a reliable financial baseline; employing rigorous business planning; and increasing market share. For today’s health care providers, however, the future is full of change and uncertainty.  The HITECH-driven road toward Meaningful Use of your EMR technology is going to be a bumpy ride, even though nobody yet knows how long that road is or exactly where it will take us. The sense is that it’s a road that must be traveled – at least while the economic incentives are favorable.

So now the focus of the discussion is on how to get information from data and the tools to mine the data stores.  The concern quickly morphs into a Healthcare Business Intelligence (HBI) discussion.  And yet, many of you will say, HBI, but is this just reporting, building dashboards and deploying a Portal?  Well, that really depends on what the Business Intelligence foundation is.  As “pay‐for‐performance” initiatives (such as those proposed by an increasing number of government and health authorities, have resulted in significant HBI investment) and Meaningful Use Stages continue to be defined, Application (clinical/EMR) vendor’s BI solutions are challenged to meet the Enterprise requirements.

Consider the current requirements for reporting, analyzing and trending quality and cost data which are increasingly supported by many fragmented systems.  Those that are knee deep in developing solutions to address the continuing and growing integration requirements have quickly realized the need for an Enterprise Data Repository or Enterprise Data Warehouse (EDW).  The “value add” outside of the platform and database for EDW must include a Data Model: both logical and physical to provide a proven methodology to integrate data across applications (subject areas) and a schema for delivering source data for the Enterprise’s analytical capabilities over “time”.

Enterprise BI versus Application BI

An “Enterprise” approach addresses disparate systems that need a flexible Extract Transform and Load (ETL) tool set and ability to manage Data Marts (with embedded Rules Engines) and expose the data to information Dashboards in a conceptual view of the integrated data (see Conceptual View of Integrated Data).  Application BI solutions present their “native” data (canned reports), but are challenged with other source system data (fragmented, independent, loosely coupled) sources that often deal with distinct data marts (aggregated data). 

Conceptual View of Integrated Data

 hbi

A Conceptual View of Integrated Data addresses the real world of healthcare.  Our “source systems” have very distinct and often very specific missions.  These missions are business driven, but were never intended to be shared or merged with other systems of the health organization.  Then came Meaningful Use, Clinical Outcome KPIs and the growing need for clinical analytics in combinations with operation improvement.  An “Integrated Data Store” in a growing concept in healthcare where we begin to leverage ETL tools to pull data from our Application systems and begin to open access to an Enterprise Data Warehouse.  The central idea is to have a single source of truth where all share a common Data Dictionary.  Yes, image a world where we all report the same FTE count.  However, our model is challenged when we begin to create “Data Marts”.  Yes, the data cubes that become the source files for our Executive Dashboards where all our KPIs are measures against our benchmarks and on-line alerts begin to ping our PDAs and automated workflows begin to fill in-boxes with “actionable” information.  All delivered as promised by our EMR vendor.

But wait, the “actionable data” is pointing to one of non-clinical systems (ERP, Scheduling, Recruiting, Revenue Cycle/Billing, SCM, Vendor Management, etc…).  Enterprise by definition means ALL the systems of the organization, not just the EMR applications.

There is a strong developing need within the healthcare industry to improve and expand quality of care analytics. Relevant Key Performance Indicators (KPIs) are sought and new predictive models are required to meet new care and competitive challenges.  Clinical and Payers are continuing to spend on analytic solutions and increase upon predictive capabilities.  The provider’s existing data sources (e.g., EMR, financial, GL, ERP, etc.) may be the origination of the data, but the Enterprise HBI solution is where the data integration will occur for further analyses across the enterprise.   Consider the following types of metrics that customers are requesting from the Enterprise HBI:

  • Achievement of Meaningful Use Administrative measures
  • Achievement of Meaningful Use Clinical Quality measures
  • Length of Stay (LOS)
  • Daily Census
  • Census by Diagnosis
  • A/R age in Patient Accounting
  • Provider Profitability ($$)
    • Contribution Margin by specialty, by product
  • Relative value unit (RVU) by physician, by specialty, by facility
  • Risk adjusted Case Mix Index
  • Inpatient Hospital Quality Measures
  • Accountable Care Metrics
  • Medical device utilization, by margin, by outcomes
  • ER re-admission rate, by service line, by specialty
  • Outcomes by provider, by specialty
  • ER admits, by channel  (e.g., walk-in, web-site, call center, etc)

Application BI

Most all EMR vendors deliver a solid BI solution set that meets almost all clinical reporting requirements for their set of modules that make of the “Application”.  The Application BI solution set on top of Application by definition.  But consider:

  • Application (EMR) BI solutions deliver predefined independent data marts to answer canned reports with a limit use reporting front ends (Enterprise Licenses must be negotiated)
  • Many data elements of information that exist in an integrated data warehouse are not in the application product (module) set that are key to enabling broader analysis of data, e.g.,
    • Patient geocoding and demographic based data.
    • Billing, General ledger (ERP)
    • Web Information
    • Historical Data
    • Accessibility to non Vendor tools, e.g., SAS, ODBC, SQL, Cognos, OBIEE
    • The Application BI is good for pre-defined points, but limited in scope for ad-hoc or across the Enterprise and all subject area analysis outside of the Application
    • Application BI tools are delivered with “limited use” licenses (e.g., Business Objects, Oracle DB, Informatica)
    • The size of the analytical repository, for the population most Providers need to analyze, is already beyond the capabilities of the delivered vendor’s analytical platforms (size and scalability are often after thoughts)
    • Often have scalability issues, e.g., typically have to split up independent data marts across multiple platforms
      • But Federated doesn’t often work. Cross region analysis on multiple platforms with multiple independent data stores has challenged many health systems
      • Lots of replication or users are limited to analysis of summary data and ad-hoc investigative analysis/reporting are often lost
  • Have fragmented data marts that often lead to a difficult or impossible data models to analyze and navigate
  • EMR Application modules are the source of data.  The canned reports are nice for certain things, but are quickly challenged by users as whose requirements go beyond what the Applications were designed to do

Enterprise BI

Enterprise solutions not only address Application front-end reporting requirements, but address the back-end infrastructure requirements as well addressing Data Models with pre-delivered Reporting/Analytics.  Enterprise Data Warehouse vendors deliver Enterprise class BI solutions that enable cross subject and any source system analysis in a single open ended framework, and support investigative query based tools. What distinguish an “Enterprise” class HBI is:

  • A scalable RDBMS
  • A repository for all data (any application and any data structure)
  • A delivered and leverage full ETL – Extract Transform & Load (Transformation being key here) and Integration (Toolset) – industry refers to this as Middleware
  • Performance
  • Rules Engine
  • Application agnostic Portal
  • Enterprise security requirements addressed
  • Workload management
  • Non-limited reporting, ETL, Integration, etc… licenses

Considerations (Enterprise Requirements)

A single HBI platform should be scalable to handle any size population and ad-hoc detail driven investigative analytics with ANY tool and:

  • Have an (optional) integrated logical and physical model that can accommodate not only clinical data, but other data sources to provide a much broader analytical capability (note that EPIC and Cerner are now quickly developing these to catch up to the Tier 1 BI vendors)
  • Have an integrated model and approach that can deliver analytics across many defined healthcare subject areas at the atomic level of detail
  • Have the ability to guarantee service level agreements for different applications on the same platform
  • Have the ability to incorporate the data from the legacy systems into an integrated model (ability to grow into the EMR source data as it is rolled out)
  • Have many areas of reporting that are enabled by adding integrated data to the data warehouse that are outside of clinical data
  • Have the ability to incorporate ANY data into the EMR data structures

Enterprise class BI solutions harkens the “buy versus build” argument.  It could take months/years to develop your own semantic model from scratch that is often required from Application BI solutions.  Use the prebuilt assets as an Enterprise class solution to guide and checkpoint your data reporting requirements.  Enterprise class HBI solutions eliminate much of the risk associated with implementing an Application data warehouse and allow for easy future growth.  Enterprise solutions now deliver:

  • Pre-built semantic data models to jump start access layer design and implementation
  • Are business friendly, flexible, & deliver easily reusable building blocks to assemble additional semantic data models for evolving data mining needs
  • Leverage best practices for cost effective access the power of the Enterprise RDBMS platform
0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *