The Trusted Guide to Marketing Thought Leadership

The Role of Centralization In Building the NHIN


mThink Knowledge's picture

mThink Knowledge - Posted on 13 November 2005

Printer-friendly versionSend to friend
Authored by: 
Matthew Quinn;
PDF File: 
Teradata
Adopting a centralized approach to building their data infrastructure provides inherent benefits ateach level of the NHIN.

Centralizing data has been a key enabler for leading retailers, manufacturers and financial services companies to become “game changers” in their markets. Taking a centralized approach to their enterprise data supports the complex integration, data quality and decision-support needs of leading businesses like Bank of America, Kaiser Permanente, 3M, SBC, Wal-Mart and Harrah’s Casino.With a centralized approach, it’s all about getting the data right. From this foundation, thousands of users in their extended enterprise get their answers every day to questions on profitability, supply chain analytics and utilization.

The centralized approach has been implemented by many of the most admired organizations in and outside of healthcare because, in comparison to distributed approaches, it delivers the most business value, highest performance, most flexibility and lowest total cost of ownership (TOC) at the lowest risk. By building a flexible structure that contains all of the data at the detail-level from the beginning, the enterprise will be able to address new business needs as they are identified, without having to compromise or restructure the underlying data. As needs change and evolve, hierarchies can be easily changed without expensive rework of the foundation. Focusing on the data provides the starting point for a solution that is incremental, manageable and simplifies the enterprise rather than adding complexity to it.

Indeed, key benefits of employing a centralized approach include:

  • Improved flexibility and lower TCO in integrating and maintaining disparate systems;
  • Expanded analytical capabilities and data quality; and
  • Improved security.

But the data for the entire National Health Information Network (NHIN) will most likely not be stored and accessed from a single, national, centralized data warehouse. While a centralized approach is technically and politically feasible for Fortune 100 corporations (and other nations’ health information networks), it is technically but probably not politically feasible to have a single, centralized data warehouse for the United States.

Centralization, however, is both beneficial and — potentially — politically feasible at every level of the building blocks of the NHIN. Public, private and military health systems, regional health information organizations (RHIOs), public and private research and surveillance agencies, as well as federal- and state-level healthcare financing organizations would all benefit from taking a centralized approach with their data.

Organizations comprising the building blocks of the NHIN should seek to centralize to the highest level politically feasible. Because of the inherent benefits of taking a centralized approach (and the inherent limitations of taking a decentralized one), organizations at all levels of the NHIN should first seek to centralize data. In some instances, gaining acceptance of all involved stakeholders will not be possible. These organizations — by taking a decentralized approach — may choose to sacrifice capability, flexibility and cost of ownership for political expediency.

Defining the Centralized Approach

The centralized or enterprise data warehouse approach is characterized by a single, enterprise-level store of atomic-level detail data from all relevant source systems, using a normalized data model that allows for ad hoc discovery and drill-down analysis by multiple user groups.

The centralized approach can scale linearly to serve as the single, unified data infrastructure to support local, regional, organizational or even national interoperability and “single version of the enterprise” analysis.

Components of the Centralized Topology

The components of this topology include (see Figure 1):

  • Transaction Systems and Data are the “feeder” systems that provide data to the warehouse. In the context of the health system enterprise, these systems could include inpatient and outpatient EHR systems and the various enterprise and departmental clinical and administrative legacy “transaction” systems. In the context of a local or regional cooperative or RHIO, the feeder systems would be the participating organizations’ EHR systems.
  • Data Transformation consists of using industry-standard ETL (extract, transfer, load) tools to cleanse and move data from the transactional systems to the data warehouse. Common ETL tools include Informatica and Ascential.
  • Data Warehouse: The heart of performance and scalability for the enterprise architecture is a massively parallel processing database engine. Better performance and linear scalability result from unconditional parallelism. The reason is the parallel database will split apart each SQL query spreading the workload across all of the units of parallelism available to it, thereby balancing the work of all the system resources. In order to offset these differences, conditional parallel databases will do a number of performance-enhancing tasks, including partitioning large tables, providing hints, reorganizing the data, de-normalizing the schema and distributing data across multiple database servers. A decentralized approach builds boundaries around the adaptability of the system, and causes the development and maintenance costs of the system to increase considerably.
  • Normalized Logical Data Model: A normalized logical data model (LDM) is a blueprint that maps healthcare business processes and functions. Operational systems throughout the enterprise are mapped to the LDM and feed the data warehouse directly. Because a normalized model maps business processes and functions — and not legacy systems — it is application agnostic, able to work with any or all of an enterprise’s applications.

Defining the Decentralized Approach

In contrast to the centralized approach, the decentralized approach maintains multiple, duplicate physical versions of the data in an enterprise. Typically decentralized architectures are built from the bottom up, bring together the physical data from the enterprise’s source systems in a central hub and break the data into “marts” or subsets of the enterprise data to meet the analytic needs of various users.

Many legacy EHR systems employ a distributed or “hub and spoke” topology. This approach takes significant time and cost to implement and maintain, is inflexible in supporting system and user changes and — inherently — leads to limitations in analytical capabilities and complicates data quality issues. Figure 2 illustrates a typical distributed or hub-and-spoke topology.

Centralized Approach Benefits

Achieving the overarching goals of the Office of the Health Information Technology Coordinator — informing clinical practice, interconnecting physicians, personalizing care and improving population health — will require more than just being able to transact health information between and among healthcare stakeholders.

At all levels of the NHIN, achieving these goals will require the ability to flexibly, securely and cost-effectively bring together disparate systems, to gain insight from unconstrained analysis of massive amounts of atomic-level structured and unstructured information, and to activate this information in improving the safety, cost and efficiency of care.

The topology that an organization chooses will directly impact the cost, flexibility, analytic capabilities and even capacity to achieve these goals. Some of the benefits of choosing a centralized approach and some of the inherent limitations of choosing a decentralized one include:

Reduced Time, Effort and Cost in Integrating And Maintaining Disparate Systems

Unlike approaches that require building and maintaining interfaces between and among all of the applications in an enterprise, the centralized approach integrates disparate systems at the normalized logical data model level. This drastically simplifies the architecture, extends the life of legacy applications and supports the use of a variety of best-of-breed applications in the enterprise. Further, because integration takes place at the data model (versus between and among many applications), application changes do not typically require complex and expensive re-architecture of the system (and construction/changes to interfaces) to support them.

For a health system, this means that supporting (and making interoperable) the various enterprise and departmental systems (used by the various stakeholders in the system) that comprise the EHR is as easy as mapping each of these systems to the LDM. This is much quicker, simpler, less disruptive and less costly than mandating a single system/set of systems for enterprise use and/or establishing and maintaining/updating strict data standards among all stakeholders. Replacing legacy systems can occur at the pace of the organization’s requirements and need not occur as part of a “big bang” up-front implementation.

Two key criteria for selecting a data warehousing approach at all levels in the NHIN will be the price performance, flexibility and TCO of that technology. The centralized approach has proven to be superior in both of these regards.

Each arrow on the topology diagrams in Figures 1 and 2 represent an IT process that must be implemented and maintained for the lifetime of the system. Each arrow represents dedicated staff, cost and risk. There are dramatically fewer arrows in the centralized topology than the distributed or hub-and-spoke one. Further, the centralized topology does not have arrows between and among the various feeder transaction systems. This means that, unlike in the hub-and-spoke model, replacing a legacy system or adding a new system does not impact each of the complex interconnection of interfaces in the hub and spoke.

In addition, the centralized topology eliminates all of the cost associated with the data marts and operational data stores in a hub-and-spoke topology — a huge component of ongoing IT costs.

Expanded Analytical Capabilities

Organizations collect and aggregate data to gain insight and achieve business value. The role of the enterprise intelligence designer is to minimize boundaries in achieving this goal. While the IT costs of choosing the wrong infrastructure can be great, the greatest cost of implementing the wrong architecture will be the opportunity costs that result from these boundaries. As much as 95 percent of future needs may be undefined early on. The key is continual expansion and flexibility. By building a flexible structure that contains all of the data at the detaillevel from the beginning, the enterprise will be able to address new business needs as they are identified, without having to compromise or restructure the database. As needs change and evolve, hierarchies can be easily changed without expensive rework of the foundation.

The ultimate goal for informing clinical practice is to provide the full breadth and depth of insight of the medical community in a format that is useful at the point of care and for deeper clinical decision support. This requires a centralized topology and data warehouse technology that supports both horizontal and vertical views and the entire continuum (transactional, tactical and strategic DSS) of queries. OLTP or transaction-based systems (and associated distributed topologies) alone cannot support concurrent insight on these three types of queries.

Activating the Data

Figure 3 describes the evolution of data warehousing toward the goal of active data warehousing (ADW), where event-based triggering takes hold and the data warehouse takes on a mission-critical role in automating decisions and pushing insight to the frontlines of an organization. Two prerequisites for evolution toward ADW are having a central store of enterprise detail-level data and data warehousing technology that can support the extreme performance, scalability, availability and data freshness needs of this type of workload. Adopting a decentralized approach by extracting data from the central store limits this evolution and the ability of any database technology, no matter how robust, to evolve to this state.

Summarization, or making only a portion of enterprise data available at above the health system level, also limits the ability to accurately gain insight from data. Think of a bank producing a monthly bank statement that records checking account activity. If it summarizes the total amount of deposits and withdrawals, determining if a certain check had cleared would not be possible. That would require detail data.

Improved Security

A centralized data warehouse is much simpler to secure than dozens of heterogeneous data marts. Indeed many industry analysts and leading healthcare and financial services organizations agree that an enterprise data warehouse is the preferred implementation model, and among that model's many virtues is the fact that a centralized data warehouse's security is simpler and less expensive to manage, while providing higher levels of security.

Security and privacy are also major drivers of simplification. Imagine proving the implementation of a privacy policy to auditors when customer information is scattered among a dozen or more separate systems in a distributed topology. Data is dispersed, access control is difficult to prove and accuracy of privacy-related controls is difficult to ensure as the data is transported and transformed. Privacy and security policies are much easier to implement, manage, log and audit when there is only one copy of the data and one physical place it is accessed.

Where in the NHIN Does Centralization Make Sense?

As we have described, taking a centralized approach to building the data infrastructure provides cost and capability advantages over alternate approaches. Consequently organizations at all levels of the NHIN — from the health system on up should seek to take a centralized approach wherever politically feasible. Centralizing data requires a greater level of trust and cooperation among the stakeholders in an organization than a structure in which organizations only share an extracted portion of their data. Gaining this level of cooperation is simplest in centrally led organizations (in healthcare and otherwise) and most difficult in settings where intense competition or distrust exists among stakeholders. Organizations must weigh the benefits of taking a centralized approach against the ability of the stakeholders in the organization to cooperate and the cost and capability tradeoffs of a decentralized approach against the political expediency of not physically sharing data.

Commercial Health Systems and Networks

The centralized approach is both beneficial and politically feasible for the nation’s for-profit and not-for-profit health systems. Even for national-scale organizations like Kaiser Permanente and HCA, despite the regional or local orientation of the stakeholders in these organizations, if the leadership of an organization seeks to gain both universal EHR adoption and a “single view of the enterprise” among the various institutions, clinics and individual physician practices in the organization, then the centralized topology would be both politically and technically feasible.

ASP EHR Vendors

A growing trend among EHR vendors is to outsource hosting of EHRs for multiple providers to a single application service provider, or ASP. Centralizing the data for all clients that such a vendor serves simplifies system management and interoperability and provides the capacity for collaborative analytics not possible with physically separate data structures.

Federal Health and Military Health System Interoperability

The centralized approach would meet the goal of coordinating and making interoperable the various federal health information systems (e.g., VA, MHA, IHS). The hierarchical leadership structures of federal and military health systems are conducive to the cooperation required for physical data sharing. While EHR adoption among these organizations is far greater than among non-governmental institutions, the systems, standards, metadata and progress in implementing these systems varies greatly. The effort that would be required to link all of these systems using interfaces would truly be monumental (to mention nothing of the effort required to maintain this infrastructure). Centralizing the data for each of these systems would speed enterprise interoperability and greatly expand analytic capabilities.

Local, Regional and Rural Health Cooperatives and RHIOs

The building blocks of the NHIN will be local, regional and state level cooperatives and RHIOs. These organizations will be composed of the payers, providers, purchasers and others that share the goal of improving the quality, safety and efficiency of care delivered in a region. If a close enough level of collaboration and trust exists among the various stakeholders in a community or region such that they feel secure in physically storing their clinical data together (while, of course, providing organization and role-based access control measures to the data), they can concurrently achieve EHR adoption and interoperability. While several state RHIOs have announced that they will be pursuing a centralized approach in building their data infrastructures, this approach might be particularly attractive for a group of, for example, underserved or rural healthcare organizations that seek to gain the benefits of EHR adoption while sharing the cost of implementation, maintenance and interoperability with other organizations.

Research and Surveillance Agencies

Implementing a centralized approach would help achieve the goal of unifying public health, research and surveillance architectures. The centralized approach is unsurpassed in supporting integration of massive amounts of data from multiple systems into a “single version of the enterprise” and pushing analysis of that data out to the appropriate stakeholders in time to take action (activating the data.) Having detail-level data would allow the optimal use of neural network and other predictive modeling technology to improve the accuracy of analysis and reduce the occurrence of “false positives” inherent in summary data.

Moving away from a centralized model for unifying public health infrastructures introduces data timeliness and quality issues. As in business, this speed to insight is especially important in the context of public health, where hours can mean lives.

Studies by Rand and others have found the dissemination and practice of best-available evidence is woefully slow and inconsistent. A solution to the goal of accelerating research and dissemination of evidence should thus address the dual issues of gaining insight from data and integrating that insight into the workflows of clinicians in the field.

Centralized warehouses designed for answering any question at any time without the associated time, effort and cost of replicating and analyzing data outside of the warehouse (i.e., building a dedicated data mart), free clinical researchers from technological limitations in gaining insight from their data. And having detailed — atomic level — data available for analysis does not force researchers to limit the scope of their data and analysis before they begin (as is common in the decentralized approaches that advocate separate data subsets or “marts” for reporting and analysis).

Conclusion

While centralization of the entire nation’s healthcare data is technically feasible, the political feasibility of such an architecture is probably unlikely. Instead the stakeholders that compose the “building blocks” of the NHIN — organizations at the health system; local, regional and state cooperative; RHIO; and research and surveillance agency levels — should consider and adopt a centralized approach except where this approach is not politically possible.

As many of the world’s largest and most prestigious companies — inside and outside of healthcare — have proven, the benefits that they have realized by taking a centralized approach would not have been possible without having a single version of their enterprise data.

About the Author
Title: 
Healthcare Program Manager
Teradata
Matthew Quinn is the healthcare program manager for Teradata, the data warehousing division of NCR. He is a graduate of the United StatesMilitary Academy at West Point and holds an M.B.A. from Colorado State University.

Sponsors