Clover
Footer
Reinventing Health
Insurance: Using
Data to Put Patient
Care First
Healthcare Analytics Lean in Conference
Oct 23, 2015
2Footer
Agenda
1 What is Clover?
2 Who am I?
3 Data Science and Clover
4 What are we doing with all this?
5 Questions
3
Who am I?
4
Data Science at Clover
Ian Blumenfeld
Platform - Health modeling at
Archimedes, lapsed physics Phd
Otis Anderson
Product - analytics at Yammer, MS
Office, former affirmative action
consultant
5
Data Science at Clover
Footer
6
Data Science Expertise
7
• Actuarial Science
• Health Economics
• Medical Informatics
• Finance
• Accounting
List of data science areas of non-expertise
8
What is Clover
Health?
9
A tech company and a health insurance
company
Healthcar
e
Technolog
y
10
• Medicare Advantage Part D plan
• Why?
• More unit cost -> more opportunity
• We think chronic disease management represents the
biggest opportunity to reduce cost of care by improving
outcomes
• 7K enrollees in New Jersey (OPEN ENROLLMENT)
• Clinical operations and customer service are in-house
• More on that later
Clover is a health insurance company
Our goal is to organize and leverage
data to fix our healthcare system.
Clover is trying to improve health
outcomes for our member population.
We are using the tools of data science
and modern web development to
prioritize, assess and iterate upon our
interventions.
1
1
Why did Clover build
the data science
function first?
Clinical Outcomes? So What?
There’s measuring clinical outcomes and then there is
optimizing them.
To see what I mean let us imagine two campaigns around
nurse visits.
Two Campaigns
Campaign
Discharged
Members
Clinical
Effectiveness
Coverage
Control
Readmission
Rate
Covered Pop
Readmissions
Uncovered
Pop
Readmissions
A 100 .15 .4 .4 10 24
B 100 .2 .2 .4 4 32
Total readmissions in campaign A - 34
Total readmissions in B – 36
So A is more effective at preventing
readmissions, even though the intervention from
B is the more clinically effective campaign
Two Campaigns
Two Campaigns
Things that can be affected…
sometimes…maybe
So even when you know the outcomes
. . .you still can push to the optimal result by pushing up the processes
that lead to the outcomes. If you want to talk about outcomes where the
targeting is less obvious than a hospital discharge, then predictive
modeling is more important.
What do you want to optimize outcomes then?
• Flexible clinical operations team
• Data warehouse full of joinable outcome and process data
• Apps that gather information as they enable operations
• Speed – data speed and decision speed
Footer
Which brings us back to this
Footer
Which brings us back to this
This part
is hard
This part is critical
Difficulties we faced, part I
• Assembling catalogue of necessary
data
• Adding joinable keys into separate
data sources
• Pinning down when membership
starts and stops
• Parsing unstructured data
• Transforming hard to scrape-data
(PDFs, invoices, one actual
photograph of a series of data
points)
• Interpreting claim duplications –
different for different files and
different use cases
• Reconciling multiple sources of truth
• Understanding claim semantics
• PROVIDER DATA
• Interpreting part d accounting rules
• Counting hospital visits
• Automating all of the above
• Making sure that the automation
doesn’t break any of the above
Difficulties we faced, part II
A stylized
representation
of our call logs
at one point.
An example – provider data
To someone who has thought about it for a few minutes, provider data
seems easy.
You want one row per provider with at least address, an identifier,
name, specialty, and whether they are in network.
What happened?
1. Our provider data migrated from Access 🙀 to a more custom
physician data management solution.
2. UI in new solution made it hard to validate data.
3. Most accurate data ended up going onto paper. All sorts of horrible
consequences follow when the source of truth is paper 🙀 🙀 🙀
An example – provider data
What did we do?
We took control of the data validation process. The object was to get
provider data into a good state and be able to maintain and update it.
But provider data is bad because it is complex. You need to reconcile
multiple sources of truth and update based on occasionally provisional
data.
An example – provider data
SIMPLIFIED
WORKFLO
W!!!
26
What have we built
out of this?
27Footer
• We can run all of the things you have to do – star ratings, finance, customer
service, claim forensics out of our data warehouse.
• It can all be joined on a unique of a member, so everything can be related to
everything else.
• We can run lots of things in SQL and Python cutting down on less
automatable solutions like Excel and access.
• Speed and flexibility to answer any ad-hoc question quickly!
A working data warehouse!
28
Useful things engineers have built
Member profile used by Clover staff surfaces history and captures observations.
29
Useful things engineers have built
Gaps in care surfaced as clinical reminders
30
Questions?

Building a Data Warehouse at Clover

  • 1.
    Clover Footer Reinventing Health Insurance: Using Datato Put Patient Care First Healthcare Analytics Lean in Conference Oct 23, 2015
  • 2.
    2Footer Agenda 1 What isClover? 2 Who am I? 3 Data Science and Clover 4 What are we doing with all this? 5 Questions
  • 3.
  • 4.
    4 Data Science atClover Ian Blumenfeld Platform - Health modeling at Archimedes, lapsed physics Phd Otis Anderson Product - analytics at Yammer, MS Office, former affirmative action consultant
  • 5.
    5 Data Science atClover Footer
  • 6.
  • 7.
    7 • Actuarial Science •Health Economics • Medical Informatics • Finance • Accounting List of data science areas of non-expertise
  • 8.
  • 9.
    9 A tech companyand a health insurance company Healthcar e Technolog y
  • 10.
    10 • Medicare AdvantagePart D plan • Why? • More unit cost -> more opportunity • We think chronic disease management represents the biggest opportunity to reduce cost of care by improving outcomes • 7K enrollees in New Jersey (OPEN ENROLLMENT) • Clinical operations and customer service are in-house • More on that later Clover is a health insurance company
  • 11.
    Our goal isto organize and leverage data to fix our healthcare system. Clover is trying to improve health outcomes for our member population. We are using the tools of data science and modern web development to prioritize, assess and iterate upon our interventions. 1 1
  • 12.
    Why did Cloverbuild the data science function first?
  • 14.
    Clinical Outcomes? SoWhat? There’s measuring clinical outcomes and then there is optimizing them. To see what I mean let us imagine two campaigns around nurse visits.
  • 15.
    Two Campaigns Campaign Discharged Members Clinical Effectiveness Coverage Control Readmission Rate Covered Pop Readmissions Uncovered Pop Readmissions A100 .15 .4 .4 10 24 B 100 .2 .2 .4 4 32 Total readmissions in campaign A - 34 Total readmissions in B – 36 So A is more effective at preventing readmissions, even though the intervention from B is the more clinically effective campaign
  • 16.
  • 17.
    Two Campaigns Things thatcan be affected… sometimes…maybe
  • 18.
    So even whenyou know the outcomes . . .you still can push to the optimal result by pushing up the processes that lead to the outcomes. If you want to talk about outcomes where the targeting is less obvious than a hospital discharge, then predictive modeling is more important. What do you want to optimize outcomes then? • Flexible clinical operations team • Data warehouse full of joinable outcome and process data • Apps that gather information as they enable operations • Speed – data speed and decision speed
  • 19.
  • 20.
    Footer Which brings usback to this This part is hard This part is critical
  • 21.
    Difficulties we faced,part I • Assembling catalogue of necessary data • Adding joinable keys into separate data sources • Pinning down when membership starts and stops • Parsing unstructured data • Transforming hard to scrape-data (PDFs, invoices, one actual photograph of a series of data points) • Interpreting claim duplications – different for different files and different use cases • Reconciling multiple sources of truth • Understanding claim semantics • PROVIDER DATA • Interpreting part d accounting rules • Counting hospital visits • Automating all of the above • Making sure that the automation doesn’t break any of the above
  • 22.
    Difficulties we faced,part II A stylized representation of our call logs at one point.
  • 23.
    An example –provider data To someone who has thought about it for a few minutes, provider data seems easy. You want one row per provider with at least address, an identifier, name, specialty, and whether they are in network. What happened? 1. Our provider data migrated from Access 🙀 to a more custom physician data management solution. 2. UI in new solution made it hard to validate data. 3. Most accurate data ended up going onto paper. All sorts of horrible consequences follow when the source of truth is paper 🙀 🙀 🙀
  • 24.
    An example –provider data What did we do? We took control of the data validation process. The object was to get provider data into a good state and be able to maintain and update it. But provider data is bad because it is complex. You need to reconcile multiple sources of truth and update based on occasionally provisional data.
  • 25.
    An example –provider data SIMPLIFIED WORKFLO W!!!
  • 26.
    26 What have webuilt out of this?
  • 27.
    27Footer • We canrun all of the things you have to do – star ratings, finance, customer service, claim forensics out of our data warehouse. • It can all be joined on a unique of a member, so everything can be related to everything else. • We can run lots of things in SQL and Python cutting down on less automatable solutions like Excel and access. • Speed and flexibility to answer any ad-hoc question quickly! A working data warehouse!
  • 28.
    28 Useful things engineershave built Member profile used by Clover staff surfaces history and captures observations.
  • 29.
    29 Useful things engineershave built Gaps in care surfaced as clinical reminders
  • 30.

Editor's Notes

  • #2 Alternate title: “We Made a Data Warehouse”
  • #6 Backgrounds in physics, neuroscience, economics, computer science , applied stats, applied math and operations research. One person worked for a health insurance company, in an actuarial support role
  • #7 Turning all of this into scalable decisions. Not dissimilar to the actuarial role in a traditional insurance company. The tools are different, but the outcome is supposed to be advice and insight based on formal reasoning. Some of this will utilize sound statistical inference and machine learning, but the key here is build systems that iterate quickly.
  • #8 But you need all of those things to run a health insurance company. What’s going on here?
  • #13 By which I mean, before a lot of the intellectual support roles associated with health insurance
  • #18 There are lots of things we can influence on this graph. Maybe we can do a series of campaigns to push up the coverage numbers at the end of the funnel. Maybe we’ll get into a state where the clinically superior campaign has the most ocverage too.
  • #19 You want to build out the human capital of your org as a complement to the software.
  • #21 On the left we’re curating external data. The bottom reflects app data pushed back in to the loop. Again the bet here is that we can speed up the amount of time it takes us to conclude something about our operations and move on to a different part of the funnel.
  • #22 All of the people who do those things that aren’t in our realm of expertise. They have hard jobs.
  • #23 Transitioning between logging systems is messy. Instrumenting human behavior – also messy.
  • #27 Software eats part of clinical operations
  • #29 We want it to be easier for NPs to get important information to help set up their visits.
  • #30 Setting up good nudges to make data capture easy. If we want Nurse Practitioners to send useful data to the data warehouse, we have to make that easy to do.