...
Data Attestation (boil down to tighter discussion Ken Sayers )
- do we have an automated way to attest to data?
- cannot attest completeness
- Provide data attestation function. Carrier attests to data for a particular date. Attestation parameters? Data attested, time frame (last data of complete transactional data), level of data (must define for attestation: like stat reporting day 0, 1, 2)
- different attestation for claims and premium data
- Must have data formats / levels defined for attestation
- on extraction - check last attested date. If last attested date meets requirement of data call.
- attesting to the quality of the data (meets 5% error constraint for data from x to y dates)
Raw Notes
- Have it or don't by time period
- Assumption - run report, everyone is always up to date with data, loading thru stat plan, data has been fixed in edit process, ask for 2021 data its there
- Automated query cant tell if data is there, may have transax that haven't processed, dont know complete until someone says complete
- Never in position to say "complete" due to late transax
- If someone queries data on Dec 31, midday. not complete - transax occur that day but get loaded Jan 3 - never a time where it is "COMPLETE"
- Time complete = when requested - 2 ways - 1 whenever Trav writes data, "data is good as of X date" metadata attached, Trav writes business rules for that date, OR business logic on extract "as long as date is one day earlier" = data valid as of transax written
- Manual insertion - might not put more data in there, assume complete as of this date
- Making req on Dec 31, may not have Dec data in there (might be Nov as of Dec 31)
- Request itself - I have to have data up to this date - every query will have diff param, data it wants, cant say "I have data for all purposes as of this date"
- 2 dates: 12/31 load date and the effective date of information (thru Nov 30)
- Point - could use metadata about insertion OR the actual data, could use one, both or either
- Data bi-temporal, need both dates, could do both or either, could say if Trv wrote data on Jan 3, assumption all thru 12/31 is good
- May not be valid, mistake in a load, errors back and fixing it - need to assert MANUYALLY the data is complete as of a cert time
- 3-4 days to load a months data, at the end of the job, some assertion as to when data is complete
- most likely as this gets implemented it will be a job that does the loading, not someone attensting attesting to data as of this date -where manual attestation becomes less valuable overe time
- as loads written (biz rule, etc.) If we load on X date it is valid - X weeks, business rule, not manual attestation - maybe using last transax date is just as good - if Dec 31 is last tranx date, not valid yet - if Dec 31 is last transax date then Jan 1
- Data for last year - build into system you cant have that for a month
- Start with MANUAL attestation and move towards automated
- Data thru edit and used for SR, data trailing by 2 years
- doesnt doesn't need to be trailing
- submission deadline to get data in within 2 years then reconciliation, these reports are trailing - uncomfortable with tis constraint
- our ? is the data good, are we running up to this end date, not so much about initial transax than claims process
- May have report that wants 2021 data in 2023 bug 2021 data updated in 2022
- Attestation is rolling, constantly changing, edit package and sdma is not reconciliatioj it is business logic - doesnt have to be trailing
- As loading data, whats the last date loaded, attestation date
- sticky - go back x years a report might want, not sure you can attest to
- decoupling attestation from a given report (data current as of x date),
- everyting everything up to the date my attestation is up to date in the system
- "Data is good through x date" not attesting to period
- Monkey Wrench: Policy data, our data is good as of Mar 2022 all 2021 data is up to date BUT Loss (incurred and paid) could go 10 years into future
- some should be Biz Logic built into extrat extract pattern - saying in HDS< good to what we know as of this date, not saying complete but "good to what we know" - if we want to dome somethign with EP, "I will only use data greater than X months old as policy evolves
- Loss exposure - all losses resolved, 10 years ahead of date of assertion, as of this date go back 10 years
- decouple this from any specific data call or stat report - on the report writer
- 2 assertion dates - one for policy vs one for claim
- not saying good complete data, saying accurate to best of knowledge at date x
- only thing changing is loss side
- saying data is accurate to this point in time, as of this date we dont have any claim transax on this policy as of this date
- adding "comfort level" to extraction? - when you req data you will not req for policies in last 5 years - but if i am eric, wants to und market, cares about attestation I can give in March
...
{"serverDuration": 286, "requestCorrelationId": "0c03a43e62a4e0b0"}