Developing an Adaptable All Payer Database

KPMG GOVERNMENT INSTITUTE
Developing
an adaptable
and sustainable
All Payer
Database (APD)
January 2015
kpmginstitutes.com/
government-institute

Developing an adaptable and sustainable All Payer Database (APD)
Contents
Why states should invest in and build an APD 1
How to develop sustainable and flexible APDs 4
APD analytic and reporting capabilities 4
What does a sustainable APD enterprise architecture look like? 6
APD implementation challenges 10
Final thoughts and next steps 14
Appendix: APD system architecture components 16
© 2015 KPMG LLP, a Delaware limited liability partnership and the U.S. member firm of the KPMG network of independent member firms
affiliated with KPMG International Cooperative (“KPMG International”), a Swiss entity. All rights reserved. Printed in the U.S.A. The KPMG
name, logo and “cutting through complexity” are registered trademarks or trademarks of KPMG International. NDPPS 312121

Developing an adaptable and sustainable All Payer Database (APD) 1
Why states should invest in and build an APD
States can save healthcare dollars, while promoting quality outcomes, by designing, building,
and correctly utilizing APDs.
Medicaid costs continue to rise and are a primary long-term cost
driver for states.1
At the same time, there is an acute awareness
that the quality outcomes that states and their citizens get for their
dollars are less than optimal. To impact rising costs and realize
quality improvements, transparency of costs and outcomes is
essential. Without insight in whether value is high or not, providers,
payers, and policy makers are limited in their ability to control costs,
and patients cannot make fully informed choices.
For these reasons, the KPMG Government Institute, in
conjunction with KPMG’s Global Human & Social Services Center
of Excellence conducted research into the use of an All Payer
Database, or APD, as a tool to support healthcare cost savings and
quality outcomes. We augmented our research with extensive
experience working with state healthcare systems and APDs.
This white paper addresses the why, what, and how of APDs and
provides our perspectives on next steps for states to consider in
moving to an APD solution.
APDs have emerged as a strategic asset for states to leverage to
help understand and define their options for addressing healthcare
cost and quality challenges. An APD is a structured repository of
healthcare data sourced from, amongst others, commercial and
public payers. This data includes claims information originating
from patient encounters with medical, pharmacy, and dental
providers; health plan membership; patient demographics; provider
profiles; and health plan information. The promise of an APD is that
it will eventually also include medical record data (see adjacent text
box); as a foundation, however, most APDs start with claims.
Currently, states have limited insight to trends in utilization, costs,
or outcomes in the Medicare and commercial populations. Yet their
Medicaid expenditures, for example, are significantly affected
by the population of patients who are also eligible for Medicare
(the “duals,” who are responsible for approximately 40 percent of
total Medicaid expenditures).2
In addition, increasing numbers
of individuals move between the Medicaid population and the
commercially insured population, creating gaps in the longitudinal
data when these multiple sources are not available.
APDs address some of these challenges, allowing states to
identify the pain points in the current healthcare systems and
enabling them to take effective action. For instance, an APD
gives the state the ability to determine the patient population that
keeps using the emergency department for nonacute/nonurgent
care across commercial and public payers. Likewise, it can help
determine cross-payer costs and quality deficits due to patients’
medication reconciliation issues. APDs can also enable the state to
obtain insight in cost-shifting between payment flows—whether
between Medicaid and Medicare (in the case of readmissions from
skilled nursing facilities (SNFs), for example) or between Medicaid
and the health exchange plans.
1 “The Fiscal Survey of States Spring 2014 – An Update of State Fiscal Conditions,”
National Association of State Budget Officers, June 12, 2014,
http://www.nasbo.org/sites/default/files/NASBOSpring2014FiscalSurvey(security).pdf
2 “Financial Models to Support State Efforts to Integrate Care for Medicare-Medicaid Enrollees,”
Centers for Medicare Medicaid Services, July 8, 2011,
http://downloads.cms.gov/cmsgov/archived-downloads/SMDL/downloads/Financial_Models_
Supporting_Integrated_Care_SMD.pdf
APDs, not APCDs
Until now, the majority of publications to date have referenced
All Payer Claims Databases (APCDs) and not APDs.
There has been a recent shift in the vernacular because
states are recognizing that the assets they are developing
will eventually include data other than just claims.
There are data sets available for states to leverage and
integrate with their existing claims such as population
demographics, pharmaceutical data (clinical trials,
research studies), retail pharmacy data, and provider
electronic medical record data.
In this light, building a data warehouse geared towards
storing only claims data can become severely limiting.
Therefore, we will use APD throughout this paper.
It is important to start with a realistic goal—integration
of claims data should be phase one. The value of a data
source with state healthcare data and health plan claims
data is significant—using it well will meet the short-term
needs of a broad stakeholder group.
Anticipating a broader range of data requirements should
be part of the planning process early on.

2 Developing an adaptable and sustainable All Payer Database (APD)
None of these examples require particularly complicated analytics;
all of these can be performed on the basis of already existing
claims data. Over time, though, drawing on broader sets of
data and more powerful analytics, APDs could help predict cost
fluctuations and quality risks and could become a true source of
information to inform patients’ choices for the highest value care.
KPMG LLP (KPMG) has seen a similar maturation process in other
industries over the past two decades. Healthcare is in the earliest
stages of analytic maturity. From this point forward, as depicted in
the figure above, states as well as other payers and care providers
should expect to continue to invest in and improve their analytic
capabilities and therefore, the value of this asset.
With an APD as the foundation, there is a clear path to achieving
states’ objectives and goals.
• States can create population-based price and outcomes
transparency.
• States can critically assess the needs for delivery system
transformation based on outcomes realized (costs and quality).
• States can critically assess current payment
methodologies and further multipayer payment reform to
stimulate value-based contracting.
Currently, a small number of APDs have been deployed with
varying degrees of success. Generally, the challenges in
developing and maintaining a sustainable APD have been
underestimated.3
Most importantly, many users of current
APDs have yet to see the full potential of this powerful tool.
Stakeholder needs and use cases are built into proposals for
funding, including objectives like information transparency,
cost comparisons, disease prevalence reporting, and other
population reporting needs. But most current APDs are
automated report creation tools that use data previously
unavailable to the state. This has value, but the inability to
perform (or high cost associated with) dynamic, ad hoc data
analysis and exploration is significant. The absence of analytic
flexibility is the largest gap KPMG has identified that needs
to be closed in the next iteration of APD design.
KPMG has developed an approach for meeting the needs and
overcoming the challenges of the early adopters.4
APD solutions
must evolve from simple automated reporting of multipayer
claims data to an on-demand, ad hoc analytics and data discovery
tool. In addition, APDs should be capable of including the full
breadth of patient-treatment-and provider-related structured and
unstructured data—from traditional data sources as well as new
and emerging sources such as social media data. For example,
“listening” to consumers discussing their experiences with
providers can be a significant aspect of a system monitoring
healthcare system risks.
States are in a unique position to benefit from a converging
healthcare industry. Conceptually, “hoarding your own
data” should no longer be seen as a competitive advantage.
The primary stakeholders in the industry—providers, health
Analytically successful organizations take an iterative approach
that leads to advanced analytics over time
Analytic Competent
Analytic Expansion
Analytic Excellence
LOW
ComplexityHIGH
Business Value HIGH
• Deliver a single source of the truth
for information
• Provide accurate and timely
retrospective indicators
• Enable ad hoc reporting/drilldown
capabilities
• Define processes to enable
expansion
• Integrate additional data sources
• Expand content offering – KPIs/
drill-downs
• Increase user community
• Leverage additional delivery
channels
• Incorporate guided/conditional
navigation
• Complete compliment of
content areas
• Add unstructured, external data
• Predictive modeling
• Application of data science
• Provide cross-functional
indicators/reporting
• Well-defined analytic processes
• Mobile capability
• Broaden audience
3
Kardish, Chris. “More States Create All-Payer Claims Databases,” Governing, February 2014,
http://www.governing.com/topics/health-human-services/gov-states-serious-about-health-data.html
4
“Staying Power – Success stories in global healthcare,” KPMG Global Healthcare, 2014,
http://kpmg.com/Global/en/IssuesAndInsights/ArticlesPublications/what-works/creating-new-value-
with-patients/Documents/staying-power-success-stories-v1.pdf

plans, life sciences, and government entities—all acknowledge
that there is greater value in sharing data across organizational
boundaries. Providers can share electronic medical records,
health plans can share their claims data, states can share
their collective discharge summaries, and third-party health
intelligence providers have huge amounts of healthcare-related
data. Above all, the value for increased quality of patient
care is evident. All of these players can benefit from an
integrated data set, independent of their own competitive
advantages in the marketplace.5
Unfortunately, while the merits of this argument are clear,
states have had difficulty getting health plans to participate,
especially early on. We continue to see a reluctance from
stakeholders to embrace transparency and release price
information.6
Many states have enacted legislation that only
stipulates voluntary data sharing agreements with the state.7
This has been a costly obstacle to overcome. Several states
had trouble obtaining federal state innovation models grants
because they could not meet grant requirements; for example,
the qualification threshold for proving that all public health plan
data and commercial health plan data can be integrated was high.
A leading practice is for states to enter into data-sharing
requirements—and if necessary stipulated in legislation—to
get APD initiatives started, beginning with claims data first.
5
“Collecting Health Data: All-Payer Claims Database,” National Conference of State Legislatures,
October 2013. http://www.ncsl.org/portals/1/documents/health/ALL-PAYER_CLAIMS_DB-2010.pdf
6
Millman, Jason. “A reminder that not everyone loves more transparency for health-care prices,”
Washington Post, June 2014, http://www.washingtonpost.com/blogs/wonkblog/wp/2014/06/23/a-
reminder-that-not-everyone-loves-more-transparency-for-health-care-prices/
7
“Local Lessons from National APCD Efforts,” Freedman Healthcare LLC. September 2014,
http://wahealthalliance.org/wp-content/uploads/2014/07/All-Alliance-Presentation-September-2014.pdf
APD objectives and benefits
The objectives of APDs include collecting, aggregating,
analyzing, and reporting healthcare information to realize
the following benefits:
• Provide data and information transparency about
healthcare delivered including quality, patient access,
service utilization, costs, and pricing
• Provide insights into the effectiveness of existing
healthcare policies and programs
• Uniquely identify all patients and attribute patients to
providers
• Provide inputs to research analysts and policy makers
to understand and design new alternative healthcare
delivery models and accompanying payment reform
• Support quality and efficiency improvements by
(groups of) providers
• Enable informed decision making by consumers on
price, expected out-of-pocket costs, and quality when
selecting care providers
• Allow for flexible, real-time changes to health
plan product pricing and design including emerging
alternatives to traditional products
• Enable analysis of the trends in demographics, profiles
of diverse member populations, and forecast outcomes
of policy responses
• Provide information to form the basis for
benchmarking healthcare performance
• Detect potential fraud, waste, and abuse
• Automate manual, time consuming reporting
already required
• Assist with state regulation of health plans by
providing data to defend against and/or justify proposed
rate increases.

How to develop sustainable and flexible APDs
APD analytic and reporting capabilities
The basic value offered by the APD is its ability to generate
the baseline data to benchmark metrics against the goals
outlined in the APD objectives and benefits section. But the
availability of data in itself is only the first step. To realize the
APD’s full value, the right user interface, presentation layer,
and analytic tool sets must be deployed. These tools will enable
users to create reports and more importantly, perform ad hoc
analysis to investigate underlying causes for regional variations
in outcomes or model impacts of proposed new policies for
example. Therefore, the analytic and reporting capabilities of
the APD should minimally include:
• Static and dynamic reporting—built-in, predefined static
reporting or parameter, ad hoc, dynamic reporting on
historical data
• User-defined reports and views where users can set and
save their reporting and sourcing preferences
• Multiple access methods via multiple devices and multiple
distribution channels, e.g., a public-facing portal that can offer
the collected information to nonprofits, researchers, data
scientists, and other research agencies promoting research
and collaboration and helping to maximize the true value from
the APD data8
• Ability to perform longitudinal patient-level data analysis
(data analysis over time) in a single episode across multiple
encounters, including the flexibility to reset episode definitions
and aggregate base episodes (e.g., a cardiac procedure) into
a larger, clinically meaningful episode (e.g., a heart attack
episode with the cardiac procedure as therapeutic intervention)
• Ability to aggregate and analyze financial information,
e.g., total inpatient costs, total office visit costs, total
prescription costs, but also total costs for diabetes care, for
care for the frail elderly, etc.
8
The data privacy and security is governed by the Federal HIPAA (The Health Insurance Portability
and Accountability Act – http://www.hhs.gov/ocr/privacy/) and HITECH (The Health Information
Technology for Economic and Clinical Health (HITECH) Act – http://www.hhs.gov/ocr/privacy/hipaa/
administrative/enforcementrule/hitechenforcementifr.html) regulations.
Figure 1: Vaccination Rate Example

• Ability to aggregate and analyze quality and outcomes
information, drawing upon dedicated quality reporting feeds
but also on state of the art claims data analytics for total cycle
of care outcomes analysis
• Ability to aggregate and analyze access information, including
travel times, capacity analytics, and service availability
• Ability to report data by region/subregion, e.g., state,
county, zip codes, community service areas, primary
service areas, secondary service areas, healthcare recipient
segments, etc., to perform comparative analysis (See Figure 1:
Vaccination Rate as an example)
• Graphical map reporting that can display two- or three-
dimensional charts, as well as, displaying geo-coded
information on maps, e.g., heat maps, community maps
(See Figure 2: Average annual stroke admissions in a region as
an example)
–– In addition to access to the “default” data sources—
including member/patient, provider, payers, plans, eligibility,
claims, case management data, and service delivery data—,
the ability to combine and analyze APD with other
relevant data, e.g., demographic, clinical, research, publicly
available quality data sets, subscription-based data sets,
retail, pharmaceuticals, etc.
–– Advanced statistical, data mining, and predictive
capabilities for operational and strategic planning,
including risk adjustment capabilities required for all
health plan payments based on risk pool, classification
and stratification (e.g., high-or low-risk classification based
on health habits), population health analysis, and gaps in
care analysis
–– Assist in the development, predictive modeling for, and
evaluation of various care coordination and payment
models to identify effectiveness and quality of various
delivery practices and models
–– Capability to detect and monitor fraud, waste, and abuse.
• Flexibility to draw upon different risk adjustment and
grouper methodologies so as to be not “locked in,” and/
or the capabilities to integrate with third-party vendor
tools and systems, e.g., HCI3 ECR episode groupers,9
3M solutions, and purpose-specific risk-attribution tools
for data set enhancement, categorization, and other value-
added activities.
© OpenStreetMap contributors., www.openstreetmap.org/copyright
9
Episode groupers are a type of software that groups inpatient, outpatient, and pharmaceutical
claims into clinically homogeneous units of analysis called episodes that describe a patient’s
complete course of care for a single illness or condition. The result is a sophisticated methodology
that is used for a wide range of applications such as provider profiling, disease management,
quality improvement, and cost and utilization analysis. These episodes can also be the building
block for bundled payments, as part of an integrated payment reform approach.
States may have these similar questions
that APDs can help answer:
• How affordable is health insurance? For a low income
family: how are low-income individuals potentially on
Medicaid able to afford health insurance as the income
threshold increases to above 133 percent of the
federal poverty level as the Affordable Care Act (ACA)
exchange-related subsidies phase out?
• Why are certain procedures more expensive in
some areas and not others, and is there a correlation
between cost and quality?
• Has participating in a health information exchange
previously demonstrated success in impacting quality
and cost? If so, show me where.
• Can I get a single longitudinal portrait of each
patient’s claims?
• Can I use this data to demonstrate clinical
effectiveness not previously demonstrated?
Figure 2: Average annual stroke admissions in a region

What does a sustainable APD enterprise architecture look like?
Business architecture overview
While an APD represents a significant technical capability that
can deliver immediate and long-term value, implementing
a database on its own will not provide optimal return on
investment. The tool sets described here must be evaluated
and integrated into a state’s existing business operating and
accountability models to help ensure the proper policies,
processes, governance, agreements, and resources are
in alignment to make an APD successful. The business
architecture overview step is especially important given that
multiple entities need to be involved in maintaining a current
and reliable data set and in producing a thorough analysis and
interpretation based on the available data.
Although the technical aspects of the APD are important, the
organization and process component are just as important to
develop and maintain a sustainable APD. Without the technical
business architecture and the organizational and process
components working in tandem, the quality of the data in the
APD will likely degrade over time, making it unreliable and of
little value to its users and consumers.
Insurance
Carriers
TPAs
TPAs Service
Cost
Quality
Ratings
Predictive
Modeling
Descriptive
Analyses
Other Data
Marts
Data StoreDI
DI
DI
DI
Standardize
Validate/
Report
De-identify
Staging Area
Master Patient
Index
Master Payer
Index
Master Provider
Index
Condition/
Treatment
PBMs
Medicaid
Medicare
Unstructured
HIX
IES
HIE
SecureFileTransfer
MDM Consumption and Distribution
Master Data Hub
Data Sources Data Intake Data Environment Access and
Distribution
Analytics and
Reporting
Analytics
Tools and Engines
Web Portal
Reports
Data
Extract
Data Federation and Virtualization
AccessandDistribution
Figure 3: Conceptual APD Enterprise Architecture

Data and systems architecture overview
To establish an APD, healthcare claims data from a variety
of sources will be collected and aggregated to support the
management, evaluation, and analysis of a state’s healthcare
system. Payers provide information about insured individuals,
their diagnoses, services received, and costs of care. Additionally,
as APDs mature and are expanded to integrate demographic,
clinical, financial, public health, and other data, a plethora of new
ways to aggregate and analyze this data for decision making will
be revealed. With links to integrated eligibility systems (IES),
health information exchanges (HIE), health insurance exchanges
(HIX) and other sources, APDs can be a component in an overall
federated healthcare ecosystem and have the opportunity to
provide a true 360-degree view of healthcare delivery to the entire
state healthcare system. These capabilities will take significant
time and effort to achieve.
Building a long-lasting solution does not need to imply higher
short- and mid-term costs. The conceptual architecture
diagram, Figure 3: Conceptual APD Enterprise Architecture,
shows different components of the APD solution based on
a combination of structured and unstructured data analysis.
This allows for a fit- for- purpose short-term solution while being
ready for longer- term build-out. The blue colored components in
the data sources represent inputs from commercial insurance
carriers, third-party administrators (TPAs), pharmacy benefits
managers (PBMs), Medicaid, and Medicare. In the long term,
the pink- colored components can be integrated, which includes
data from health benefits exchanges, health and social services
benefits information from IESs, and electronic health records
data from state HIEs. Unstructured data from various social
media sources can also be integrated to feed into APD through
a Big Data platform (such as direct enrollee feedback on health
plans, services received through their doctor’s office visits, and
other purchasing data summary in pharmacy and grocery stores).
The data can be cleansed, personal identifiable information
removed, and standardized to a common format in the data
intake stage. A master data management (MDM) hub would be
used to maintain the data integrity (same key for reference data
across different sources) for patients, providers, payers, and
conditions. The data store component is the main data warehouse
for the APD. The data store is the heart of the solution and will
maintain the data in multiple dimensions in star schema,10
carry
the metadata for users, and provide a scalable solution. The data
marts stage will provide a slice of the central data store for further
customized and specialized or ad hoc research analysis to data
scientists and the internal user community. The analytics and
reporting stage is the intelligence behind the APD solution that
performs data visualization, statistical analysis, data mining, and
other computational algorithms.
Data sources
The APD should have well-defined interfaces, based on
standards, to accommodate a variety of sources, including:
• Existing and evolving Medicaid claims data
• Centers for Medicare Medicaid Services (CMS) supplied
Medicare claims data
• Commercial payer claims data
• Pharmacy benefit management claims
• Third-party administrator claims
• Other existing claims repositories.
The APD should be designed to accommodate or access future
data sources such as:
• Health information exchange clinical data related to the
payer claims
• Health insurance exchange enrollment, claims, and clinical
data for qualified health plans
• IESs enrollment, claims, and utilization data related
to healthcare, mental health, substance abuse,
nutritional programs, and broader social services
• Data derived from unstructured data sources such as
social media, call center communications logs, and
healthcare case notes
• Machine and medical device data, wearable electronic data
collection devices (e.g., data from Fitbit or similar devices)
• Consumer behavior, credit card transactions,
loyalty program data.
An in-depth view of the APD architecture components
can be found in the Appendix: APD system architecture
components.
10
The star schema separates business process data into facts, which hold the measurable,
quantitative data about a business, and dimensions, which are descriptive attributes related to
fact data. Examples of fact data include sales price, sale quantity, and time, distance, speed, and
weight measurements. Related dimension attribute examples include product models, product
colors, product sizes, geographic locations, and salesperson names.

APD implementation risks and mitigation strategies
We have identified the following example APD project risks and associated mitigation strategies, based on our experience with
other APDs and projects with similar requirements and complexities:
Risk Mitigation Strategy
Multiple steps (e.g., de-identification,11
aggregation,
and analytic reporting) may result in schedule
delays before any meaningful results can be
realized.
• Coordinate closely in the data aggregation stage to receive early
deliveries of test data.
• Use the test data to verify the data transfer, data quality, and load
designs and scripts.
Data quality issues during the aggregation process
result in a delay in loading the data environment and
running the analytic functions.
There is an associated risk that the longer the
data quality improvement cycle takes, the longer
users have to wait for meaningful analysis.
• Coordinate during the data aggregation process to receive early and
frequent deliveries of data.
• Use data quality routines to test for structural, referential integrity,12
and value issues.
• Provide daily feedback to the data aggregation team, data suppliers,
and to the project management office (PMO) on data-quality issues
so they can be corrected. These teams are often multientity teams
working concurrently with Medicare, Medicaid, and commercial
systems.
• Document all decisions made in data cleanup for the governance
framework.
Users expect only automated production of
previously manual reports; they do not have the
ability to think beyond their previous reporting and
analytic restrictions.
• Set expectations with users that improving their analytic maturity is
part of the phased implementation process.
• Establish training programs, guidelines, and time lines.
The state’s historical data will likely require unique
integration and may not align with current system
capabilities.
• Architecture should allow for segmentation of historical versus
current data sets, while enabling integration of the two wherever
possible. This helps to ensure users can still analyze historical data
even if its granularity, aggregation, and dimensionality do not align and
integrate seamlessly with current data structures.
The APD solution will automate many processes
that were previously manual. This will require the
users to obtain or improve other skill sets such as
interacting with stakeholders to address changes
that are needed based on these new and improved
automated reports and analysis.
• States should consider developing multiple roles aligned with the
life cycle of the data—users to test integration of data, transformation of
data, reporting and visualizing the data, and new roles for performance,
process, and quality improvement activities.
APD solution capable of only integrating structured
data sources.
• The majority of healthcare data is currently unstructured. Building in
new technology capable of mining both structured and unstructured
data is a critical component of the APD solution.
APD solution dependent on consultants and
high-dollar subcontractors for extension and
enhancement.
• Make training available during implementation. The analytic
capabilities should mirror the skill sets of the end users. Focus on
deploying automated reporting and simple analysis first so users are
not overwhelmed. As maturity improves, they should be coleading
enhancement efforts along side the consulting implementation
team and eventually taking on full maintenance and enhancement
responsibility.
11
De-identification is the process used to prevent a person’s identity from being connected with information.
12
Referential integrity is a relational database concept in which multiple tables share a relationship based on
the data stored in the tables, and that relationship must remain consistent.

APD standards, regulations, mandates, and funding
sources will evolve to address these implementation
challenges. To address this evolution, the APD
business and technical architecture designs need to
be flexible, adaptable, and sustainable. KPMG has
referenced hundreds of information management and
business intelligence projects13
in both the public sector
and across multiple industries in the commercial sector
and based on research of prior APD implementations,
and developed a set of required APD capabilities.
These capabilities are related to business and architecture
functions, components, and design guidelines that should
be considered while states are initiating or revisiting their
APD strategies.
A case study by Nuna Health*
Benefits of cloud storage using Amazon Web Services
Storing data on distributed servers, known as “the
cloud,” has become increasingly favorable in all sectors,
including healthcare. Storing data in the cloud simply
means that the physical server infrastructure is not owned
by the user. Usually the data is distributed over many
machines. The methods for distributing data vary by cloud
arrangement and retailer. Cloud storage is safe, secure,
flexible, and relatively inexpensive when compared with
owning and maintaining the physical server infrastructure.
With respect to amassing large amounts of health data,
an additional benefit to cloud storage solutions is the
flexibility for performing data analytics. Traditional data
storage arrangements do not allow for the computing
capacity required when dealing with hundreds of
terabytes to petabytes of data. Data scientists require
techniques (e.g., Elastic Map Reduce) that spread data
across multiple machines to query and do analytics
on these type of data sets in a time efficient manner.
Without a distributed arrangement, data scientists can do
the necessary analytics only with very large amounts of
investments, manpower, and specialized software that
runs on a private cloud.
Recently, in an unprecedented move, the CMS moved
to using Amazon Web Services (AWS) for the second
generation of the application on Healthcare.gov, also
known as the federally facilitated marketplace. CMS’s
bold steps towards more convenient storage solutions
for sensitive healthcare data heralds the conveniences,
safety, and affordability of cloud storage for healthcare
data.
Among other options, AWS was selected for its security,
cost, and track record. AWS has recently undergone
a rigorous security audit from CMS to host the next
generation of major health-related government projects.
Furthermore, AWS continuously runs intrusion detection
on a global scale across their entire network, and
automatically shuts down instances exhibiting suspicious
or malicious behavior without impacting the performance
of the underlying virtual machines.
AWS charges hourly and at different prices for the virtual
hardware being used. You can instantly multiply your
deployment a hundredfold or more during peak traffic
or burst computation. Traditional data centers make you
preallocate and purchase for the entire year your peak
load. This more efficient pricing model saves money and
accommodates need.
AWS has hosted over 1,000,000 consumer Internet
applications, including large-scale deployments such
as Amazon.com, Instagram, Dropbox, and now parts of
Healthcare.gov. In total, AWS serves 1percent of the
entire Internet’s traffic.
*Nuna Health brings engineers and data scientists to organize and leverage healthcare data
for the purpose of solving problems around cost and quality.
13
KPMG Data Analytics Portal, http://kpmg.com/Global/en/topics/data-analytics/Pages/default.aspx

APD implementation challenges
States implementing the first set of APDs faced a number of
challenges, including problems developing and justifying a
business case for funding, technical integration, stakeholder
uncertainty and lack of confidence in the underlying data,
and immature analytic capabilities. These challenges fall
into three main areas:
Difficulties in obtaining data
Historically, health plans have shared cost data with states
on a voluntary basis, requesting clear insight into how the
data will be used and with whom it will be shared. Usually,
protections/restrictions on disclosing discount and pricing
arrangements were put in place at the request of both
payers and the providers they contract with; providers often
object to payers reporting data about their practices that
could be considered as their competitive advantage or core
to their value proposition. Historically speaking, transparency
in markets is generally not brought about by the existing
market parties themselves.14
Rather, transparency has been
created by regulatory action, consumer advocacy, and trend-
setting market players, including universities, nonprofits,
and public-private partnerships.15,16,17,18
Valid concerns are
raised about how the data will be used, whether the data
released will accurately reflect prices and quality, and if it
will account for variations in the complexity of individual
cases. Costs of advanced imaging MRI services varies widely
between and within states; the mere existence of variation
does not indicate whether actual costs differ meaningfully or
not.19
Consumers may be concerned about the privacy and
security of their information, although this is often explicitly
addressed in federal and state regulations such as the Health
Insurance Portability and Accountability Act (HIPAA) and state
APD regulations.
Voluntary (that is, not state-run or state-mandated) APD
initiatives have been established in Louisiana, Wisconsin,
and Washington.20
These cover a limited area or set of claims
data and are not carried out in direct collaboration with state
reporting entities. A comprehensive APD that maximizes data
completeness and includes all relevant stakeholders requires
a state mandate. Kansas, Maine, Maryland, Massachusetts,
Minnesota, New Hampshire, Utah, Vermont, Colorado,
Oregon, and Tennessee already established state-mandated
APDs. Texas, Nebraska, and Rhode Island have passed
legislation supporting the creation and funding of these
systems. New York has an approved budget for an APD and
is formulating regulations to implement the mandate. If a
state wants to embark on the path of a fully fledged APD,
experiences suggest that it needs to require the providers
and payers to share the claims and cost data, comply with the
legislation, and understand the protections and restrictions that
states will have to follow in sharing data.
14
Mcintosh, Sarah. “Colorado’s All-Payer Database Raises Privacy
Concerns,” http://news.heartland.org/newspaper-article/colorados-all-
payer-database-raises-privacy-concerns
15
Colorado All-Payer Database Bill, http://www.leg.state.co.us/clics/
clics2010a/csl.nsf/billcontainers/7772EFE1E998E627872576B700617FA
4/$FILE/1330_01.pdf
16
APCD legislation across United States: http://apcdcouncil.org/claims-
data-collection-legislation
17
NYS Health Innovation Plan based on NYS APD legislation:
http://www.health.ny.gov/technology/innovation_plan_initiative/docs/
ny_state_health_innovation_plan.pdf
18
APCD Council Vendor List: http://apcdcouncil.org/vendors
19
“All-Payer Claims Database: Overview and Success,” Page 35-36,
APCD Council. http://mihin.org/wp-content/uploads/2014/06/D.-Denise-
Love-National-Experiences-creating-an-All-Payer-Claims-Database.pdf
20
Alaska Department of Health and Human Services, Policy Update
All Payer Claims Database (URL: http://08e8b087be13672c3556-
50439c37af4aa61e7b9ef49111ab15f6.r18.cf1.rackcdn.com/Policy_
Update_All-Payer_Claims_Database.pdf)

The following map highlights the legislative healthcare data collection requirements in 2010. This information was gathered by
National Association of Health Data Organization (NAHDO).21
21
“All-Payer Claims Databases,” National Association of Health Data
Organization, March 17, 2011,|
https://apcdcouncil.org/sites/apcdcouncil.org/files/APCD%20
Overview%2C%20Prysunka.pdf
Source: National Association of Health Data Organization

No perfect formula for sustainable funding
Historically, APDs have been established after state legislation
and budget allocations have been approved for building and
maintaining initial versions. The total funding allocations for the
initial development and future updates of APDs have ranged
from less than $5 million to more than $12 million over the first
five years in early adopter states.22,23,24,25
The cost varies based
on features of the APD system and types and sizes of data sets
integrated.26
The development cost is front loaded, but you
should plan to allocate in the hundreds of thousands of dollars
for the continued annual investment.
Therefore, states should have a detailed, multiyear funding
model and financing available to support the APD initiative
to not only implement the solution, but also maintain it and
accommodate for new use cases emerging from initial
experience. States can leverage one-time federal fiscal
support, such as rate review and exchange establishment
grant funds created by the ACA, for which funding under Office
of Management and Budget Circular A-87 Cost Allocation
Exception is available through December 31, 2015. Obtaining
continuous funding after the start-up period to pay for
operational costs of maintaining and updating the APD solution
can be challenging. In some states, the ongoing maintenance
is paid primarily with state and Medicaid matching funds
(e.g., New Hampshire) or through general appropriations
(e.g., Utah). Some states are exploring user fee-based revenue
streams, but these may be less significant than public funding.
Also, states planning to recover costs by selling data in a raw
form are finding that difficult to achieve. Adding value to the
data through analytics, as we have discussed here, and making
this information available at cost basis for both providers and
payers may be a better way to generating structural revenues.
Lack of national standards
The healthcare ecosystem in each state is unique as regulatory
frameworks, populations, providers, and health plan markets
greatly differ between states. Yet, the fact that so far, each
state APD initiative has reestablished its own reporting,
analytic, and data warehouse specifications almost from
scratch impacts the value that these solutions are providing.
The absence of a standardized approach diminishes the overall
potential of these technologies to inform policy and practice
from a common framework for definitions, processes, and
analysis.27
It also creates additional expenses for health plans
that are submitting data to multiple states. For example
in 2013, 11 states had an APD, including Kansas, Maine,
Maryland, Massachusetts, Minnesota, New Hampshire, Utah,
Vermont, Colorado, Oregon, and Tennessee.28
If each state
were to adopt a unique reporting format, payers will have
to submit 11 different file extracts for multiple analytic files
(e.g., medical claims, eligibility). As more states implement
APDs, the need for uniform reporting specifications increases
dramatically. The APCD Council’s recommended standards for
data exchanges are a first helpful step towards bringing some
structure to these developments.
22
“Analysis of All Payer Claims Database for the State of Iowa,” State of
Iowa, December 2011, http://dhs.iowa.gov/sites/default/files/2011_All_
Payer_Claims_Database_0.pdf
23
“All Payer Claims Database Study,” State of Alaska, February 2013,|
http://dhss.alaska.gov/ahcc/Documents/meetings/201303/AK-APCD-
FeasibilityReport20131402.pdf
24
“$4.5 Million in Funding Secured to Support Colorado Health Care
Database,” State of Colorado, April 2012,
http://www.civhc.org/News-Events/News/$4-5-Million-in-Funding-
Secured-to-Support-Colorad.aspx/
25
“Local Lessons from National APCD Efforts,” Freedman Healthcare
LLC, September 2014, http://wahealthalliance.org/wp-content/
uploads/2014/07/All-Alliance-Presentation-September-2014.pdf
26
“All-Payer Claims Database (APCD) Fact Sheet,” APCD Council, 2010,
http://www.apcdcouncil.org/sites/apcdcouncil.org/files/APCD%20
Fact%20Sheet_FINAL_2.pdf
27
APCD Council, Standards: http://apcdcouncil.org/standards
28
APCD Council, Interactive map: http://apcdcouncil.org/state/map

The initial versions of APDs have been developed and
deployed, across a range of states. They will need to
evolve further to meet the ever-changing capabilities and
requirements of mature data analytic user groups in the
converging healthcare industry. The need for greater evolution
in APDs can be largely attributed to inadequate numbers of
healthcare providers participating in data sharing voluntarily
at this stage, the ability to leverage advances, in data analytic
capabilities, as well as the potential of what state-of-the-
art business intelligence technologies and difficulties in
integration of data due to different data standards. The design
of APDs must naturally mature to accommodate higher and
more complex data demands. APD standards, regulations,
mandates, and funding sources will need to evolve to address
the aforementioned APD challenges from state APD and
legislative leadership that promote sharing of data, updating
the APD solution with advanced Big Data technologies, cloud
deployments, and finding more sustainable sources of funding
by creating smarter business models (generating information
that is of value to healthcare providers and plans alike) and by
lowering the relative cost of creating this information. Also,
the range of public-private partnerships, fee-based models,
and identifying and channeling cost savings into maintaining
an APD solution are only beginning to be explored. As states
initiate their APD development or formulate their strategies
for the next generation of their solution, they should consider
the business and technical concepts presented in this white
paper for achieving a sustainable APD that will readily adapt to
this evolution.
The APD architecture must evolve from automated reporting
to dynamic, advanced on-demand analytics that can be
customized by end users. New APD implementers and
users must plan for current and future data sources. Mature
users must plan to integrate emerging technologies to allow
for unstructured and real-time data reporting and analysis.
Healthcare leaders must prepare for data not traditionally
collected or analyzed by their analyst communities.
The age of healthcare system redesign is here. The APD is
a critical component of the future enterprise healthcare data
ecosystem. As reporting and analytic maturity evolves, with
broader underlying integrated healthcare data, so too will
the system capabilities of the overall enterprise architecture.
APD solutions form the analytic cornerstone required to make
this transformation a success. Stakeholders who can build
maturity with these solutions, and capitalize on emerging
technologies and nontraditional data sources can quickly realize
a competitive advantage. This advantage will be in the form of
federal and state incentive dollars, retaining talent with clinical
and data analytics skills, higher rates of provider satisfaction
and participation, as well as new health plan contracts that
favor quality outcomes and higher reimbursement rates for
high-performing healthcare systems.
Data analytics is the new currency that will be a key
differentiator in public and private healthcare outcomes and
financial viability of healthcare organizations and systems.
APDs will help those that want to succeed and have the vision
that integrated data from multiple sources is not a threat, but a
strategic asset to be nurtured constantly over time.
Final thoughts and next steps

The following steps will help you begin the process.
1.
Begin the process to obtain funding now
The clock is ticking on the availability of the federal ACA grants funds to develop APDs. December 2015 will be upon
you quickly if the process does not begin now. Request funding to design and build the solution, and do not stop asking.
There should be a budget line item in every budget, every year, for the foreseeable future directly linked to enhancing the
APD solution.
2. Build internal support and buy-in
Designate an APD champion, who is able to lead the effort both internally and with external stakeholders.
3.
Build a coalition of health plans in your state
Engage champions from every health plan early and often. Having these healthcare organizations at the table, ready
and willing to share their claims data, is essential. And make sure you build a business case for your APD solution that
highlights the benefits your commercial health plans will get from active participation.
4.
Take inventory
Make sure you have every possible piece of technology, business process, and report laid out that will be improved,
automated, or eliminated as a result of the APD. Building a sustainable APD will have a heavy upfront cost, but you
should be able to find a significant return on investment by adopting a technology-driven data analytic solution in place of
current manual, inefficient, and redundant processes.
5.
Prioritize and start small
The idea of integrating all claims and related data sets into one solution can be overwhelming. Prioritize your objectives
and needs, and start small in order to rapidly deploy teams to complete short, three- to six-month cycles of integration,
automation, and analysis.
6.
Create a detailed business case
Develop a comprehensive business case that includes the consideration of alternatives and the return on investment for
the various options considered, as well as funding needs, both short and long term.

To satisfy the data, reporting, system, and sustainability
requirements and guidelines the APD architecture should have
the following components:
Data intake
Data is the foundation for extracting meaningful metrics and
insights for healthcare delivery and healthcare payment reform.
As with any foundation, it must be solidly built and of sufficient
quality to sustain the analytics and reporting layers it needs to
support. The data intake stage contains the following functions:
Collection
The APD needs to have the capability to collect healthcare
encounter data from both public and commercial payers in
a uniform and standard format and landed in a staging area.
Because the encounter data have both personal health and
personal identifiable information, it needs to be communicated
and stored securely. Dependent upon state regulations, the
collection function may need to have an opt-in/out option for
healthcare recipients to filter the collected data. There are many
interrelated technical and business challenges associated with the
regular transfer of large volumes of data from multiple sources.
The business processes and available level of automation to
capture, send, and receive the data must all be evaluated to
establish a sufficient level of operational support but is not
onerous to the state.
Standardization
Because the data is being sourced from a variety of data suppliers,
the data will be in different formats and types. These will need to
be standardized so that analytic algorithms can ultimately be used
on a cohesive set of data.
De-identification
States occasionally expose APD data to researchers, health
plans, providers, and the public. To satisfy HIPAA and HITECH
regulatory requirements, fields such as name, social security
number, medical record number, and claim number need to be
masked and/or hashed, while keeping the referential integrity of
the data intact.
Depending on a state’s requirements, this function may be
deferred to a later stage in the architecture to accommodate the
storage of personally identifiable information, protected health
information, and de-identified data.
Validation/Reporting
The accuracy of the analytics is correlated to the accuracy
and quality of the underlying data. Validation and data quality
monitoring and checks need to be performed at every stage of
data movement and enhancement. Critical data received from
the sources that are missing or incorrect need to be reported and
communicated back to the source data providers for remediation.
Data integration
The data integration function provides the secure and quality
controlled movement, translation, and aggregation of data
between the APD architecture components. They are triggered by
either a timed schedule, completion of an event, or a combination
of both. For example, the update of the quality ratings mart may be
updated no earlier than the tenth day of each month and after the
data warehouse has completed its payer table loads. The function
is supported by either batch extract-transform-load processes or
near real-time converters/loaders. The function also provides
in-line data quality monitors and controls.
Master data management hubs
A typical APD aggregates claims data from disparate payer
systems. To match and link the data sets, a master data hub is
necessary to facilitate record linkage and standardization along
key entities such as patient, provider, payer, and health-related
reference data. The hubs act as the master data version of “truth”
for the data warehouse, data marts, and other components of the
architecture that use or consume master data.
Data store
The data store component is designed to accommodate a variety
of types of structured and unstructured data in a variety of formats
and is capable of storing data at the lowest level of detail required
for analysis.
Data marts
Data marts are logical or physical constructs used to enable slicing
and dicing of data. They focus on a specific area of interest and
are constructed for access control, facilitation of analyses, or
improved access performance, which drives whether physical
or logical instances are required. APD data marts can be tailored
to specific reporting or analytical needs such as calculating cost
efficient and quality rating of care delivered.
Access and distribution
The access and distribution architecture layer provides the user
an application/tool gateway to the transformed, integrated, and
aggregated healthcare data. This is where the APD delivers value
to its constituents in a consumable manner and enables reporting
operational performance metrics to support healthcare plan
design and development, quality control, research, and strategic
planning. It also provides controls to limit access and distribution
to authorized users, produces extracts and de-identified data sets
for researchers and other stakeholders approved through a data
governance process, and provides information through a variety of
media, including Web portals and mobile devices. This component
also provides the interface to advanced data analytic and
visualization tools and allows results feedback from these tools
into the APD.
Appendix: APD system architecture components

Security—access and distribution controls, masking and anonymizing of protected health information
data, and capture and maintenance of audit trails.
High availability to users—data should be available for access and analysis with minimal downtime for
maintenance or data loads.
Business and technical data transparency—business and technical metadata captured in all layers of
the architecture.
Storage—capability to store multiple type, formats, and years of data online for access and query.
Backup/Restore—the ability to perform incremental or full backups of the APD and to recover it in case
of failure within hours.
Archive—based on the needs of APD data consumers, a minimum number of years of encounter
history will need to be available online in primary storage media. This may vary from 3–5 years to perform
operational reporting and analytics to 10–30 years to support longitudinal studies of treatments and
outcomes. If the need to access older historical data is not immediate, this data may be archived to
secondary or tertiary storage media.
Disaster recovery—the ability to store and recover data from a remote site within hours or days
depending upon the mission criticality determination of the APD. (The APD may be built such that the
disaster recovery instance of the APD is continuously synched in near real time with the operational APD
and can be used as a “hot” backup.)
Metadata manager
The metadata manager is responsible for providing the visibility
and linkage between business metadata, technical metadata,
and operational metadata. Examples of business metadata are
definitions for claim number and provider identification number.
Technical metadata may describe the transformations performed
as data moves from sources through the APD, the format of each
field, and the relationships between fields. Operational metadata
may describe run times of processes for moving the data and
expected times of arrival into the APD data warehouse.
APD architecture design guidelines
Alignment with the enterprise healthcare information system
Claim information is only one component of the enterprise
healthcare information ecosystem. The architecture should be
designed in a way that the APD is a member of a federated data
infrastructure that enables inclusion of other healthcare data
sources, such as healthcare insurance/benefits exchanges, HIEs,
IESs, as well as other healthcare data sources. Together, these
data repositories can provide data transparency on healthcare
delivery, outcomes, and a thorough view of healthcare recipients.
System functions and capabilities
To be sustainable, the APD should be scalable and extendable to
accommodate increased volumes of data, increased number of
parallel queries, increased processing demands on data, and an
expanding user base. The APD should also be designed to have
the following supporting system functions and capabilities:

The information contained herein is of a general nature and is not intended to address the circumstances of any particular individual or entity.
Although we endeavor to provide accurate and timely information, there can be no guarantee that such information is accurate as of the
date it is received or that it will continue to be accurate in the future. No one should act on such information without appropriate professional
advice after a thorough examination of the particular situation.
© 2015 KPMG LLP, a Delaware limited liability partnership and the U.S. member firm of the KPMG network of independent member
firms affiliated with KPMG International Cooperative (“KPMG International”), a Swiss entity. All rights reserved. Printed in the U.S.A.
The KPMG name, logo and “cutting through complexity” are registered trademarks or trademarks of KPMG International. NDPPS 312121
Contact us
Paul Hencoski
U.S. Lead Partner – Health and
Human Services
T: 212-872-3131
E: phencoski@kpmg.com
Marc Berg, MD
Principal, Healthcare Strategy and
Transformation
T: 240-380-0402
E: mberg1@kpmg.com
Ryan Hayden
Director, Healthcare Analytics
T: 315-380-0672
E: rhayden@kpmg.com
Sid Frank
Director, Public Sector Data Analytics
T: 770-833-0983
E: sidfrank@kpmg.com
kpmg.com
This white paper was developed by the KPMG Government Institute in conjunction
with KPMG’s Global Human Social Services Center of Excellence.
About the KPMG Government Institute
The KPMG Government Institute was established to serve as a strategic resource for
government at all levels, and also for higher education and nonprofit entities seeking to
achieve high standards of accountability, transparency, and performance.
The institute is a forum for ideas, a place to share leading practices, and a source of
thought leadership to help governments address difficult challenges, such as effective
performance management, regulatory compliance, and fully leveraging technology.
For more information, visit us at: www.kpmginstitutes.com/government-institute.
Jeffrey C. Steinhoff
Executive Director
T: 703-286-8710
E: jsteinhoff@kpmg.com

Developing an Adaptable All Payer Database

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Destaque

Destaque (17)

Semelhante a Developing an Adaptable All Payer Database

Semelhante a Developing an Adaptable All Payer Database (20)

Developing an Adaptable All Payer Database