972-836-7750 Request a demo Talk to an expert
Talk to an expert Request a demo Call sales 972-836-7750

EDIFACT message guide · Insurance

ICASRP Insurance claim assessment and reporting

The UN/EDIFACT message exchanged among insurers, intermediaries, assessors and repairers in the claims handling process.

Sent by
Insurer, intermediary, assessor or repairer
Received by
Other parties in the claims process
Standard
UN/EDIFACT · Batch message
X12 equivalent
No direct equivalent

What is the EDIFACT ICASRP message?

ICASRP is the UN/EDIFACT insurance claim assessment and reporting message. The directory defines it as a message exchanged between all parties involved in the claims handling process, including insurers, intermediaries, assessors and repairers.

Claims handling involves assigning assessors, receiving damage assessments and repair estimates, authorizing repairs and reporting completion. One message used throughout the process lets each party see the same claim data and status. It can carry images and documents as references. Using one message type throughout lets every party see the same claim record and status, from the first notification to the final repair invoice.

How the EDIFACT ICASRP message worksDiagram of the UN/EDIFACT ICASRP Insurance claim assessment and reporting message. Insurer, intermediary, assessor or repairer sends it to other parties in the claims process. It usually starts the exchange. Inside the UNB and UNH envelopes, the directory D.21A requires, in the start of message: BGM (Beginning of message) and body and segment groups: the required SG1 loop with PNA (Party identification), the required SG3 loop with EVE (Event), the required SG12 loop with PNA (Party identification) and the required SG14 loop with ROD (Risk object type). 10 conditional segment groups are listed by their trigger segment.How the EDIFACT ICASRP message worksInsurance claim assessment and reporting: who sends it, where it fits and what the directory marks mandatory1 WHERE IT FITSUSUALLY FOLLOWSStarts the exchangeICASRPSENDERInsurer, intermediary,assessor or repairerRECEIVEROther parties in theclaims processCONTRL syntax report back, if agreedUSUALLY FOLLOWED BYNo business reply expected2 WHAT DIRECTORY D.21A REQUIRESInterchange: sender and recipient IDsUNB … UNZMessage ICASRPUNH … UNTSTART OF MESSAGEBGMBeginning of messageBODY AND SEGMENT GROUPSMandatory group SG1 · repeats up to 9PNAParty identificationMandatory group SG3 · repeats up to 99EVEEventMandatory group SG12 · repeats up to 99PNAParty identificationMandatory group SG14 · repeats up to 99RODRisk object type+ 10 conditional groups, starting with:RFFTCCCODICDDOCPRCSEQBlue box: mandatory segment group. Conditional groups are listed by the trigger segment that starts them; a group is sent only when its data applies.Conditional segments outside groups are not drawn.Structure: mandatory segments and groups in the UN/EDIFACT directory D.21A listing for ICASRP. Your trading partner's implementation guide adds itsown requirements.
How the EDIFACT ICASRP message worksDiagram of the UN/EDIFACT ICASRP Insurance claim assessment and reporting message. Insurer, intermediary, assessor or repairer sends it to other parties in the claims process. It usually starts the exchange. Inside the UNB and UNH envelopes, the directory D.21A requires, in the start of message: BGM (Beginning of message) and body and segment groups: the required SG1 loop with PNA (Party identification), the required SG3 loop with EVE (Event), the required SG12 loop with PNA (Party identification) and the required SG14 loop with ROD (Risk object type). 10 conditional segment groups are listed by their trigger segment.How the EDIFACT ICASRPmessage worksInsurance claim assessment and reporting: whosends it, where it fits and what the directorymarks mandatory1 WHERE IT FITSUSUALLY FOLLOWSStarts the exchangeICASRPSENDERInsurer,intermediary,assessor orrepairerRECEIVEROther parties inthe claimsprocessCONTRL syntax report back, if agreedUSUALLY FOLLOWED BYNo business reply expected2 WHAT DIRECTORY D.21A REQUIRESInterchange: sender and recipient IDs(UNB … UNZ)Message ICASRP (UNH … UNT)START OF MESSAGEBGMBeginning of messageBODY AND SEGMENT GROUPSMandatory group SG1 · repeats upto 9PNAParty identificationMandatory group SG3 · repeats upto 99EVEEventMandatory group SG12 · repeats upto 99PNAParty identification+ required SG14 (ROD) and 10 conditionalgroups, starting with:RFFTCCCODICDDOCPRCSEQBlue box: mandatory segment group. Conditionalgroups are listed by the trigger segment thatstarts them; a group is sent only when its dataapplies. Conditional segments outside groups arenot drawn.Structure: mandatory segments and groups in theUN/EDIFACT directory D.21A listing for ICASRP.Your trading partner's implementation guide adds itsown requirements.

How to read this diagram: the top row shows who sends ICASRP, to whom, and which messages usually come before and after it. The lower part shows what the directory D.21A itself requires: the envelopes around ICASRP and the segments and segment groups it marks mandatory. Conditional groups are listed by their trigger segment rather than drawn in full. This is the directory's minimum, not a trading partner's requirement: a message implementation guide, such as an industry subset or a partner’s own guide, usually makes some conditional groups mandatory, restricts the codes and may use an older directory.

Expand diagram Download SVG

When it is used

  • Instructing an assessor on a new claim
  • Receiving assessment reports and estimates
  • Authorizing repairs and reporting completion

Where it fits in the message flow

This message ICASRP Insurance claim assessment and reporting

No other message routinely comes directly before or after ICASRP; it is exchanged when the business event occurs. If the partners agree, the receiver confirms each interchange with a CONTRL syntax and service report.

Structure

Mandatory segments in ICASRP (directory D.21A)

In UN/EDIFACT directory D.21A, the ICASRP message has 205 segment positions arranged in 25 segment groups. These are the segments and segment groups marked mandatory at message level, in order; a mandatory group is shown with the segment that starts it. Segments inside conditional groups are needed only when the group is used. This is the directory’s requirement, not your trading partner’s: each partner’s message implementation guide names the directory it uses, often an older one such as D.96A or D.01B where the structure can differ, makes some conditional segments mandatory and restricts the codes.

  • UNH
  • BGM
  • SG1 (PNA)
  • SG3 (EVE)
  • SG12 (PNA)
  • SG14 (ROD)
  • UNT

Practical example

ICASRP in practice

A homeowner reports storm damage to the roof. The insurer sends an assessor an ICASRP with the claim and policy details. The assessor returns an assessment with photos and a repair estimate, the insurer authorizes a repairer, and the repairer reports completion and costs with the same message.

Implementation

Implementation considerations for ICASRP

  • Use claim references that all parties share.
  • Define status codes for each stage of handling.
  • Exchange supporting documents and images securely.
  • Track repairs against authorized amounts.

How ECOM helps

Automate ICASRP with ECOM

Industry

Financial Services

Secure file transfer and B2B integration for banks and financial institutions.

Solution

B2B Integration

Connect every customer, supplier, carrier and bank across EDI, API, file and portal channels.

Solution

Intelligent Document Processing

Automate data capture from PDFs, emails and spreadsheets with validation and human review.

Compare X12 and EDIFACT, or see answers to general questions in the EDI FAQ.

Related messages

Related insurance messages

All 18 insurance messages

Need help with ICASRP?

ECOM maps, tests and monitors EDIFACT messages for your trading partners and integrates them with your ERP.

Request a Demo Contact us