InsClaimItemService:calculateCoverages

Tjenesten tager gældende fradragsberettigelser, copays, co-insurance og maksimalt antal betalinger med i betragtning, når der oprettes justeringer.

Denne tjeneste evaluerer formlen til dækningsberegning, hvis en er defineret på dækningsspecifikationen.

Kategori: InsClaimItemService

Metode: calculateCoverages

Sådan fungerer det

Tjenesten bruger objektgrænsefladenavne som standardinput og output for almindelige felter i både Vlocity (ClaimLineItem__c) og Salesforce FSC (ClaimCoveragePaymentDetail) datamodeller.

Denne tjeneste fungerer forskelligt, afhængig af om der findes en dækningsberegningsformel på dækningsspecifikationen.

Når der ikke er nogen dækningsberegningsformel til stede, gør denne tjeneste følgende:

1. Bruger følgende oplysninger til at hente skadesregistreringen, den tilknyttede policeregistrering og attributværdier for både kravet og politikken.

   • claimId

   • claimCoverageId

   • claimItemId (hvis tilgængelig)

   • claimAmount

2. Kaldes InsPolicyTermsService: proces service.

   Denne tjeneste beregner alle beløb for forsikret forpligtelse (copay/coinsurance, fradragsberettiget og ikke-på-lomme-maks.) og returnerer disse data.

3. Trækker beløbene for den forsikrede forpligtelse fra skadesbeløbet, hvis der findes et eller flere beløb for den forsikrede forpligtelse.

4. Returnerer outputtet inklusive det endelige justerede beløb og underordnede skadeselementer (hvis der er nogen).

Når der findes en dækningsberegningsformel på dækningsspecifikationen, gør denne tjeneste følgende:

• Bruger følgende oplysninger til at hente skadesregistreringen, den tilknyttede policeregistrering og attributværdier for både kravet og politikken.

  • claimId

  • claimCoverageId

  • claimItemId (hvis tilgængelig)

  • claimAmount

• Kompilerer følgende objekter (herunder AttributeSelectedValues <productcode.key>) for at stille dem til rådighed for beregningsformlen for dækning på dækningsspecifikationen:

  • Skade

  • Politik

  • PolicyCoverage (Policedækning)

  • InsuredParty

  • InsuredItem

  • InvolvedInjury

  • InvolvedProperty

• Kører formlen til beregning af dækning.

• Kaldes InsPolicyTermsService: proces service.

  Denne tjeneste beregner alle beløb for forsikret forpligtelse (copay/coinsurance, fradragsberettiget og ikke-på-lomme-maks.) og returnerer disse data.

• Trækker beløbene for den forsikrede forpligtelse fra skadesbeløbet, hvis der findes et eller flere beløb for den forsikrede forpligtelse.

• Returnerer outputtet inklusive det endelige justerede beløb og underordnede skadeselementer (hvis der er nogen).

Fjernindstillinger

Denne indstilling bruger de grænsefladefeltnavne, der er beskrevet i denne tabel i input og output for almindelige felter i Vlocity ClaimLineItem__c og Salesforce FSC ClaimCoveragePaymentDetail-datamodeller:

For felter, der ikke er angivet her, skal du bruge feltets fuldt kvalificerede navn.

Attributter, der er præfikset med ClaimLineItem, der har skadeslinjevarens API, gemmes på den skadeslinjevare, der oprettes.

Input JSON og Output JSON

Hvis indbyggede metoder til at bestemme det justerede beløb for en betalingsdetalje opfylder dine forretningsbehov, kan du springe over dette afsnit. Men hvis du ønsker at justere betalingsdetaljebeløb på måder, der ikke er understøttet, er dette afsnit til dig.

Disse anvendelsessituationer, der er klar til brug, er typisk for scenarier, der ikke er dækket af power-attributklasser, f.eks.:

• Betingede afdrag, hvor der findes to afdrag på samme dækningsspecifikation. F.eks. gælder Deductible A for et brandskadestab, og Deductible B gælder for et oversvømmelsesskadestab. Du ønsker, at systemet bestemmer, hvilke fradrag der skal anvendes på betalingsdetaljerne på kørselstidspunktet.

• Copay/Coinsurance-rækkefølge for handlinger. F.eks. findes coinsurance og copay på samme dækningsspecifikation, og du ønsker at anvende coinsurance, før du anvender copay på en betalingsdetalje.

• Beregning af et udbetalingsbeløb for en fordelstype. For en sundhedsbesøgsfordelstype ønsker du f.eks., at systemet beregner et $50-beløb for betalingsdetaljerne.

Når du har forstået InsClaimItemService: calculateCoverages output JSON-formatet, kan du implementere power-attributlignende adfærd for at beregne udbetalingsbeløb og justeringer uden at have en underliggende power-attributklasse.

Før vi kommer foran os selv, lad os bruge et enkelt eksempel til at illustrere output JSON forventes at blive returneret af InsClaimItemService: calculateCoverages. Overvej en nem anvendelsessituation, der understøttes af den køreklare attributklasse Deductible power.

Eksempel: $5.000-kravsbeløb på en police med en fradragsbeløb på $1.000

Her er input-JSON for InsClaimItemService: calculateCoverages.

{ 
	"claimId": "01t000000000000001",
	"claimCoverageId": "01t000000000000002",
	"claimItemId": "01t000000000000003",
	"additionalInput": {
		"ClaimLineItem.claimAmount": 5000
		"ClaimLineItem.description": "first party claim payment"
		"ClaimLineItem.recipientId": "01t000000000000004"
	}
}

Her er output JSON returneret af InsClaimItemService: calculateCoverages.

{  
	"claimItem": {
		"adjustedAmount": 4000 // loss item adjusted amount
	},
	"claimLineItemAdjustment": {
		"attributeClass": "Deductible", // policy terms attribute class
		"adjustedAmount": 1000, // policy terms tracking entry postedAmount
		"assetTermId": "a6ERN00000000dg2AA", // policy terms id
		"remainingAmount": 0 // policy terms tracking entry remainingAmount
	}
}

Her kan du se, hvordan brugerinteraktioner på fanen Økonomi kalder tjenester, hvordan InsClaimItemService: calculateCoverages henter data, og hvad der sker med dataene derefter.

• (1) På fanen Finansielle oplysninger for et krav klikker en bruger på Ny tabselement og angiver et skadesbeløb på $5.000. Hvis du trykker på Tabulator for at flytte fra Fordringsbeløb til det næste felt, kaldes InsClaimItemService: calculateCoverages. I dette eksempel indeholder JSON-outputtet, der returneres fra InsClaimItemService: calculateCoverages, disse værdier.

  • claimLineItem: adjustedAmount Beløbet, der er betalt til betalingsmodtageren, efter at fradraget er trukket fra fordringsbeløbet: $5,000-$1,000=$4,000. Denne værdi vises tilbage til brugeren i feltet Justeret beløb på formularen Ny tabselement.

  • claimLineItemAdjustment:adjustedAmount Beløbet for justeringen af betalingsdetaljer for skadesdækning, i dette tilfælde de 1.000 USD, der kan fratrækkes fra skadesbeløbet.

  • claimLineItemAdjustment:attributeClass Årsagen til, at det beløb, der skal udstedes til betalingsmodtageren, er forskelligt fra det fordrede beløb. I vores eksempel reduceres det fordrede beløb med $1.000, fordi der gælder en deductible på $1.000 (attributeClass = Deductible).

  • claimLineItemAdjustment:assetTermId Den politikperiode, som en sporingsoplysning for policeudtryk er oprettet for. I vores eksempel er det id'et for politikudtrykket Deducerbart.

  • claimLineItemAdjustment:remainingAmount Det beløb, der skal angives i posten til sporing af policeperiode, i dette tilfælde $0, da der ikke er nogen fradrag tilbage efter denne transaktion.

• (2) Hvis du klikker på Tilføj for at gemme det nye tabselement, kaldes InsClaimItemService: add, som bruger returneret JSON-output fra InsClaimItemService: calculateCoverages til at bevare data til ClaimCoveragePaymentDetail-, ClaimCoveragePaymentAdjustment- og InsurancePolicyTermTrackingEntry-registreringer. (InsClaimItemService: update fungerer på samme måde.) Hver registrering indeholder værdier, der er relateret til vores eksempel:

  • ClaimCoveragePaymentDetail-registreringen har en ClaimCoveragePaymentDetail.ClaimedAmount på $5.000 og en ClaimCoveragePaymentDetail.AdjustedAmount på $4.000.

  • ClaimCoveragePaymentAdjustment-registreringen har en ClaimCoveragePaymentAdjustment.AdjustedReason for Deductible og en ClaimCoveragePaymentAdjustment.AdjustedAmount på $1.000.

  • InsurancePolicyTermTrackingEntry-registreringen har en InsurancePolicyTermTrackingEntry.PostedAmount på $1.000 og en InsurancePolicyTermTrackingEntry.RemainingAmount på $0.

Med en forståelse af basisstrukturen for output-JSON kan du opsætte en mere avanceret anvendelsessituation ved at introducere logik i beregningsformlen for dækning i en dækningsspecifikation.

Eksempel: På fanen Detaljer for en dækningsspecifikation angiver du en dækningsberegningsformel som denne ved brug af den samme ClaimLineItem-syntaks, der bruges til additionalInput.

InvokeIP('ClaimCoverage_ClaimCoverageFormula', , INPUT('claimId', ClaimLineItem.claimId) INPUT('benefitType', ClaimLineItem.benefitType), INPUT('quantityCount', ClaimLineItem.unitCount), 'resultat')

På kørselstidspunktet kalder denne formel en integrationsprocedure ved navn ClaimCoverage_ClaimCoverageFormula. Denne integrationsprocedure forventer input for claimId, benefitType og quantityCount, som vist i dette eksempelinput-JSON til test af integrationsproceduren:

{ 
	"claimId": "a2b4W000007W2pQQAS",
	"benefitType": "Ambulance - Air",
	"quantityCount": "1",
}

Formlen for dækningsberegning angiver, at output-JSON for ClaimCoverage_ClaimCoverageFormula-integrationsproceduren er i en node ved navn result. Så længe JSON-strukturen i den pågældende result overholder det forventede InsClaimItemService: calculateCoverages JSON-outputformat, fungerer systemet nøjagtigt, som om det bruger en underliggende potensattributklasse: visning af det justerede beløb for brugeren og vedvarende data i ClaimCoveragePaymentDetail-, ClaimCoveragePaymentAdjustment- og InsurancePolicyTermTrackingEntry-registreringer efter klik på knappen Tilføj.

I dette output-JSON-eksempel på en udbetaling på $50 for et wellnessbesøg medfører result, at InsClaimItemService: add udfører en indsættelse på 50 i ClaimCoveragePaymentDetail.AdjustedAmount.

{  
	"result": {
		"claimLineItem": {
			"adjustedAmount": "50"
			}
	},
}

Her er nogle tips til konfiguration af beregningen.

• Hvis din anvendelsessituation involverer eksisterende potensattributklasser, kan du bruge InsurancePolicyTerms: getCurrentStandings til at bestemme, hvor meget der er tilbage på en politikbetingelse, før du anvender en justering. Dette trin giver dig mulighed for at anvende den korrekte justering og overføre det relevante assetTermId tilbage. I disse anvendelsessituationer skal du konfigurere den JSON-struktur, der returneres af din integrationsprocedure, til at inkludere både noderne claimLineItem og claimLineItemAdjustment.

  I noden claimLineItemAdjustment skal du sørge for at:

  • Inkluder assetTermId.

  • Inkluder attributeClass.

  InsClaimItemService: add har brug for begge disse værdier for at bestemme, hvordan du opretter indtastningsregistreringen for forsikringspolicevilkårsporing for den specifikke potensattribut på policen. En dækningsspecifikation med en betinget afdragelig har f.eks. to attributter for afdragelig potens: Deductible A for brand og Deductible B for flod. Integrationsproceduren i formlen for dækningsberegning kan bruge InsurancePolicyTerms: getCurrentStandings til at bestemme, at fradragsberettiget A for denne police er $1.000 og fradragsberettiget B er $500. Derefter kan integrationsproceduren på grundlag af årsagen til tabet for denne fordring finde ud af, hvilken fradragsberettiget der skal anvendes. Når du returnerer output-JSON, skal du sørge for at returnere det korrekte assetTermId baseret på, hvilken deductible der blev anvendt.

• Nogle anvendelsessituationer involverer ikke de køreklare power-attributklasser, men kræver stadig, at der foretages en justering af betalingsdetaljerne. Når f.eks. en udbyder fakturerer mere end en aftalt sats, skal du have en ClaimCoveragePaymentAdjustment-registrering for at forklare, hvorfor det justerede betalingsbeløb er mindre end det fordrede beløb. I disse anvendelsessituationer skal du konfigurere den JSON-struktur, der returneres af din integrationsprocedure, til at inkludere både noderne claimLineItem og claimLineItemAdjustment.

  I noden claimLineItemAdjustment:

  • Udelad assetTermId, da der ikke er nogen power-attributklasse, der definerer denne justering.

  • Inkluder attributeClass som justeringsårsag (f.eks. "Overbilling Justering").

  InsClaimItemService: add bruger attributeClass-strengen til at udfylde feltet ClaimCoveragePaymentDetail.AdjustedReason, selvom der ikke er nogen relateret attributeClass.

• Hvis en anvendelsessituation involverer et udbetalingsbeløb for en fordelstype, er der ingen uoverensstemmelse mellem fordrede og justerede beløb. F.eks. gælder en flad sats på $100/dag for hospitalsophold. I disse situationer skal du lade hele claimLineItemAdjustment-noden være ude af din JSON.