Experian Health: Moving Universal Identity Manager from ANSI SQL to MongoDB

©2017 Experian Information Solutions, Inc. All rights reserved. Experian and the Experian marks used herein are trademarks or registered
trademarks of Experian Information Solutions, Inc. Other product and company names mentioned herein are the trademarks of their
respective owners. No part of this copyrighted work may be reproduced, modified, or distributed in any form or manner without the prior
written permission of Experian.
Experian [Public. Confidential. Internal. Restricted. – please choose the appropriate category]

© Experian Private and confidential Moving Universal Identity Manager from ANSI SQL to MongoDB 2
Experian Health - Moving Universal Identity Manager
from ANSI SQL to MongoDB
MongoDB World – Chicago
Sean Reisz
June 20, 2017

1.The steps to migrate from a traditional SQL architecture to a MongoDB architecture, including
improvements and iterations to simplify the migration.
2.Understand the design of a reference architecture for a performant and highly available application
using MongoDB.
3.Architecture performance and scale comparisons between traditional SQL database schemas and
the MongoDB document model.
Learning Objectives

• Simplify our schema and queries
• Improve performance
• Simplify future growth
• Improve replication & failover
Migrating from ANSI SQL to MongoDB allowed us to:

Experian Health – Our Vision
To shape the future of healthcare through cutting-edge,
innovative product designs, and improve operational
efficiency through integrated solutions and services
leveraging data-driven analytics and insights.

Experian Health Solutions
Revenue Cycle
Optimization Services &
Analytics
Revenue Cycle
Management
Care
Management
Identity
Management
Patient
Engagement
 Patient Estimates
 Patient Gifting
 Patient Schedule
 Patient Self-Service
 Patient Statements
 PaymentSafe®
 Care Coordination
Manager
 Clinical Data
Clearinghouse
 MemberMatch®
 Precise ID® with
Digital Risk Score
 Return Mail
 Universal Identity
Manager
 Patient Access
 Contract
Manager
 Claims
 Collections

Why Experian Health?
The Power of
Experian Data
Well-rounded
suite of offerings
Patented, KLAS-
ranked Touchless
WorkflowTM
System
Strong heritage in
RCM & Patient
Access
• 220 million consumer
credit profiles
• 235 million consumer
demographic profiles
Strength of solutions in
revenue cycle management
(SearchAmerica, MPV) &
Patient access (Passport
Health Communications)
• Revenue Cycle
Management
• Identity Management
• Patient Engagement
• Care Management
Our eCare NEXT® platform
earned the highest score
in the Patient Access
category of the 2017 Best
in KLAS: Software &
Services Report

Universal Identity Manager – What Is It?
What does the UIM Do?
The Universal Identity Manager (UIM) Is a person
record matching tool:
•Probabilistic matching engine
•Data Improvement
– Scrubbing
– Normalization
– Augmentation
•Matches related Person records
•Assigns a single identifier
•Provides a combined “best” view

Universal Identity Manager – What Is It?
How Is This Useful?
Allows for Disparate Data
•Incomplete Records
•Different data sources / domains
•Different data quality levels
Uses
•Improved patient care
•Historical and longitudinal data collection
•Coordination of benefits across clients

UIM SQL Schema
Source Record
Addresses
Aliases Phone Numbers
Identifiers
Address / Alias
Cross Reference

UIM Major Database Steps
Incoming
Record is
Received
Is
Record
in DB?
Pull Existing
Record Data
Find Candidate
Records
Pull Candidate
Record Data
Insert New
Record
Update Existing
Record
Was
Match
Found
?
Return UIM ID
Y
N
Y
N
Source Record
Lookup

UIM Major SQL DB Steps
Source Record Lookup (SQL)
SELECT * FROM SourceRecord WHERE
SourceRecordID = ?
Find Candidate Records (SQL)
SELECT category, id FROM (
SELECT DISTINCT ‘FN-LN-ZIP’ as category,
SourceRecordID from Xref WHERE FirstName = ?
AND LastName = ? AND Zip = ?
UNION ALL
SELECT DISTINCT ‘FN-DOB’ as category,
AND Dob = ?
UNION ALL
SELECT DISTINCT ‘LN-DOB’ as category,
SourceRecordID from Xref WHERE LastName = ?
AND Dob = ?
UNION ALL
… )

Pull Candidate / Existing Record Data (SQL)
SELECT * FROM SourceRecord
LEFT OUTER JOIN Addresses on (SourceRecord.id =
Addresses.SourceRecordID)
LEFT OUTER JOIN Phones on (SourceRecord.id =
Phones.SourceRecordID)
LEFT OUTER JOIN Identifiers on (SourceRecord.id =
Identifiers.SourceRecordID)
LEFT OUTER JOIN Aliases on (SourceRecord.id =
Aliases.SourceRecordID)
LEFT OUTER JOIN Xrefs on (SourceRecord.id =
WHERE SourceRecord.id = ?

Insert / Update Record Data (SQL)
INSERT INTO SourceRecord VALUES (?,?,…)
-or- UPDATE SourceRecord SET VALUES = (?,?,..) WHERE id = ?
INSERT INTO Addresses VALUES (?,?,…)
-or- UPDATE Addresses SET VALUES = (?,?,…) WHERE id = ?
-or- DELETE FROM Addresses WHERE id = ?
INSERT INTO PhoneNumbers VALUES (?,?,…)
-or- UPDATE PhoneNumbers SET VALUES = (?,?,…) WHERE id = ?
-or- DELETE FROM PhoneNumbers WHERE id = ?
INSERT INTO Identifiers VALUES (?,?,…)
-or- UPDATE Identifiers SET VALUES = (?,?,…) WHERE id = ?
-or- DELETE FROM Identifiers WHERE id = ?
INSERT INTO Aliases VALUES (?,?,…)
-or- UPDATE Aliases SET VALUES = (?,?,…) WHERE id = ?
-or- DELETE FROM Aliases WHERE id = ?
INSERT INTO Xref VALUES (?,?,…)
-or- UPDATE Xref SET VALUES = (?,?,…) WHERE id = ?
-or- DELETE FROM Xref WHERE id = ?

UIM SQL Schema - Challenges
Database Size Multiple Indexes
Table Joins
Multiple Writes Per Person
Record
Cross Reference Table Replication and Failover

UIM New Architecture – Why MongoDB?
• MongoDB presence in the organization
• Document based writes / retrievals
• Easier growth as data increased
• Naturally better replication and failover

UIM Initial MongoDB Schema
Source Records
{
_id: <ObjectId>,
dob: ‘19010101’,
…
}
Addresses
Aliases
Phone
Numbers
Identifiers

MongoDB Performance
0
5000
10000
15000
20000
25000
Proof of Concept (100M Records)
Average Inserts / Minute
ANSI SQL
18,000 / minute
MongoDB 2.6.5
20,000 / minute

UIM MongoDB Lesson – Category Lookup
• Candidate lookup queries required multiple indexes
• Candidate queries could not use queries optimized for shards
Categories
{
_id: <ObjectId>,
sourceRecordId: <Source Record ObjectId>
category: ‘FN-DOB’,
value: ‘SEAN-19010101’
}
• Shard key is Category + Value
• Candidate lookup now can use queries that are optimized for shards
• Only one additional index was required

UIM MongoDB Lesson – Source Record ID Lookup
• Source Record lookup requires a query against the record’s logical key
• This query required an additional index
• Could not use queries optimized for shards
Source Record IDs
{
_id: <SourceRecord Logical ID>,
sourceRecord: <SourceRecord ObjectId>
}
• Source Record lookups now use default index
• Source Record lookups can use queries optimized for shards

UIM MongoDB Lesson – Single Document Category Lookup
• Candidate selection returns multiple records for each value
• The candidates returned are always the same set
• The Category collection still has an additional index
Categories
{
_id: { category: ‘FN-DOB’,
value: ‘SEAN-19010101’},
sourceRecords: [
<SourceRecord ObjectId>,
<SourceRecord ObjectId>,…]
}
• Allows single document retrieval
• Removes additional index

UIM Final MongoDB Schema
Categories
{
_id: { category: ‘FN-DOB’,
value: ‘SEAN-19010101’},
sourceRecords: [
<SourceRecord ObjectId>,
<SourceRecord ObjectId>,…]
}
Source Record IDs
{
_id: <SourceRecord Logical ID>,
sourceRecord: <SourceRecord
ObjectId>
}
Source Records
{
_id: <ObjectId>,
dob: ‘19010101’,
…
}
Addresses
Aliases
Phone
Numbers
Identifiers

Major Database Steps
Source Record Lookup (SQL)
SELECT * FROM SourceRecord WHERE
SourceRecordID = ?
Source Record Lookup (MongoDB)
db.SourceRecordIDs.find({_id: ?})
Find Candidate Records (SQL)
SELECT category, id FROM (
SELECT DISTINCT ‘FN-LN-ZIP’ as category,
AND LastName = ? AND Zip = ?
UNION ALL
SELECT DISTINCT ‘FN-DOB’ as category,
AND Dob = ?
UNION ALL
SELECT DISTINCT ‘LN-DOB’ as category,
SourceRecordID from Xref WHERE LastName = ?
AND Dob = ?
UNION ALL
… )
Find Candidate Records (MongoDB)
db.Categories. find({$or:[
{"_id.category":“FN-LN-ZIP", "_id.value" :?},
{"_id.category":"FN-DOB", "_id.value" :?},
{"_id.category":“LN-DOB", "_id.value" :?},
…]})

Pull Candidate / Existing Record Data (SQL)
SELECT * FROM SourceRecord
LEFT OUTER JOIN Addresses on
(SourceRecord.id = Addresses.SourceRecordID)
LEFT OUTER JOIN Phones on (SourceRecord.id
= Phones.SourceRecordID)
LEFT OUTER JOIN Identifiers on
(SourceRecord.id = Identifiers.SourceRecordID)
LEFT OUTER JOIN Aliases on (SourceRecord.id =
LEFT OUTER JOIN Xrefs on (SourceRecord.id =
WHERE SourceRecord.id = ?
Pull Candidate / Existing Record Data
(MongoDB)
db.SourceRecords.find({_id: ?})

Insert / Update Record Data (SQL)
INSERT INTO SourceRecord VALUES (?,?,…)
-or- UPDATE SourceRecord SET VALUES = (?,?,..) WHERE id =
?
INSERT INTO Addresses VALUES (?,?,…)
-or- UPDATE Addresses SET VALUES = (?,?,…) WHERE id = ?
-or- DELETE FROM Addresses WHERE id = ?
INSERT INTO PhoneNumbers VALUES (?,?,…)
-or- UPDATE PhoneNumbers SET VALUES = (?,?,…) WHERE id
= ?
-or- DELETE FROM PhoneNumbers WHERE id = ?
INSERT INTO Identifiers VALUES (?,?,…)
-or- UPDATE Identifiers SET VALUES = (?,?,…) WHERE id = ?
-or- DELETE FROM Identifiers WHERE id = ?
INSERT INTO Aliases VALUES (?,?,…)
-or- UPDATE Aliases SET VALUES = (?,?,…) WHERE id = ?
-or- DELETE FROM Aliases WHERE id = ?
INSERT INTO Xref VALUES (?,?,…)
-or- UPDATE Xref SET VALUES = (?,?,…) WHERE id = ?
-or- DELETE FROM Xref WHERE id = ?
Insert / Update Record Data (MongoDB)
db.SourceRecords.save({…})
db.SourceRecordIds.save({…})
db.Categories.save({…})

UIM MongoDB Schema - Benefits
Simplified Structure
Simplified Document
Retrieval / Document Writes
Simplified Queries Reduced Number of Indexes
Futureproofing – Sharding
Improved Failover /
Replication

UIM MongoDB Reference Architecture

MongoDB Performance
0
10000
20000
30000
40000
50000
60000
70000
80000
Reference DB (300M Records)
Average Inserts / Minute
MongoDB 3.2.9
70,000 / minute
ANSI SQL
15,000 / minute

In Summary
•We started with an ANSI SQL database
•We transitioned to MongoDB which better fit our
natural model
•With a few iterations we developed a final model
that
– Simplified the schema
– Minimized indexes
– Simplified queries
– Allowed all queries to be optimized for shards
•Final Architecture
– Significantly Improved performance
– Allowed for simpler future growth
– Improved failover / replication

Questions / Comments

Experian Health: Moving Universal Identity Manager from ANSI SQL to MongoDB

More Related Content

Similar to Experian Health: Moving Universal Identity Manager from ANSI SQL to MongoDB (20)

More from MongoDB (20)

Recently uploaded (20)

Experian Health: Moving Universal Identity Manager from ANSI SQL to MongoDB

Editor's Notes