Health care data-as-a-service A shopping list

Transcription

1 Health care data-as-a-service A shopping list

2 Contents Data-as-a-service architecture 4 Enterprise data services 5 Data integration services 6 Information delivery services 7 Information delivery services 8 Closed-loop use case 9 Conclusion 10 1

3 The health care provider industry is entering into its era of big data. This is on the heels of industries that have had to address the same challenges of exponentially growing data assets sourced from their websites, social networks, and global supply chains. The health care industry has been focused on the electronic health record journey as stimulated by HITECH Meaningful Use incentives. Add to the mix, ambulatory electronic medical record diffusion into our provider communities, health information exchanges, and the increasing availability of genomics and proteomics data. These emerging data sources are pushing health systems into the reality of having to manage lots and lots of data. Many health systems are coming to the realization that they do not have in place the required next-generation architectures to exploit their expanding data assets. Health care secondary data use cases are growing in complexity and are crossing domains that once were able to function in silos, but no longer. It is no longer about a financial decision support system where costs and revenue can be modeled and applied to product line analysis. We now want to integrate cost structure insights with supply chain insights with surgical outcome insights to negotiate a center of excellence contract for hip replacements. It is now about proving the value equation (Value = Safety and Outcomes / Cost) in the emerging reimbursement environment of value-based purchasing. It is now about comparative effectiveness both internally as well as with peers across the nation. It is now about clinical and translational research to deliver the bench-to-bedside vision through the integration of the data ecosystems of the clinical and research enterprises. The data architecture response to date by the industry has been a cumulative collection of hundreds of independent labors of love. Each department, each Accountable Care Organization (ACO) Pioneer contract, each clinical discipline, each research institute, each disease registry initiative has resulted in a localized investment. These hundreds of independent investments have been in the labor and technology to define, capture, integrate, store, and deliver data into the measures and analytics of the localized subject area of the project. It is also unfortunate to see how many business intelligence and enterprise data warehousing projects get waylaid by the singular pursuit of pretty dashboards, undoubtedly the fun part, which sponsors seek to justify any investments in data and analytics. Meanwhile, the hidden iceberg of health care data management, the hard part, in all its glorious complexity remains undermanaged. Given the current directions of data management disciplines, the cost of data, viewed collectively across the organization, may soon exceed the derived benefits of using the data. Health care Data-as-a-Service 2

4 There are two primary responses to harness the potential of health care big data. One response is to keep adding labor and local investments in an attempt to keep up with the demand for the capture and preparation of data for analytics. Labor comes in the form of more chart abstractors, more RN data specialists, more registry case report forms and data entry clerks, more data administrators, and more data analysts to be found in every facet of health care operations. Not to speak of the resources consumed where data capture and management are add-on duties to the primary functions of a clinician or other operations specialist. The second response is to shift the cost of data curve by investing in an enterprise data-as-a-service architecture. Define, capture, and manage data assets once at an enterprise level, and offer it up as a service to the many different use cases in a far more efficient manner. The premise is that investment in thoughtfully designed enterprise data architectures as a shareable resource can lower the onus and cost to the organization to satisfy its hundreds of secondary data use cases. This shift downward of the data cost curve is a direct result of several attributes. Constituencies can move quickly with their projects due to the relative simplicity of the data architecture to deliver shareable data artifacts a patient, an encounter, a lab result. If data consumers require a slightly different data structure or have local domain requirements, the cost of implementation is still dramatically reduced as they need only concentrate on the localized requirement, and not the larger shared enterprise definition of data representing health care operations and outcomes already accounted for as a service. Figure 1: Negative breakeven point of the cost of data Economies of scale Less is less. Less custom data extracts, less data abstraction resources, less inefficient data capture efforts, less database software licensing, less arguing about his data versus her data. Data consumers can focus on the use case at hand, and not the underlying data required to satisfy the use case, which is now a shareable resource, and the economies of scale achieved by managing data as an enterprise. Focus on quality As soon as data assets are managed with discipline and rigor as an enterprise, attention can be paid to defining, monitoring and improving the quality of those assets. Once there is an organizational implicit trust in the data, the endless wasted time and resources of unhealthy second-guessing, verifying, reconciling, and debating about different data sources can be reduced. It may never completely go away. It is even a positive behavior to have a healthy level of questioning and continuous verification of data quality as part of a data integrity discipline. 3

5 Data-as-a-service architecture There are many components to the future-state of health care big data management including data governance, data integrity, data storage innovations, information delivery architecture, and support services design. This discussion focuses on data services architecture. As health systems design and go to market for their enabling dataas- a-service technologies, what are the components and functional requirements they should seek from their potential solutions and services partners? An important consideration to the effective design of a data-as-a-service architecture is the ease with which it can be used to deliver data out to secondary data uses (the opposite of a transactional system, which is focused on design for getting data in for operational data uses). Data-as-a-service is the notion that data integration from operational source systems can happen once within a centralized enterprise place. This place, otherwise known as an enterprise data warehouse, can take on several different designs ranging from operational data stores, replicates, highly normalized star schemas, highly de-normalized atomic data stores, virtual federated data integration, and each variation and combination in between. Whatever the enterprise data warehouse design, there are several data services that should be acquired, designed, and implemented into next-generation data architectures. Figure 2: Versatile, scalable, and flexible data ecosystem for secondary data use cases Health care Data-as-a-Service 4

6 Enterprise data services As health systems design their data-as-a-service architectures, form must follow function, and therefore there are several design principles and architecture components that should be considered. These are categorized into Data Integration, Data Enhancement, and Information Delivery services. This discussion highlights the next-generation capabilities assuming the basics of data integration, storage, and management for secondary data use are a minimum threshold of functionality being designed and deployed. Also, it is recognized that Data-as-a-Service has related definitions of cloud-based on demand data techniques. We take a broader view of a service. It is not narrowly defined as SOA and cloud-based only techniques of delivering data to a use case. A monthly spreadsheet extract that is sent via File Transfer Protocol (FTP) to your Core Measures vendor can be viewed as a data service too. 5

7 Data integration services Next-generation architectures will likely consume data from a wide variety of new sources, and in turn deliver information downstream to a wide variety of new targets. The need remains to reconcile disparate meanings of operational data across the enterprise into a new agile information resource designed explicitly for secondary data uses. The importing of flat files pushed out of scores of operational information systems may not be sufficient looking ahead to the era of big data. Next-generation architectures should facilitate the following: Inbound adaptors Next-generation data architectures will likely understand the data ecosystem of prevalent health care operational environments. The days of custom designing data integration out of very complex third party environments is not sustainable in the era of big data. Adaptors will be increasingly packaged and made available to health systems so that operational EHR and revenue cycle data can be moved and transformed into health care secondary data use models out of the box. The same has already been expected for the packaged adaptors to industry agnostic solutions. Message consumption In order to achieve near real-time data movement and actionable insights, next-generation architectures will likely consume operational HL7 and X12 message streams and XML packages, parse them, and create persistent analytical data environments from them. With these next-generation capabilities, in addition to the many minimal requirement data integration capabilities, data can now be staged and removed from the operational environment and is ready to be enhanced for secondary data uses. Change data capture In order to achieve both near real-time data integration and reduce the batch sizes of data to be processed, architecture will require change data capture services. This involves detecting changes in operational data environments through techniques such as accessing database management system logs. Advanced solutions will have native access capabilities to all the prevailing database management systems (i.e., Caché, DB2, SQL- Server, Oracle, SAS, Sybase ASE). Health care Data-as-a-Service 6

8 Information delivery services Once data is moved out of the operational data environments, several specific capabilities are now available that are both industry agnostic, but also health care specific in nature. Again, there are several capabilities that are simply deemed minimum requirements such as metadata management, data profiling, and transformation, and load capabilities. Business rules engine Architecture will require a common enterprise-wide rules definition and access engine. The term rule is used at the highest conceptual level as rules should be applied to different scenarios. Health systems will likely seek as an example to define their data quality rules that are health care and quality measures aware. Health systems will likely also seek to define complex event processing rules (e.g., New Diabetic Patient event) and apply them to inbound data. First generation architectures that had each of these in separate silo architectures, if at all, are not sustainable in the era of big data as the sheer number of shared business rules and the use cases that seek to access them exponentially grow. Terminology services The language of health care operations and therefore the data representing it needs to be exposed as a service. A distinctly health care specific capability is needed to define, map and manage terminology, hierarchy, ontology, and semantic networks for prevalent medical vocabulary systems such as SNOMED CT, ICD-9, ICD-10, CPT, and LOINC in addition to any desired local terminologies. Serving as the enterprise linguistic interpreter for secondary data use, this service can allow, for example, the reconciliation of problem lists sourced by three different ambulatory EMRs, with those from the acute care EHR, and those recorded in a chronic care disease registry. Natural language processing The capability to identify medical concepts embedded in the free-form narrative of clinical and administrative documentation. Then to translate the identified concepts into a controlled medical vocabulary system of choice within the terminology service described above. This is the pragmatic recognition that clinical and operational documentation will likely always have a degree of narrative in addition to controlled medical vocabularies embedded in structured clinical documentation. 7

9 Information delivery services The term information is used purposefully in that we have taken the raw ingredients of data, and transformed them through integration and enhancement services into information; into assets poised to deliver actionable insights to decision makers. Actions engine Building upon the business rules engine described above, this service can generate actions based on the satisfied business rules as data moves through the environment. Such actions include a database / data mart update, or generation of a message pushed to another information system for ingestion, a mobile device alert, or conditional changing the value of a data element. Enterprise measures catalog Much of what health systems are seeking to meet the demand for is the measurement of performance. Core measures, Meaningful Use, executive dashboards, benchmarking collaboratives, and a dozen other internal and external activities that require the delivery of measures across clinical, financial, and operational domains. The future data architecture can provide facilities to define and manage corporate measures in a central shareable service environment. This includes the definition of their numerators, the denominators, inclusion criteria, and exclusion criteria. It includes the tools used by measure analysts and data stewards to maintain the catalog of undoubtedly hundreds of measures in use by the typical health system. The final mile of the architecture is to then instantiate a performance measure to the underlying data model of the enterprise data warehouse so that the measure can be calculated as a service. The calculated measure and/or the raw underlying data records can be delivered to multiple consumers of a measure a dashboard, a benchmarking outbound interface, an analytical application with consistency and efficiency. Outbound adaptors Bringing us full circle to the value proposition of data-asaservice architectures is to reduce the hundreds of labors of love duplicated, isolated, fragmented data marts throughout health system operations. Next-generation architectures can allow for the definition of outbound data channels (i.e., a file, a message, a data set, a measure) of now integrated, transformed, and enhanced data. Furthermore, adaptors to prevalent consumers of health care data will likely be increasingly pre-packaged, similar to how manufacturing and retail industries have packaged data movement into and out of ERP environments. Health systems will seek adaptors to feed MedVentive disease registries, Advisory Board analytical solutions such as Crimson, TJC / Oryx Core Measures platforms, Meaningful Use submissions, i2b2 clinical research repositories, and MGMA Anceta physician practice analytics, to name several examples. Health care Data-as-a-Service 8

10 Closed-loop use case To highlight the potential of data-as-a-service architectures, let us follow an example use case. A primary care physician is seeking to manage their diabetes patient population. In this chronic care management use case, the data architecture should unlock data from EHRs through an inbound adaptor to the very popular, fill in the blank, acute care and ambulatory EHR solution. The data is enhanced by reconciling the HbA1C lab test definitions and results using terminology services. The data is further enhanced by translating the History & Physical documentation into SNOMED vocabulary. Observations of diabetes are discovered through the business rules engine looking for both three consecutive HbA1C results > 9 and/or an H&P observation of diabetes. These rules are satisfied and trigger an outbound adaptor to the diabetes registry solution as a daily SQL Server data set consumed by the registry. The registry does its magic applying risk stratification, cost prediction, readmission prediction, and severity segmentation algorithms to the data. The data-as-a-service architecture has a subscription rule that tells it to query the registry database every 3 hours and seek any records with new or changed risk scores. This data is processed and stored back in the enterprise data architecture which in turn satisfies another business rule new risk score event to send HL7 messages containing health maintenance triggers and supporting data to the ambulatory EMR of the primary care physicians on record via a health information exchange (HIE) architecture. The EMR takes over and the flagged diabetes patients show up in standard health maintenance reports or physician requested queries so that they can take clinical action. This closed-loop movement of data and insights is a hall mark of data-as-a-service architectures. From a user experience perspective, the clinical team does not need to go to the disease registry solution to run a report and manage patients, and then back to their EMR to manage the same patients. Each information system serves its purpose-built function; data-as-a-service architecture enables the flow of data and insights between them on demand. From a data value-chain perspective, data is data, and has value for operational, tactical, and strategic purposes. Let us at least lower the barriers, if not completely remove them, between the decision making process divides. 9

11 Conclusion Health systems are seeking to prepare their data management environments for the era of big data. A holistic program and future-state roadmap should include advancing clinical informatics, data governance, data integrity, information delivery, and data management disciplines, services, and technologies. Through more effective data capture, management, and multi-channel delivery of data assets as a shareable enterprise service to the many secondary data use cases, health systems can seek to bend the cost of data trajectory. ConvergeHEALTH has assisted many of our clients to strategize, create roadmaps, design future-state data architectures, and go to market to source enabling technologies. In summary, as health systems consider the design of their next-generation data architectures, Figure 3: Bending the cost of data curve health care organizations should consider pushing the expectations of the solutions and services of their technology partners. Specific architectural components that should be considered for data architectures, today and into the future, include the following shopping list: Service oriented architecture (SOA) layer Multi-channel consumption of data files, messages, change data capture Multi-channel delivery of data files, messages, APIs, subscription services, FTP drops, alerts Terminology and ontology services to normalize the language of health care Natural Language Processing (NLP) services to unlock the insights embedded in clinical narrative Business rules engine across clinical, financial, and administrative logic Inbound and outbound adaptors to prevalent health care information technology solutions Enterprise measures definition, management, and data instantiation engine Health care Data-as-a-Service 10

12 About the Author Jason Oliveira is the Specialist Leader of Health System Consulting at ConvergeHEALTH by Deloitte. With over 27 years of experience working with and advising the leaders of health care organizations, Jason has dedicated his practice to the strategies, roadmaps, and architecture designs of health care business intelligence and data warehousing. Jason can be reached at: or This publication contains general information only and is based on the experiences and research of Deloitte practitioners. Deloitte is not, by means of this publication, rendering business, financial, investment, or other professional advice or services. This publication is not a substitute for such professional advice or services, nor should it be used as a basis for any decision or action that may affect your business. Before making any decision or taking any action that may affect your business, you should consult a qualified professional advisor. Deloitte, its affiliates, and related entities shall not be responsible for any loss sustained by any person who relies on this publication. About ConvergeHEALTH by Deloitte ConvergeHEALTH brings powerful, demonstrated analytics platforms and data models from Recombinant by Deloitte, advanced proprietary and open source analytics, content and benchmarks through collaboration with industry leaders and deep experiences from Deloitte s Life Sciences and Health Care consulting practice to help our clients survive and thrive in the new paradigm of value-based, personalized medicine. For more information, visit About Deloitte Deloitte refers to one or more of Deloitte Touche Tohmatsu Limited, a UK private company limited by guarantee, and its network of member firms, each of which is a legally separate and independent entity. Please see for a detailed description of the legal structure of Deloitte Touche Tohmatsu Limited and its member firms. Please see for a detailed description of the legal structure of Deloitte LLP and its subsidiaries. Certain services may not be available to attest clients under the rules and regulations of public accounting. Copyright 2014 Deloitte Development LLC. All rights reserved. Member of Deloitte Touche Tohmatsu Limited 11