Healthcare and Finance: 
How can two complex industries and their regulators understand each other?

Mitch Stonehocker

Join the Conversation #WolframTechConf

Topics

Obligatory Note: 
Given contractual and regulatory constraints real data or results can’t be shown.  Any data that looks as if it could be patient account data is in fact fictitious data generated to have the statistical properties of patient accounts.  I’m speaking for myself and making no representations for or of Healthcare TTU, any healthcare provider, financial organization, or government regulator.

Overview of the business use case

Background

Problem

Solution

Example

Data description

Scope, scale and type

Health Event Object (HEO)

Evolution of HEOs through states over time

Sampling of results

Sampling of data processing results

Sampling of analytical and modeling results

Use of Dataset[ ] objects are fundamental

(a simple) Illustration of transformations and validations performed on datasets

Pattern matching tames data cleaning and business logic

Do all values have an expected Head[ ]

Does the dataset (or a portion of the dataset) match a trusted peer?

What Head[ ] scenarios are exhibited in the dataset?

Summary

Shout out - make sure to see:

Alen Calvitti presentation ‘Patterns in Functional Data Analysis’.  Al has been a reliable funal to the firehose of ways Dataset[ ], Query[ ] and Rule[ ] can be used in irregular data structures and complex combinations of variables that support the relatively simple data representations needed for analysis and modeling.  Also, for being a second pair of eyes when evaluating analytical and modeling results.

Anton Antonov presentation ‘Monadic Programming: With Application to Data Analysis, Machine Learning and Language Processing’.  Anton has been a large help in the use of Quantile Regression Analysis in clumpy power law data - because linear and non-linear methods are lacking - unless I’m missing something.

Mark Kotanchek presentation ‘Life Doesn’t Have to Be Hard’.  Mark was very kind to let me test with his software DATAMODELER and permitted me many detailed questions about conditions when, of the predictor variables, characteristic variables dwarf numeric variables.

1) Overview of the business use case

1.1) Background

US Healthcare spending was $3.2T in 2015 accounting for 17.8% of US GDP.  The financial industry services the healthcare industry in three ways: insurance, investment banking, and treasury services.  Each industry has their own set of regulators demanding ever greater compliance to ever expanding regulations.

1.2) Problem

The volume of transactional data, disconnections arising from deep specialization, and the lack of standardized financial engineering methods for healthcare, combine to short circuit the universal need for financial understanding of healthcare business operations.   Currently, information relied on by analysts and managers is neither timely, nor automated, and is typically disconnected from audit requirements.  These two critical industries rely on experienced people using incomplete information and disconnected metrics to manage and communicate financial performance, exposures and risk profiles.

1.3) Solution

A distributed ledger applying the Healthcare Revenue and Cash-flow Forecasting (H-RCF) analytical method.  H-RCF overlays legal and accounting principles used every day by healthcare providers, their bankers, and regulators answering three fundamental questions simultaneously: how much, when, with what risk.  Financial engineering methods allow analysts and managers to predict, monitor, interrogate, and interpret operational data from a financial context. 

An automated data management method, generates and manages dataset objects providing full auditability throughout data validation processes, computation processes, and reporting processes.  The result is an ‘always on’ system of information that categorizes healthcare business events, benchmarks expected performance, tracks actual performance, and back-tests differences - automatically validated and ready for audit.







new picture

1.4) Example

What should a healthcare provider’s reserve requirement be given gross charges of current open accounts?  The finance department needs to predict payments over future time periods.  A starting point is to leverage the accounts receivable (AR) aging analysis to formulate what an AR forecasting model can be.  The goal is to calculate how much, when, with what risk.  How do we achieve the goal?  

The first step is know what fundamental data is needed.  Second, source of the data.  Third, validate, normalize, and sequence the data.  Fourth, compute with the data.  Fifth, report.  The needed data typically comes from three sources, claims, remits, and accounting records.  Once plugged into the H-RCF, data is validated, normalized, and sequenced for computation and reporting.  The system is always on, so new data is automatically processed making sure everyone is looking at reporting results from a consistent set of data, computed comprehensively.  

Accounts with missing or conflicting data are branched off into an Exception Group were staff can spot and correct errors and omissions.  Immediate identification and correction of data problems is essential to quality data management.  Waiting to the end of month almost guaranties an unresolvable data mess.  The result is information that ties together history and future, cash and revenue, open and closed accounts, benchmarks, predictions and actual results.



Make a .png movie of 3 or 4 steps

New picture

2) Data description

Scope and scale of source data:

Source data is:

Claim (industry standard 837 message type)

Remit (industry standard 835 message type)

Accounting records (client vendor dependent on the accounting system or HIS system)

There is no typical or average client so I’ll give a general description of one client

Approximately 100M accounting records

About 5M claim and remit records

Loading 3 years of historical data from SQL, running through first data validation and initial preparation steps takes about 14 hours, requires about 500G RAM to process in memory, and saves to disk at nearly 11G .  This first Dataset[ ] object is the first ‘branch’ (B1 more like the trunk) of all subsequent branches created for specific reporting, analysis, and modeling tasks.  Daily (but can be weekly or monthly) incremental upload and clean up is a triviality in relative terms, typically taking a few minutes.  The daily dataset object is joined to the historical dataset for archiving and use.

Data description:
	- Characteristic variables dwarf numeric variables
	- All variables follow power laws everywhere (all and everywhere are not exaggerations), so variable - variable relationships have one area (usually) of very large mass that dissipates away quickly
	- Variances universally show Heteroskedasticity, usually large 
	- Characteristic and numeric variable combinations when measuring HEO relative to each other or groups of HEO dollar value weights are required  
	- “Business’ rules limit the possible combination of HEO variables, as well as, the state an HEO can be in.  (business rules being organizational process control rules, commercial law, accounting standards, regulatory requirements,...)
One saving grace for this difficult data is, in the time dimension all variables tend to be mean reverting and many are tightly mean reverting.
While there is economic periodicity in the data, there is surprisingly little.

Types and examples of data extracted from source data:

Characteristic variables

- Service type: inpatient, outpatient, emergency
	- Type of record: charge, adjustment, payment
		- Adjustment type: a list in the area of 10's of values
		- Charge type: a list in the upper thousands of distinct values
		- Payments: a list in the area of 10's of values 
	- Plans: can easily be a list of 2k or more distinct values
	- you get the idea...

Numerical variables financial and economic

- How much (p)
	- How many (q)
	- Total = p * q

Units

- Dollars
	- Dates
	- Doses
	- ...

Time

- Various dates from accounting, claim and remit records (while not shown in this presentation we use TemporalData[ ] objects extensively so as to keep sparse timeseries sparse).
	- Date arithmetic and day counting

Health Event Object (HEO)

A control object, I call a Health Event Object (HEO), is created to contain characteristic and financial data with their units and dates.  Every account has a unique HEO evolution from first record to last.  The HEO is a ‘what’ and is specifically designed to answer the financial questions:
- How much?
- When?
- What risk (quantiles)?

States of a HEO

- Starting state: Open.  In the more detailed model this includes pre-admission and pre-pay states
- Transition states: In-house, unbilled, aging, and bad debt
- Absorbing state: Closed.  While closed in always the ultimate absorbing state there are instances when an account that was closed reenters

All in a Dataset[ ] object   --- VS ---   SQL & C# (and/or R and/or JAVA and/or Python and/or...)

3) Sampling of results

We’ve identified variables that drive HEO states, amounts and times.  This permits asking financial and economic questions like:
- For a given set of accounts currently in the in house state, what is the the probability the number of days double?
- For a given set of accounts currently in the in house state, what is the expected number of days they remain in house?
- For a given set of accounts currently in the in house state, what is the expected additional charges that will accrue?
An so on.

({{, }})

Payoff Performance Profile (PPP)

The PPP is a bespoke quantile regression given the unique conditions of the data and specific goal of conducting financial analysis and modeling.  The thick black line is a single actual payment path between 0 and 60 days while the red, pick, yellow, green and blue areas are the quantiles of payment expectations as of day 0.

Open Balance Current State Dashboard

This dashboard is a stylized representation of a customer dashboard.  It’s stylized because the ‘data’ driving the accounting, graphics, and aging tables are derived from a representative continuous distribution.  This dashboard is used for demonstrations and training because it conveys the underlying concepts and shows how the total financial picture can be brought into one top view if a single dataset, and consistent analytics, and model are used throughout.

All healthcare provider periodically create a historical AR aging report. periodically (monthly or quarterly is typical)  This is required by formal accounting reporting.  We can produce the report daily.

The current ability of healthcare providers to forecast cash-flows of current (already booked) revenue is minimal (‘finger in the air’).  We produce and report daily.

Accounts Receivable Aging and Forecasting (ARAF)

The ARAF report shows historical and future aging time ‘buckets’ on the columns and grouping and sub-grouping on the rows.  The column buckets also permit inspection of current states for in-patient and unbilled states.

The current ability of healthcare providers to forecast cash-flows of current (already booked) revenue is minimal (‘finger in the air’).  We produce and report daily.

Liquidity Measurement, Leverage Management and Risk (LMR)

One of the primary goals of this entire endeavor is to quantify and provide liquidity, leverage, and risk information to the relavent internal and external constituents.  We show that a timeseries of the ebb and flow of liquidity can be quantified.  This result, along with the strategic goals of management, can be used to judge the impact on leverage risk given periodic cashflow fluctuations, can be used to stress test the financial strength of a healthcare provider, can be used to ‘what if’ potential goals and opportunities management are considering.

4) Use of Dataset[ ]

By far, the most time consuming task is data management from source to complete preparation and synchronized for computation and analysis.  How to discover combinations of variable values across states that are not permitted or suspicious and deserving of investigation.

4.1) Illustration of transformations and validations in Datasets

Preparation of data for computation is foundational... can you prove you have the right data synchronized in the right way for a particular computation?  There are two primary motivations for this effort:
1 - Make sure data used in modeling is preciously consistent with data used in historical reporting
2 - Make the System and Organization Controls (SOC) audit is as efficient as possible
The down stream benefits are:
3 - End users (of all the interested constituents internal and external) have provable confidence in the accuracy of the data and model forecasts by separating out the difference between data error contributions to model error and model error on its own.
4 - Timely, accurate and direct feedback for the source processes and systems that generate the source data.

Three fundamental capabilities can give exacting clarity in the fog of big (very large quantities of) data:
1) Do all values have an appropriate Head[ ]?
2) Does the dataset (or a portion of the dataset) match a known and trusted peer?
3) What Head[ ] scenarios are exhibited in the dataset?

Note: We show this process on heads of data but the same approach works on key - value pairs at the value level.

We’ll use a simple dataset to illustrate how to achieve answers to these three questions.  We use branches (B) and steps (S) for tracking branching levels and transitions.

ds[B0,S0]=Dataset[<|
"1"-> <|"x"->6,"y"->"a","z"->{2017,06,15}|>,
"2"-><|"x"->-5,"y"->"b","z"->{01,01,01}|>,
"3"-><|"x"->-4,"y"->"b","z"->{2017,07,25}|>,
"4"-><|"x"->Null,"y"->"c","z"->{2017,06,15}|>,
"5"-><|"x"->3,"y"->Null,"z"->{2017,03,29}|>,
"6"-><|"x"->-1,"y"->"a","z"->Null|>,
"7"-><|"x"->"<none>","y"->"b","z"->{2017,04,05}|>
|>]

4.2) Pattern matching tames data cleaning and business logic
rules, rules, and more rules, and that’s not the end of the rules... try and imagine the nested ifs...

A list of rules that are applied to all key value pairs.

elementRules[{"B0","B1"}]=Replace[ {
Null:> Missing[<|"reason"->"Null"|>] ,
"<none>":> Missing[<|"reason"->"<none>"|>],
"":> Missing[<|"reason"->"empty string"|>]
} ];

A controller of the rule application in the dataset.

transformElements[{"B0","B1"}]=Query[ elementRules[{"B0","B1"}] ];

ds[B0,S0][All,All,transformElements[{"B0","B1"}] ]

Several ways to examine the row 4 column ‘x’.

ds[B0,S0][{"4"},"x",transformElements[{"B0","B1"}] ]
ds[B0,S0][{"4"},"x",transformElements[{"B0","B1"}] ]//Normal
ds[B0,S0]["4","x",transformElements[{"B0","B1"}]]
ds[B0,S0]["4","x",transformElements[{"B0","B1"}] ]//Last

Managing rules for specific kinds of data.

dateHandler[{y_,m_,d_}]:=DateObject[{y,m,d}];
dateHandler[_Missing]:=Missing[<|"reason"->"no date"|>];
dateHandler[Null]:=Missing[<|"reason"->"NULL"|>];
dateHandler[""]:=Missing[<|"reason"->"blank space"|>];
dateHandler[{1,1,1}]:=Missing[<|"reason"->"SQL returned {1,1,1}"|>];

transformDates[{"B0","B1"}][key_]:=Query[Thread[{key} -> dateHandler ] ];

temp[1]=ds[B0,S0][ All, transformDates[{"B0","B1"}]["z"] ]
temp[1][All,"z"]//Normal

4.3) Do all values have an appropriate Head[ ]?

Head Table

How to get there

Examine the permitted Head[ ] per column.  Easily - and automatically - discover and report non-compliance.

Grid[{{
temp[2]=ds[B0,S0][All,All,transformElements[{"B0","B1"}]][All,transformDates[{"B0","B1"}]["z"]],
temp[2][All,All,Head]
}}]

Note (not illustrated here), supplemental rules can be applied at this branch level to validate each head in a column has only a permitted Head[ ].  For instance, column ‘x’ can only have head: Integer or Missing.  This allows automated exception handing at the head level, creating an head exception dataset with all rows for which a column head rule is violated.

We can apply all rules consecutively on a dataset in a single query control line.  We can also pass the rules applied in a meta branch.

Grid[{
{"before","after"},
{ds[B0,S0],
ds[B1,S1]=ds[B0,S0][All,All,transformElements[{"B0","B1"}]][All,transformDates[{"B0","B1"}]["z"]]}
}]
Grid[{
{"element\nrules",transformElements[{"B0","B1"}]},
{"date\nrules",transformDates[{"B0","B1"}]["z"]},
{"Normal[ ]",ds[B1,S1]//Normal}
},Alignment->Left,Frame->All]

4.4) Does the dataset (or a portion of the dataset) match a known peer?

SameQ Table

How to get there

So far we’ve made sure all values of all keys in the dataset have a Mathematica Head[ ].  This is very convenient when one needs to observe the types of data relationship scenarios that exist in a dataset.  We use this as the first step on looking at large datasets for the first time.  The following steps presuppose one can determine which data relationship scenarios are acceptable and which are not - in other words some business rules.  Rather than get into specific business rules the following steps show how to use Head[ ] in rules and process Replace[ ] under data-scenario logic rules.

Case i) Replace values directly when more than one key - value is needed for rule logic.

xyRules[V1]=Replace[{
{x_/;x>0,y_String}:> 1,
{x_/;x<0,y_String}:> -1,
{x_/;x==0,y_String}:> 0,
{x_?NumberQ,y_Missing}:> Missing[<|"y"->y|>],
{x_Missing,y_String}:> Missing[<|"x"->x|>],
{x_,y_}:> Missing[<|"comment"-> "additional rules may be needed."|>]
}];

replaceTransform[V1]=Query[{
Identity,
Query[{"x","y"}]/*Values/*xyRules[V1]/*(<|"x"-> #|>&)
}]/*Apply[Join];

Grid[{
{"before","after"},
{ds[B1,S1],
ds[B1,S1][All,replaceTransform[V1]]}
}]

Case ii) Add a new key and values to existing keys and values using the same rules xRules[1]

addTransform[V1]=Query[{
Identity,
Query[{"x","y"}]/*Values/*xyRules[V1]/*(<|"x->{1||-1}"-> #|>&)
}]/*Apply[Join]/*KeySort;

Grid[{
{Style["before",12],Style[Text["after (with new & old keys & values)"],12],Style[Text["after (with old key & new values)"],12],Style[Text["after (with new key & new values)"],12]},
{ds[B1,S1],
ds[B1,S1][All,addTransform[V1]],
ds[B1,S1][All,replaceTransform[V1]],
ds[B1,S1][All,replaceTransform[V1]/*KeyMap[Replace["x"-> "x->{1||-1}"]]]}
}]

transform[{"B0","B1"}]=replaceTransform[V1];

Two ways to get to ds[“S”] intermediate step T0

Grid[{
{"Start","intermediate step 1","intermediate step 2","intermediate step 3","jump"},
{"source B0","B0 to B1","B1 S1 to B1 S2","B1 S2 to B1 S3","B0 to B1 S3"},
{ds[B0,S0],
ds[B1,S1]=ds[B0,S0][All,All,transformElements[{"B0","B1"}]],
ds[B1,S2]=ds[B1,S1][All,transformDates[{"B0","B1"}]["z"]],
ds[B1,S3,F1]=ds[B1,S2][All,replaceTransform[V1]],

ds[B1,S3,F2]=ds[B0,S0][All,All,transformElements[{"B0","B1"}]][All,transformDates[{"B0","B1"}]["z"]][All,replaceTransform[V1]]
(*
ds[B1,S3,F2]=datasetTransform[{"B0","B1"},V1][ ds[B0,S1],transform[{"B0","B1"},V1] ][All,replaceTransform[1]]
*)
}
}]

We can diff datasets ds[B1,S3,F1] and ds[B1,S3,F2] to validate equivalence (or not).  This technical is used for intra and inter branch dataset diff’ing.

rgReplace=Replace[{False-> Style[False,Red],True-> Style[True,Darker[Green]]}];

Grid[{
{"ds[B1,S3,F1]","ds[B1,S3,F2]","SameQ"},
{
ds[B1,S3,F1],
 ds[B1,S3,F2],
{ds[B1,S3,F1],ds[B1,S3,F2]}//Map[Normal]//Merge[Merge[Apply[SameQ]]]//Dataset/*Query[All,All,rgReplace]
}
}]

Case iii) Make a new branch.

First a rule sets

4.5) What Head[ ] scenarios are exhibited in the dataset?

TF Head Scenario Table

How to get there

xyzRules[V1]=Replace[{
{x_/;x>0,y_:("a"|"b"),z_DateObject}:> DatePlus[z,x],
{x_/;x<0,y_String,z_DateObject}:> DatePlus[z,x],
{x_/;x==0,y_:"c",z_DateObject}:> z,
{x_?NumberQ,y_,z_Missing}:> Missing[<|"y"->y,"z"->z|>],
{x_Missing,y_String,z_Missing}:> Missing[<|"a"->a,"z"->z|>],
{x_,y_,z_}:> Missing[<|"comment"-> "additional rules may be needed."|>]
}];

newDates[V1]=Query[<|"new date"-> Query[{"x","y","z"}]/*Values/*xyzRules[V1]|>];

Grid[{
{"ds[B1,S3,F2]","ds[B2,S1]"},
{ds[B1,S3,F2],
ds[B2,S1]=ds[B1,S3,F2][All,Query[{Query[{"x","y"}],newDates[V1]}]/*Apply[Join]]}
}]

now run TF matrix...

validation[TF,V1]=GroupBy[
Query[<|
"x"->"x"/*(MissingQ[#]==False&),
"y"->"y"/*(MissingQ[#]==False&),
"new date"->"new date"/*(MissingQ[#]==False&)
|>]
];

validationQuery[V1]=Query[{
Keys,
Query[All,Length]/*Query[{
Identity,
Query[{Identity,Total}]/* (First[#]/Last[#]&)
}/*Merge[AssociationThread[{"count","percent"},#]&]]/*Values
}/*MapThread[Join]];

validationDS[B1,S1,V1]=ds[B2,S1][validation[TF,V1]][validationQuery[V1]][All,All,rgReplace]

Summary of dataset illustration: Automated upfront data management matters

The data of an object (like an account) evolves over time from state to state.  Being able to catalog all valid data scenarios per state opens the door to up front data validation of first time loads of historical data and the daily new data coming into the system.  This auto-assist preemptive data triage, rather than lenient data capture policy, assures superior historical reporting and model valuation, and produces a source of audit quality data for the organization.  Each scenario is a group of accounts that can extracted and examined at all deeper branches all the way to the source data.  This permits an analysis to determine if new rules need to be added to a transformation step, discover source system processing errors or omissions, correct source data, or updated permitted scenarios for a model state.

TF head table for acceptable data scenarios in the inhouse account state.

TF head table for acceptable data scenarios in the closed account state.

Presentation Summary

There are many constituents that have direct interests in making sure healthcare providers are financially healthy.  Current financial information is sorely lacking the ability to accurately inform the constituents.  Current measurement methods and process lack the timeliness, consistency, and hence trustworthiness needed to obtain precision and confidence.  The lack of automation in the data preparation and computation steps are a critical economic hurdle to ever attaining the needed financial information at the proscribed precision.  This presentation has shown, in a limited way, how source claim, remit, and accounting data are processed in a semi-automated way (full automation is in the road map) for preparation of the computation needed to generate models needed to compute benchmarks, forecasts, probabilities, estimates consistently and simultaneously useful to all the constituents.  This with the added advantage that any constituent (as permitted) can audit the data used to generate the models, historical reports, forecasts reports and back-test reports.