Date

14 Jun 2022

Antitrust Policy

Attendees

Sean Bohan (openIDL)
PeterA
James Madison
Dale Harris
Brian Hoffman
Greg WIlliams
Ken Sayers
James MAdison
Truma Esmond
Nathan Southern
Tsvetan Georgiev
Joan Zerkovich

Agenda:

Continuing Discussion of Requirements from Architecture WG Call 6/6/2022
1. openIDL - System Requirements Table (DaleH @ Travelers)

Time	Item	Who	Notes

Action items

Notes:

PeterA
Current arch using MongoDB
(Shows alabama coverage doc - see recording)
Experimenting with extraction patterns
few weeks: update on feasibility, extract pattern in Mongo might look like
DavidR - Mongo?
PeterA
Current existing arch, single table using Map Reduce
giving report back in a couple weeks
show feasibility
Ken - POC to get thru stat reporting
DavidR - trying in Mongo a great idea as POC
PeterA - reviewing with actuarial team, experiment
DavidR - if successful, maybe load existing into Mongo
great idea
James - Mongo where we currently are, not necessarily where we are gonna be
wretched idea
document store DBs for document store
problem - queries in the future, all doable, but arbitrary structures, glorious to load
prob - pull stuff out of it, meaningful relationships problems at scale
DavidR - good reqs help - extremely complex, very Varied, ad hoc, but things like stat reporting prob fine, performance isnt AS important - maybe works, maybe simplicity ok
James - looks forward to seeing that query
PeterA - hard right now, way require stat records, sit and cases where you have mult coverages, all tied together, maybe better off being more policy oriented, having to combine all these stat recpords to build policy then do aggregations
KenS - dont have policy term. dont have that in the stat data, dont have "effective date"
James
Mong - easy to make arbitrary stuctures
structure prob
DavidR - do believe there is a lot of value exposing what is there
always get the stat plan report at the end
saying has "limited value to them"
thesis - if they have the ability to build versions of this, not completely diff, but ask targeted questions with existing data, a lot of lift there
PeterA - how many diff patterns of extractions are common
similar processing as earned premium
w/ Mongo a lot of processing that has to happen in the query
like idea of mult layers
James - all ffor JSON, what is more structured on the right? stat reports limited value, data calls provide value
do we have an archetype of a data call that happens over and over - x% have same basic pattern
DavidR - don't know if complxity is requisite yet
if there are VERY complex data calls, maybe 2 choices, more performant, more queryable OR maybe more static and put more complexity on the query side
aovoid very complext data store wihtout being sure
Joan - all req for current stat reporting uploaded to the wiki
annual stat reporting goes to regulators, fixed for some time, Sandra on DMWG working with NAIC
1200 diff data calls gathered from different states - any state can request any data element
stat reporitng one of many ways it will be used
struggled with fixed requirements - idea of openIDL you have data store where you have flexibility
DavidR - REgs - "can I get more current data"
Joan - AAIS has done RR for so long - REGS want granular AND timliness, reports more than zipcode level, address level into a repository, timliness - high on the priority, mentioned before independent there are requests 12 months ahead of past requests
old model is a struggle
one DB doesnt need to be end all and be all of all DB
original stat reporting has polcy and claims data, but have diff ways of joining info, doesnt have to be all built into stat reporting HDS
think of this as one part of many diff types of DB available to answer REG questions
baseline set of polciy and claims data that have more granularity and much quicker THEN we c an think about joining other info to that
keep the design of the initial datastore simple to meet first two criteria
extremely large and complex DB carriers are used to - this data store should not be that complex
Truman - solve prob of arch struggle, only have one - opp for diff analytics nodes for diff purposes
only one network does one thing and therefore must do everything
create a seat for AAIS or IPSO of ND and they can deploy analytics node, they can do what they want
the only place extract patterns are coming from is openIDL
Joan - good conv
echo what truman is mentioning here
carrier nodes with HDS, intention not to be extremely complex, but granualrity and timliness
answer future data calls, can be a network of diff types of data stores, dont have to figure out here
<missed comments>
Truman - focus model on being policy centric
policy - centered model, telling us historical transactional data, in a month time period, coverage level
datastore should have ideally
reporting required for that carrier
some things increasingly timely, policy effective date, more timely access to the information, future looking data would be helpful
JeffB - may use one datastore as staging and derive other things from it
TRuman - not just staging, sequencing of data and what comes from it, daily transax coming from agent - other data stores a company can deploy analytics node
JeffB - starting point
Joan - requirements, specify data elements, when things need to be reported to REGS, baseline for reporting to happen
other elements to be requested
stat reporitng pretty straighhtforward
elements per product line, avail on annual basis gor other reports
handbook is the start, 1200 other types of reqs
"pull these reqs, perform function on them, report this way"
we dont need to go through extensive biz req process
need to get data elements from 1200 diff reports, first thing of value define them, no consistent data model across P&C insurance industry
called one thing by one state, another by another
once HDS designed, common platform foe all reports REGS are asking for
more imp to discuss "what is HDS, create reportts, analytics node "
spending a lot of time on HDS - dont want to spend too much time on it
summarized list of data elements to this group
NAIC handbook reqs
those are the reqs - if the group want to kno what stat reporting is, thats it
DavidR - what is more granular mean? lets write design thinking sessions as requirements - if someone isnt intimately familair with stat reportiyn ghandbook, thrwoing that into reqs ian't helpfuli
if it makes sense to put in dM WG reqs
document Dale made, which is fantastic
"here are the ones that matter"
might matter to analuytics node, key componotens to how we build HDS
Joan - simeple in the handbook
heart of all stat reporting
find straightforward
Dale - doesnt tell us how openIDL should function
we ended off on IR 13 yea
JeffB - diff components for entire system - good luck peter
PeterA - indexing and breaking out reporting reqs into consumable manner - can give update on Monday 6/20
JeffB - informative, great to see
Joan - agree Dale, what we want openIDL in the future, helpoing do that
just get started, what the baseline reqs are
we need a working sessionm with technical team to get thru reqs to get everyone up to speed, simple really
agree with dale and brian and others, prefer this do something better, where the reqs work is helping, baseline reqs for stat reporitng
working session
Peter - take every line, break out by coverages, sometimes regionally/not regiounally, break out by coverage and loss, secondary thing - what is the value of "address" - want to know what the value of is "2 miles from coast"
come up with the risk area
DavidR
traceability
story-requirements
need is to document that user story, decompose to requirement
cant be something we all keep in our heads
good reqs def key to any project
und what we are all going to, documented at least at user story level
JeffB - can get to that in more detail
DavidR - thought thats where we were
PeterA - find data elements and repro - auto is pretty darn close -
Dale - auto is set, met REGS, reqs for stat handbook, addressed all regs are looking for in terms of data
impatient because we are not building anything
cant build until get reqs done so others can battle out how we put things together
David -James and I both have a POV on what we should build but no definition on which direction to go
nowhere to make decision "doc db not acceptable", if you want me to build for the future I need reqs
Jaon - peter building examples to see
issue - lack of exp with stat reporitng
we do have auto, can build this out so people can see how stat reporitng is done
trumans point - second way of propcessing this data is on analytics node
so poeple can see what HDS is for autor, how stat reporting reqs met, w/ HDS you can without doing additional work can begin to participate with ND in uninsured motorist app
get to examples here
Dales reqs are good
using those and making decision
maybe its the example thats needed
Brian - und but can we not bring in ND
large carriers here dont write biz in ND
distraction
hear about ND
here spending a ton of money to build stat repoting
Joan - point is that we are tyring to explain knowing every possible use case for stat data not needed
exp just get auto data standard built in HDS, if this focuses on this, show you dont need to know today and build today - simplify process to get HDS pulled together acc Dale's res, build stat reports, get experience, make it more clear
Brian - 100% agree, build HDS, show other things to do, please REGS, get it
DavidR - good place, but side of XYZ/ABC down the road
if we keep saying "yeah but" we gotta write it down
right now, very clear, Peter doing great job, but then detour about being more flexible
dont want to be that flex, if we keep discussing it, written down in concrete terms
Joan
Stat reporting, data reqs very simple
offering to have asession, go through reqs, cover auto (dale did auto data model)
simplify it
concern or
David - ok with auto model reqs
concern - xyz and not a requirement for it
seeing "complexity level is sufficient lets build it"
happy with whats here now, as progressing down, next level to bridge what james /dale has
wants biz req written down
happy where we are if we just build
Peter - what % of data calls does TRavelers do vs AAIS
Dale - all stat reporting in my group, has only 300 data calls
Peter - working with state DOI reports
seen what a lot look like
how many data calls break general mold
Dale - beyond specifics looking for policy counts
tricky - parameters they are looking for of that data - zipcode, deductible, something else
builk of extract patterns come through, how they want the patterns sliced and diced
getting to that slicing and dicing
James - metrics by attribution
if we look at these exhibits - metrics by attributes, structures quickly, gets close to somethign to execute on
get into those reqs
take and put into industry standard for for model like this
Kimbal model
heavily inform model
Peter
IR.13

Recording:

Browser not supported