Using document stores in business model transformation

www.pwc.com/technologyforecast
Technology Forecast: Remapping the database landscape
Issue 1, 2015
Using document stores
in business model
transformation
By Alan Morrison
and Colin White
Healthcare providers need data model flexibility now.
The US healthcare industry’s ongoing business
model shift is having a considerable impact
on how providers collect, analyze, and store
data. Although the fee-for-service model
still dominates, payers are refining pay-forperformance programs, which measure
and reward the value, not the volume,
of healthcare delivered. To get paid for
performance, providers are finding they
need data collection and analysis capabilities
that are different from those that relational
databases deliver.
More than
14 percent
of Medicare
beneficiaries—
nearly 8 million
people—already
receive care
through pay-forperformance plans.
The pay-for-performance model encourages
providers to focus less on the most aggressive
treatment of each distinct ailment and more
on a balanced approach to the patient’s
overall health. For example, a payer might
seek evidence that a provider has successfully
brought blood pressure, blood glucose and
lipid levels under control for a given patient
population with both high blood pressure
and diabetes.
By building in incentives, program advocates
hope to reduce the overall cost and to improve
the quality of care. More than 14 percent of
Medicare beneficiaries—nearly 8 million
people—already receive care through a payfor-performance program, and the Obama
administration aims to reach 30 percent by
the end of 2016.1
Pay for performance triggers changes in the
data collection and analysis that surrounds
patient care. Providers need to document,
aggregate, and share detailed analyses of the
impact of their care on overall patient health.
Reliable and persuasive health outcome
reporting is essential to the billing process
and the success of pay for performance.
To achieve successful outcome reporting,
providers such as Avera (a chain of nonprofit
hospitals, clinics, and nursing homes in the
American Midwest) know they need to run
longitudinal queries on the same patient
populations over time across a continuum of
care. Unfortunately, electronic medical record
(EMR) databases, the primary data source,
weren’t designed for longitudinal analysis.
Most EMR data models are visit oriented to
facilitate the old fee-for-service billing.
To address this challenge, Avera uses
Apache CouchDB, a NoSQL document
Medicare patients moving out of fee-for-service programs
Number of patients receiving pay-for-performance care, millions
8 million
2 015
6
2 014
4
2 013
2
2 012
0
Source: Bloomberg Business, 2015
1 John Tozzi, “How Obama’s $3 Trillion Health-Care Overhaul Would Work,” Bloomberg Business, January 26, 2015,
http://www.bloomberg.com/news/articles/2015-01-26/how-obama-s-3-trillion-health-care-overhaul-would-work,
accessed January 26, 2015.
2 Structured query language, or SQL, is the dominant query language associated with relational databases. NoSQL stands for not only
structured query language. In practice, the term NoSQL is used loosely to refer to non-relational databases designed for distributed
environments, rather than the associated query languages. PwC uses the term NoSQL, despite its inadequacies, to refer to non-relational
distributed databases because it has become the default term of art. See the section “Database evolution becomes a revolution” in
“Enterprises hedge their bets with NoSQL databases” at http://www.pwc.com/us/en/technology-forecast/2015/remapping-databaselandscape/features/enterprises-nosql-databases.jhtml for more information on relational versus non-relational database technology.
2
PwC Technology Forecast
Using document stores in business model transformation
store, as a bridge between the EMR and the
healthcare provider’s analytics systems.2
NoSQL document stores such as CouchDB,
MongoDB, or Microsoft DocumentDB can
offer an expedient bridge between a rigid EMR
database and a more permissive, versatile,
general-purpose data repository.
Healthcare is just one domain where a sea
change is under way in database technology.
This issue of the Technology Forecast continues
to explore the upheaval caused by these
technologies. This article provides a deeper
look at the NoSQL document store and how
it differs from the relational database.
How document stores and
relational databases compare
Unlike a typical EMR relational database,
a document store accommodates data in
many structures and formats and allows the
longitudinal queries necessary for patient
outcome reporting purposes. This kind of
flexibility pays off when working with all the
different data formats providers collect.
Take the case of diabetics who’ve also had
high cholesterol levels during three visits over
12 months. With a document store, providers
can preserve the full fidelity of the data,
regardless of the structure or quality of the
data. The CouchDB database that Avera uses
identifies a test result as an element connected
to its parent, the low-density lipid cholesterol
test. The tags describing the relationship
connecting them indicate the data type,
such as a fax image, a PDF, or other file type.
Any query in CouchDB would indicate the
presence of a lab result and its data type, even
if the user can’t read the result value itself.
Contemporary relational databases can
store data in various forms, but they weren’t
originally designed for that purpose, which
limits their utility for querying. To function
properly, queries to relational databases
generally require data to be in a specifically
keyed, tabular form with predetermined,
explicit schema (that is, predefined tables,
fields, views, indices, and other elements)
and all the table cells filled in.
Document objects, by comparison, may
conform to a schema (a data description list
matched to the tabular data), but the schema
is rarely explicit and can be unique to each
document in the store. Document stores
typically support familiar schemas but won’t
strictly enforce them.
How relational databases and document stores handle four records
Relational data model
Highly structured table organization with rigidly
defined data formats and record structure
Document data model
Collections of complex documents with arbitrary, nested
data formats and varying “record” format
Collections
R1C1
R1C2
R1C3
R1C4
R2C1
R2C2
R2C3
R2C4
R3C1
R3C2
R3C3
R3C4
R4C1
R4C2
R4C3
R4C4
{
{
"UUID": “21f7f8de-8051-5b89-8
{
"UUID": “21f7f8de-8051-5b89-8
"Time": "2011-0401T13:01:02.42”
{
"UUID": “21f7f8de-8051-5b89-8
"2011-0401T13:01:02.42”
"Server": "Time":
"A2223E",
"UUID": “21f7f8de-8051-5b89-8
"Time":
"2011-0401T13:01:02.42”
"Server":
"A2223E",
"Calling Server":
"A2213W",
"Time":
"2011-0401T13:01:02.42”
"Server":
"A2223E",
"Calling Server":
"A2213W",
"Type": "E100",
"Server":
"A2223E",
"Calling Server":
"A2213W",
"E100",
"Initiating"Type":
User": "[email protected]",
"Calling
Server": "A2213W",
"Type":
"E100",
"Details": "Initiating User": "[email protected]",
"E100",
User": "[email protected]",
"Details": "Initiating"Type":
{
"Details": "Initiating User": "[email protected]",
{
"IP": "10.1.1.22",
"Details":
{
"IP": "10.1.1.22",
"API": "InsertDVDQueueItem",
{
"IP": "10.1.1.22",
"API": "InsertDVDQueueItem",
"Trace": "cleansed",
"IP": "10.1.1.22",
"API": "InsertDVDQueueItem",
"Tags": "Trace": "cleansed",
"API": "InsertDVDQueueItem",
"Trace":
"cleansed",
"Tags":
[
"Tags": "Trace": "cleansed",
[
"SERVER",
"Tags":
[
"SERVER",
"US-West",
[
"SERVER",
"US-West",
"API"
"SERVER",
"US-West",
"API"
]
"US-West",
"API"
]
}
"API"
]
}
}
]
}
}
}
}
}
Source: “Making the Shift from Relational to NoSQL,” Couchbase, 2014, p. 1, http://www.couchbase.com/sites/default/files/
uploads/all/whitepapers/Couchbase_Whitepaper_Transitioning_Relational_to_NoSQL.pdf, accessed January 27, 2015.
3
PwC Technology Forecast
Using document stores in business model transformation
A lack of strict enforcement in this sense
means more flexibility overall. Document
stores typically store data in either a version
of JSON (JavaScript Object Notation) or XML
(Extensible Markup Language) objects. Inside
the objects are inherently hierarchical, tagged
data consisting of values and their associated
name tags, also known as name-value or
attribute-value pairs.
is, table linking) metadata that demands
consistency across tables. This metadata in
essence occurs between the tables and can
include patient name metadata that needs to
be queried. Treating the metadata the same as
the data, which is what happens in document
stores, improves ease of use.
Document stores treat data and metadata
equally within documents, and they aren’t
fussy about whether each document has
a particular tag or not. In CouchDB, for
example, running a map function on lastName
creates a view in documents that have the
lastName attribute (or tag), which a user can
then query. With the help of multiple queries,
users can either query multiple collections
that have this tag or embed all documents
within a single document or collection. All
the data elements can describe a constantly
changing patient, rather than a single
transactional visit.
By contrast, adding new tables to relational
databases can complicate the data model
substantially, resulting in foreign key (that
Finally, in document stores, the documents
themselves can contain hierarchical
collections of subdocuments. This capability
suits continuous, small, volatile read and
write operations, such as telemetry from a
bedside monitor.
When to use NoSQL
document stores
For most enterprises in most industries,
document stores will augment, rather than
replace, relational databases. For lots of
writes, relational technology continues to
be the norm. Relational databases are write
intensive, and immediate consistency is
mandatory—known as ACID (atomicity,
consistency, isolation, and durability)
compliance. By requiring immediate
consistency, they allow thousands of users
to concurrently trigger changes in the data.
This sample of JSON side by side with its XML equivalent shows the name-value pairs
Source: “JSON,” Wikipedia, February 6, 2015, http://en.wikipedia.org/wiki/JSON, accessed February 11, 2015.
4
PwC Technology Forecast
Using document stores in business model transformation
Mission-critical transactional systems will
continue to be relational.
Pros and cons of document
stores and relational databases
Many of the other distinctions between
relational databases and document stores
involve the heritage and maturity of
these different types. Fundamentally, the
distinctions boil down to a tradeoff. Relational
databases have maturity on their side; a
broad range of management and visualization
tools are available, as well as comprehensive
security and transactional integrity features.
Document stores, by contrast, are horizontally
scalable; they are generally designed to scale
out across clusters and between data centers,
and they have developer ease of use and
flexibility on their side.
Document store workloads are read
intensive and generally designed to be
highly available. NoSQL document stores
relax ACID requirements somewhat, and
many—such as MongoDB, CouchDB, and
DocumentDB—claim tunable consistency.
But consistency expectations coming from
the relational data world can’t always be met
in the document world, nor should they be.
The focus is on the richness of the data for
analytics purposes and thus read capabilities
are more important than write capabilities.
For analytics and auditability, the principle
of immutability—preserving versions intact
for data mining, audit trail, and historical
A comparison of document stores and relational databases
Document stores
Relational databases
Consistency (ACID
compliance)
Moderate, tunable
consistency
High, concurrency controlled
Integrity of writes
Within a single document
Cross-system
Query language
Fragmented and evolving
Standard SQL
Developer API
REST and method
invocation a
ODBC and derivatives b
Horizontal scalability
Across and between clusters
at different data centers
Local clusters
Schema flexibility
Fluid
Rigid
Management and
visualization tools
Evolving
Mature
Tree and graph processing
Optimized
Adequate
Security paradigm
Generally application layer
oriented
Role oriented and directory
service friendly
Encryption
Application layer only
Well supported
Audit and compliance
Undetermined and evolving
Transaction logging (SOX, PCIDSS, and HIPAA friendly) c
a. Representational State Transfer (REST) is a simplified, web-based method for communicating with IT systems.
b. Open Database Connectivity (ODBC) is a long-established method for communicating with database management
systems. Established in 1992, ODBC predates the commercial web.
c. SOX = Sarbanes–Oxley Act of 2002
PCI-DSS = Payment Card Industry Data Security Standard
HIPAA = Health Insurance Portability and Accountability Act of 1996
5
PwC Technology Forecast
Using document stores in business model transformation
consistency purposes—becomes a higher
priority than immediate writability. As storage
costs continue to decline, immutability
becomes more feasible. In healthcare
as in other industries, the absence of a
transaction is as important as its presence, and
inconsistencies or gaps can be crucial clinical
indicators, rather than something that needs
normalizing, smoothing, or interpolating.
Document stores also allow developers to
be much more efficient. The favored way
to access document stores are RESTful
application programming interfaces (APIs),
which is one reason for their efficiency.
Another element of efficiency is ease of
use. Click-to-deploy capability is emerging
for Amazon DynamoDB, MongoDB, and
DocumentDB, for example.
Conclusion
Healthcare organizations will increasingly
explore NoSQL document stores as a means of
gaining insight into their growing data lakes.
Providers are largely technical, science-driven
To have a deeper conversation
about remapping the database
landscape, please contact:
Gerard Verweij
Principal and US Technology
Consulting Leader
+1 (617) 530 7015
[email protected]
Chris Curran
Chief Technologist
+1 (214) 754 5055
[email protected]
Oliver Halter
Principal, Data and Analytics Practice
+1 (312) 298 6886
[email protected]
Bo Parker
Managing Director
Center for Technology and Innovation
+1 (408) 817 5733
[email protected]
professionals and will acquire the skills they
need to work with NoSQL document stores as
long as NoSQL offers competitive advantage
and freedom from relational constraints.
However, relational databases for transaction
processing will continue to precede document
stores in the data pipeline. For healthcare and
many other industries, weak ACID compliance
is a showstopper for any critical transaction
processing purpose. Some document stores
claim ACID compliance, but the approach
to consistency differs from that of relational
databases. Document stores have gained
in popularity, and enterprises will need to
become more familiar with their capabilities
and limitations.
Over the next several years, NoSQL document
stores are expected to expand their role of
ingesting relational data to feed auxiliary
systems such as clinical reporting and
advanced analytics, and enterprises will
gain familiarity with their advantages and
limitations for various purposes.
About PwC’s Technology Forecast
Published by PwC’s Center for Technology
and Innovation (CTI), the Technology Forecast
explores emerging technologies and trends
to help business and technology executives
develop strategies to capitalize on technology
opportunities.
Recent issues of the Technology Forecast have
explored a number of emerging technologies
and topics that have ultimately become
many of today’s leading technology and
business issues. To learn more about the
Technology Forecast, visit www.pwc.com/
technologyforecast.
About PwC
PwC US helps organizations and individuals
create the value they’re looking for. We’re a
member of the PwC network of firms in 157
countries with more than 195,000 people.
We’re committed to delivering quality in
assurance, tax and advisory services. Find
out more and tell us what matters to you by
visiting us at www.pwc.com.
© 2015 PricewaterhouseCoopers LLP, a Delaware limited liability partnership. All rights reserved. PwC refers to the US member firm, and may
sometimes refer to the PwC network. Each member firm is a separate legal entity. Please see www.pwc.com/structure for further details. This
content is for general information purposes only, and should not be used as a substitute for consultation with professional advisors. MW-15-1351 LL