Datasjabloon: claimafhandeling
Uw datasjabloon voor schadeafhandeling
- Aanbevolen attributen om vast te leggen
- Belangrijkste activiteiten om te monitoren
- Richtlijnen voor data-extractie uit Duck Creek Claims
Attributen van de schadeafhandeling
| Naam | Beschrijving | ||
|---|---|---|---|
Activiteitsnaam ActivityName | De naam van de bedrijfsactiviteit of het event dat op een bepaald moment bij een claim heeft plaatsgevonden. | ||
Beschrijving Dit attribuut beschrijft een specifieke stap of taak binnen het claimproces, zoals 'Claim Submitted', 'Adjuster Assigned' of 'Payment Issued'. Elke activiteit vormt een afzonderlijk moment in de levenscyclus van een claim. Het analyseren van de volgorde en frequentie van deze activiteiten is de kern van process mining. Zo ontdek je het feitelijke procesmodel, spoor je knelpunten op, herken je rework-lussen en analyseer je procesafwijkingen ten opzichte van een referentiemodel. Waarom het belangrijk is De naam van de activiteit bepaalt de stappen in het proces en is essentieel om het schadeproces in kaart te brengen, te analyseren en te monitoren. Waar te verkrijgen Wordt doorgaans afgeleid uit eventlogs, transactienamen of statuswijzigingsrecords binnen Duck Creek Claims. Dit kan betekenen dat een mapping nodig is vanuit meerdere bronvelden of tabellen. Voorbeelden Claim ingediendSchadebehandelaar toegewezenOnderzoek gestartBetaling uitgeschrevenClaim afgesloten | |||
Claim-ID ClaimId | De unieke ID voor één schadedossier; de primaire case-ID. | ||
Beschrijving Het Claim ID is de sleutel die alle events en activiteiten van één schadedossier verbindt, van melding tot sluiting. Zo kan de volledige levenscyclus van een claim consistent worden gevolgd. Binnen process mining is dit attribuut cruciaal voor de caseweergave. Het stelt analisten in staat het volledige traject van elke claim te volgen, end-to-end doorlooptijden te meten en procesvarianten te analyseren. Waarom het belangrijk is Dit is de essentiële Case ID die alle gerelateerde events in het proces koppelt en daarmee een volledig end-to-end beeld van de levenscyclus van de claim mogelijk maakt. Waar te verkrijgen Dit is een primary key in de hoofdentiteit of -tabel voor claims binnen Duck Creek Claims. Raadpleeg de systeemdocumentatie voor de exacte tabel- en veldnaam. Voorbeelden CL-2023-001234CL-2023-005678CL-2024-009101 | |||
Tijdstip Gebeurtenis EventTime | De timestamp die aangeeft wanneer een specifieke activiteit of een event heeft plaatsgevonden. | ||
Beschrijving Event Time bevat de exacte datum en tijd van elke activiteit in de levenscyclus van een claim. Die tijdsinformatie is cruciaal voor prestatie-analyses. In de analyse wordt deze timestamp gebruikt om doorlooptijden tussen activiteiten te berekenen, wachttijden te identificeren, de totale caseduur te meten en procesprestaties over verschillende perioden te vergelijken. Het is de ruggengraat van elke tijdgebonden procesmetriek. Waarom het belangrijk is Deze timestamp is cruciaal voor het berekenen van alle tijdsgebonden metrics, zoals doorlooptijden en activiteitsduren, en maakt prestatieanalyse en het identificeren van knelpunten mogelijk. Waar te verkrijgen Dit is een standaard timestampveld dat hoort bij event- of transactielogs in Duck Creek Claims. Zoek naar velden als 'CreateDate', 'Timestamp' of 'EventDate'. Voorbeelden 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
Afdeling Department | De afdeling of het team dat op dat moment verantwoordelijk is voor de activiteit of de claim. | ||
Beschrijving Dit attribuut specificeert de functionele groep of afdeling, zoals 'Initial Intake', 'Investigation Unit' of 'Settlement Team', die de claim behandelt. Het geeft organisatorische context aan de procesflow. Analyseren per afdeling is essentieel om procesprestaties op aggregatieniveau te begrijpen. Het helpt interdepartementale knelpunten bloot te leggen, efficiëntie op teamniveau te meten en inzichtelijk te maken hoe werk door de organisatie stroomt. Waarom het belangrijk is Maakt prestatieanalyse per functiegebied mogelijk en legt overdrachten tussen afdelingen en teamspecifieke knelpunten bloot. Waar te verkrijgen Raadpleeg de documentatie van Duck Creek Claims. Deze informatie is vaak gekoppeld aan het profiel van de toegewezen gebruiker of aan een toewijzing aan een queue of workgroup. Voorbeelden AutoschadeclaimsSchade aan eigendom – grote schadeAfdeling Bijzondere OnderzoekenBetalingsverwerking | |||
Claimstatus ClaimStatus | De algemene status van de claim op een bepaald moment, zoals Open, In behandeling of Gesloten. | ||
Beschrijving Claimstatus geeft de huidige fase van de claim in de levenscyclus weer. Het biedt een overzicht op hoofdlijnen van waar de claim zich in het totale proces bevindt. Dit attribuut is nuttig om een overzicht op hoofdlijnen van de claimvoorraad te maken en om cases te filteren. Het is vooral belangrijk om de einduitkomst van een claim te identificeren (bijv. 'Gesloten - Uitbetaald', 'Gesloten - Afgewezen'), wat essentieel is voor uitkomstenanalyse en het begrijpen van afwijspercentages. Waarom het belangrijk is Geeft een momentopname van de huidige status en het eindresultaat van de claim—essentieel voor uitkomstanalyse en het filteren van cases. Waar te verkrijgen Raadpleeg de documentatie van Duck Creek Claims. Dit is een fundamenteel veld op het hoofdrecord van de claim. Voorbeelden OpenIn afwachting van informatieGesloten - AfgewikkeldGesloten - Afgewezen | |||
Claimtype ClaimType | De categorie van de claim, zoals Auto, Brand/Inboedel of Aansprakelijkheid. | ||
Beschrijving Claimtype classificeert claims op basis van de productlijn of de aard van de schade. Dit is een fundamentele dimensie voor het segmenteren en analyseren van claimdata. Dit attribuut wordt gebruikt om de procesprestaties tussen verschillende claimtypen te vergelijken. Zo volgt een 'Auto - Total Loss'-claim een heel ander proces en heeft die andere KPI's dan een 'Property - Water Damage'-claim. Analyseren op claimtype biedt context en maakt zinvollere prestatievergelijkingen en gerichte procesverbeteringen mogelijk. Waarom het belangrijk is Dit is een cruciale dimensie om analyses te segmenteren, omdat verschillende claimtypes vaak eigen processen, SLA's en complexiteitsniveaus hebben. Waar te verkrijgen Raadpleeg de documentatie van Duck Creek Claims. Dit is een kernattribuut op het hoofdrecord van de claim. Voorbeelden Particuliere auto – aanrijdingCommercieel vastgoed - BrandArbeidsongevallenverzekeringAlgemene aansprakelijkheid | |||
Ernst van de claim ClaimSeverity | Een indeling van de financiële of operationele complexiteit van de claim, bijvoorbeeld Laag, Gemiddeld of Hoog. | ||
Beschrijving Ernst van de claim geeft aan wat de verwachte impact of complexiteit van een claim is. Dit kan gebaseerd zijn op de initiële schaderaming, de aard van het incident of andere vooraf gedefinieerde bedrijfsregels. Dit attribuut is cruciaal voor prestatieanalyse, omdat claims met een hoge ernst doorgaans meer stappen, langere doorlooptijden en gespecialiseerde resources vragen. KPI's segmenteren op ernst helpt realistische prestatiedoelen te stellen en te begrijpen hoe complexiteit de procesefficiëntie en uitkomsten beïnvloedt. Waarom het belangrijk is Helpt claims naar complexiteit te segmenteren, waardoor je prestaties genuanceerder kunt analyseren en realistische benchmarks voor doorlooptijden en kosten kunt hanteren. Waar te verkrijgen Raadpleeg de documentatie van Duck Creek Claims. Dit kan een apart veld zijn of worden afgeleid van de initiële schadereserve. Voorbeelden LaagGemiddeldHoogCatastrofaal | |||
Schadebedrag LossAmount | Het geschatte of werkelijke schadebedrag dat in de claim is opgegeven. | ||
Beschrijving Dit attribuut staat voor de aanvankelijk geschatte waarde van de schade die bij de claim hoort. Het is een belangrijke financiële metriek die vaak de routering, ernst en de benodigde diepgang van onderzoek beïnvloedt. In analyses wordt het schadebedrag gebruikt om claims te segmenteren en te begrijpen hoe financiële impact samenhangt met procesgedrag. Zo volgen claims met hogere bedragen vaak andere paden of hebben ze langere doorlooptijden. Het biedt cruciale financiële context naast de operationele procesdata. Waarom het belangrijk is Geeft financiële context aan de claim, zodat je kunt analyseren hoe de waarde van een claim het procespad, de doorlooptijd en de uitkomst beïnvloedt. Waar te verkrijgen Raadpleeg de documentatie van Duck Creek Claims. Dit is een essentieel financieel veld binnen de claim, vaak aangeduid als 'Reported Loss' of 'Initial Reserve'. Voorbeelden 1500.0025000.50125000.00 | |||
Toegewezen schadebehandelaar AssignedAdjuster | De naam of ID van de schadebehandelaar die voor een bepaalde activiteit verantwoordelijk is. | ||
Beschrijving Dit attribuut identificeert de gebruiker of resource die een activiteit uitvoert. Dit kan wisselen gedurende de levenscyclus van de claim wanneer de zaak wordt overgedragen tussen schadebehandelaars of teams. Dit is essentieel voor het analyseren van prestaties per resource, werkverdeling en overdrachten. Dashboards over doorvoer per schadebehandelaar, verschillen in werkdruk en het opsporen van knelpunten leunen sterk op dit attribuut om te zien hoe werk wordt toegewezen en door individuele medewerkers wordt afgehandeld. Waarom het belangrijk is Maakt analyse mogelijk van resourceprestaties, werkverdeling en werkbelasting, en samenwerkingspatronen, zodat knelpunten en opleidingsbehoeften zichtbaar worden. Waar te verkrijgen Raadpleeg de documentatie van Duck Creek Claims. Zoek naar de velden user, owner of assignee in tabellen die betrekking hebben op claimtaken, events of de primaire claimentiteit. Voorbeelden John SmithJane DoeRobert Brownadjuster_1138 | |||
Behandelingstijd ProcessingTime | De actieve verwerkingstijd van een activiteit, berekend als Eindtijd minus Starttijd. | ||
Beschrijving Behandelingstijd, ook wel ‘active time’ of ‘handling time’, meet hoe lang een resource actief aan een specifieke taak heeft gewerkt. Dit wordt berekend door de StartTime van de EndTime van een activiteit af te trekken. Deze meetwaarde is een kernonderdeel van de prestatieanalyse. Ze helpt onderscheid te maken tussen inefficiënties door langlopende taken (hoge behandelingstijd) versus vertragingen door wachten op resources of informatie (hoge wachttijd). Dat is cruciaal om de echte bron van knelpunten te vinden. Waarom het belangrijk is Meet de actieve werktijd van een activiteit en helpt zo onderscheid te maken tussen inefficiënte taken en lange wachttijden bij het analyseren van knelpunten. Waar te verkrijgen Dit is geen veld uit het bronsysteem. Het wordt tijdens de datavoorbereiding bepaald door per activiteit 'EndTime' minus 'StartTime' te berekenen. Voorbeelden 360086400300 | |||
Bronsysteem SourceSystem | Het systeem waaruit de eventdata is geëxtraheerd. | ||
Beschrijving Dit attribuut geeft de brontoepassing waar de claimdata vandaan komt. In deze context is dat altijd 'Duck Creek Claims'. Ook al lijkt het overbodig als alle data uit één systeem komt, voor data governance, traceerbaarheid en scenario's waarin later data uit meerdere systemen wordt samengevoegd, is het cruciaal. Het biedt context over de herkomst en structuur van de data. Waarom het belangrijk is Biedt essentiële data lineage en context—cruciaal voor data governance en troubleshooting, zeker in omgevingen met meerdere geïntegreerde systemen. Waar te verkrijgen Dit is doorgaans een statische waarde die tijdens extractie en transformatie van data wordt toegevoegd om de herkomst van de data aan te duiden. Voorbeelden Duck Creek Claims | |||
Eindtijd EndTime | De timestamp die aangeeft wanneer een activiteit is afgerond. | ||
Beschrijving Dit attribuut registreert het voltooiingstijdstip van een activiteit. StartTime geeft aan wanneer een activiteit begon, EndTime vormt de andere kant van de berekening van de duur voor die specifieke taak. Binnen process mining maakt de combinatie van start- en eindtijd een veel diepere prestatieanalyse mogelijk. Zo bereken je nauwkeurig 'Processing Time' (actieve werktijd) versus 'Waiting Time' (wachttijd tussen taken). Dat onderscheid is cruciaal om knelpunten scherp te identificeren. Waarom het belangrijk is Maakt het mogelijk om nauwkeurige doorlooptijden per activiteit te berekenen en actieve werktijd van wachttijd te onderscheiden—cruciaal voor een goede knelpuntenanalyse. Waar te verkrijgen Kan beschikbaar zijn als een apart timestamp-veld in event logs, of worden afgeleid als de StartTime van de volgende activiteit in de reeks voor hetzelfde dossier. Voorbeelden 2023-10-26T10:05:12Z2023-10-26T15:00:00Z2023-10-27T11:20:30Z | |||
Is Geautomatiseerd IsAutomated | Een booleaanse vlag (ja/nee) die aangeeft of de activiteit automatisch door het systeem is uitgevoerd zonder menselijke tussenkomst. | ||
Beschrijving Deze vlag onderscheidt taken die door menselijke gebruikers zijn voltooid van taken die door systeemautomatisering worden uitgevoerd, zoals automatische notificaties, initiële datavalidatie of straight-through processing (STP)-stappen. Analyse van dit attribuut is cruciaal om het automatiseringsniveau in het claimproces te begrijpen. Het helpt de impact van automatiseringsinitiatieven te meten, kansen voor verdere automatisering te vinden en te borgen dat geautomatiseerde stappen presteren zoals verwacht zonder verderop in het proces problemen te veroorzaken. Waarom het belangrijk is Helpt de impact van automatisering op efficiëntie en kosten te meten en identificeert kansen voor straight-through processing (STP). Waar te verkrijgen Deze informatie kan worden afgeleid uit de 'user' die aan een event is gekoppeld (bijv. 'SYSTEM' of 'BATCH'), of uit een specifieke vlag op het eventrecord. Voorbeelden truefalse | |||
Is herstelwerk IsRework | Een berekende vlag die aangeeft of een activiteit deel uitmaakt van een rework-lus. | ||
Beschrijving Dit booleaanse attribuut staat op true als een activiteit opnieuw voorkomt voor een claim nadat er andere, verschillende activiteiten hebben plaatsgevonden. Bijvoorbeeld wanneer het proces van 'Loss Assessed' teruggaat naar 'Investigation Started'. Dit attribuut is onmisbaar om rework te kwantificeren en te analyseren. Het ondersteunt de KPI 'Claim Rework Rate' en het dashboard 'Claim Rework & Reprocessing Patterns' door direct te kunnen filteren en activiteiten en cases met rework te markeren. Zo spoor je gericht inefficiënties en kwaliteitsproblemen in het proces op. Waarom het belangrijk is Maakt herwerk op activiteiteniveau meetbaar, zodat je oorzaken en impact van procesinefficiënties eenvoudig kunt visualiseren en analyseren. Waar te verkrijgen Dit is geen veld uit het bronsysteem. Het wordt tijdens de datavoorbereiding berekend met algoritmen die herhaalde reeksen activiteiten binnen een claimdossier opsporen. Voorbeelden truefalse | |||
Laatste data-update LastDataUpdate | De timestamp van de meest recente gegevensverversing uit het bronsysteem. | ||
Beschrijving Dit attribuut geeft aan wanneer de dataset voor het laatst is bijgewerkt. Het biedt een referentiepunt voor de actualiteit van de geanalyseerde data. In dashboards en analyses laat dit zien hoe recent de inzichten zijn. Het helpt verwachtingen te sturen over de vraag of de meest recente transacties in de procesweergave zijn opgenomen. Waarom het belangrijk is Laat zien hoe actueel de data is, cruciaal om analyses goed te interpreteren en tijdig te beslissen. Waar te verkrijgen Deze timestamp wordt gegenereerd tijdens het extractie-, transformatie- en laadproces (ETL) en wordt doorgaans opgeslagen in de metadata van de dataset. Voorbeelden 2024-05-21T02:00:00Z | |||
Op tijd afgehandeld IsOnTimeResolution | Een berekende vlag die aangeeft of een claim op of vóór de streefdatum voor afhandeling is gesloten. | ||
Beschrijving Dit booleaanse attribuut wordt afgeleid door de timestamp van de activiteit 'Claim Closed' te vergelijken met de 'ResolutionTargetDate' van die claim. Elke claim wordt gemarkeerd als op tijd (true) of te laat (false). Dit attribuut ondersteunt direct de KPI 'On-Time Claim Resolution Rate'. Het maakt eenvoudige aggregatie en visualisatie van SLA-naleving in dashboards mogelijk en biedt drill-downanalyse om veelvoorkomende kenmerken van te late claims te achterhalen (bijv. specifieke claimtypes, afdelingen of procespaden). Waarom het belangrijk is Meet SLA-naleving per claim, met krachtige filters en root cause-analyse voor achterstallige claims. Waar te verkrijgen Dit is geen bronsysteemveld. Het wordt tijdens de datavoorbereiding berekend door de timestamp van de laatste activiteit te vergelijken met het veld 'ResolutionTargetDate'. Voorbeelden truefalse | |||
Polisnummer PolicyNumber | De unieke polis-ID waaronder de claim is ingediend. | ||
Beschrijving Dit attribuut koppelt de claim aan de onderliggende verzekeringspolis. Het geeft context over dekking, voorwaarden en de klant die bij de claim hoort. Hoewel het niet altijd direct wordt gebruikt in de procesanalyse, is het 'Policy Number' zeer waardevol om claimdata te verrijken. Zo kun je koppelen met polis- en klantdata om te analyseren hoe de procesprestaties verschillen per klantsegment, polistype of polisleeftijd, en krijg je een completer bedrijfsbeeld. Waarom het belangrijk is Koppelt de claim aan klant en polis, zodat je breder kunt analyseren hoe procesprestaties verschillen per klantsegment of polistypen. Waar te verkrijgen Raadpleeg de documentatie van Duck Creek Claims. Dit is een standaardreferentieveld op de primaire claimentiteit. Voorbeelden PA-987654321CP-123456789WC-555444333 | |||
Reden van afwijzing RejectionReason | De specifieke reden waarom een claim is afgewezen. | ||
Beschrijving Wanneer besloten wordt een claim af te wijzen, geeft dit attribuut de onderliggende reden voor die beslissing. Meestal wordt gekozen uit een vooraf gedefinieerde lijst met codes of omschrijvingen. Het analyseren van afwijsredenen is cruciaal voor het dashboard 'Claim Decision & Rejection Insights'. Het helpt veelvoorkomende problemen in claims te identificeren, mogelijke fraudepatronen te herkennen en gebieden aan te wijzen waar polisvoorwaarden onduidelijk zijn. Deze inzichten sturen verbeteringen in het intakeproces of de acceptatieregels. Waarom het belangrijk is Legt uit waarom claims worden afgewezen en biedt concrete inzichten om de intake te verbeteren, ongeldige inzendingen te verminderen en trainingskansen te identificeren. Waar te verkrijgen Raadpleeg de documentatie van Duck Creek Claims. Dit veld wordt doorgaans gevuld zodra de status van een claim wijzigt naar 'Denied' of een vergelijkbare status. Voorbeelden Niet-gedekt risicoPolis verlopenDubbele claimVermoeden van fraude | |||
Streefdatum afhandeling ResolutionTargetDate | De streefdatum waarop de claim naar verwachting is afgehandeld, gebaseerd op SLA's of interne doelen. | ||
Beschrijving Dit attribuut slaat de uiterste datum op voor het sluiten van een claim. Deze datum is vaak bepaald door wet- en regelgeving, service level agreements (SLA's) of interne key performance indicators (KPI's) en kan variëren per claimtype of ernst. Dit is de basis voor de berekening van de KPI 'On-Time Claim Resolution Rate' en ondersteunt het dashboard 'Claim Resolution Target Adherence'. Zo kun je claims die het risico lopen hun SLA te overschrijden proactief monitoren en het werk prioriteren. Waarom het belangrijk is Stelt je in staat prestaties te meten ten opzichte van service level agreements (SLA's) en interne doelstellingen, met directe impact op klanttevredenheid en compliance. Waar te verkrijgen Raadpleeg de documentatie van Duck Creek Claims. Dit kan een specifiek SLA-datumveld zijn of worden berekend op basis van de indieningsdatum van de claim en de bedrijfsregels. Voorbeelden 2023-11-15T23:59:59Z2024-01-20T23:59:59Z2024-03-01T23:59:59Z | |||
Uitkeringsbedrag SettlementAmount | Het definitief overeengekomen bedrag voor de afwikkeling van de claim. | ||
Beschrijving Dit attribuut legt het uitkeringsbedrag vast dat is berekend en geautoriseerd voor betaling. Dit is een belangrijke resultaatgerichte metriek voor elke claim die tot een uitbetaling leidt. Dit attribuut is cruciaal voor financiële analyses en voor dashboards zoals 'Payment Authorization & Issuance Time'. Je kunt het vergelijken met het initiële 'Loss Amount' om de juistheid van reserveringen te beoordelen en het is essentieel om de financiële uitkomsten van het claimproces te begrijpen. Waarom het belangrijk is Staat voor het belangrijkste financiële resultaat van een claim; essentieel voor financiële rapportage en het toetsen van de nauwkeurigheid van de eerste schaderamingen. Waar te verkrijgen Raadpleeg de documentatie van Duck Creek Claims. Deze informatie wordt meestal opgeslagen in tabellen voor financiële transacties of betalingen die aan de claim zijn gekoppeld. Voorbeelden 1450.7522000.00115800.20 | |||
Activiteiten binnen de schadeafhandeling
| Activiteit | Beschrijving | ||
|---|---|---|---|
Beslissing over de claim genomen | Deze activiteit markeert de formele beslissing over de claim, zoals 'Approved', 'Partially Approved' of 'Denied'. Dit is een cruciale mijlpaal die wordt afgeleid uit een wijziging naar een definitieve beslisstatus. | ||
Waarom het belangrijk is Dit is een cruciale beslismijlpaal. De tijd tot aan dit punt en de uiteindelijke uitkomst staan centraal in de procesanalyse en in het meten van de efficiëntie. Waar te verkrijgen Afgeleid uit een wijziging in een specifiek veld 'Claim Decision' of 'Claim Status' naar een eindstatus zoals 'Approved' of 'Denied'. De bijbehorende timestamp wordt vastgelegd. Vastleggen Afgeleid uit een update van het primaire status- of beslissingsveld van de claim. Gebeurtenistype inferred | |||
Betaling geautoriseerd | Markeert de formele goedkeuring van het berekende uitkeringsbedrag. Dit is vaak een aparte stap waarbij een manager of andere autoriserende rol betrokken is, vastgelegd als een expliciete goedkeuringsactie. | ||
Waarom het belangrijk is Dit is een belangrijk controlepunt en een potentieel knelpunt vóór de uitbetaling. De doorlooptijd van 'Claim Decision Made' tot dit punt wordt gemeten met de KPI 'Average Claim Approval Time'. Waar te verkrijgen Dit is doorgaans een expliciet event in een workflow- of financiële module waar een gebruiker met specifieke rechten de betaling goedkeurt. Dit is terug te vinden in een goedkeuringslogboek. Vastleggen Een expliciet goedkeuringsmoment dat is vastgelegd in een workflow- of transactielog. Gebeurtenistype explicit | |||
Betaling uitgeschreven | Deze activiteit markeert de uitvoering van de financiële transactie om de claim uit te betalen. Het is een expliciet event dat wordt vastgelegd wanneer de betaling wordt verstuurd via cheque, EFT of andere methoden. | ||
Waarom het belangrijk is Dit geeft aan dat de financiële verplichting voor een goedgekeurde claim is afgerond. De tijd tussen 'Payment Authorized' en 'Payment Issued' laat de efficiëntie van de financiële afdeling zien. Waar te verkrijgen Afkomstig uit de financiële transactietabel in Duck Creek Claims, die alle uitgaande betalingen registreert met een specifieke transacticode en timestamp. Vastleggen Bij het verwerken van een betaling wordt een aparte logregel voor de financiële transactie aangemaakt. Gebeurtenistype explicit | |||
Claim afgesloten | Dit is de laatste activiteit en markeert de administratieve afsluiting van het schadedossier nadat de betaling is uitgevoerd of de claim is afgehandeld. Dit wordt vastgelegd bij de laatste statusupdate naar 'Closed'. | ||
Waarom het belangrijk is Deze activiteit markeert het succesvolle einde van het proces. Dit is het eindpunt voor het berekenen van de 'Gemiddelde end-to-end doorlooptijd van claims' en andere belangrijke tijdsindicatoren. Waar te verkrijgen Afgeleid uit de timestamp van de laatste statuswijziging naar 'Closed' of 'Settled' in de hoofdtabel met claimgegevens. Vastleggen Afgeleid uit het feit dat de eindstatus van de claim is ingesteld op 'Closed'. Gebeurtenistype inferred | |||
Claim afgewezen | Deze activiteit staat voor een alternatief einde van het proces waarbij de claim officieel wordt afgewezen. Dit wordt vastgelegd wanneer de eindstatus van de claim wordt ingesteld op 'Denied' of 'Rejected'. | ||
Waarom het belangrijk is Dit is een cruciale uitkomst die aparte analyse vraagt. Begrijpen waarom en wanneer claims worden afgewezen helpt om intakeprocessen te verbeteren en compliance te borgen. Waar te verkrijgen Afgeleid uit de timestamp van de laatste statuswijziging van de claim naar 'Denied', 'Rejected' of 'Closed without Payment' in de entiteitstabel voor claims. Vastleggen Afgeleid uit het feit dat de eindstatus van de claim een afwijsreden is. Gebeurtenistype inferred | |||
Claim ingediend | Dit is het eerste event en staat voor de First Notice of Loss (FNOL), de eerste schademelding bij de verzekeraar. Dit wordt meestal als een expliciete transactie vastgelegd wanneer een tussenpersoon of verzekeringnemer de eerste claimgegevens in het systeem invoert. | ||
Waarom het belangrijk is Deze activiteit markeert de start van de volledige levenscyclus van een claim. De tijd tussen dit event en daaropvolgende events is cruciaal om de totale doorlooptijd en de efficiëntie van de intake te begrijpen. Waar te verkrijgen Dit is meestal een expliciet event dat wordt vastgelegd in een claims- of FNOL-logtabel wanneer een nieuw claimrecord voor het eerst in Duck Creek Claims wordt aangemaakt. Vastleggen Event dat wordt gelogd bij het aanmaken van een nieuw claimrecord. Gebeurtenistype explicit | |||
Aanvullende informatie aangevraagd | Deze activiteit vindt plaats wanneer de schadebehandelaar vaststelt dat extra informatie nodig is en een verzoek stuurt naar de polishouder of een derde partij. Dit is vaak een expliciet event dat gekoppeld is aan de communicatie- of correspondentiemodule van het systeem. | ||
Waarom het belangrijk is Een hoge frequentie van deze activiteit kan wijzen op problemen bij de initiële dataverzameling. Het veroorzaakt bovendien veel wachttijd, wat de totale doorlooptijd negatief beïnvloedt. Waar te verkrijgen Afkomstig uit logs van uitgaande communicatie (bijv. brieven, e-mails) of uit een specifieke 'Request for Information'-transactie in Duck Creek Claims. Vastleggen Gelogd wanneer een correspondentie of taak voor het opvragen van informatie wordt aangemaakt. Gebeurtenistype explicit | |||
Aanvullende informatie ontvangen | Markeert de ontvangst van de gevraagde informatie, waardoor de claimverwerking kan doorgaan. Dit kan handmatig door de schadebehandelaar worden vastgelegd of automatisch als de informatie via een digitaal portaal is aangeleverd. | ||
Waarom het belangrijk is De tijd tussen 'Information Requested' en 'Information Received' is een cruciale wachttijd. Analyse van deze duur maakt externe afhankelijkheden en communicatieknelpunten zichtbaar. Waar te verkrijgen Dit kan een expliciet event zijn vanuit een koppeling met het documentmanagementsysteem, of een handmatige logboekaantekening of statuswijziging door de schadebehandelaar bij ontvangst van documenten. Vastleggen Event gelogd bij upload van een document of handmatige invoer door een behandelaar. Gebeurtenistype explicit | |||
Claim geregistreerd | Markeert de formele acceptatie en registratie van de ingediende claim; op dit moment wordt officieel een unieke Claim ID toegekend. Dit is vaak een geautomatiseerd systeemevent na de eerste datavalidatie. | ||
Waarom het belangrijk is Formaliseert de start van de claim en zet vervolgstappen, zoals toewijzing aan een schadebehandelaar, in gang. De tijd tussen indiening en registratie kan wijzen op problemen met datakwaliteit of systeembelasting. Waar te verkrijgen Afgeleid uit de timestamp waarop de primaire Claim ID wordt gegenereerd en de claimstatus verschuift van 'pending' of 'submitted' naar 'open' of 'registered' in de hoofdentiteitstabel voor claims. Vastleggen Afgeleid van de tijdstempel van het aanmaken van het hoofdrecord van de claim of van een statuswijziging naar 'Open'. Gebeurtenistype inferred | |||
Initiële beoordeling voltooid | Markeert de afronding van de eerste volledige beoordeling van de claim door de toegewezen schadebehandelaar. Meestal herken je dit aan een statuswijziging na toewijzing, bijvoorbeeld van 'Assigned' naar 'Under Review' of 'Investigation'. | ||
Waarom het belangrijk is Deze mijlpaal helpt de tijd tot de eerste actie door de schadebehandelaar te meten en kan wijzen op mogelijke achterstanden in de werkvoorraad. Het is het eerste belangrijke controlemoment. Waar te verkrijgen Afgeleid uit een statuswijziging in het veld voor claimstatus, bijvoorbeeld een overgang naar 'Initial Review Complete' of 'Pending Information'. De timestamp van deze statuswijziging wordt gebruikt. Vastleggen Afgeleid uit een wijziging in het claimstatusveld na toewijzing van de behandelaar. Gebeurtenistype inferred | |||
Onderzoek afgerond | Markeert het einde van het onderzoek, wanneer alle benodigde feiten zijn verzameld. Dit blijkt meestal uit een statuswijziging van 'Under Investigation' naar een beslisstatus zoals 'Pending Decision'. | ||
Waarom het belangrijk is Het afronden van het onderzoek is een belangrijke mijlpaal die de weg vrijmaakt voor de besluitvorming en de afwikkeling. Vertraging hier heeft een groot effect verderop in het proces. Waar te verkrijgen Afgeleid uit de timestamp van een update van de claimstatus van een 'investigation'-toestand naar een 'review'- of 'decision'-toestand. Vastleggen Afgeleid van een statuswijziging van de claim die het einde van de onderzoeksactiviteiten aangeeft. Gebeurtenistype inferred | |||
Onderzoek gestart | Deze activiteit geeft het begin aan van de formele onderzoeksfase van de claim. Vaak wordt dit afgeleid uit een statuswijziging naar 'Under Investigation' of een vergelijkbare status. | ||
Waarom het belangrijk is Dit markeert het begin van een arbeidsintensieve fase. Het meten van de onderzoeksduur is cruciaal voor de KPI 'Average Investigation Duration' en helpt bij het sturen van een kritisch deel van het proces. Waar te verkrijgen Afgeleid uit de timestamp van een update van de claimstatus naar 'Investigation in Progress' of 'Pending Inspection' in het hoofdstatusveld van de claim. Vastleggen Afgeleid van een statuswijziging van de claim die het begin van de onderzoeksactiviteiten aangeeft. Gebeurtenistype inferred | |||
Schade vastgesteld | Deze mijlpaal markeert het moment waarop schadereserves worden ingesteld of bijgewerkt op basis van de onderzoeksbevindingen. Dit geeft de inschatting van de financiële impact van de claim weer en wordt vastgelegd wanneer reservebedragen worden ingevoerd of aangepast. | ||
Waarom het belangrijk is Dit is een belangrijk financieel beslismoment in het proces. Analyseren wanneer dit plaatsvindt, geeft inzicht in de snelheid en nauwkeurigheid van de financiële beoordeling. Waar te verkrijgen Dit is vaak een expliciete financiële transactie die is vastgelegd in het financiële transactielogboek van de claim of in de tabel met reservegeschiedenis binnen Duck Creek Claims. Vastleggen Gelogde financiële transactie voor het instellen of bijwerken van claimreserves. Gebeurtenistype explicit | |||
Schadebehandelaar toegewezen | Dit event legt de toewijzing vast van een schadebehandelaar aan de geregistreerde claim. Het systeem registreert deze toewijzing, waardoor een helder overdrachtsmoment ontstaat en het eigenaarschap over de levenscyclus van de claim wordt vastgelegd. | ||
Waarom het belangrijk is Cruciaal om de inzet van resources, de werkdruk van schadebehandelaars en vertragingen bij toewijzing in kaart te brengen. Dit is een belangrijk overdrachtsmoment dat wachttijd kan veroorzaken. Waar te verkrijgen Wordt gevolgd via een update van het veld 'Assigned Adjuster' in de hoofdtabel met claimdata. Een historie- of auditlogboek voor dit veld levert de timestamp. Vastleggen Gelogd in de audit trail wanneer het veld voor behandelaar wordt gevuld of gewijzigd. Gebeurtenistype explicit | |||
Uitkering berekend | Na de goedkeuringsbeslissing staat deze activiteit voor het berekenen van het definitieve schikkings- of uitbetalingsbedrag. Dit kan een expliciete stap zijn of worden afgeleid uit het vastleggen van het eindbedrag in de financiële module van het systeem. | ||
Waarom het belangrijk is Deze activiteit is cruciaal om de KPI 'Settlement Rework Rate' te meten. Als deze activiteit binnen één claim meerdere keren voorkomt, duidt dat op inefficiënties, fouten of onderhandelingen in de uitkeringsfase. Waar te verkrijgen Kan een expliciete transactielogregel zijn of worden afgeleid uit updates van het veld 'Settlement Amount' in de financiële gegevens van de claim. Auditlogs op dit veld zijn de primaire bron. Vastleggen Event gelogd wanneer het definitieve uitkeringsbedrag is berekend en opgeslagen. Gebeurtenistype explicit | |||
Extractie Guides
Stappen
- Open de Duck Creek Data Hub Configuration Utility: Log in op de Duck Creek-omgeving en ga naar de Data Hub-applicatie. Je hebt de juiste rechten nodig om exportconfiguraties aan te maken of te wijzigen.
- Maak een nieuwe exporttaak aan: Start in de Data Hub-tool een nieuwe exporttaak. Geef deze een duidelijke naam, bijvoorbeeld ProcessMind_Claims_Event_Log_Export.
- Definieer de gegevensbron: Configureer de taak om te verbinden met de primaire Data Hub SQL-database. Geef de servernaam, databasenaam en inloggegevens op van een gebruiker met leesrechten op de relevante schema’s.
- Voer de extractiequery in: Ga naar de sectie voor de querydefinitie van de exporttaak. Kopieer het volledige script uit de onderstaande sectie query en plak dit in de query-editor.
- Stel queryparameters in: Ga naar de parameters in de configuratie. Definieer en vul de waarden in voor @StartDate en @EndDate die in de query worden gebruikt om het gewenste datumbereik te bepalen. Bijvoorbeeld '2023-01-01' en '2023-12-31'.
- Koppel de outputkolommen: Stel de instellingen voor het outputbestand in. Zorg dat de kolommen uit de SELECT-instructie (ClaimId, ActivityName, EventTime, enz.) correct worden gekoppeld aan de kolommen in het outputbestand. De kolomkoppen in het outputbestand moeten exact overeenkomen.
- Configureer het outputbestand: Kies CSV als bestandsformaat. Stel het scheidingsteken in op een komma (,) en gebruik UTF-8 als tekencodering voor compatibiliteit met ProcessMind.
- Bepaal de bestemming: Geef het pad of de netwerklocatie op waar het gegenereerde CSV-bestand wordt opgeslagen. Zorg dat het systeem schrijfrechten heeft op deze locatie.
- Plan de exporttaak: Stel een schema in voor de taak. Voor een eerste analyse kun je deze handmatig uitvoeren. Voor doorlopend monitoren stel je een terugkerend schema in (bijv. dagelijks of wekelijks).
- Voer uit en haal het bestand op: Voer de taak uit om het eventlog te genereren. Haal na voltooiing het CSV-bestand op van de in stap 8 opgegeven bestemming.
- Voorbereiden op upload: Open vóór de upload naar ProcessMind het CSV-bestand voor een laatste check. Controleer of de kopteksten kloppen, het datumformaat consistent is (YYYY-MM-DD HH:MI:SS) en de gegevens er goed uitzien.
Configuratie
- Vereisten: Toegang tot de Duck Creek Data Hub-module is vereist. De gebruiker of het serviceaccount dat de exportjob draait, moet leesrechten hebben op de onderliggende databasetabellen van de Data Hub (bijv. [DataHubSchema].[FactClaimTransaction], [DataHubSchema].[DimClaim], [DataHubSchema].[DimStatusHistory]).
- Datumbereik instellen: De query gebruikt de parameters @StartDate en @EndDate. Het is essentieel om deze in te stellen om de extractieperiode te bepalen. Voor een eerste analyse wordt een periode van 6–12 maanden aanbevolen om voldoende afgeronde en lopende dossiers te verzamelen.
- Filtering: De query bevat een placeholder /* AND DC.LineOfBusiness IN ('[Your_LOB_Filter]') */ binnen de Common Table Expression (CTE). Verwijder de commentaartekens en pas deze regel aan om te filteren op specifieke Lines of Business (bijv. 'Personal Auto', 'Commercial Property') om het datavolume te beperken en de analyse te richten.
- Ververscyclus van de Data Hub: Houd rekening met de latentie van de Data Hub. De data is niet real-time en wordt doorgaans volgens een schema ververst (bijv. ’s nachts). De geëxtraheerde data is actueel tot en met de laatste succesvolle Data Hub-verversing.
- Uitvoerformaat: Configureer de exportjob om een flat file te produceren, bij voorkeur CSV. Zorg dat de text qualifier is ingesteld op dubbele aanhalingstekens (") zodat komma’s in velden correct worden verwerkt.
a Voorbeeldquery config
`config
-- Common Table Expression (CTE) to fetch core claim attributes
-- This improves readability and performance by querying base tables once.
WITH ClaimBase AS (
SELECT
DC.ClaimId,
DC.ClaimNumber,
DC.ClaimType,
DC.Severity AS ClaimSeverity,
DC.CurrentStatus AS ClaimStatus,
FC.LossAmount,
DA.AdjusterName AS AssignedAdjuster,
DD.DepartmentName AS Department,
-- Timestamps for various events
FC.FNOLReportedDate AS ClaimSubmittedTime,
FC.ClaimRegisteredDate AS ClaimRegisteredTime,
FC.AdjusterAssignmentDate AS AdjusterAssignedTime,
FC.PaymentIssuedDate AS PaymentIssuedTime,
FC.ClaimClosedDate AS ClaimClosedTime
FROM
[DataHubSchema].[DimClaim] AS DC
LEFT JOIN
[DataHubSchema].[FactClaim] AS FC ON DC.ClaimKey = FC.ClaimKey
LEFT JOIN
[DataHubSchema].[DimAdjuster] AS DA ON FC.AssignedAdjusterKey = DA.AdjusterKey
LEFT JOIN
[DataHubSchema].[DimDepartment] AS DD ON FC.DepartmentKey = DD.DepartmentKey
WHERE
FC.FNOLReportedDate BETWEEN @StartDate AND @EndDate
/* AND DC.LineOfBusiness IN ('[Your_LOB_Filter]') */ -- Optional: Uncomment to filter by Line of Business
)
-- 1. Claim Submitted
SELECT
cb.ClaimId,
'Claim Submitted' AS ActivityName,
cb.ClaimSubmittedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Submitted' AS ClaimStatus, -- Status at the time of this event
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimSubmittedTime IS NOT NULL
UNION ALL
-- 2. Claim Registered
SELECT
cb.ClaimId,
'Claim Registered' AS ActivityName,
cb.ClaimRegisteredTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Registered' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimRegisteredTime IS NOT NULL
UNION ALL
-- 3. Adjuster Assigned
SELECT
cb.ClaimId,
'Adjuster Assigned' AS ActivityName,
cb.AdjusterAssignedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Assigned' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.AdjusterAssignedTime IS NOT NULL
UNION ALL
-- 4. Initial Review Completed (Inferred from status change)
SELECT
cb.ClaimId,
'Initial Review Completed' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.PreviousStatus IN ('Assigned', 'Registered') AND sh.NewStatus IN ('Under Review', 'Investigation')
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus IN ('Under Review', 'Investigation'))
UNION ALL
-- 5. Additional Information Requested
SELECT
cb.ClaimId,
'Additional Information Requested' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'InformationRequestSent'
UNION ALL
-- 6. Additional Information Received
SELECT
cb.ClaimId,
'Additional Information Received' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'InformationResponseReceived'
UNION ALL
-- 7. Investigation Started (Inferred from status change)
SELECT
cb.ClaimId,
'Investigation Started' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus = 'Under Investigation'
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus = 'Under Investigation')
UNION ALL
-- 8. Investigation Completed (Inferred from status change)
SELECT
cb.ClaimId,
'Investigation Completed' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.PreviousStatus = 'Under Investigation' AND sh.NewStatus = 'Pending Decision'
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.PreviousStatus = 'Under Investigation' AND s2.NewStatus = 'Pending Decision')
UNION ALL
-- 9. Loss Assessed (Reserve Set/Updated)
SELECT
cb.ClaimId,
'Loss Assessed' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount -- Use transaction amount for this event
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'ReserveSet'
UNION ALL
-- 10. Claim Decision Made (Inferred from status change)
SELECT
cb.ClaimId,
'Claim Decision Made' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
sh.NewStatus AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus IN ('Approved', 'Partially Approved', 'Denied')
AND sh.StatusSetDate = (SELECT MIN(s2.StatusSetDate) FROM [DataHubSchema].[DimStatusHistory] s2 WHERE s2.ClaimId = cb.ClaimId AND s2.NewStatus IN ('Approved', 'Partially Approved', 'Denied'))
UNION ALL
-- 11. Settlement Calculated
SELECT
cb.ClaimId,
'Settlement Calculated' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'SettlementCalculated'
UNION ALL
-- 12. Payment Authorized
SELECT
cb.ClaimId,
'Payment Authorized' AS ActivityName,
fct.TransactionDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
cb.ClaimStatus,
fct.TransactionAmount AS LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[FactClaimTransaction] fct ON cb.ClaimId = fct.ClaimId
WHERE
fct.TransactionType = 'PaymentAuthorized'
UNION ALL
-- 13. Payment Issued
SELECT
cb.ClaimId,
'Payment Issued' AS ActivityName,
cb.PaymentIssuedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'PaymentIssued' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.PaymentIssuedTime IS NOT NULL
UNION ALL
-- 14. Claim Denied
SELECT
cb.ClaimId,
'Claim Denied' AS ActivityName,
sh.StatusSetDate AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Denied' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
JOIN [DataHubSchema].[DimStatusHistory] sh ON cb.ClaimId = sh.ClaimId
WHERE
sh.NewStatus = 'Denied'
UNION ALL
-- 15. Claim Closed
SELECT
cb.ClaimId,
'Claim Closed' AS ActivityName,
cb.ClaimClosedTime AS EventTime,
cb.AssignedAdjuster,
cb.Department,
cb.ClaimType,
cb.ClaimSeverity,
'Closed' AS ClaimStatus,
cb.LossAmount
FROM
ClaimBase cb
WHERE
cb.ClaimClosedTime IS NOT NULL;
`