Page Comparison

...

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:

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

...

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: