address aggregate

ISO Services Properties, Inc., 2021 ISO Confidential/Proprietary Information Version 1.0

XML Manual For AWS Version 1.0

SEPTEMBER 2021 I N S U R A N C E S E R V I C E S O F F I C E, I N C.

i

Use of a term in this publication shall not be construed as granting any right, title, or interest in or to any patent, trademark, copyright, or other right in or to the information. All information contained in this publication remains the property of ISO or the applicable third-party. THE SYSTEM DESCRIBED IN THIS DOCUMENT IS CONFIDENTIAL AND PROPRIETARY TO INSURANCE SERVICES OFFICE, INC. (ISO) OR ITS LICENSORS. NO PART OF THIS PUBLICATION MAY BE REPRODUCED, COPIED, SOLD, DISTRIBUTED IN ANY MANNER OR BY ANY MEANS, WITHOUT THE EXPRESS WRITTEN PERMISSION FROM ISO. The terms and conditions governing the licensing and use of ISO systems consist solely of those set forth in the written contracts between ISO and its members. ISO makes no warranty of any kind with regard to this material, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose. ISO shall not be liable for errors contained herein or for damages in connection with the furnishing, performance, or use of this material. Information in this publication is subject to change without notice. NOTICE: © ISO Properties, Inc. 2021. This Documentation includes proprietary trade secrets and confidential information of ISO.

ii

TABLE OF CONTENTS

INTRODUCTION ......................................................................................................................................................... 1 Purpose of this Guide .............................................................................................................................................. 1 About ISO ClaimSearch and the XML Format ....................................................................................................... 1 Protection of Data..................................................................................................................................................... 1 Summary .................................................................................................................................................................. 2

ISO CLAIMSEARCH OPERATING RULES ............................................................................................................. 3 Member Obligations ................................................................................................................................................. 3 Audit and Verification ............................................................................................................................................... 3 System Use .............................................................................................................................................................. 3 Reporting Office Code Assignment ......................................................................................................................... 3 Member Codes ......................................................................................................................................................... 3

SUMMARY OF CHANGES ........................................................................................................................................ 4 Version 1.0 Changes ............................................................................................................................................... 4

XML COMMUNICATIONS .......................................................................................................................................... 5 Communication Options .......................................................................................................................................... 5

HTTPS POST/ Web Services SOAP .................................................................................................................. 5 REST API ............................................................................................................................................................. 5 Visualized ISO ClaimSearch ............................................................................................................................... 5

SSL Certificate Requirements ................................................................................................................................. 6 Communication Operations ..................................................................................................................................... 6

Establishing Connectivity ..................................................................................................................................... 6 XML Request ........................................................................................................................................................ 6 XML Response ..................................................................................................................................................... 6 Common Causes of Communication Errors ....................................................................................................... 7

TESTING PROCEDURES .......................................................................................................................................... 8 Testing Support ........................................................................................................................................................ 8 Test Planning Considerations ................................................................................................................................. 8 Testing Phases ......................................................................................................................................................... 8

Communications Operations ............................................................................................................................... 8 Testing XML Request Format ............................................................................................................................. 9 Testing ISO ClaimSearch Field/Relationship Edits ............................................................................................ 9 Testing Matching Claims Data .......................................................................................................................... 10

Additional Testing Notes ........................................................................................................................................ 10 Test Environment Considerations ......................................................................................................................... 11

PRODUCTION REQUIREMENTS ........................................................................................................................... 12 Production Steps .................................................................................................................................................... 12 Production Support ................................................................................................................................................ 12

SYSTEM INPUT (REQUEST) .................................................................................................................................. 13 Types of Requests ................................................................................................................................................. 13

Initial Request ..................................................................................................................................................... 13 Replacement Request ....................................................................................................................................... 13 Update Request ................................................................................................................................................. 14 Research Request ............................................................................................................................................. 15 Refresh Request ................................................................................................................................................ 15

XML Request Aggregates by Request Type ........................................................................................................ 16 ISO ClaimSearch XML Structure ...................................................................................................................... 16 Initial and Replacement ..................................................................................................................................... 16 Update (1) Adding or Update (2) Updating an Involved Party ........................................................................ 22 Update (3) Updating an Amount or Status ....................................................................................................... 24 Update (4) Research Request – Claim Level ................................................................................................... 25 Update (4) Research Request – Involved Party Level ..................................................................................... 25 Update (5) Changing Key Fields ....................................................................................................................... 26 Update (6) Adding a Service Provider .............................................................................................................. 27

iii

XML Request Aggregates by Line of Business .................................................................................................... 28 ISO ClaimSearch XML Structure ...................................................................................................................... 28 Claim Level Elements Common to All Claims .................................................................................................. 28 ClaimsParty Required Elements and System Rules ........................................................................................ 29 Casualty Claims – 1st Party Injury and 3rd Party Injury, Liability, and Property Damage ................................ 35 Vehicle Claims – 1st Party and 3rd Party Auto Physical Damage and Theft .................................................... 37 Property Claims – 1st Party General Property, Boat, Off-Road/Mobile Equipment ........................................ 42 Vehicle, Boat, or Mobile Equipment Theft Recovery ....................................................................................... 45 Watercraft or Mobile Equipment Salvage ......................................................................................................... 45 Vehicle Salvage .................................................................................................................................................. 46

Special Programming Notes .................................................................................................................................. 47 ClaimInvestigationAddRq/Rs RqUID ................................................................................................................ 47 Claim Level Reporting Vs. Exposure Level Reporting ..................................................................................... 47 Deleting Information ........................................................................................................................................... 48 Important Notice Regarding Updating Claims on the Claimsearch Website .................................................. 48 Important Notice Regarding Update Requests and CMS Medicare Reporting .............................................. 48 Miscellaneous Text Fields <RemarkText> ....................................................................................................... 48 Minimizing Replacement and Update Rejections ............................................................................................ 49 Multiple Vehicle Reporting ................................................................................................................................. 49 No Coverage/ No Loss Type ............................................................................................................................... 50 Physical Risk, Mailing Address, and SIU Claim Level Elements .................................................................... 50 Preventing Unwanted Searches:....................................................................................................................... 51 Replacement and Research Records from "Other Offices" ............................................................................ 51 Searchable Elements ......................................................................................................................................... 51 Validating Update Request:s ............................................................................................................................. 52

SYSTEM OUTPUT (RECEIPT AND RESPONSE) ................................................................................................. 53 Synchronous Receipt (Acknowledgement) .......................................................................................................... 53 Synchronous Error ................................................................................................................................................. 54 AgencyId Error ....................................................................................................................................................... 54 Asynchronous Reject Response ........................................................................................................................... 55 Asynchronous Success Response ....................................................................................................................... 57

Summary of XML Success Response Aggregates in Schema Order ............................................................ 57 Automatic Update Reports ................................................................................................................................ 62 Vehicle Recovery Reports ................................................................................................................................. 63 VIN Quality Control (NICB) ................................................................................................................................ 64 Impound Update Reports .................................................................................................................................. 64

ENTITIES ................................................................................................................................................................... 65 ACORD Document Request Entity (%ACORDREQ) .......................................................................................... 65 Claims Investigation Information Entity (%CLAIMSINVESTIGATIONINFO) ..................................................... 65 Claims Message Request Information Entity (%CLAIMSMSGRQINFO) ........................................................... 66 Claims Message Response Information Entity (%CLAIMSMSGRSINFO) ........................................................ 66 Currency (%Currency) ........................................................................................................................................... 66 Duration (%DURATION)........................................................................................................................................ 67 Measurement (%MEASUREMENT) ..................................................................................................................... 67 Property Casualty Policy Entity (%PCPOLICY) ................................................................................................... 67

WRAPPER AGGREGATES ..................................................................................................................................... 68 ACORD Aggregate <ACORD> ............................................................................................................................. 68 Signon Aggregates ................................................................................................................................................ 68 Claims Service ....................................................................................................................................................... 69

Request <ClaimsSvcRq> .................................................................................................................................. 69 Claims Investigation Submission Messages ........................................................................................................ 69

Request <ClaimInvestigationAddRq> ............................................................................................................... 69 Response <ClaimInvestigationAddRs> ............................................................................................................ 70

Miscellaneous Aggregates .................................................................................................................................... 71 AGGREGATES ......................................................................................................................................................... 72

Additional Information <com.iso_AddInfo> ........................................................................................................... 72

iv

Additional Coverage Information <com.iso_AddCovInfo> ................................................................................... 72 Additional Matches Aggregate <AdditionalMatchInfo> ........................................................................................ 72 Address Aggregate <Addr> ................................................................................................................................... 73 Airbag Information Aggregate <AirbagInfo> ......................................................................................................... 73 Adjuster Party Aggregate <AdjusterParty> ........................................................................................................... 73 Adjuster Party Information Aggregate <AdjusterPartyInfo> ................................................................................. 74 Appraiser Activity Information <AppraiserActivityInfo> ........................................................................................ 74 Auto Investigation Information Aggregate <AutoInvestigationInfo> .................................................................... 74 Auto Loss Information Aggregate <AutoLossInfo> .............................................................................................. 75 Catastrophe Aggregate <Catastrophe> ................................................................................................................ 75 Claims Driver Information Aggregate <ClaimsDriverInfo> ................................................................................... 75 Claims Injured Information Aggregate <ClaimsInjuredInfo> ................................................................................ 76 Claims Injury Aggregate <ClaimsInjury> .............................................................................................................. 76 Claims Occurrence Request Aggregate <ClaimsOccurrence> .......................................................................... 77 Claims Occurrence Response Aggregate <ClaimsOccurrence> ....................................................................... 78 Claims Party Aggregate <ClaimsParty> ............................................................................................................... 80 Claims Party Information Aggregate <ClaimsPartyInfo> ..................................................................................... 80 Claims Party Relationship Aggregate <ClaimsPartyRelationship> ..................................................................... 81 Claims Party Vehicle Information <com.iso_ClaimsPartyVehInfo> .................................................................... 81 Claims Payment Aggregate <ClaimsPayment> ................................................................................................... 81 Claims Payment Coverage Info Aggregate <ClaimsPaymentCovInfo> ............................................................. 82 Claims Reported Aggregate <ClaimsReported>.................................................................................................. 82 Claims Subject of Insurance Information Aggregate <ClaimsSubjectInsuranceInfo> ....................................... 82 Commercial Name Aggregate <CommlName> ................................................................................................... 83 Communications Aggregate <Communications> ................................................................................................ 83 Coverage Information 1 <com.iso_CovInfo1> ...................................................................................................... 83 Coverage Information 2 <com.iso_CovInfo2> ...................................................................................................... 85 Driver’s License Aggregate <DriversLicense> ..................................................................................................... 85 Email Information Aggregate <EmailInfo> ............................................................................................................ 85 Employee Information Aggregate <EmployeeInfo> ............................................................................................. 86 Event Information Aggregate <EventInfo> ........................................................................................................... 86 General Party Information Aggregate <GeneralPartyInfo> ................................................................................. 86 Item Definition Aggregate <ItemDefinition> .......................................................................................................... 86 Item Id Information Aggregate <ItemIdInfo> ......................................................................................................... 87 Item Information Aggregate <ItemInfo> ................................................................................................................ 87 Investigation Information Aggregate <InvestigationInfo> ..................................................................................... 88 Key Reason Information Aggregate <com.iso_KeyReasonInfo> ....................................................................... 89 Litigation Information Request Aggregate <LitigationInfo> .................................................................................. 89 Litigation Information Response Aggregate <LitigationInfo> ............................................................................... 89 Match Details Aggregate <MatchDetails> ............................................................................................................ 90 Match Information Aggregate <MatchInfo> .......................................................................................................... 90 Match Reason Information Aggregate <MatchReasonInfo> ............................................................................... 90 Miscellaneous Party Aggregate <MiscParty>....................................................................................................... 90 Miscellaneous Party Information Aggregate <MiscPartyInfo>............................................................................. 91 Name Information Aggregate <NameInfo> .......................................................................................................... 91 Non Tax Identity Aggregate <NonTaxIdentity> .................................................................................................... 91 Party Investigation Information Aggregate <PartyInvestigationInfo> .................................................................. 91 Person Information Aggregate <PersonInfo> ....................................................................................................... 92 Personal Name Aggregate <PersonName> ........................................................................................................ 92 Personal Vehicle Information Aggregate <PersVehInfo> .................................................................................... 92 Phone Information Aggregate <PhoneInfo> ......................................................................................................... 92 Policy Aggregate <Policy> ..................................................................................................................................... 93 Property Loss Information Aggregate <PropertyLossInfo> ................................................................................. 93 Property Schedule Aggregate <PropertySchedule> ............................................................................................ 94 Recovery Information Aggregate <RecoveryInfo> ............................................................................................... 94 Registration Aggregate <Registration> ................................................................................................................. 95

v

Salvage Information Aggregate <SalvageInfo> ................................................................................................... 95 Special Investigator Aggregate <com.iso_SIUInfo> ............................................................................................ 95 Special Investigation Details Aggregate <com.iso_SIUParty> ............................................................................ 96 Special Investigator Phone Information Aggregate <com.iso_SIUPhoneInfo> .................................................. 97 Summary Reason Information Aggregate <com.iso_SumReasonInfo> ............................................................ 97 Tax Identity Aggregate <TaxIdentity> ................................................................................................................... 97 Vehicle Information Aggregate <VehInfo> ............................................................................................................ 98 Vehicle Theft Verification Aggregate <com.iso_TheftVerification> ..................................................................... 98 Watercraft Aggregate <Watercraft> ...................................................................................................................... 99 Workers Compensation Loss Information Aggregate <WorkCompLossInfo> ................................................... 99

UPDATE REQUEST AGGREGATES ................................................................................................................... 100 Claims Update Aggregate <com.iso_Update> ................................................................................................... 100 Claims Update Original Fields Aggregate <com.iso_OriginalFields> ............................................................... 100 Claims Update Original Key Fields Aggregate <com.iso_KeyFields> .............................................................. 100

ADDITIONAL SERVICES ....................................................................................................................................... 101 Standard Additional Services .............................................................................................................................. 102

Account Management Reports & Dashboards ............................................................................................... 102 Mandatory – Statutory Reporting .................................................................................................................... 103 National Motor Vehicle Title Information System (NMVTIS) .......................................................................... 105

Optional Additional Services ................................................................................................................................ 107 Append-DSSM ................................................................................................................................................... 107 Child Support Enforcement Agency (CSLN/OCSE) Reporting ..................................................................... 109 ClaimDirectorSM ................................................................................................................................................ 110 Marine Index Bureau Claims ........................................................................................................................... 112 Medicaid Reporting Service (MAIS) ................................................................................................................ 113 Medicare Secondary Payer Reporting Service (CMS) .................................................................................. 114 OFAC Compliance Solutions........................................................................................................................... 116

Additional Services Aggregates .......................................................................................................................... 118 Append-DS Aggregate <com.iso_AppendDS> .............................................................................................. 118 ClaimDirector Rules Aggregate <com.iso_ClaimDirectorRules> .................................................................. 118 Claims Handling Characteristics Aggregate <com.iso_ClaimsHandlingCharacteristics> ........................... 118 Claims Party Scored Match Aggregate <com.iso_ScoredMatch> ................................................................ 118 Claims Score Report Aggregate <com.iso_ClaimScoreReport> .................................................................. 119 Claims Scoring Information Aggregate <com.iso_ClaimsScoringInfo> ........................................................ 119 CMS Warning Aggregate <com.iso_CMS> ................................................................................................... 120

ANSWERS TO FREQUENTLY ASKED QUESTIONS ........................................................................................ 121 APPENDIX A – CODE LISTS ................................................................................................................................ 123

Special Programming Notes ................................................................................................................................ 123 APPENDIX B – POLICY, COVERAGE, AND LOSS TYPES .............................................................................. 124

Special Programming Notes ................................................................................................................................ 124 APPENDIX C – FIELD AND RELATIONSHIP EDITS ......................................................................................... 125

Special Programming Notes ................................................................................................................................ 125 Entering “Invalid” Names ................................................................................................................................. 127 System Limitations ........................................................................................................................................... 127

APPENDIX D – ROLE CODES .............................................................................................................................. 128 Special Programming Notes ................................................................................................................................ 128

Involved Party Role Codes .............................................................................................................................. 128 Service Provider Role Codes .......................................................................................................................... 128 Additional Claimant Role Codes for Medicare Section 111 Reporting ......................................................... 128 Legal Representative Role Codes for Medicare Section 111 Reporting ...................................................... 129 Other Party Role Codes ................................................................................................................................... 129

APPENDIX E – CLAIMS PAYMENT AND STATUS REPORTING RULES ...................................................... 130 Claims Payment Reporting Rules ....................................................................................................................... 130

Casualty ONLY................................................................................................................................................. 130 Casualty, Auto, Boat, or Mobile Equipment .................................................................................................... 132 First-Party General Property ONLY ................................................................................................................ 134

vi

Claims Status Reporting Rules ........................................................................................................................... 138 WHO TO CALL ........................................................................................................................................................ 139

1

INTRODUCTION

Purpose of this Guide The ISO ClaimSearch system is a valuable information resource for first-party and third-party claim reporting and retrieval. This manual on transmission of claims through XML Format is intended to assist Information Systems personnel with the proper formatting of files and records for submission of claims to, and receipt of, matching reports from ISO ClaimSearch. About ISO ClaimSearch and the XML Format ISO ClaimSearch is the property/casualty insurance industry's first and only comprehensive system for improving claims processing and fighting fraud. Each year, participating insurers, self-insurers, third-party administrators, and healthcare organizations submit millions of reports on individual insurance claims. ISO stores those reports in a single database, furnishing essential data for researching prior-loss histories, identifying claims patterns, detecting suspect claims, and identifying adverse carriers and additional potential insurance coverage. XML Format provides a single point of entry for claim input and a delivery system for matching claim information. The results allow participating healthcare organizations to identify additional coverage to maximize the recovery effort and assist the revenue management organizations with the identification of potential coverage. The ISO ClaimSearch database now holds information on over 1.5 billion casualty, property, automobile, and healthcare claim records. Claim reports transmitted to ISO ClaimSearch are processed and matched against millions of other claims in the database. For participating healthcare organizations, the system automatically performs searches against relevant casualty lines of business. As an added enhancement, the system will now also match against collision losses in the automobile layer of the database. For example, the submission of a claim for healthcare treatment will identify the existence of other claims for the individual that may be related to an injury or automobile collision, possibly alerting users to the fact that the corresponding claim may be the primary coverage for a healthcare payment. Users of the system are encouraged to provide required and additional data elements for all lines of business to increase the value of the data available through the ISO ClaimSearch system. All claims should be submitted to the system. Complete reporting by all members enhances the value of the ISO ClaimSearch database for all users. Protection of Data ISO protects the ISO ClaimSearch database against unauthorized access. For the protection of its members, ISO ClaimSearch is operated and maintained according to the requirements of federal and state privacy laws. Individuals are allowed full disclosure of any data regarding their own claims that the database may contain. If a consumer requests information regarding data maintained in ISO ClaimSearch, subscribers should refer the individual to ISO. After receipt of a written request, the information will be released directly to the requester. If the consumer disputes the claim information in writing, ISO will initiate an investigation with the submitting subscriber, who under system rules must assist in the investigation. Pending the outcome of that investigation, ISO will then change or delete the claim or add a Statement of Dispute (provided by the consumer) to the claim record. The information maintained in the ISO ClaimSearch system is confidential and is not made available to the general public. Unauthorized individuals or companies that do not subscribe to the various segments of the ISO ClaimSearch database will not receive claim information unless ISO receives written consent from the individual in question (as in the situation outlined in the preceding paragraph) or is required by court order.

2

Summary The ISO ClaimSearch database is a vital and dependable information resource that assists the P&C industry with insurance claim investigations and settlements, and the healthcare organizations with the identification of the existence of other claims for the individual that may be related to an injury or automobile collision, possibly alerting users to the fact that the corresponding claim may be the primary coverage for a healthcare payment. To increase the ability for healthcare organizations to identify related claims, submitted claims are searched across related casualty and auto collision claims. The system is managed and operated under stringent privacy rules to protect the confidentiality and integrity of the data.

3

ISO CLAIMSEARCH OPERATING RULES

Member Obligations Members have an obligation to provide accurate information. In those states where required by law, members also have an obligation to inform the insured that claim information will be reported to the ISO ClaimSearch database, and that claim information may be released to other subscribers that have a permissible purpose. Members should request information only in connection with an active claim and should disclose any such information only to persons directly involved in the investigation and settlement of the claim. The Health Information Portability and Accountability Act (HIPAA) Privacy Rule generally restricts the use and disclosure of Protected Health Information (PHI) by covered entities and their business associates. However, covered entities may disclose PHI to carry out payment and healthcare operations for their own organizations and for other covered entities (e.g., resolving individual insurance subrogation claims). Neither Licensee nor its Authorized Users, nor anyone acting by or through Licensee, shall aggregate information from or search the Database or the ClaimSearch Information in pursuit of finding legal causes of action or pursuing class action lawsuits. In addition, the subscriber agrees that i) it is not a collection agency; ii) it is not an attorney or firm that practices in debt collection, or initiates or participates in class action lawsuits; iii) it is not a subrogation rights purchaser; iv) it is not an assignee of the subrogation recovery rights other than being a third-party administrator of the subrogation claim, working on behalf of an Insurer. Audit and Verification ISO reserves the right to audit and verify submissions to the system. All members must comply with such procedures pursuant to the ISO Privacy and Security Policy and the ISO ClaimSearch Participation Agreement. The ISO ClaimSearch Privacy and Security Policy can be located within ISO ClaimSearch in the Manuals section. System Use Information obtained from ISO ClaimSearch shall be used exclusively by the subscriber, its adjusters, and investigators. The information shall not be used for purposes of insurance underwriting (include ratemaking, risk classification, actuarial calculations, identification of prospective members, or reclassification of insureds), policy cancellation or renewal, establishing or stabilizing claims payment levels, pre- or post-employment screening, granting of credit or any similar purpose, or pursuing legal causes of action or class action lawsuits. The member assumes all responsibility for assuring that its adjusters and investigators use ISO ClaimSearch only for the foregoing authorized purposes. The member shall designate which of its employees and representatives will be authorized to receive claims reports and other information from the system. The ClaimSearch Member shall not warehouse ClaimSearch Information, in whole or part, received from ISO. “Warehouse” shall mean the electronic accumulation and storage of any amounts of ClaimSearch Information for general decision support or business intelligence purposes or any other purposes other than processing an individual and active insurance claim. Reporting Office Code Assignment The establishment of reporting offices and authorized submitting agencies to submit reports to the ISO ClaimSearch database on behalf of subscribing members is subject to the approval of ISO. The home office of the Member Company must notify ISO Customer Support, in writing, of office openings, closings, or changes of address. Member Codes ISO will provide 9-character alphanumeric codes to companies to utilize for their electronic reporting. This is known varyingly as the Customer Code, Subscriber Code, Member Code, Insuring Company Code, Office Code or AgencyId. The Member Code indicates the location of each reporting office. All claims should be reported at an office level (For example, not A00100000, but A00100023 in the AgencyId.) In order to process reports and provide timely responses, ISO Customer Support must be informed of office openings, closings, address, and personnel changes. It is strongly recommended (and encouraged), that a designated representative of your company periodically review and update the list of reporting locations for your company.

4

SUMMARY OF CHANGES

Every version of the User Manual includes any new or updated elements or processes that have been added to the system since the last version as a matter of course. However, each manual also contains many corrections and clarifications to make the manual a little bit better and easier to understand based on the requests and commentary of users like you. Therefore, not every possible change is listed in the summary below. If you should find a discrepancy or a section that is not clear, please feel free to bring it to our attention so that we may improve it in our next version for future users. Version 1.0 Changes

Although this User Manual is marked AWS version 1.0, it is not the first XML Format version that ISO ClaimSearch has supported. The following information is for customers that have used our prior XML Formats as to what is different about this manual than prior versions.

What changes are in this User Manual:

− The manual was rewritten to bring the language in line with the ISO ClaimSearch system processes of 2021. Language referencing paper versus electronic submissions and other legacy formats has been removed.

− Sentence structure has been simplified and bullet lists have been used more prevalently to assist the vast number of system developers ISO ClaimSearch works with internationally who are non-native English users of this Manual.

− Language has been updated to reflect the common phrases either displayed in our system or used by the ISO ClaimSearch first- and second-level support teams to make better use of the “Find” feature in Word.

− Additional hyperlinks and use of header labels have been added throughout the manual to aid in the referencing of corresponding sections as needed through the use of hyperlinks directly, the use of the “Find” feature, or the use of the Navigation toolbar in Word.

− Sections of the manual have been rewritten to untangle overlapping programming scenarios that have caused confusion to developers; notably, the distinctions between the differences in what is required and how to report the many different types of ClaimsParty and ClaimsPayment aggregates.

− The tables that were previously included in the Appendices A-E have been recreated into Excel spreadsheets that are more “development friendly”. The Appendices A-E of the User Manual contain further information on how to read the Excel spreadsheets as well as Special Programming Notes on the individual topics.

What changes are NOT in this User Manual:

− Over the course of time since the last User Manual release from our system, a number of updates to the system have been made that are not currently in the User Manual. For example, new Policy/Coverage/Loss combinations are not currently reflected in this manual.

− This release is to allow our members and vendors to take advantage of an updated, rewritten overhaul of the User Manual at large. The intention is to follow this relatively quickly with a version 1.1 refinement of the Manual to account for the system updates that have occurred. The current ETA for version 1.1 is Q1, 2022.

5

XML COMMUNICATIONS

Communication Options

HTTPS POST/ Web Services SOAP

To facilitate the direct transmission of this information and the return of match reports in the most efficient manner, the system supports two methods for exchanging XML-based ISO ClaimSearch transactions with ISO: HTTPS Post or Web Services SOAP. Please refer to the ISO ClaimSearch XML Package/ Communications/ XML Connectivity Information.docx for further information on the required elements for these transmission methods. Since there are many different platforms and programming languages that can be used for the creation of XML data, ISO ClaimSearch does not provide documentation on how to submit and receive via either method. If members have questions on how to apply these transmission methods, most answers can be found on the public internet.

REST API

As of the writing of this User Manual, ISO ClaimSearch XML communications for the ISO ClaimSearch Basic Services does not support the use of REST API at this time. If this is a method that your organization desires, please let the ISO ClaimSearch XML Support Team at [email protected] know so that we can gauge interest levels for future development considerations.

Visualized ISO ClaimSearch

Visualized ISO ClaimSearch is delivered as a SaaS (software as a service) and can be consumed using the SEARCH feature on the ISO ClaimSearch website, or can be fully integrated into a company’s home-grown or vendor claim system through single sign on and integration of a Risk Response. Visualized ISO ClaimSearch provides real-time alerts, actionable intelligence, and visualizations. Through single sign on, by embedding the ISO File Number generated on the Asynchronous Match Response, you can build a link directly from the claim within your company’s claim system to the matching claim in visualized ISO ClaimSearch. Through the Risk Response (which is a separate output response, delivered in XML format to a post-back URL provided by your organization), you can incorporate the risk level (low, medium, high) and actionable alerts into your system to further direct workflow. Please contact ISO ClaimSearch at [email protected] if you are interested in learning more about full integration options. Any questions regarding any of the transmission options should be discussed early in the development process as the answers may have bearing on the programming of transmissions. Further information can be found in the Communications folder of the XML Customer Package or contact the ISO ClaimSearch XML Support Team at [email protected] to discuss the above information in greater detail.

mailto:[email protected]



6

SSL Certificate Requirements Regardless of transmission option chosen, ISO ClaimSearch requires each member’s transmissions to be protected through SSL encryption. The ISO ClaimSearch system currently requires that both the ISO ClaimSearch servers and the member’s servers each have a valid, third-party SSL Certificate installed in order to complete the SSL handshake. Self-signed SSL certificates cannot be accepted. The ISO ClaimSearch system does NOT require the installation of the member’s SSL certificate in our keystore UNLESS the member’s system requires it. XML communications test may be required to determine if the member’s server has this requirement. Communication Operations

Establishing Connectivity

Members must provide ISO ClaimSearch XML Support with a range of the IP Address that the member will be transmitting from, as well as an established postback URL for the receipt of Responses from the ISO ClaimSearch system using the ISO ClaimSearch XML Customer Package/ Communications/ XML Connectivity Letter.docx. ISO ClaimSearch will then provide the UserId, Password, AgencyId (if not already known), and URLs for sending Requests.

XML Request

Members can make a Web Services Call or post via HTTPS Post to the appropriate ISO-provided URL. The transmission can contain one claim per transmission. The Request will pass through several levels of security and formatting checks before passing on to the ISO ClaimSearch database.

Synchronous Rejection: If the transmission does not clear a security or formatting check, then a Synchronous Response Rejection message is returned to the member’s OUTBOUND server with a <StatusCd> not equal to 0 and a <StatusDesc> or <MsgStatusDesc> which indicates the general reason for failure. Synchronous Acknowledgement: If the transmission clears all security and formatting checks, then a Synchronous Response Acknowledgement message is returned to the members OUTBOUND Server with a <StatusCd> equal to 0 and a <MsgStatusCd> “Response Pending”.

XML Response

Members can receive a Web Services Call or post via HTTPS Post to the Member-provided postback URL. The member may receive the Response using IP Address whitelisting, or Basic Authentication for additional security beyond the required SSL Certification. Members are requested to program to expect an XML string that uses “Content-type: application/x-www-form-urlencoded.” The member will need to be able to parse the XML string and save to an .xml file type. Members should be prepared to acknowledge the Response file within 1 second of processing time.

Asynchronous Rejection Response: If the claim does not pass, then an XML Data Error Response will be passed back to the INBOUND post-back URL indicating the reasons for rejection. Asynchronous Match Response: If the claim successfully passes the edits, then the member’s claim and any matching claim information will also be contained within the asynchronous Response passed back to the INBOUND post-back URL.

7

Common Causes of Communication Errors

ISO ClaimSearch should return Asynchronous Responses to the member’s INBOUND postback URL within minutes in both our Test and Production environments. If an Asynchronous Response is NOT received within minutes, it is likely that ISO ClaimSearch is receiving an error from the member’s system when attempting to postback to the member’s INBOUND postback URL. The member should review their system for the common causes for error and contact their Testing Representative (see Who to Call) and the ISO ClaimSearch XML Support team [email protected] for further assistance on troubleshooting the error. Common Causes for not receiving the Asynchronous Response:

1. Verify that the member provided postback URL is up, active, and ready to receive responses.

2. Whitelist the ISO ClaimSearch IP Addresses in the member’s external INBOUND firewall rules as well as on any internal proxies or load balancers that also have this requirement.

NOTE: A current list of IP Addresses may be obtained from [email protected].

3. Verify that ISO ClaimSearch has been provided with the current UserId/Password if the member’s system requires it for Basic Authentication.

NOTE: UserIds and Passwords should NOT contain an ampersand (&) as this is the XML character that indicates “stops processing”. This has caused XML files to truncate in the Response process.

4. Verify all proxy, load balancers, and internal routing settings are allowing responses to pass through and return an HTTP 200 code acknowledgement within 1 second.

5. Verify that the SSL certificate is currently valid; is installed on the member’s most external server of the system; and is NOT self-signed.

6. Some members require SSL Certs to be installed on our system. Please verify that your SSL cert is active and provide a copy to ISO ClaimSearch XML Support Team as a whole certificate in .cer format. SSL certs may NOT be self-signed. Please contact [email protected] for instructions on how to send the cert file to avoid email filters that strip these as attachments.

7. Identify unexpected data elements that your system is rejecting and either allow your system to accept them or

ignore them.

8. ISO ClaimSearch uses Content-type: application/x-www-form-urlencoded when posting Responses. This is a global setting in our system that cannot be changed. Please verify that your system is set to receive this type of encoding.

9. ISO ClaimSearch can generate Asynchronous Response files as large as 6MB. Although it is difficult to generate such a large Response in the Test environment, it is becoming increasingly common in the Production environment. It is recommended that the member’s system settings allow files up to 6MB to be received.




8

TESTING PROCEDURES

To ensure proper formatting and efficient use of the ISO ClaimSearch System, all new members will participate in testing before going "live." The total length of the testing period will vary from company to company depending on the complexity of the programming and the claims being sent and received. ISO ClaimSearch relies on each member to decide when their programming has been fully tested. Testing Support

An ISO ClaimSearch Testing Representative will be assigned to assist you as your first point of contact throughout the process. Testing Representatives will be able to answer questions directly or to pull in the relevant ISO ClaimSearch personnel who can best assist with your questions. Testing Representatives work normal Eastern time zone business hours, 8am-5pm Monday through Friday. (see Who to Call) As we try to meet the needs of all members, ISO ClaimSearch staff will make every effort to respond to requests within 1 business day but may take up to 3 business days for investigation, troubleshooting, and the coordination of multiple internal teams as necessary. Please keep this in mind during your testing process. Test Planning Considerations

Although ISO ClaimSearch cannot provide a comprehensive plan for every members’ testing phases, our team suggests that your test plan includes these considerations to fully test your system:

1. Start by testing XML communications round trip to ensure that all test claims can be submitted and receive Asynchronous responses in a timely fashion.

2. Data testing should begin by adding Initial claims to the test database completing all required elements. 3. Expand this to adding Initial claims with as many elements as possible, sending optional elements such as Aliases

and Service Providers, sending multiple claims parties and coverage types. 4. Create your own Match Reports by slightly altering some of the key information (PolicyNumber, AgencyId,

InsurerId, LossDt) on successfully submitted Initial claims to create new Initial claims that will produce matches against the original claims.

5. ISO ClaimSearch can also provide searchable data that will produce matches in the test system if you code claims using the data provided.

6. Finally test Updating or Replacing previously submitted test claims, including changing Key Fields which can only be done with the UpdateInd=5 Request.

Testing Phases

Communications Operations

Establishing Connectivity: • Member or Vendor will submit the ISO ClaimSearch XML Package/ Communications/ XML Connectivity

Letter.docx form to ISO ClaimSearch 3 weeks in advance of expected testing date. • ISO ClaimSearch will create member profile in test environment. • ISO ClaimSearch will provide UserId, Password, AgencyId, and Request URLs to access the system.

Testing Connectivity: ISO ClaimSearch is a “throughput” system which requires the member/vendor to submit a

Request in order to generate a Response. • Member/Vendor will send/receive data to ensure that both parties have a successful round-trip connection. • This can be a test claim from the member/vendor’s system, or it can be pushing through a sample claim from the

provided sample files using the ISO provided UserId, Password, AgencyId, and Request URL. • The claim should progress through ISO ClaimSearch automatically and generate an Asynchronous Response

file back to the member/vendor’s postback URL. • Note: Receiving an Asynchronous “Data” Rejection is considered a successful round-trip for this test.

9

Testing XML Request Format

Each transmission is required to: • Pass ACORD industry-standard schema validation to ensure the file is in a valid XML Format. • Pass Verisk Analytics security authorization (IP Address whitelist) and authentication (UserId and Password

validation). • Pass through a conversion step to convert the file from XML Format to our database records format per ISO

ClaimSearch system processing rules.

Synchronous Rejection: If a test fails any of these steps, a Synchronous Response will be sent to the member’s OUTBOUND server with a Status Code that does not equal 0 and a StatusDesc or MsgStatusDesc that indicates the reason for error.

Synchronous Acknowledgement: Test claims that pass the above communication and XML format validation steps will send a Synchronous Response Acknowledgement with a MsgStatusDesc of “Response Pending” back to the member’s OUTBOUND server and proceed to the data format validation.

Members may test their files for ACORD schema validation issues prior to sending them to the ISO ClaimSearch system by using XML editing software to run a validation against the ISO-provided Request schema file. (Please find the schema files in the ISO ClaimSearch XML Package/ Programming Documentation/ Schema Files.) • XML editing software is not provided by ISO ClaimSearch; however, there are various options available on the

open market via free trials or purchase.

Testing ISO ClaimSearch Field/Relationship Edits

Upon passing the XML Conversion process into our database processing, the following steps should occur for every XML Request file: • Edits: Field and Relationship Edits will be processed to check the validity of the data values and field

combinations. This test verifies that: All fields are accurate and complete. Each field does not contain a value on the invalid list for that field.

• A listing of values considered invalid for name fields, address fields, numeric fields, and claim numbers can be found in ISO ClaimSearch XML Customer Package/ Programming Documentation/ Invalid Lists. Additional information can be found in Appendix C.

Relational fields meet the criteria for their relationship. • For example: checking that the CoverageCd and LossCauseCd are a valid combination.

If a test fails the ISO ClaimSearch data format validation check, an Asynchronous Rejection will be sent to the member’s INBOUND server with a MsgStatusCd=Rejected and a MsgStatusDesc that indicates the reason for error. • See Appendix C for additional data format validation rules and ISO ClaimSearch XML Customer

Package/ Programming Documentation/ Appendices A-E/ Appendix C – Field and Relationship Edits.xlsx for a full listing of error codes and their explanations.

If successful, it will pass to the Add step.

• Add: Once a claim has passed the Edits above, then there are two more checks a claim must pass before it is added to the database. A duplicate check is performed for Initials and Key Field Updates (UpdateInd=5) New Fields. If a Request is

found with the EXACT PolicyNumber, AgencyId, InsurerId, and LossDt as a claim that exists on the system, then an Asynchronous Rejection is sent with the reason: “Request would create a duplicate.”

An initial claim check is performed for Replacements, Updates, and Research Requests. If no claim is found on the system with the EXACT PolicyNumber, AgencyId, InsurerId, and LossDt as on the processing request, then an Asynchronous Rejection is sent with the reason: “Initial claim not found.”

Once the claim has passed the appropriate Add check, then the claim data is actually added to the database, can be viewed in the Claims Inquiry tool on the website, and passes to the Search step.

10

• Search: ISO ClaimSearch performs a search of the Searchable data elements and creates the Match Report per your specific membership agreements.

• Visualized ISO ClaimSearch: ISO ClaimSearch will populate the visualized ISO ClaimSearch platform with the Match Report. If an Update Request submitted included an UpdateInd=1, 2, 5, or 6, then visualized ISO ClaimSearch is not

automatically updated with the new information. The end user will be prompted to request a “Refresh” of the data the next time they attempt to access the claim via visualized ISO ClaimSearch to retrieve the most recent claim information from the table.

• Match Report: ISO ClaimSearch will generate an Asynchronous Match Report that includes an echo back of the

claim and any matching claim(s). If no matching claims are found (No Match Report), then only an echo back of the submitted request is provided. This Asynchronous Response is sent to the members INBOUND postback URL using the XML Connectivity information provided.

Testing Matching Claims Data

It is recommended that the member first add initial records completing as many fields as possible and verify that all expected field values are present on an Asynchronous Match Report.

Once a successful Asynchronous Match Report has been received, it is recommended that the member change the claim number (InsurerId), policy number (PolicyNumber), or date of loss (LossDt) and resubmit the claim as an Initial Request. This will cause the second claim to find the first claim as a match and generate matching claims data within the Asynchronous Match Report.

In addition, the ISO ClaimSearch Testing Representative can provide searchable data that, when the data is coded into the members Request, will produce matches in the test system.

To test the Automatic Update, Vehicle Recovery Notices, and/or Impound Update Asynchronous Responses, please

work with your ISO ClaimSearch Testing Representative to generate these systematic responses back to your system. Additional Testing Notes

Every Initial, Replace, or Update Request should receive a Synchronous Response (either Rejection or Acknowledgement).

Every Initial, Replacement or Research (UpdateInd=4) Request that has received a Synchronous Acknowledgement should receive an Asynchronous Response (either Rejection or Acknowledgement).

Every Update Request with UpdateInd=1, 2, 3, 5, or 6 that has received a Synchronous Acknowledgement should

receive either: • NO Asynchronous Match Report (This is system working as designed.) • OR an Asynchronous Rejection for data format validation errors

11

Test Environment Considerations

ISO ClaimSearch has only one Test environment for members to access regardless of the number of test environments the member has. All member test claims from across their Test environments will be added to and searched against a single environment on the ISO ClaimSearch system.

The Test environment is not as robust as the Production environment and does not have the ability to scale as easily.

Therefore, members are restricted to sending no more than 60 claims per minute per IP Address. If your system sends more than this, you will receive an error “Insufficient Space on Resource”.

If your company requires a system load test prior to moving to Production, please consult with your ISO ClaimSearch Testing Rep on the planning of this.

ISO does not recommend using Production data in the Test environment. The Test environment is used by other

companies that are also testing their system feeds and have the potential to match against the data sent by your system. Likewise, we ask that you treat other member’s test data as if it were Production PII not knowing when another member’s system has sent live data to the Test system.

ISO ClaimSearch uses the Test environment as our Pre-Production test environment before releasing changes to the

Production environment. This is the only way to determine if changes to our system will negatively impact our members’ systems before moving to Production. While ISO ClaimSearch does its best to minimize disruptions to our members testing, not all system changes are successful on their first test. We appreciate your communication of any issues experienced and patience in the resolution of unexpected consequences.

Test data may be purged after 90 days. If you plan to continue to perform regression testing, please be advised that

your previously reported test data may no longer be available for replacements, updates or to match against.

12

PRODUCTION REQUIREMENTS

Production Steps

Three (3) to four (4) weeks prior to production implementation, ISO ClaimSearch requires the following items to approve a “Go-Live” date in our Production system: Data Quality Analysis (DQA): Receive test transmissions of data similar to what would be sent in production from

your test database in order to assess the quality of your data prior to production implementation. Production XML Connectivity: Send an updated XML Connectivity Letter.doc with Production information. Setup

production communications and test a “round-trip” through the chosen transmission method with a claim that is coded to reject or a live Production claim.

Historical Conversions: If you plan to send a historical conversion file of claims submitted using prior systems, it

should be sent and processed during this time period. Go-Live Meeting: A meeting should be held with an ISO ClaimSearch representative, the member’s business area,

the member’s technical area, and, if a vendor is being used, a representative of the vendor’s company. The purpose of this meeting is for ISO ClaimSearch to gain basic facts about how the member’s XML Format transmissions were designed, what types of claims are being sent, how errors are being handled, etc. It serves as a check that all steps are in place for the production date. It is also a good time to answer any other questions by any party on the call.

Approval of Go-Live Date: ISO ClaimSearch relies on each member to decide when their programming has been

fully tested. However, ISO ClaimSearch reserves the right to approve or deny a “Go Live” date depending on the satisfactory completion of the items above in order to protect the quality of our database for all users of the system.

Please contact your ISO Testing Representative (See Who to Call) to coordinate the details of the above. Production Support

Normal Business Hour Support: The ISO ClaimSearch Testing Representative will continue to assist you as your first point of contact even after to moving to Production. It is very common for members to continue testing even after going live in order to test the reporting of optional data, additional lines of business or services, or system changes occurring on either the member’s system or the ISO ClaimSearch system. These representatives continue to be referenced as “Testing Representatives” even if the member is not currently testing.

Testing Representatives will be able to answer Production questions directly or to pull in the relevant ISO ClaimSearch personnel who can best assist with your questions during normal Eastern time zone business hours, 8am-5:00pm Monday through Friday. (See Who to Call)

As we try to meet the needs of all members, ISO ClaimSearch staff will make every effort to respond to requests within 1 business day but may take up to 3 business days for investigation, troubleshooting, and the coordination of multiple internal teams as necessary.

Emergency Off-Hours Support: If you require Production support outside of normal business hours that cannot wait

for business hours to resume, please contact Verisk Analytics Technical Operational Center (TOC), and let the person answering the phone know that you have an “ISO ClaimSearch Production issue requiring emergency off-hours support.” Please be prepared to describe the nature of the issue. The TOC group will not be able to resolve your issue directly but acts as an emergency dispatch to contact the relevant personnel who are on call.

Verisk Analytics Technical Operational Center (TOC) can be reached at 1-201-469-3300.

13

SYSTEM INPUT (REQUEST)

Types of Requests

Initial Request

The first time a claim is sent to ISO ClaimSearch, it should be sent as an Initial claim. Only one Initial report needs to be filed listing the insureds, claimants, and coverages for an incident regardless of the claim type. Upon passing the XML Conversion process into our database processing, the following steps should occur: Edits: Field and Relationship Edits (see Appendix C) will be processed to check the validity of the data values and

field combinations. If successful, it will pass to the Add step. If failed, it will provide an Asynchronous Rejection with the reasons for failure.

Add: ISO ClaimSearch performs a duplicate check which will reject claims with the same PolicyNumber, AgencyId, InsurerId, and LossDt. If a claim is found with the same key fields above, then an Asynchronous Rejection will be sent with the reason: “Request would create a duplicate”. If this step is successful, the claim data is added to the database, can be viewed in the Claims Inquiry tool on the website, and passes to the Search step.

Search: ISO ClaimSearch performs a search of the Searchable data elements and creates the Match Report per your specific membership agreements.

Visualized ISO ClaimSearch: ISO ClaimSearch will populate the visualized ISO ClaimSearch platform with the Match Report.

Match Report: ISO ClaimSearch will generate an Asynchronous Match Report that includes an echo back of the claim and any matching claim(s). If no matching claims are found (No Match Report), then only an echo back of the submitted request is provided. This Asynchronous Response is sent to the members INBOUND postback URL using the XML Connectivity information provided.

Risk Response: If your company is a member of this service, ISO ClaimSearch will generate a separate Asynchronous Risk Response that has its own file layout. This Asynchronous Response is sent to the members INBOUND postback URL using the XML Connectivity information provided. This can be the same connectivity information as the Match and Rejection Reports or have its own XML Connectivity information.

Replacement Request

A Replacement Request is sent after an Initial Request has been successfully processed in the ISO ClaimSearch system and an Asynchronous Match Response has been returned. The purpose of a Replacement Request is to find the Initial claim in the system, remove the Initial claim, and REPLACE the Initial claim with updated claim information. It may also be used to perform a new search on an existing claim without any changes. Replacement Requests Programming Notes: Does require all the same aggregates, elements, and schema hierarchy as Initial Requests, with one additional

element <ReplacementInd> = 1. Does require all data elements in the Initial claim to be sent again – unless the intention is to delete them. Will completely overwrite the existing claim in the database. Will automatically perform another search of the database. Does not replace the ISO FileNumber, the ISO Received Date, PolicyNumber, AgencyId, InsurerId, or LossDt Does not change the timeframe of the Automatic Update Reports Upon passing the XML Conversion process into our database processing, the following steps should occur: Edits: Field and Relationship Edits (see Appendix C) will be processed to check the validity of the data values and


Add: ISO ClaimSearch performs a replacement check which will search for a claim in the system with the same PolicyNumber, AgencyId, InsurerId, and LossDt. If no claim is found with the same key fields above, then an Asynchronous Rejection will be sent with the reason: “Initial claim not found”. If this step is successful, the claim data is added to the database, can be viewed in the Claims Inquiry tool on the website, and passes to the Search step.

14



Match Report: ISO ClaimSearch will generate an Asynchronous Match Report that includes an echo back of the claim and any matching claim(s). If no matching claims are found (No Match Report), then only an echo back of the submitted request is provided. This Asynchronous Response is sent to the members INBOUND postback URL using the XML Connectivity information provided.

Risk Response: If your company is a member of this service, ISO ClaimSearch will generate a separate Asynchronous Risk Response that has its own file layout. This Asynchronous Response is sent to the members INBOUND postback URL using the XML Connectivity information provided. This can be the same connectivity information as the Match and Rejection Reports or have its own XML Connectivity information.

Update Request

An Update Request is sent after an Initial Request has been successfully processed in the ISO ClaimSearch system and an Asynchronous Match Response has been returned. The purpose of an Update Request is to allows members to send key identifiers on a claim and specific sections of the claim to be updated without generating a new search. The following actions may be completed using the Update Request process. (Numbers here correspond to the UpdateInd value used to request the action and are often referred to quickly as UpdateInd=1 , UpdateInd=2, etc.):

1. Add an Involved Party 2. Update an Involved Party 3. Update an Amount or Status for a Coverage 4. Request a New Search to be Completed on Claim or Involved Party (Research Request) 5. Change Key Field Identifiers 6. Add a Service Provider to an Involved Party

Update Requests Programming Notes: Does NOT require all the same aggregates, elements, and schema hierarchy as Initial Requests. Does require <com.iso_Update> aggregate, <Policy>, <ClaimsOccurrence>, and the relevant aggregates necessary

to complete the specific transactions (listed in the Update Required fields section by Update type). Will only update the part of the claim identified in the Update Request. Does NOT perform a search of the claim for UpdateInd values 1, 2, 3, 5, or 6. (See Research Request for UpdateInd=4

rules.) Does not replace the ISO FileNumber, the ISO Received Date, PolicyNumber, AgencyId, InsurerId, or LossDt Does not change the timeframe of the Automatic Update Reports The first time a claim is sent to ISO ClaimSearch, it should be sent as an Initial claim. Update Requests should be reported on subsequent transmissions. Upon passing the XML Conversion process into our database processing, the following steps should occur: Edits: Field and Relationship Edits (see Appendix C) will be processed to check the validity of the data values and


Add: ISO ClaimSearch performs an update check which will search for a claim in the system with the same PolicyNumber, AgencyId, InsurerId, and LossDt. If no claim is found with the same key fields above, then an Asynchronous Rejection will be sent with the reason: “Initial claim not found”.

Search: Update Requests do NOT perform a search by default. Visualized ISO ClaimSearch: Update Requests do NOT update visualized ISO ClaimSearch by default. (See

Refresh Request) Match Report: Update Requests do NOT provide an Asynchronous Match Report Risk Response: Update Requests do NOT provide an Asynchronous Risk Response.

15

Research Request

A Research Request is sent after an Initial Request has been successfully processed in the ISO ClaimSearch system and an Asynchronous Match Response has been returned. The purpose of a Research Request is to perform a new search of the claim information by only providing key field information. When filing a Research, the PolicyNumber, AgencyId, InsurerId, and LossDt (the key fields) must be provided exactly as they appeared on the Initial claim. The System will use this "key" information to find your "Initial" claim in the database and perform another search. When sending a Research, only the key fields listed below are required; no additional claim information should be sent. Research Requests Programming Notes: Does NOT require all the same aggregates, elements, and schema hierarchy as Initial Requests. ONLY send <com.iso_Update> aggregate and Key Field information as submitted on the Initial claim (Policy Number,

AgencyId, InsurerId, and LossDt), and <SearchBasisCd> to indicate if a Claim level or Involved Party level search should be completed.

If an Involved Party level search is desired, then the <ClaimsParty> name is also a required field and must be an EXACT match or the Initial claim will not be found.

If a “key” field in an Initial request was subsequently changed, then the newest (i.e., changed) record with the revised key fields should be submitted.

Will search entire claim or only ClaimsParty Does perform a search of the claim for UpdateInd=4. Does not replace the ISO FileNumber, the ISO Received Date, PolicyNumber, AgencyId, InsurerId, or LossDt Does not change the timeframe of the Automatic Update Reports It is not recommended to send a Research request within the first 365 days after an initiating casualty claim, 60 days

after an initiating property claim, or 30 days after an initiating auto claim, since the System automatically searches claim reports during the prescribed time periods. As a guideline, in most cases, Researching open claims for the first time 15 months after the Initial was sent, and then every six months thereafter up to settlement should be sufficient (See Automatic Update Reports).

Upon passing the XML Conversion process into our database processing, the following steps should occur: Edits: Field and Relationship Edits (see Appendix C) will be processed to check the validity of the data values and


Add: ISO ClaimSearch performs an update check which will search for a claim in the system with the EXACT same PolicyNumber, AgencyId, InsurerId, and LossDt (and <ClaimsParty> name if an individual Involved Party is searched.) If no claim is found with the same key fields above, then an Asynchronous Rejection will be sent with the reason: “Initial claim not found”.



Match Report: ISO ClaimSearch will generate an Asynchronous Match Report that includes an echo back of the claim and any matching claim(s). If no matching claims are found (No Match Report), then only an echo back of the submitted request is provided with no <MatchDetails> aggregate. This is the system working as designed. This Asynchronous Response is sent to the members INBOUND postback URL using the XML Connectivity information provided.

Refresh Request

A Refresh Request (only available through visualized ISO ClaimSearch) is the equivalent of a Research Request but allows a user to perform the search within the visualized ISO ClaimSearch platform in order to generate a more recent match report without having to submit a systematic request for another search. This is also used to refresh the data after an UpdateInd=1, 2, 3, 5, or 6 are submitted to get the most updated information from the database tables.

16

XML Request Aggregates by Request Type

ISO ClaimSearch XML Structure

ISO ClaimSearch XML transmissions require a specific basic XML structure as well as certain required aggregates and elements for the reporting of XML Requests. Below is an explanation of the basic structure and required elements common to all Initial and Replacement Requests, followed by an explanation of how to report various Update and Research Requests. Each section includes the high-level XML structure and the required elements specific to the type of Request being submitted. See Special Programming Notes/ Searchable Elements for a listing of the that are not required on any claim, but if provided will be searched to improve your search results. The basic hierarchy structure of an XML transmission is defined by the order that Entities, Wrappers, Aggregates, and Elements are listed within the tables in the file layout section of the manual. Please follow this order when programming the XML Structure. . ISO ClaimSearch also provides Schema files to assist in the programming of Request, Response, and Acknowledgement hierarchies. These can be found in ISO ClaimSearch XML Package/ Programming Documentation/ Schema Files. The following section describes the common aggregates in schema order required for a successful submission to ISO ClaimSearch. There may be additional aggregates and elements that may be used to report optional information that are not summarized here but may be found in the tables later in the manual. Also, there may be additional elements required by the ACORD specification, not listed in this section. In addition, due to the nature of ACORD XML, there are certain identifiers and references that ISO requires to properly interpret the XML. These have been marked as “Required” in their proper context in a later section of this manual.

Initial and Replacement

ACORD wrapper Every XML transmission must begin and end with the <ACORD> tag to signify the beginning and end of file

transmission. SignonRq

Every XML transmission must contain a <SignonRq> aggregate containing the UserId, and Password (Pswd) provided by ISO ClaimSearch XML Support for authentication to the ISO system.

ClaimsSvcRq Every XML transmission must contain a single <ClaimsSvcRq> aggregate to indicate the beginning and ending

of the data transmission. ClaimInvestigationAddRq

Every XML transmission must contain one <ClaimInvestigationAddRq>. The RqUID for the ClaimInvestigationAddRq is returned on the ClaimInvestigationAddRs in order to tie the

response back to the request. The RqUID may not be blank or null. It must contain at least one alpha character and start with an alpha character

if there is more than one character, or the Response will not be returned to your system. NOTE: Members using the Guidewire ClaimCenter system will have the RqUID system-generated in the last step

before the XML Request leaves the member’s system. It may not be readily visible on your files. CodeList

This aggregate is required to identify any CodeList used within the transmission that is NOT an ACORD standard codelist.

ACORD industry-standard codelists are identified in ISO ClaimSearch XML Customer Package/ Programming Documentation/ Appendices A-E/ Appendix A – Code Lists.xlsx document. See also Appendix A.

CodeList names are case and spelling sensitive. If a CodeList is incorrectly coded at the top of the file for a:

− Required field, the claim will be rejected for “missing” data in that element. − Optional field, the data for that element will be dropped in the processing.

17

ReplacementInd This element is the only difference between an Initial and a Replacement request in terms of XML coding. ReplacementInd value =1 is used to indicate that the claim exists on the database and should be overwritten with

the claims data listed below. This element should either not be submitted or submitted with a data value = 0 on an Initial request.

The PolicyNumber, AgencyId, InsurerId, and LossDt (i.e., Key Fields) must be an EXACT match to find the existing claim, remove all data except the Key Fields, ISO FileNumber, and ISO Received Date, and replace it with the claims data provided on this transaction.

If data was submitted on the existing claim but is not present on the Replacement, that claims data will be removed from the claim.

NOTE: If the claims data has been touched on the ISO ClaimSearch Claims Reporting website, then the data may NOT be removed via system to system, only changed.

SuppressMatchInd Initials and Replacements perform a search by default. This is not always desired by the member. This element is used to indicate that the entire claim should be added to the database, but not searched. If this indicator value is set to 1:

− This will return an Asynchronous Error Response if there is a data error. − This will NOT return a Success Response. − This will NOT return CMS Warnings.

This element is also available on the ClaimsParty level. See PartyInvestigationInfo below for further information. Policy

Required Elements: PolicyNumber, LOBCd (Policy Type), AgencyId, MiscPartyRoleCd (defaults to “CarrierInsurer”.) − If you are a self-insured that does not use a policy number, the claim number may be reported in the

PolicyNumber field. Optional Elements: Physical Risk or Mailing Address, SIU Contact information, and NMVTIS reporting code.

ClaimsOccurrence Required Fields: @id, InsurerId (Insurer claim number), LossDt, IncidentDesc, Addr/StateProvCd (Location of

Loss State) − If this is a policy that does not use claim number, the policy number may be repeated in the InsurerId field

and vice versa, the claim number may be repeated in the PolicyNumber field. This aggregate also contains RRE Code, TIN, and Site ID for CMS reporting.

− Either none of these fields should be reported (system-derived) OR all three fields need to be reported. Otherwise, the system will drop the information in processing and CMS Warnings will be generated.

− TIN requires a codelistref and corresponding Code List declaration at the top of the file. ClaimsParty

At least one is required, only the first 99 involved parties reported will be searched. This aggregate is used to report persons or organizations involved in the claim. This can include involved parties,

service providers, aliases, salvage buyers, CMS additional claimants, etc. Required Fields are dependent on the ClaimsPartyRoleCd submitted. Specific roles are identified through the use of the ClaimsPartyRole (ACORD) or ClaimsPartyRoleCd code lists in

Appendix A and Appendix D. GeneralPartyInfo

− NameInfo • This aggregate can be used to report either a Business Name <CommlName> unparsed up to 70

characters OR an Individual Name <PersonName> parsed into first, middle, and surnames. • Required on all involved parties, service providers, recovering agencies, and salvage buyers. • Optional on an Alias as long as an Addr is provided, however if it is provided it will be searched to

enhance the search results. • CMS reporting may have additional requirements specific to CMS role codes.

− Addr • This aggregate is used to report the address associated with the NameInfo directly above it. • AddrTypeCd element is NOT used outside of the Policy aggregate. • Addr1, City, and StateProvCd are required on all involved parties

18

• City and StateProvCd are required for all service providers • Addr aggregate is not required for recovering agencies or salvage buyers • Addr aggregate is not required for Alias as long as a NameInfo is provided. • CMS reporting may have additional requirements specific to CMS role codes. • The following data elements may not be required, but if provided they can be searched (depending on

role code) and enhance your search results – Addr1, City, StateProvCd, and PostalCode. − Communications

• This optional aggregate can be used to report the following phone types and email address: ♦ Home Telephone – PhoneTypeCd = Phone; CommunicationUseCd = Home ♦ Business Telephone – PhoneTypeCd = Phone; CommunicationUseCd = Business ♦ Cellular Telephone – PhoneTypeCd = Cell; CommunicationUseCd = ** ♦ EmailAddr – In this location, Alias email address only. See com.iso_SIUParty for Involved Party or

Service Provider email address. ** can enter either Home or Business, this is ignored. Note: Only one phone number of each PhoneTypeCd per ClaimsParty is stored in system.

PersonInfo − This optional aggregate is used to report Gender, Birth Date, and Occupation of the ClaimsParty. It is optional

for ISO ClaimSearch Basic Service Reporting. − Required element, for CMS Reporting: BirthDate − Reporting Gender is optional for CMS Reporting, but is useful in determining matches.

ClaimsPartyInfo − Required elements: ClaimsPartyRoleCd to identify the ClaimsParty’s role in the claim. Please see Appendix

A and Appendix D for further information. − Optional elements: Lawsuit (SuitFiledInd) or Closed Date (ClosedDt) of a particular coverage.

• Both of these elements require an idref referring to the particular coverage (ClaimsInjuredInfo, AutoLossInfo, or PropertyLossInfo) that it is being reported for, and may be repeated to provide individual data on multiple coverages.

ClaimsDriverInfo − Optional elements: Driver’s License Number and Driver’s License State.

• These elements are optional but will contribute to the search results if provided. ClaimsInjuredInfo

− This aggregate is required for all involved parties with injuries, liabilities (such as harassment or slander), or 3rd party property damage. It may be repeated as necessary to cover all coverage/loss types being claimed.

− Required elements: @id, InjuryNatureDesc − Not allowed if the ClaimsPartyRoleCd is Owner, Partner, Tenant, Witness, Alias, or any of the Service

Provider role codes listed in Appendix D. PartyInvestigationInfo

− Initials and Replacements perform a search by default. This is not always desired by the member. − SuppressMatchInd within this aggregate is used to indicate that this ClaimsParty should be added to the

database, but not searched. − If this indicator value is set to 1:

• This will return an Asynchronous Reject Response if there is a data error. • The claim will return an Asynchronous Match Report, but this party will indicate “NS” for Not Searched. • This will NOT return CMS Warnings on this ClaimsParty.

− This element is also available on the Claim level. See SuppressMatchInd above for further information. com.iso_ClaimsPartyVehInfo

− This aggregate is optional and only used to report the VIN of the vehicle the party was an occupant of and whether there was physical damage to the vehicle.

com.iso_CSLNInd − This indicator is used by TPA’s for Optional Services - Child Support Enforcement Agency (CSLN/OCSE)

Reporting.

19

ClaimsPartyRelationship The ClaimsPartyRelationship aggregate is required to tie the involved party’s ClaimsParty (ClaimsParty1Ref) to

the Service Provider or Alias ClaimsParty (ClaimsParty2Ref). − ClaimsPartyRoleCd codelistref requirements apply to all Involved Parties and Service Providers. − Alias does NOT use a codelistref.

Service Provider or Alias information must be listed in its own ClaimsParty aggregate. Multiple Service Providers may be tied to a single involved party ClaimsParty by repeating the aggregate. Multiple Aliases may be tied to either an involved party ClaimsParty or a service provider ClaimsParty by repeating

the aggregate with the appropriate ClaimsParty1Ref and ClaimsParty2Ref values. com.iso_SIUParty

Required elements: @idref linking this aggregate to an Involved Party OR a Service Provider, com.iso_MedicareEligibleInd (required for CMS), HICN/MBI (required for CMS) − Without the idref, the data will be dropped from the claim and NO data, including CMS required fields, will be

retained. This aggregate can reference Claimant or Insured role codes for special investigation details, CMS required fields,

or email address. This aggregate can reference a Service Provider only for special investigation details or email address.

AdjusterParty Required elements: AdjusterPartyInfo Only one Adjuster name and contact information may be reported per individual ClaimsInjuredInfo, AutoLossInfo,

or PropertyLossInfo aggregates. The aggregate may be repeated if more than one Adjuster is handling separate ClaimsInjuredInfo, AutoLossInfo,

or PropertyLossInfo aggregates. (For example, there is one adjuster handling the ClaimsInjuredInfo and one adjuster handling the AutoLossInfo on the same claim, this aggregate may be repeated and refer to the individual coverages that each adjuster is handling.)

AdjusterPartyInfo − Required elements:

• @AssignmentRef referring to an individual ClaimsInjuredInfo, AutoLossInfo, or PropertyLossInfo. • CoverageCd (EXCEPT for PropertyLossInfo/ClaimsSubjectInsuranceInfo claims) • LossCauseCd

− There must be at least ONE AdjusterPartyInfo aggregate for EACH ClaimsInjuredInfo, AutoLossInfo, or PropertyLossInfo aggregate on the claim.

− The AdjusterPartyInfo aggregate may refer to the SAME ClaimsInjuredInfo, AutoLossInfo, or PropertyLossInfo more than once as long as EACH CoverageCd and LossCauseCd combination is unique.

− The AdjusterPartyInfo aggregate may be repeated within the AdjusterParty aggregate for EACH coverage the named adjuster is handling on the claim.

AutoLossInfo Required elements for 1st party losses (ClaimsPartyRoleCd = IN, ID, IP, or CI): @id, @ClaimsPartyRefs,

VehInfo/ModelYear, VehInfo/VehIdentificationNumber, ManufacturerCd Required elements for 3rd party losses (ClaimsPartyRoleCd = CL, CD, or CP): @id, @ClaimsPartyRefs

− VehIdentificationNumber becomes required if salvage is being reported on a 3rd party vehicle or more than one vehicle is reported for the same 3rd party to distinguish the vehicles reported.

Not allowed for any other ClaimsPartyRoleCds. This aggregate may be repeated up to 100 times per involved party to report multiple vehicles involved in a single

claim. This aggregate SHOULD NOT BE SENT if the vehicle has not sustained damage or is not being reported stolen.

PropertyLossInfo Required elements: @id, @ClaimsPartyRefs. EACH PropertyLossInfo must contain only one <Watercraft> aggregate, OR one <ItemInfo>, OR one or more

<ClaimsSubjectInsuranceInfo> aggregates. <Watercraft> and <ItemInfo> aggregates may not be reported on the same claim. Multiple <Watercraft> or

<ItemInfo> may not be reported on the same claim. PropertyLossInfo/ ClaimsSubjectInsuranceInfo and PropertyLossInfo/ Watercraft OR PropertyLossInfo/

ClaimsSubjectInsuranceInfo> and PropertyLossInfo/ ItemInfo may be reported on the same claim. Only allowed if the ClaimsPartyRoleCd is IN, CI, TN, PT, IP, or ID.

20

PropertySchedule − Required elements if ClaimsSubjectInsuranceInfo is present and LossCauseCd=THFT: IsSummaryInd,

ItemDefinition/ItemTypeCd. • If a theft is being reported, then at least one ItemTypeCd is required to report the category of items stolen.

May be repeated to report multiple categories. Uses “SubjectInsuranceCd” codelist. − Optional elements if ClaimsSubjectInsuranceInfo is present and LossCauseCd is other than theft: This

aggregate may be used to report scheduled property. Only one of the following THREE types of sub-aggregates may be reported on a single PropertyLossInfo.

− The subaggregate tag is required to pass the ISO ClaimSearch conversion step and will result in a Synchronous Rejection if not present.

− ItemInfo • This aggregate is required for the reporting of an off-road or mobile equipment claim. • Only one may be reported by claim. • Required elements: ItemDefinition/ ItemTypeCd uses “ItemDefinition” codelist with a value of

“MoblEquip”, SerialIdNumber, ModelYear, ManufacturerCd, ModelCd − Watercraft

• This aggregate is required for the reporting of a claim on a boat policy (hull or motor coverage). • Only one may be reported per claim. • Required elements: ItemInfo/ ItemDefinition/ ItemTypeCd uses “ItemDefinition” codelist with a value of

“Watercraft”, Manufacturer, SerialIdNumber, ModelYear − ClaimsSubjectInsuranceInfo

• This aggregate is required for the reporting of 1st party property losses (fire, theft, other peril). • This aggregate may be repeated within the SAME <PropertyLossInfo> aggregate up to FIVE times, but

only ONCE for each SubjectInsuranceCd value (BLDG, C, Stock, UseOccupancy, OT). • Each PropertyLossInfo that contains one or more ClaimsSubjectInsuranceInfo aggregates may only be

associated with ONE AdjusterPartyInfo/LossCauseCd • 1st Party property insurance does not use AdjusterPartyInfo/CoverageCd, instead it uses dollar amounts

within ClaimsPayment to indicate what coverage is being applied. • ClaimsPayment

♦ Required elements: At least ONE dollar amount is required to indicate coverage being applied. ♦ All fields within this aggregate are programmatically listed as “optional” because not every loss will

have a dollar amount in every field. ♦ Please see Appendix E – Claims Payment and Status Reporting Rules for further information. ♦ Estimated Loss Amount (ProbableIncurredAmt) is required by some State Fire Marshalls for the

reporting of fire losses to their specific states. WorkCompLossInfo

This aggregate is optional and used to report elements specific to Workers’ Compensation claims and Marine Casualty Claims (Commercial Ocean Marine and Longshore/Harborworkers’ Workers’ Compensation.)

LitigationInfo This aggregate only refers to injury, liability, or 3rd party property damage claims where an involved party has filed

a lawsuit. If the <PlaintiffRef> refers to an AutoLossInfo or PropertyLossInfo, the information provided will be dropped out in the processing of the claim and not stored on the ClaimSearch system.

ClaimsPayment Optional elements: dollar amounts for Policy Amount, Reserve, Estimated Loss, or Payment Amount as well as

the Claim Status (ex. open, closed, closed without payment, etc.). This aggregate is used in for reporting the dollar amounts associated with ClaimsInjuredInfo, AutoLossInfo,

PropertyLossInfo/ItemInfo, and PropertyLossInfo/Watercraft. Please see Appendix E – Claims Payment and Status Reporting Rules for further information.

RemarkText This element is used to assist with the distribution of reports within your company. The data provided in this

element is stored and echoed back as part of the member company’s submitted claim. This element can refer to ClaimsOccurrence for claim level information, ClaimsParty for claims party level

information, or ClaimsInjuredInfo, AutoLossInfo, or PropertyLossInfo for coverage level information. The field length is 20 characters long, EXCEPT when referring to a ClaimsParty then it is limited to 5 characters.

21

InvestigationInfo This aggregate is used to report Theft Recovery or Salvage information for vehicles or boats. This aggregate also contains the Vehicle Disposition Code required for NMVTIS reporting. RecoveryInfo

− Required elements (Conditional - Optional, if one of these fields are reported, then they ALL are required).: • @ItemRef (pointing to AutoLossInfo or PropertyLossInfo/Watercraft) • @RecoveryAgencyRef (pointing to ClaimsParty with “RecoveringAgency” role code, only NameInfo is

required, all other ClaimsParty data is dropped.) • Recovery Dt and Addr/StateProvCd

SalvageInfo − This aggregate provides information regarding the salvage of a vehicle, boat, or mobile equipment. − Required elements: Dependent on claim. Please see Optional Services – National Motor Vehicle Title

Information System (NMVTIS) for specifics. com.iso_AddCovInfo

This aggregate contains Additional Coverage Information including the Coverage Information 1, Coverage Information 2.

com.iso_CovInfo1 − This aggregate captures fields required by CMS for Medicare Eligible Individuals. − This aggregate refers to the ClaimsInjuredInfo aggregate to which it is associated. − It may refer to an AutoLossInfo aggregate only if company is reporting casualty information using an

AutoLossInfo aggregate. com.iso_CovInfo2

− This aggregate captures fields optional for CMS reporting and Mass Tort reporting − This aggregate refers to the ClaimsInjuredInfo @id. − It may refer to an AutoLossInfo aggregate only if company is reporting casualty information using an

AutoLossInfo aggregate. com.iso_ClaimDirectorInd

Please see Optional Services – ClaimDirector for further information on this element. com.iso_RecallRqInd

This service has been temporary suspended and may resume at a future date.

22

The following section provides the required aggregates/elements in order for each of the types of Update requests. All aggregates/elements retain the same requirements as the Initial/Replacement requests listed above, unless otherwise indicated. Bold indicates required on ALL requests. Italics indicates required depending on data being added or updated. Bold and Italics – at least one ClaimsInjuredInfo, AutoLossInfo, OR PropertyLossInfo must be submitted per Request.

Update (1) Adding or Update (2) Updating an Involved Party

ACORD wrapper SignonRq ClaimsSvcRq ClaimInvestigationAddRq

Required elements: RqUID, TransactionRequestDt, CurCd CodeList com.iso_Update

Required elements (one or the other but not both in the same transaction): − <com.iso_UpdateInd> value is set to “1” to Add an Involved Party to an existing claim − <com.iso_UpdateInd> value is set to “2” to Update an Involved Party to an existing claim.

Policy Required elements: PolicyNumber, LOBCd, AgencyId, MiscPartyRoleCd All other fields will be dropped in processing.

ClaimsOccurrence Required elements: InsurerId, LossDt All other fields will be dropped in processing

ClaimsParty At least one is required, only the first involved party with an Involved Party Role Code will be added. This aggregate is used to report persons or organizations associated with this particular Involved Party. This can

include service providers, aliases, salvage buyers, CMS additional claimants, etc. Specific roles are identified through the use of the ClaimsPartyRole (ACORD) or ClaimsPartyRoleCd code lists in


− NameInfo − Required element: Involved Party Name must be EXACTLY the same for an Update to an Involved Party,

otherwise the Party will be ADDED to the claim, not Updated. − Addr − Communications

PersonInfo ClaimsPartyInfo

− Required element: ClaimsPartyRoleCd must be EXACTLY the same for an Update to an Involved Party, otherwise the Party will be ADDED to the claim, not Updated.

ClaimsDriverInfo ClaimsInjuredInfo

− Required elements, if reporting first-party injury or third-party liability: @id, InjuryNatureDesc PartyInvestigationInfo com.iso_ClaimsPartyVehInfo com.iso_CSLNInd

ClaimsPartyRelationship com.iso_SIUParty AdjusterParty

AdjusterPartyInfo − Required elements: @AssignmentRef, CoverageCd, LossCauseCd

AutoLossInfo

23

Required elements if reporting auto physical damage for − First party: @id, @ClaimsPartyRefs, ModelYear, VehIdentificationNumber, ManufacturerCd − Third-party: @id, @ClaimsPartyRefs

PropertyLossInfo PropertySchedule

− Required elements, if reporting first-party theft: IsSummaryInd, ItemDefinition/SubjectInsuranceCd Only one of the following sub-aggregates may be reported on a PropertyLossInfo:

− ItemInfo • This aggregate is required for the reporting of an off-road or mobile equipment claim.

− Watercraft • This aggregate is required for the reporting of a claim on a boat policy (hull or motor coverage).

− ClaimsSubjectInsuranceInfo • This aggregate is required for the reporting of 1st party property losses (fire, theft, other peril). • ClaimsPayment

♦ ClaimsSubjectInsuranceInfo does not use AdjusterPartyInfo/CoverageCd ♦ At least one dollar amount should be reported to indicate the coverage of the claim.

WorkCompLossInfo LitigationInfo ClaimsPayment

This aggregate is used in for reporting the dollar amounts associated with ClaimsInjuredInfo, AutoLossInfo, PropertyLossInfo/ItemInfo, and PropertyLossInfo/Watercraft. Please see Appendix E – Claims Payment and Status Reporting Rules for further information.

RemarkText InvestigationInfo

RecoveryInfo SalvageInfo

− Please see Optional Services for additional requirements specific to NMVTIS reporting. com.iso_AddCovInfo

com.iso_CovInfo1 com.iso_CovInfo2

com.iso_ClaimDirectorInd Please see Optional Services – ClaimDirector for further information on this element.

24

Bold indicates required on ALL requests. Italics indicates required depending on data being added or updated. Bold and Italics – at least one ClaimsInjuredInfo, AutoLossInfo, OR PropertyLossInfo must be submitted per Request.

Update (3) Updating an Amount or Status



Required elements: <com.iso_UpdateInd> value is set to “3” to Update a Dollar Amount or Coverage Status to an existing claim, and OriginalFields/NameInfo

OriginalFields − NameInfo: Involved Party Name must be EXACTLY the same for an Update to an Involved Party, otherwise

the Request will reject for “Initial claim not found.” Policy

Required elements: PolicyNumber, LOBCd, AgencyId, MiscPartyRoleCd All other fields will be dropped in processing.


ClaimsParty Required elements: Only the <ClaimsParty> @id is required, the name is taken from the com.iso_Update

aggregate. ClaimsInjuredInfo

− Required elements: @id AdjusterParty

AdjusterPartyInfo − Required elements: @AssignmentRef, CoverageCd, LossCauseCd

AutoLossInfo Required elements: @id, @ClaimsPartyRefs Required element, if more than one vehicle on SAME ClaimsParty: VehIdentificationNumber

PropertyLossInfo Only one of the following sub-aggregates may be reported on a PropertyLossInfo:

− ItemInfo • Required element: @id, @ClaimsPartyRef

− Watercraft • Required element: @id, @ClaimsPartyRef

− ClaimsSubjectInsuranceInfo • Required element: @id, @ClaimsPartyRef • ClaimsPayment

♦ On the UpdateInd=3 Request only, the ClaimsPayment inside the PropertyLossInfo is NOT used. Only the ClaimsPayment outside the PropertyLossInfo is used with a default CoverageCd of “PROP”.

ClaimsPayment This aggregate is used in for reporting the dollar amounts associated with ClaimsInjuredInfo, AutoLossInfo, and

ALL PropertyLossInfo types. Please see Appendix E – Claims Payment and Status Reporting Rules for further information.

On the UpdateInd=3 Request only, the ClaimsPayment inside the PropertyLossInfo is NOT used. Only the ClaimsPayment outside the PropertyLossInfo is used with a default CoverageCd of “PROP”.

25


Update (4) Research Request – Claim Level


Required elements: RqUID, TransactionRequestDt, CurCd com.iso_Update

Required elements: <com.iso_UpdateInd> value is set to “4” to Research a claim without changing data SearchBasisCd: required element, value = “C” Policy



NOTE: PolicyNumber, AgencyId, InsurerId, and LossDt must match EXACTLY with a claim existing on the database, otherwise the Request will be rejected for “Initial claim not found.”

Update (4) Research Request – Involved Party Level


Required elements: RqUID, TransactionRequestDt, CurCd com.iso_Update

Required elements: <com.iso_UpdateInd> value is set to “4” to Research an individual Involved Party without changing data.

com.iso_OriginalFields − GeneralPartyInfo/NameInfo

• Required fields: CommlName, Surname, GivenName, OtherGivenName elements are required to be submitted EXACTLY as they exist on the system or Request will be rejected for “Initial claim not found.”

SearchBasisCd: required element, value = “I” Policy



ClaimsParty Required elements: @id, NameInfo EXACTLY how it exists on the system

NOTE: PolicyNumber, AgencyId, InsurerId, LossDt, and NameInfo/CommlName or PersonName must match EXACTLY with a claim existing on the database, otherwise the Request will be rejected for “Initial claim not found.”

26


Update (5) Changing Key Fields



Required elements: <com.iso_UpdateInd> value is set to “5” to Update the Key Fields without changing any other claims data

com.iso_OriginalFields − com.iso_KeyFields − Required fields, PolicyNumber, AgencyId, InsurerId, and LossDt are required to be submitted EXACTLY as

they exist on the system or Request will be rejected for “Initial claim not found.” Policy

Required elements: PolicyNumber, LOBCd, AgencyId, MiscPartyRoleCd These elements will become the NEW key fields and will be required on future Replacement and Update

Requests. All other fields will be dropped in processing.

ClaimsOccurrence Required elements: InsurerId, LossDt These elements will become the NEW key fields and will be required on future Replacement and Update

Requests. All other fields will be dropped in processing

NOTE: PolicyNumber, AgencyId, InsurerId, and LossDt submitted outside the OriginalFields aggregate will be entered as the NEW Key Fields and must be a UNIQUE combination on the database, otherwise the Request will be rejected for “Request would create a duplicate record.”

27


Update (6) Adding a Service Provider

Bold indicates required on ALL requests, Italics indicates required depending on data being added or updated ACORD wrapper SignonRq ClaimsSvcRq ClaimInvestigationAddRq


Required elements: − <com.iso_UpdateInd> value is set to “6” to Add a Service Provider to an Involved Party on an existing claim.

Policy Required elements: PolicyNumber, LOBCd, AgencyId, MiscPartyRoleCd All other fields will be dropped in processing.


ClaimsParty Required elements: One ClaimsParty with an Involved Party Role Code. Specific roles are identified through the use of the ClaimsPartyRole (ACORD) or ClaimsPartyRoleCd code lists in


− NameInfo − Required element: Involved Party Name must be EXACTLY the same for an Update to an Involved Party,

otherwise the claim will be rejected for “Initial claim not found.” − Addr

ClaimsPartyInfo − Required element: ClaimsPartyRoleCd – Involved Party role code, − Must be EXACTLY the same for an Update to an Involved Party, otherwise the claim will be rejected for “Initial

claim not found.”. ClaimsParty

Required elements: One ClaimsParty with a Service Provider Role Code. Specific roles are identified through the use of the ClaimsPartyRole (ACORD) or ClaimsPartyRoleCd code lists in


− NameInfo • Required element: Involved Party Name – CommlName or PersonName

− Addr • Required elements: Address, City, StateProvCd

ClaimsPartyInfo − Required element: ClaimsPartyRoleCd –Service Provider role code,

ClaimsPartyRelationship Required elements: @ClaimsParty1Ref, @ClaimsParty2Ref, ClaimsPartyRole1Cd, ClaimsPartyRole2Cd ClaimsParty1Ref and ClaimsPartyRole1Cd should reference the Involved Party.

− ClaimsPartyRole1Cd requires a codelistref. ClaimsParty2Ref and ClaimsPartyRole2Cd should reference the Service Provider.

− ClaimsPartyRole2Cd requires a codelistref.

28

XML Request Aggregates by Line of Business

ISO ClaimSearch XML Structure

ISO ClaimSearch XML transmissions require a specific basic XML structure as well as certain required aggregates and elements for the reporting of claims data. Below is an explanation of the basic structure and required elements common to all claims, followed by an explanation of how to report claims by line of business and type of claim. Each of the line of business sections include a description of the type of claim reported, the high-level XML structure, and the required elements specific to the type of claim being reported. See Special Programming Notes for additional situations to consider when programming. The basic hierarchy structure of an XML transmission is defined by the order that Entities, Wrappers, Aggregates, and Elements are listed within the tables in the file layout section of the manual. Please follow this order when programming the XML Structure. ISO ClaimSearch also provides a Schema file to assist in the programming of Request hierarchy.

Claim Level Elements Common to All Claims

This section represents the elements that are reported at the claim level for every Initial or Replacement Request submitted regardless of Line of Business. The following sections describes the MINIMUM aggregates required for a successful submission to ISO ClaimSearch for each Line of Business. Other aggregates and elements may be used to report optional information or may be necessary for the Additional and Optional Services that ISO ClaimSearch provides based on membership agreements. These are outlined elsewhere in the manual (see Additional and Optional Services). Also, there may be additional elements required by the ACORD specification, not listed in this section. In addition, due to the nature of ACORD XML, there are certain identifiers and references that ISO requires to properly interpret the XML. These have been marked as “Required” in their proper context in a later section of this manual. Every Claim Submission will have the following aggregates: ACORD – to identify the beginning and end of transmission SignonRq – for authentication ClaimsSvcRq/ ClaimInvestigationAddRq – for XML transaction information CodeList – to list all non-ACORD code lists used within the file Policy – to identify information regarding the policy itself ClaimsOccurrence – to identify the information that applies to the entire claim ClaimsParty – to identify the individuals or organizations involved in the claim. It is also not necessary to report an

individual who has not been injured and who does not have a vehicle or property damaged in the accident. AdjusterPartyInfo – to identify the coverage and loss type(s) that apply to the individuals or organizations making

claims against the policy The Common Elements to all claims can be found at these locations within the provided Schema file.

Data Element Location

Policy Number ClaimInvestigationAddRq/ Policy/ PolicyNumber

Policy Type ClaimInvestigationAddRq/ Policy/ LOBCd

Insuring Company ID ClaimInvestigationAddRq/ Policy/ MiscParty/ ItemIdInfo/ AgencyId and ClaimInvestigationAddRq/Policy/MiscParty/MiscPartyRoleCd = “CarrierInsurer”

Claim Number ClaimInvestigationAddRq/ ClaimsOccurrence/ ItemIdInfo/ InsurerId

Date of Loss ClaimInvestigationAddRq/ ClaimsOccurrence/ LossDt

Incident Description ClaimInvestigationAddRq/ ClaimsOccurrence/ IncidentDesc

Location of Loss State ClaimInvestigationAddRq/ ClaimsOccurrence/ Addr/ StateProvCd

Coverage Type ClaimInvestigationAddRq/ AdjusterParty/ AdjusterPartyInfo/ CoverageCd (except for 1st party property losses, please see property claims section for further information)

Loss Type ClaimInvestigationAddRq/ AdjusterParty/ AdjusterPartyInfo/ LossCauseCd

29

ClaimsParty Required Elements and System Rules

The following section outlines the differences in what elements are required for the successful adding of a ClaimsParty information into the system based on the ClaimsPartyRoleCd. Please see Appendix D – Role Codes for further explanation of what role codes fall into each category.

Involved Party Required Elements

The following elements are required for ALL parties with an Involved Party Role Code for ISO ClaimSearch Basic Claims Reporting and can be found within the labeled location in the tables within this manual or the XML Request Schema file. There may be additional elements required for Additional or Optional Services listed in that section of the manual. Involved Party System Processing Rules Every claim must contain a role of CI or IN. The roles IN, ID, and IP do not require a coverage record, but if they are sent with a casualty coverage record

(ClaimsInjuredInfo) and names use <PersonName> aggregate, then the involved party will be searched. A coverage record (ClaimsInjuredInfo, PropertyLossInfo, or AutoLossInfo) is required for these roles: CD, CE, CL, CI,

CP. • ClaimsInjuredInfo can only exist for roles CL, CP, CD, CI, IN, ID, IP, IE. • PropertyLossInfo can only exist for roles IN and CI and can exist only one time in a claim. • AutoLossInfo can only exist for roles CL, CP, CD, CI, IN, ID, or IP.

Required Elements: • GeneralPartyInfo/NameInfo:

CommlName/CommercialName for Businesses PersonName/Surname and PersonName/GivenName for Individuals

• GeneralPartyInfo/Addr Addr1 for street address information. City StateProvCd (for US States)

• CountryCd may be used for other countries • Canada addresses require both (StateProvCd and CountryCd)

• ClaimsPartyInfo/ClaimsPartyRoleCd with codelistref Searchable Elements:

• GeneralPartyInfo/NameInfo TaxIdentity/TaxIdTypeCd (SSN for individual) and TaxId

• GeneralPartyInfo/Addr PostalCode (Zip Code)

• GeneralPartyInfo/Communications PhoneTypeCd: Cell and PhoneNumber (+1-NNN-NNNNNNN format) CommunicationUseCd: Home and PhoneNumber (+1-NNN-NNNNNNN format) EmailInfo/EmailAddr

• PersonInfo/BirthDt (Date of Birth) • ClaimsDriverInfo/DriversLicense (searched in combination with each other)

DriversLicenseNumber StateProvCd

• AutoLossInfo/VehInfo/Registration (searched in combination with each other) RegistrationNumber (License Plate Number) StateProvCd

30

Service Provider Required Elements

The following elements are required for ALL parties with a Service Provider Role Code for ISO ClaimSearch Basic Claims Reporting and can be found within the labeled location in the tables within this manual or the XML Request Schema file. There may be additional elements required for Additional or Optional Services listed in that section of the manual. Service Provider System Processing Rules Reporting of Service Providers are entirely optional for ISO ClaimSearch Basic Claims Reporting. The Required Elements below are what is required if you choose to report Service Providers. There may be different requirements for Additional or Optional Services, such as CMS Reporting. Service Providers require a ClaimsPartyRelationship aggregate to tie the Service Provider to the Involved Party. Service Providers with ClaimsPartyRoleCd = CO, FM, LP, or SM are searched when tied to Involved Party’s with a

PropertyLossInfo Service Providers with ClaimsPartyRoleCd = MA, MC, MD, ME, MF, MG, MH, MK, ML, MM, MN, MO, MR, MS, MT,

MX, MY, MZ may include the Optional field <com.iso_1stDoctorDt>. Required Elements (only if you opt to report a Service Provider):

• GeneralPartyInfo/NameInfo: CommlName/CommercialName for Businesses PersonName/Surname and PersonName/GivenName for Individuals

• GeneralPartyInfo/Addr. City StateProvCd (for US States)


• ClaimsPartyInfo/ClaimsPartyRoleCd with codelistref • ClaimsPartyRelationship aggregate to tie Service Provider to an Involved Party

Searchable Elements (only Service Providers with ClaimsPartyRoleCd = CO, FM, LP, or SM are searched when tied to Involved Party’s with a PropertyLossInfo): • GeneralPartyInfo/NameInfo

TaxIdentity/TaxIdTypeCd (SSN for individual) and TaxId • GeneralPartyInfo/Addr

PostalCode (Zip Code) • GeneralPartyInfo/Communications

PhoneTypeCd: Cell and PhoneNumber (+1-NNN-NNNNNNN format) CommunicationUseCd: Home and PhoneNumber (+1-NNN-NNNNNNN format) EmailInfo/EmailAddr




To link the Service Provider information to the Involved Party it is associated with: On the <ClaimsPartyRelationship> aggregate, enter the Involved Party ClaimsParty id as ClaimsParty1Ref and the role code of that party in ClaimsPartyRole1Cd. Enter the Service Provider ClaimsParty id as ClaimsParty2Ref and the role code of that party in the ClaimsPartyRole2Cd value. NOTE: ClaimsPartyRoleCd codelistref is required for all Involved Party and Service Provider role codes. <ClaimsPartyRelationship ClaimsParty1Ref="ClaimsParty-02" ClaimsParty2Ref="ClaimsParty-03"> <ClaimsPartyRole1Cd codelistref="ClaimsPartyRoleCdList">CL</ClaimsPartyRole1Cd> <ClaimsPartyRole2Cd codelistref="ClaimsPartyRoleCdList">MD</ClaimsPartyRole2Cd> </ClaimsPartyRelationship>

31

Alias Required Elements

The following elements are required for ALL parties with the Alias Role Code and can be found within the labeled location in the tables within this manual or the XML Request Schema file. There may be additional elements required for Additional or Optional Services listed in that section of the manual. Alias System Processing Rules Reporting of aliases are entirely optional for ISO ClaimSearch Basic Claims Reporting and can be reported for either

Involved Parties or Service Providers. The Required Elements below are what is required if you choose to report Alias. There may be different requirements for Additional or Optional Services, such as CMS Reporting. Alias requires a ClaimsPartyRelationship aggregate to tie the information to the Involved Party or Service Provider

which it is being submitted for. Search Rules: Name/Address of Alias will be cross searched against the Name/Address of the Involved Party (or

searchable Service Provider) that it is associated with in all combinations using fuzzy logic to find spelling variations. Only the different name OR address needs to be submitted on the Alias ClaimsParty aggregate. Do not repeat the same name/address on the Alias OR provide all spellings. This will cause extra-large Response files and/or delays in receiving your Asynchronous Response due to excessive cross-searching results.

Required Elements (if data values are different than the Involved Party or Service Provider ClaimsParty): • GeneralPartyInfo/NameInfo:




• ClaimsPartyInfo/ClaimsPartyRoleCd=Alias (no codelistref used) • ClaimsPartyRelationship to tie Alias to Involved Party or Service Provider

Searchable Elements (if data values are different than the Involved Party or Service Provider ClaimsParty): • GeneralPartyInfo/NameInfo

TaxIdentity/TaxIdTypeCd (SSN for individual) and TaxId • GeneralPartyInfo/Addr

PostalCode (Zip Code) • GeneralPartyInfo/Communications

PhoneTypeCd: Cell and PhoneNumber (+1-NNN-NNNNNNN format) CommunicationUseCd: Home and PhoneNumber (+1-NNN-NNNNNNN format) EmailInfo/EmailAddr




To link the Alias information to the Involved Party or the Service Provider it is associated with: On the <ClaimsPartyRelationship> aggregate, enter the Involved Party or Service Provider ClaimsParty id as ClaimsParty1Ref and the role code of that party in ClaimsPartyRole1Cd. Enter the Alias ClaimsParty id as ClaimsParty2Ref and the role code of “Alias” in the ClaimsPartyRole2Cd value. NOTE: Alias is an ACORD code and does NOT use a codelistref. <ClaimsPartyRelationship ClaimsParty1Ref="ClaimsParty-02" ClaimsParty2Ref="ClaimsParty-03"> <ClaimsPartyRole1Cd codelistref="ClaimsPartyRoleCdList">CL</ClaimsPartyRole1Cd> <ClaimsPartyRole2Cd>Alias</ClaimsPartyRole2Cd> </ClaimsPartyRelationship>

32

Additional Claimant for Medicare Section 111 Reporting Required Elements

The following elements are required for ALL parties with the Additional Claimant Role Codes for ISO ClaimSearch Medicare Section 111 Reporting and can be found within the labeled location in the tables within this manual or the XML Request Schema file. These role codes are not used by ISO ClaimSearch but will be added to the claim if submitted. Additional Claimant System Processing Rules Additional Claimant role codes (ES, FA, OC) are intended for Medicare Section 111 Reporting only. Each requires its own ClaimsParty and a ClaimsPartyRelationship aggregate tying it to an Involved Party ClaimsParty

the same as a Service Provider. Up to 4 Additional Claimants may be reported per ClaimsParty. NOTE: more than 4 may be submitted, but only the

first 4 are stored in the system. The others will be dropped in processing. Each Additional Claimant may have its own Service Provider Legal Representative as well as Alias information for

each the Additional Claimant and Service Provider Legal Representative where the Additional Claimant role code is used as “ClaimsParty1” on the ClaimsPartyRelationship aggregate.

Required Elements (for Medicare Reporting, not required for ISO ClaimSearch Basic Claims Reporting): • GeneralPartyInfo/NameInfo:




• GeneralPartyInfo/Communications CommunicationUseCd: Home and PhoneNumber (+1-NNN-NNNNNNN format)

• ClaimsPartyInfo/ClaimsPartyRoleCd=ES, FA, or OC values only - codelistref is required • ClaimsPartyRelationship to tie Additional Claimant to Involved Party or Service Provider

Searchable Elements: None. Additional Claimants are NOT searched in ISO ClaimSearch Basic Claims Reporting.

33

Legal Representative Role Codes for Medicare Section 111 Reporting Required Elements

The following elements are required for ALL parties with the Legal Representative Role Codes for ISO ClaimSearch Medicare Section 111 Reporting and can be found within the labeled location in the tables within this manual or the XML Request Schema file. These role codes are not used by ISO ClaimSearch Basic Claims Reporting, but will be added to the claim, if submitted correctly. Legal Representative for Medicare System Processing Rules Legal Representative role codes (GU, LS, OR, PW) are intended for Medicare Section 111 Reporting only. Each requires its own ClaimsParty and a ClaimsPartyRelationship aggregate tying it to an Involved Party or Additional

Claimant ClaimsParty the same as a Service Provider. Each Legal Representative for Medicare may also have Alias information tied to it through the

ClaimsPartyRelationship aggregate where the Legal Representative role code is used as “ClaimsParty1” on the ClaimsPartyRelationship aggregate.

Required Elements (for Medicare Reporting, not required for ISO ClaimSearch Basic Claims Reporting): • GeneralPartyInfo/NameInfo:

PersonName/Surname and PersonName/GivenName for Individuals • GeneralPartyInfo/Addr.

City StateProvCd (for US States)


PostalCode (Zip Code) • ClaimsPartyInfo/ClaimsPartyRoleCd=GU, LS, OR, PW values only - codelistref is required • ClaimsPartyRelationship to tie Additional Claimant to Involved Party or Service Provider

Searchable Elements: None. Additional Claimants are NOT searched in ISO ClaimSearch Basic Claims Reporting. Claims with Attorney Roles (GU, LC, LI, LM, LO, LR,LS, LW, OR, or PW) associated with an Injured Party reported on or after 1/1/11 are required to report the following fields for Legal Representatives to CMS Medicare

Field Name CMS Usage XML Tag Name CMS Field Description

Business Name Optional <CommercialName> CMS Field #70 for Attorney Roles (LC, LI, LM, LO, LR, LW)

Last Name Required <Surname> CMS Required Field #65 if Injured Party has a representative (for roles indicated in Role description above).

First Name Required <GivenName> CMS Required Field #66 if Injured Party has a representative (for roles indicated in Role description above).

SSN Optional <TaxId> CMS Field #68 - if Injured Party has a representative which is an individual

TIN Optional <TaxId> CMS Field #68 - if Injured Party has a representative which is a business

Address Info Line 1 Required <Addr1> CMS Field #69 – Street Number and Name. If no US address is available, empty tag should be sent with “FC” in the <StateProvCd>

Address Info Line 2 Optional <Addr2> CMS Field #70 – Other address info, such as suite number.

City Required <City> CMS Field #71 – If no US address is available, empty tag should be sent with “FC” in the <StateProvCd>

State Required <StateProvCd> CMS Field #72 – If no US address is available, supply “FC.” The District of Columbia, American Samoa, Guam, Puerto Rico, and the US Virgin Islands are considered to have US addresses.

Postal Code Required <PostalCode> 9 digits, CMS Field #73 and 74

Telephone Required <Communications/ PhoneInfo/ PhoneTypeCd “Phone”/ CommunicationUseCd “Home”/ PhoneNumber>

CMS Field #75 and 76 - Only one phone number plus extension is submitted to CMS. There is no distinction of “Home” or “Business”; “Phone” or “Cell”. If no US phone number is available, fill with zeroes and supply “FC” in the <StateProvCd>

Role Code Required <ClaimsPartyRoleCd>

Uses codelistref

CMS Field #64 for Attorney Roles (LC, LI, LM, LO, LR, LW), Guardian (GU) and/or Power of Attorney (PW).

34

Other Party Role Codes (ACORD) Required Elements

The following elements are required for ALL parties with the ACORD-standard Role Codes for ISO ClaimSearch Basic Claims Reporting and can be found within the labeled location in the tables within this manual or the XML Request Schema file. There may be additional elements required for Additional or Optional Services listed in that section of the manual. Other Party Role Codes (ACORD) System Processing Rules There are 9 ACORD-standard role codes that do NOT require a codelistref when reporting these role codes. The rules for Alias are listed in Alias Required Elements. The ACORD role codes are case and spelling sensitive. Note that the value for Impounding Agency “ImpouundAgcy”

has two u’s in it and must be submitted as such. Required Elements (within ClaimsParty by role code):

• DeathMaster: Response Only. Provided by Social Security Administration for SSNs of individuals reported as deceased. GeneralPartyInfo/NameInfo/ PersonName/Surname and PersonName/GivenName GeneralPartyInfo/Addr/ City and StateProvCd (for US States) ClaimsInjuredInfo/ EventInfo/ EventCd=”Death” (no codelistref) and EventDt (Date of Death) ClaimsPartyInfo/ClaimsPartyRoleCd=DeathMaster ClaimsPartyRelationship to tie Death Master information to Involved Party

• Emergency: Used to report the “Agency Notified of Loss (Police/Fire). GeneralParty/NameInfo/CommlName/CommercialName ClaimsPartyInfo/ClaimsPartyRoleCd=Emergency ClaimsParty id must be referred to in ClaimsOccurrence/ClaimsReported ReportedToRef=” “. NO ClaimsPartyRelationship is used.

• ImpoundFac: Response Only. Used to report Impound Facility Name and Phone Number GeneralParty/NameInfo/CommlName/CommercialName GeneralParty/Communications/PhoneInfo/PhoneNumber ClaimsPartyInfo/ClaimsPartyRoleCd=ImpoundFac ClaimsParty id must be referred to in MatchDetails/ InvestigationInfo/ AutoInvestigationInfo/

ImpoundFacilityRef • ImpouundAgcy:

Response Only. Used to report Impound Agency Name and Phone Number GeneralParty/NameInfo/CommlName/CommercialName GeneralParty/Communications/PhoneInfo/PhoneNumber ClaimsPartyInfo/ClaimsPartyRoleCd=ImpouundAgcy ClaimsParty id must be referred to in MatchDetails/ InvestigationInfo/ AutoInvestigationInfo/

ImpoundAgencyRef • PortOrigin:

Response Only. Used to report Port Name for vehicle export GeneralParty/NameInfo/CommlName/CommercialName ClaimsPartyInfo/ClaimsPartyRoleCd=PortOrigin ClaimsParty id must be referred to in MatchDetails/ InvestigationInfo/ AutoInvestigationInfo/ PortOriginRef

• RecoveringAgency: GeneralPartyInfo/Addr/ StateProvCd (for US States) ClaimsPartyInfo/ClaimsPartyRoleCd=RecoveringAgency NO ClaimsPartyRelationship is used ClaimsParty id must be referred to in RecoveryInfo RecoveringAgencyRef=” “.

• SalvageBuyer: GeneralParty/NameInfo/

• CommlName/CommercialName OR PersonName/Surname and PersonName/GivenName ClaimsPartyRoleCd = SalvageBuyer For 3rd party salvage buyer, ClaimsParty id must be referred to in SalvageInfo BuyerRef=” “. NO ClaimsPartyRelationship aggregate is used.

35

Casualty Claims – 1st Party Injury and 3rd Party Injury, Liability, and Property Damage

The majority of casualty claims involve at least two claims parties – the insured that is named on the policy; and the claimant that was physically injured, liabled (harassment, slander, wrongful termination, etc.), or had property damaged due to the insured. There are a few coverages that may apply directly to the insured (PIP, uninsured motorist, or underinsured motorists). For these coverages, a single claims party may be submitted with a role code of CI for Claimant and Insured. These aggregates are used regardless of the type of policy (Commercial Liability, Commercial Auto, Personal Liability [including Homeowners Liability], Personal Auto, Workers Compensation, Accident & Health, or Life). If the injury or liability claim is being applied against an auto policy, it is NOT necessary to report the vehicle involved UNLESS the vehicle itself has been damaged. ACORD wrapper SignonRq ClaimsSvcRq ClaimInvestigationAddRq: RqUID CodeList Policy

Required Elements: PolicyNumber, LOBCd (Policy Type), AgencyId, MiscPartyRoleCd (defaults to “CarrierInsurer”.)


Loss State) CMS Fields: This aggregate also contains RRE Code, TIN, and Site ID for CMS reporting.

ClaimsParty At least one is required, only the first 99 involved parties reported will be searched. Required Fields are dependent on the ClaimsPartyRoleCd submitted and are broken out by type below. GeneralPartyInfo

− NameInfo • Required: on all involved parties and service providers, Name is optional for Alias if Addr is provided. • Searchable: on alias if name provided is different than involved party • CMS reporting may have additional requirements specific to CMS role codes.

− Addr • Required for Involved Parties: Addr1, City, and StateProvCd • Required for Service Providers: City and StateProvCd • Searchable for Alias: Addr1, City, and StateProvCd. Addr is optional for Alias if NameInfo is provided. • CMS reporting may have additional requirements specific to CMS role codes. • Searchable for all parties: PostalCode, if provided enhances address searches.

PersonInfo − Required: Birth Date for CMS Reporting: − Optional: Gender is optional for CMS Reporting, but is useful in determining matches


A and Appendix D for further information. ClaimsDriverInfo

− Searchable Elements: Driver’s License Number and Driver’s License State. ClaimsInjuredInfo

− This aggregate is required for all involved parties with injuries, liabilities (such as harassment or slander), or 3rd party property damage. It may be repeated as necessary to cover all coverage/loss types being claimed.

− Required elements: @id, InjuryNatureDesc − Not allowed if the ClaimsPartyRoleCd is Owner, Partner, Tenant, Witness, Alias, or any of the Service

Provider role codes listed in Appendix D. −

36

ClaimsPartyRelationship Required elements: The entire aggregate, but only if reporting Alias or Service Provider information.

com.iso_SIUParty CMS elements: @idref linking this aggregate to an Involved Party OR a Service Provider,

com.iso_MedicareEligibleInd (required for CMS), HICN/MBI (required for CMS) AdjusterParty

Required elements: AdjusterPartyInfo Only one Adjuster name and contact information may be reported per individual ClaimsInjuredInfo aggregate. The aggregate may be repeated if more than one Adjuster is handling separate ClaimsInjuredInfo aggregates. AdjusterPartyInfo

− Required elements: @AssignmentRef referring to an individual ClaimsInjuredInfo, CoverageCd, LossCauseCd

WorkCompLossInfo Required elements: VesselCallId is used for Location of Loss when incident occurs at sea.

com.iso_AddCovInfo com.iso_CovInfo1

− CMS Fields: @idref, com.iso_MedicareEligibleInd

37

Vehicle Claims – 1st Party and 3rd Party Auto Physical Damage and Theft

Vehicle claims may be applied to 1st party losses (insured placing a claim against his/her own policy) or 3rd party losses (claimant placing a claim against someone else’s policy). These aggregates are used regardless of the type of policy (Commercial Auto or Personal Auto). DO NOT SEND this aggregate UNLESS a coverage and loss type are being applied to this vehicle.

Auto Claim – 1st Party

In the case of a 1st party loss, a single claims party may be submitted with the role code of CI for Claimant and Insured. The following elements are required per 1st party vehicle loss. ACORD wrapper SignonRq ClaimsSvcRq ClaimInvestigationAddRq: RqUID CodeList Policy



Loss State) ClaimsParty

At least one is required, only the first 99 involved parties reported will be searched. Required Fields are dependent on the ClaimsPartyRoleCd submitted and are broken out by type below. GeneralPartyInfo

− NameInfo • Required: on all involved parties and service providers, Name is optional for Alias if Addr is provided. • Searchable: on alias if name provided is different than involved party

− Addr • Required for Involved Parties: Addr1, City, and StateProvCd • Required for Service Providers: City and StateProvCd • Searchable for Alias: Addr1, City, and StateProvCd. Addr is optional for Alias if NameInfo is provided. • Searchable for all parties: PostalCode, if provided enhances address searches.



− Searchable Elements: Driver’s License Number and Driver’s License State. ClaimsPartyRelationship

Required elements: The entire aggregate, but only if reporting Alias or Service Provider information. AdjusterParty

Required elements: AdjusterPartyInfo Only one Adjuster name and contact information may be reported per individual AutoLossInfo aggregate. The aggregate may be repeated if more than one Adjuster is handling separate AutoLossInfo aggregates. AdjusterPartyInfo

− Required elements: @AssignmentRef referring to an AutoLossInfo id, CoverageCd, LossCauseCd AutoLossInfo

Required elements: @id, @ClaimsPartyRef referring to the ClaimsParty with an Insured role code, ModelYear, ManufacturerCd, VehIdentificationNumber

38

Auto Claim – 3rd Party

In the case of a 3rd party loss, two claims parties must be submitted, one for the Insured and one for the Claimant. The following elements are required per 3rd party vehicle loss. ACORD wrapper SignonRq ClaimsSvcRq ClaimInvestigationAddRq: RqUID CodeList Policy




At least two are required: one with an insured role code (IN, ID, IP, or CI) and one with a claimant role code (CL, CD, or CP), only the first 99 involved parties reported will be searched.

Required Fields are dependent on the ClaimsPartyRoleCd submitted and are broken out by type below. GeneralPartyInfo








− Required elements: @AssignmentRef referring to an AutoLossInfo id, CoverageCd, LossCauseCd AutoLossInfo

Required elements: @id, @ClaimsPartyRef referring to the ClaimsParty with a Claimant role code, ModelYear, ManufacturerCd,

VehIdentificationNumber (VIN) is not required for 3rd Party Claimants, particularly at First Notice of Loss; however, VIN becomes required for 3rd Party Claimants (roles CL, CD, CP) in the following scenarios: − Loss Type is THFT (to receive Vehicle Theft Recovery Notices for NICB members) − Multiple vehicles are reported for a single ClaimsParty (to distinguish the vehicles which often have the same

coverage/loss type applied) − If the vehicle is salvaged and is being reported to NMVTIS (to mark the specific vehicle being salvaged).

39

Auto Claim – 1st and 3rd Party

In the case where both 1st party and 3rd party damage are being reported, both formats above would be combined with one ClaimsParty aggregate, one AdjusterPartyInfo aggregate and one AutoLossInfo aggregate per Involved Party in the claim. The Required and Searchable elements stay the same as the individual scenarios above. Below is an example of the aggregates repeated for the multiple party reporting. ACORD wrapper SignonRq ClaimsSvcRq ClaimInvestigationAddRq: RqUID CodeList Policy




GeneralPartyInfo − NameInfo − Addr

ClaimsPartyInfo − Required elements: ClaimsPartyRoleCd for Insured role code (IN, ID, IP, or CI).

ClaimsParty GeneralPartyInfo

− NameInfo − Addr

ClaimsPartyInfo − Required elements: ClaimsPartyRoleCd for Claimant role code (CL, CD, or CP).

ClaimsPartyRelationship − Required elements: The entire aggregate, but only if reporting Alias or Service Provider information

AdjusterParty AdjusterPartyInfo

− Required elements: @AssignmentRef referring to an AutoLossInfo id for the Insured’s vehicle, CoverageCd, LossCauseCd

AdjusterPartyInfo − Required elements: @AssignmentRef referring to an AutoLossInfo id for the Claimant’s vehicle,

CoverageCd, LossCauseCd AutoLossInfo

Required elements: @id, @ClaimsPartyRef referring to the ClaimsParty with an Insured role code, ModelYear, ManufacturerCd, VehIdentificationNumber (VIN)

AutoLossInfo Required elements: @id, @ClaimsPartyRef referring to the ClaimsParty with a Claimant role code, ModelYear,

ManufacturerCd, VehIdentificationNumber (VIN) per 3rd Party Claimant reporting rules above.

40

Auto Claim – Multiple Vehicles for Single ClaimsParty

In the case where a single ClaimsParty is reporting damage to more than one vehicle, then there will be one ClaimsParty aggregate with multiple AdjusterPartyInfo aggregates and multiple AutoLossInfo aggregates associated with that party in the claim. The Required and Searchable elements stay the same as the individual scenarios above. Below is an example of the aggregates repeated for the multiple party reporting of an Insured with damage to two vehicles (for example, two vehicles damaged in the same hailstorm). If the multiple vehicles belong to a 3rd party (for example, an insured and their spouse driving vehicles in traffic and both are involved in a multi-car collision), then a separate ClaimsParty would be required for the Insured and the multiple AdjusterPartyInfo and AutoLossInfo aggregates would point to the ClaimsParty with a Claimant role code (CL, CD, or CP). In this case, VIN is a required field for 3rd party Claimants. NOTE – Multiple vehicles may be reported for a single ClaimsParty with the same coverage and loss types, however they must have unique VINs, or the claim will reject. Up to 100 VINs may be reported for a single ClaimsParty. ACORD wrapper SignonRq ClaimsSvcRq ClaimInvestigationAddRq: RqUID CodeList Policy




GeneralPartyInfo − NameInfo − Addr

ClaimsPartyInfo − Required elements: ClaimsPartyRoleCd for Insured role code (IN, ID, IP, or CI).

AdjusterParty AdjusterPartyInfo

− Required elements: @AssignmentRef referring to an AutoLossInfo id for the Insured’s first vehicle, CoverageCd, LossCauseCd – coverage/loss combination can be the same as below if VIN is unique

AdjusterPartyInfo − Required elements: @AssignmentRef referring to an AutoLossInfo id for the Insured’s second vehicle,

CoverageCd, LossCauseCd - coverage/loss combination can be the same as above if VIN is unique AutoLossInfo

Required elements: @id, @ClaimsPartyRef referring to the ClaimsParty with an Insured role code, ModelYear, ManufacturerCd, VehIdentificationNumber (VIN) - must be unique

AutoLossInfo Required elements: @id, @ClaimsPartyRef referring to the ClaimsParty with an Insured role code, ModelYear,

ManufacturerCd, VehIdentificationNumber (VIN) – must be unique

41

Auto Claim – Vehicle Theft

For those who have memberships in both ISO ClaimSearch Auto and NICB and wish to receive NCIC Vehicle Theft Recovery notices on stolen vehicles, there are specific indicators that are required. The claim must contain a CoverageCd of COMP (Comprehensive), GGKP (Garage Keepers) or OTAU (Other Auto) The claim must contain a LossCauseCd of THFT. Theft Type Indicator <com.iso_TheftTypeInd> must contain a “T” for Total Theft. ACORD wrapper SignonRq ClaimsSvcRq ClaimInvestigationAddRq: RqUID CodeList Policy












− Required elements: • @AssignmentRef referring to an AutoLossInfo id, • CoverageCd MUST = COMP, GGKP, or OTAU • LossCauseCd MUST = THFT

AutoLossInfo Required elements: @id, @ClaimsPartyRef referring to the ClaimsParty with an Insured role code, ModelYear,

ManufacturerCd, VehIdentificationNumber InvestigationInfo

Required elements: − @ItemRef referring to the AutoLossInfo of the stolen vehicle − <com.iso_TheftTypeInd>T</com.iso_TheftTypeInd>

42

Property Claims – 1st Party General Property, Boat, Off-Road/Mobile Equipment

The PropertyLossInfo is used for 1st Party Property Damage (Commercial Property or Personal Property) reporting only. Property Damage to 3rd Party Property is covered under the liability portion of the policy and therefore reported on the ClaimsInjuredInfo aggregate. Note: A 1st party general property claim <ClaimsSubjectInsuranceInfo> may be reported in conjunction with a single boat policy claim <Watercraft>, OR in conjunction with a single off-road/mobile equipment claim <ItemInfo>; however, <Watercraft> and <ItemInfo>, multiple <Watercraft>, or multiple <ItemInfo> are still not allowed to be reported within a single claim.

ItemInfo – Off-Road or Mobile Equipment

Off-Road or Mobile Equipment is generally any vehicle not licensed for road use, such as ATVs or Construction Vehicles. See PropertyLossInfo aggregate below for further details specific to this type of claim reporting.

ACORD wrapper SignonRq ClaimsSvcRq ClaimInvestigationAddRq: RqUID CodeList Policy








A and Appendix D for further information. ClaimsPartyRelationship


Required elements: AdjusterPartyInfo Only one Adjuster name and contact information may be reported per individual PropertyLossInfo aggregate. AdjusterPartyInfo

− Required elements: @AssignmentRef referring to an PropertyLossInfo id, CoverageCd, LossCauseCd PropertyLossInfo

Required elements: @id, @ClaimsPartyRefs referring to the ClaimsParty with an Insured role code, ItemInfo ItemInfo

− ItemDefinition • Required elements: ItemTypeCd=MoblEquip, SerialIdNumber, ModelYear, ManufacturerCd, ModelCd

− This aggregate may NOT be repeated to report multiple vehicles. Each vehicle must be reported as a separate claim.

43

Watercraft

See PropertyLossInfo aggregate below for further details specific to this type of claim reporting.












− Required elements: @AssignmentRef referring to an PropertyLossInfo id, CoverageCd, LossCauseCd PropertyLossInfo

Required elements: @id, @ClaimsPartyRefs referring to the ClaimsParty with an Insured role code, Watercraft Watercraft

− Required elements: WaterUnitTypeCd, ItemDefinition − ItemDefinition

• Required elements: ItemTypeCd=Watercraft, Manufacturer, SerialIdNumber, ModelYear − This aggregate may NOT be repeated to report multiple watercrafts. Each watercraft must be reported as a

separate claim.

44

ClaimsSubjectInsuranceInfo – 1st Party Property

See PropertyLossInfo aggregate below for further details specific to this type of claim reporting.












− Required elements: @AssignmentRef referring to an PropertyLossInfo id, LossCauseCd − NOTE: CoverageCd is NOT used for PropertyLossInfo claims. The Coverage for a 1st Party Property

claim is determined by the SubjectInsuranceCd and the dollar amount reported. These fields are listed as optional for coding purposes, but at least one should be reported to provide information as to what type and how large a claim is being reported.

PropertyLossInfo Required elements: @id, @ClaimsPartyRefs referring to the ClaimsParty with an Insured role code,

ClaimsSubjectInsuranceInfo PropertySchedule/ ItemDefinition

− Required elements: If the LossCauseCd = THFT, then ItemDefinition becomes Required. At least one category of stolen items from the “SubjectInsuranceCd” code list must be reported. This may be repeated to report more than one category.

ClaimsSubjectInsuranceInfo − Required elements: SubjectInsuranceCd, and at least ONE dollar amount (See Appendix E for further

information.) − This aggregate may be repeated to report multiple SubjectInsuranceCd values. − InsuranceAmt, ProbableIncurredAmt, ClaimsPayment: Dollar amounts for 1st Party Property claims are

reported on ClaimsPayment aggregates INSIDE the PropertyLossInfo aggregate. All other claim types report dollar amounts on ClaimsPayment aggregates OUTSIDE the PropertyLossInfo aggregate.

45

Vehicle, Boat, or Mobile Equipment Theft Recovery

If a vehicle, boat, or mobile equipment has been stolen and the insuring agency is reporting the theft recovery information, then the <InvestigationInfo> aggregate (including the <RecoveryInfo> aggregate) should be added to the aggregates reported above within the <ClaimInvestigationAddRq> of the claim. InvestigationInfo

Required elements: @ItemRef referring to the AutoLossInfo or PropertyLossInfo id of the stolen vehicle RecoveryInfo Required elements:

− @ItemRef referring to the AutoLossInfo or PropertyLossInfo id of the stolen vehicle − @RecoveryAgencyRef if there is a ClaimsParty with role code “RecoveringAgency” − RecoveryStatusCd codelistref=”RecoveryConditionCd” − RecoveryDt − Addr/ StateProvCd (State where Recovery occurred)

Watercraft or Mobile Equipment Salvage

If a watercraft or mobile equipment has been salvaged and the insuring agency is reporting the salvage information, then the <InvestigationInfo> aggregate (including the <SalvageInfo> aggregate) should be added to the aggregates reported above within the </ClaimInvestigationAddRq> of the claim. The following elements are required if salvage information is being reported by the insuring organization. These are in addition to the Boat Loss Elements or Mobile Equipment Loss Elements provided above. InvestigationInfo

Required elements: @ItemRef referring to the PropertyLossInfo id of the salvaged watercraft or mobile equipment

SalvageInfo − Required elements:

• @ItemRef referring to the PropertyLossInfo id of the salvaged watercraft or mobile equipment • @BuyerRef if there is a ClaimsParty with role code “SalvageBuyer” and the OwnerRetainingSalvageInd

= 0. • SalvageDt • OwnerRetainingSalvageInd

46

Vehicle Salvage

If a vehicle has been salvaged and the insuring agency is reporting the salvage information, then the <InvestigationInfo> aggregate (including the <SalvageInfo> aggregate should be added to the aggregates reported above within the </ClaimInvestigationAddRq> of the claim. The following elements are required if salvage information is being reported by the insuring organization. These are in addition to the Auto Loss Elements provided above.

Insured Retaining the Vehicle (1st Party Salvage)

InvestigationInfo

Required elements: − @ItemRef referring to the AutoLossInfo id of the salvaged vehicle. − <VehDispositionCd codelistref=”VehDispostionCdList”>T</VehDispositionCd>


• @ItemRef referring to the AutoLossInfo id of the salvaged vehicle. • SalvageDt • <OwnerRetainingSalvageInd>1</OwnerRetainingSalvageInd>

Insurance Company Retaining the Vehicle (2nd Party Salvage)

InvestigationInfo


NOTE: If the Vehicle Disposition is set to T and there is no SalvageInfo aggregate present, then the Insurance Company (based on AgencyId submitted) is assumed to be the owner of the salvage.

Another Party Retaining the Vehicle (3rd Party Salvage)

InvestigationInfo



• @ItemRef referring to the AutoLossInfo id of the salvaged vehicle.@BuyerRef referring to a ClaimsParty id that contains a NameInfo (either Commercial or PersonName) and a ClaimsPartyRoleCd of “SalvageBuyer”. ♦ If this reference is missing the error code generated states “Individual/Business Indicator Missing or

Invalid”. • SalvageDt • <OwnerRetainingSalvageInd>0</OwnerRetainingSalvageInd>

47

Special Programming Notes This section is dedicated to the nuances of programming. These are details that should be kept in mind as you design and develop your system to interact with ISO ClaimSearch. We have consolidated them into a single section for easy reference back to whenever you need them. Some of these apply only to Initial or Replacement Requests. Some apply only to Update Requests. Some apply to ALL types of Requests. Please read through this section carefully to see what applies to section you are programming. They are listed in alphabetical order.

ClaimInvestigationAddRq/Rs RqUID

For Initial and Replacement claims, ISO ClaimSearch will store the ClaimInvestigationAddRq/RqUID and return it on the Response as the ClaimInvestigationAddRs/RqUID to aid members in matching Request with Response. This will occur regardless of whether the Response is a “Success” or “Reject”.

For all requests that use the <com.iso_Update> aggregate which includes both Update Requests and Research

Requests, the ClaimInvestigationAddRq/RqUID is NOT stored and returned. If an Update Request is successful, there is no Response returned. If a Research is requested successfully, then the search process will return the last successfully submitted ClaimInvestigationAddRq/RqUID as it exists on the database.

Automatic Update Reports, Vehicle Recovery Reports, and Impound Update Reports will also return the last

successfully submitted ClaimInvestigationAddRq/RqUID as it exists on the database. If there is no RqUID in the system because the claim came in a different format (Universal Format system-to-system

or data entry on the web), then no XML Response can be returned. Please contact your ISO ClaimSearch Testing Rep regarding a systematic conversion process to populate this field prior to your accessing these claims through XML.

Claim Level Reporting Vs. Exposure Level Reporting

ISO ClaimSearch designed our Universal Format system as a means to get away from exposure level reporting. It was named “Universal” as it combined all the elements of a single claim into a single transaction to ISO, allowing for multiple claimants and coverages to be reported at once. The system is designed to search multiple searchable fields for each claimant on the claim and bring back a single match report that contains the matches for all claims. When there is activity on the system that matches against your claim, ISO ClaimSearch provides an automatic update to your system for the claim in its entirety. When you update a portion of the claim, the system will search against the claim in its entirety by default, or only on the sections that you indicate. With exposure level reporting, ISO ClaimSearch has found several issues that have adversely impacted members who choose to do this type of reporting. The first is that while the claimant and coverage might change from claim to claim, the overall claim details and insured information do not. Therefore, it is often the case that the different exposures create matches against themselves. This creates extra “noise” for the adjusters as they are required to sort through their own company’s claims to find other matching claims. If there are enough matches in the system and a particular claimant maxes out at 25 claims, they could be missing out on matches if their own company’s reports are filling up many of the 25 slots per claimant. When an automatic update matches against the insured, every exposure on the claim will receive an automatic update. Again, this creates extra “noise” for the adjusters as they will have multiples of the same report for a single claim. For many companies that have chosen to go this route, ISO ClaimSearch has received many complaints from users about the excessive reports they are receiving. Unfortunately, it is a case of “system working as designed” and we have to direct the users back to their own development team to state that this is not what they had in mind. Finally, when other companies match against your claims, or are using fraud investigation tools, an insured with 5 claimants on the claim has now moved from a single claim with 5 claimants, to appearing as if the insured has 5 separate claims against the policy. This throws off any claims scoring products as the computer systems will count it as multiple claims indicating that your insured is more fraudulent than they really are, possibly flagging them in the companies you match against. For these reasons, ISO ClaimSearch is no longer allowing members to move into Production with exposure level reporting. If a company is already reporting exposure level reporting, they will be asked to change to claim level reporting during their next system upgrade.

48

Deleting Information

Field Level:

Non-Required fields may be data deleted by submitting the claim with the field value blanked or not present. Required fields may not have data deleted but may change existing data. If the field has been updated on the ISO ClaimSearch website, then the data may only be deleted or updated on

the ISO ClaimSearch website.

Claim Level: To delete an entire claim record, users must utilize the self-administration feature available to your company’s

authorized administrator(s). Exceptions to the self-administration process will be considered on a case-by-case basis (and may incur a

processing fee). Contact ISO ClaimSearch Customer Support. ([email protected]).

Important Notice Regarding Updating Claims on the ClaimSearch Website

Most system-to-system companies do all updates to their claim information using either the Replacement or Update process through their system-to-system (STS) feed with ISO ClaimSearch. However, it is also possible to update claim information using the ISO ClaimSearch website to manually add or update the claims information that is stored on our system. If the claim is manually updated on the website, it is assumed that that information is more accurate and up to date and we do not want an STS Request to overwrite what was manually entered. Claims that were initially submitted STS and then updated on the website are now protected by the “Web Overlay” rules. Per these rules, subsequent actions on the same claim by the STS interface will: Allow the STS to change data within a field, but not blank out a value. Require that each party reported via STS must match name fields (business name or first, middle, last names) and

role codes EXACTLY in order to complete changes, otherwise the system will assume a new party is being added. Require that if data needs to be removed on a claim, then a new web update must be entered to remove the value. Cause the Web Overlay Ind, <com.iso_WebOverlayInd> to return as “Y” to indicate the claim has been touched on

the web and information in the Echo portion of the match report may be different than what was on the Request submitted via STS.

Important Notice Regarding Update Requests and CMS Medicare Reporting

RRE Codes, TINs, and SiteIds used for CMS Medicare Reporting should be reported on Initials and Replacements only. RRE Codes cannot be added through the Update Request process Update Requests do not generate CMS Warning Messages If an individual RRE Code, TIN, or SiteId element is reported on an Initial or Replacement Request, then it is required

to report all three fields in order to add the data to the database. If only one or two of these fields are submitted, then the data will not be added to the database.

If your company only uses one RRE Code, one TIN, and one SiteId, then these values do not need to be reported on your claims but will be derived from the AgencyId submitted.

Miscellaneous Text Fields <RemarkText>

ClaimInvestigationAddRq/ RemarkText idref=” “ If this field is submitted on Requests, then it will be returned on the Response unaltered. It will not display on Matching

Claims. This field can be utilized for internal distribution of Asynchronous Match Responses or for identification of the claim in

Asynchronous Rejection Responses. If the idref points to the id of ClaimsOccurrence, ClaimsInjuredInfo, AutoLossInfo, or PropertyLossInfo, then this field

can contain 20 bytes. If the idref points to the id of ClaimsParty, then this field can contain 5 bytes.


49

Minimizing Replacement and Update Rejections

Claim Number <InsurerId> and Policy Number <PolicyNumber> values should only include the actual values for these numbers. Any identifiers that may change (such as adjuster’s initials or internal office mailbox) should be placed in the <ClaimInvestigationAddRq> <RemarkText> field instead.

Replacements, Updates, and Researches must submit the EXACT values for PolicyNumber, AgencyId, InsurerId, and LossDt that were used on the Initial claim or the most recent successful UpdateInd=5 Key Field Change. Otherwise, the Request will fail for “Initial claim not found”.

PolicyNumber, AgencyId, InsurerId, and LossDt must be a new unique combination for each Initial Request and for

the “New” values in the UpdateInd=5 Key Field Change Requests. Otherwise, the Request will fail for “Request would create a duplicate record.”

If you have any questions regarding the above or would like ISO staff to research potential problems, please contact your ISO ClaimSearch Testing Representative (see Who to Call).

Multiple Vehicle Reporting

Initial and Replacements - Multiple vehicles may be reported for a single ClaimsParty with the same coverage and loss types, however they must have unique VIN numbers, or the claim will reject. For third-party claimants, where VIN is not normally required for a single vehicle, the VIN will become required in the event of multiple vehicles reported for the same ClaimsParty. Up to 100 VINs may be reported for a single ClaimsParty.

Updates to a Single Vehicle Claim - When sending <com.iso_UpdateInd>=1, 2, or 3 on a claim that has a single VIN

for each ClaimsParty, VIN is not required. The claim will be updated based on involved party, coverage type, and loss type.

Updates to a Multiple Vehicle Claim - When sending <com.iso_UpdateInd>=1, 2, or 3 on a claim that has a multiple

VINs for a single ClaimsParty, you must indicate which vehicle record the update is for by providing the VIN of the vehicle, even if the ClaimsParty is a third-party claimant. The claim will be updated based on involved party, coverage type, loss type, and VIN.

NOTE – When sending <com.iso_UpdateInd>=3 to update an amount or status for a ClaimsParty that has multiple

vehicles, the VIN field becomes required. It must be an exact match of the previously submitted VIN on the database or the update will be rejected for “Initial Claim Not Found”.

50

No Coverage/ No Loss Type

For members who wish to report vehicle information on a liability claim when there are no vehicle coverages to be reported, ISO has the ability to allow you to report an AutoLossInfo aggregate with the appropriate vehicle information (VIN is the only required field), and members may choose the coverage and loss type (NCVG/NLOS) to indicate that no vehicle coverage is being reported for the claim. When reporting the claim, members must report the liability information on a ClaimsInjuredInfo with a valid liability coverage and loss type, and the VIN and any other information on the vehicle on the AutoLossInfo with NCVG/NLOS type. A ClaimsInjuredInfo aggregate MUST be associated with the same ClaimsParty aggregate as the AutoLossInfo with NCVG/NLOS or the claim will be rejected. This is an optional type of reporting and is not required to be programmed by any company. Please note that this has not yet been added as an option on the ISO ClaimSearch website for Claims Reporting. It will be added as a future enhancement. The following Policy Types allow for No Coverage/No Loss reporting. Please see Appendix B for further details. BOAT – Boat PLIB – Personal Liability CAPP – Commercial Auto PLMA – Personal Liability Marine CCGL – Commercial General Liability PPFM – Personal Property Farmowners CFRM – Commercial Farmowners PPHO – Personal Property Home Owners COMR – Commercial Ocean Marine PPMH - Personal Property Mobile Home CLBO – Commercial Business Owners UMBR – Umbrella CPMP – Commercial Multi-Peril WCEL – Workers’ Comp & Employers Liability OLIB – Other Liability WCMA – Workers’ Comp Marine PAPP – Personal Auto

Physical Risk, Mailing Address, and SIU Claim Level Elements

The following elements represent one of the few areas in the XML programming where data in the Request and the same data in the Response are in two different aggregates. See below for the proper Request/Response mapping. Request Mapping:

Data Element Location Physical Risk Address Policy/ MiscParty/ GeneralPartyInfo/ Addr (AddrTypeCd=”PhysicalRisk”)

Mailing Risk Address Policy/ MiscParty/ GeneralPartyInfo/ Addr (AddrTypeCd=”MailingAddress”)

SIU Company Name Policy/ MiscParty/ GeneralPartyInfo/ NameInfo/ CommlName/ CommercialName

SIU Investigator Personal Name Policy/ MiscParty/ GeneralPartyInfo/ NameInfo/ PersonName

SIU Investigator Business Phone Policy/ MiscParty/ GeneralPartyInfo/ Communications/ PhoneInfo (Business)

SIU Investigator Cell Phone Policy/ MiscParty/ GeneralPartyInfo/ Communications/ PhoneInfo (Cell)

Claim Associated with Insurer Fraud Ring ClaimsOccurrence/ com.iso_InsurerFraudRingInvestigation

Response Mapping:

Data Element Location Physical Risk Address Policy/ MiscParty/ GeneralPartyInfo/ Addr (AddrTypeCd=”PhysicalRisk”)

Mailing Risk Address Policy/ MiscParty/ GeneralPartyInfo/ Addr (AddrTypeCd=”MailingAddress”)

SIU Company Name Policy/ MiscParty/ com.iso_SIUInfo/ com.iso_CommlName

SIU Investigator Personal Name Policy/ MiscParty/ com.iso_SIUInfo/ com.iso_SurName; com.iso_GivenName; com.iso_OtherGivenName

SIU Investigator Business Phone Policy/ MiscParty/ com.iso_SIUInfo/ com.iso_SIUPhoneInfo (Business)

SIU Investigator Cell Phone Policy/ MiscParty/ com.iso_SIUInfo/ com.iso_SIUPhoneInfo (Cell)

Claim Associated with Insurer Fraud Ring Policy/ MiscParty/ com.iso_SIUInfo/ com.iso_InsurerFraudRingInvestigation

51

Preventing Unwanted Searches:

On either Initial or Replacement Requests, searches and Match Reports are provided as the system default. If you wish to provide information to the database but do not wish to perform a search, please use the <SuppressMatchInd> on the <ClaimInvestigationAddRq> for the entire claim or on the <PartyInvestigationInfo> for specific ClaimsParty’s to request that No Search be performed by the system. When searches are suppressed at the <ClaimInvestigationAddRq> level, an Asynchronous Rejection Response will

be sent if there is an error, but NO ASYNCHRONOUS MATCH RESPONSE will be returned if the claim is successfully updated.

When searches are suppressed at the <PartyInvestigationInfo>, an Asynchronous Match Response will be returned, but the <MatchReasonCd> will indicate “NS” for the <ClaimsParty> that was not searched.

Replacement and Research Records from "Other Offices"

Some members may wish to automatically change the AgencyId on a claim record whenever a change is submitted on a claim. This, in effect, will transfer the claim to whichever office submitted the change. In XML Format, this can be accomplished two ways:

Replacement Request: First send an UpdateInd=5 Key Field Change Requests which will overwrite the existing

AgencyId in the database. The Update should be followed by the Replacement Request containing the new office information in the AgencyId after a 90-second delay. This will automatically generate output to the new office.

Update Request: First send an UpdateInd=5 Key Field Change Requests which will overwrite the existing

AgencyId in the database. To receive output on the change, submit an UpdateInd=4 Research Request after a 90-second delay to generate a new search that will produce output to the new office.

Searchable Elements

In addition to the required fields listed above, it is strongly encouraged that you include other optional information that can enhance your search results. The fields listed below can be very beneficial when performing searches for prior claims histories. For example, use of a claimant’s Social Security Number will automatically generate a wider database search for the claimant, as it is a more unique identifier and can be searched more readily within the system. The following fields are all optional but will be searched in addition to the required fields if provided on a searchable <ClaimsParty>. Alias Names and Addresses Date of Birth Driver’s License Number and State Social Security Number (SSN)** License Plate Number and State Zip Code Home Phone Number Cell Phone Number Email Address **Social Security Number may display as a Reason for Match even if no SSN is provided on the claim due to the Append-DS Optional Service. Please see the Append-DS section of the manual for further information. Location of Loss Search – One of the Match Reason Codes indicates that the claim matched due to the location of loss on the claims being similar. This search is only performed on claims with a <PropertyLossInfo> and the loss type is not 'BURG', 'LOBG', 'MYST', 'ROBB', or 'THFT’. Inclusion of a zip code on the Location of Loss address will further limit the search to matching on claims that also include the same zip code.

52

General Searching Rules: <ClaimsParty> are searched based on their role on the claim and the coverage records associated with them. A <ClaimsParty> with an Involved Party role code may match against other Claims Parties with an Involved Party role

code or “Alias” role code. Please see Appendix D – Role Codes for additional information on the roles and coverage records requirements.

A <ClaimsParty> with an “Alias” role code is only searched if the associated <ClaimsParty> with an Involved Party

role code is searched. Then, all name and address combinations between the Involved Party and Alias are searched. It is not necessary to repeat names and addresses as it will only cause additional searches on the same criteria. An Alias <ClaimsParty> may match against Involved Party <ClaimsParty> information or other Alias <ClaimsParty> aggregates.

A <ClaimsParty> with a Service Provider Role is only searched if the claim involves general property

<PropertyLossInfo><ClaimsSubjectInsuranceInfo> and the role code is CO, FM, LP, or SM. A “searchable” Service Provider may match against <ClaimsParty> aggregates with Involved Party role codes only.

NOTE: Only the first 99 <ClaimsParty> aggregates on a claim will be searched, regardless of role code based solely

on the order provided on the claim.

Validating Update Requests

Unlike Replacements, Update Requests do not perform searches. After an Update Request is sent, if a search is desired, a Research Request should be sent after a 90-second delay to allow for the processing of the Update. Updates do not replace the ISO FileNumber, the ISO Received Date, or any information entered or updated by the website; nor do they change the timeframe of the Automatic Update Reports.

53

SYSTEM OUTPUT (RECEIPT AND RESPONSE)

Synchronous Receipt (Acknowledgement) Upon successful submission, an immediate receipt will be returned to the member’s outgoing IPA. No claims data is sent in the receipt, just the information below where the <MsgStatusCd> is “ResponsePending.” Note that there are 3 <StatusCd>0</StatusCd> values below, and two <StatusDesc> which indicate success. Your system should expect the <StatusCd> 0 and a <MsgStatusCd> of “ResponsePending”. Any other values should be flagged as error. <ACORD> <Status> <StatusCd>0</StatusCd> <StatusDesc>Success</StatusDesc> </Status> <SignonRs> <Status> <StatusCd>0</StatusCd> <StatusDesc>Sign on was successful</StatusDesc> </Status> <CustId> <SPName>iso.com</SPName> <CustLoginId>…</CustLoginId> </CustId> <ClientDt>…</ClientDt> <CustLangPref>en-US</CustLangPref> <ClientApp> <Org>ISO</Org> <Name>XML_TEST</Name> <Version>1.0</Version> </ClientApp> <ServerDt>…</ServerDt> <Language>en-US</Language> </SignonRs> <ClaimsSvcRs> <Status> <StatusCd>0</StatusCd> </Status> <RqUID>…</RqUID> <ClaimInvestigationAddRs> <RqUID>Request Identifier for this claim returned here</RqUID> <TransactionResponseDt>Client date returned here</TransactionResponseDt> <CurCd>US</CurCd> <MsgStatus> <MsgStatusCd>ResponsePending</MsgStatusCd> </MsgStatus> </ClaimInvestigationAddRs> </ClaimsSvcRs> </ACORD>

54

Synchronous Error ISO ClaimSearch creates a Synchronous Error when a transmission does not pass security validation or required aggregates, elements, id’s, or idref’s on a submitted claim are invalid, not provided, or out of order. If the XML format is not valid due to one of these reasons, an immediate Response will be returned to the member’s outgoing IPA. No claims data is sent in the Response, just a <StatusCd> and a <StatusDesc>. The <StatusCd> values are industry standard HTTPS error codes. The <StatusDesc> should provide further information about the error encountered. Note –XML format errors will return based on the FIRST error encountered within the claim; however, there may be more than one format error within a single Request. Please review the entire Request for other possible errors before resubmitting. <ACORD> <Status> <StatusCd>300</StatusCd>

<StatusDesc> <![CDATA[ Unexpected Error: Reference to undeclared ID is 'ClaimsParty-01'. An error occurred at , (1, 4052). :: at System.Xml.XmlValidatingReader.InternalValidationCallback(Object sender, ValidationEventArgs e) at System.Xml.Schema.ForwardRef.Check(SchemaInfo sinfo, Validator validator, ValidationEventHandler eventhandler) at System.Xml.Schema.Validator.CheckForwardRefs() at System.Xml.Schema.Validator.CompleteValidation() at System.Xml.XmlValidatingReader.ReadWithCollectTextToken() at System.Xml.XmlValidatingReader.Read() at ISO.Claimsearch.XmlSubmission.XmlSubmission.Validate(String SchemaPath) at ISO.Claimsearch.XmlSubmission.XmlSubmission.Submit(String rqXmlStr, String SchemaPath, String sCallingIPAddress)]]>

</StatusDesc> </Status> </ACORD>

AgencyId Error If a Request is submitted where the <AgencyId> is missing or the first four characters are invalid, an XML Format Error Response will be sent to the member’s outgoing IPA indicating that an MQ processing error has occurred (code 2085) as we use this information to direct your claim through our processing queues. If a Request is submitted where the first 4 characters of the <AgencyId> are valid, but the last five are not valid for XML processing, then a Response (Successful or Rejected) cannot be sent from the ISO System as we use this information to identify the member’s incoming post-back URL.

55

Asynchronous Reject Response ISO ClaimSearch creates an Asynchronous Reject Response (aka Rejection Reports or Data Errors) when required data on a submitted claim is either invalid or not provided. Asynchronous Rejection Reports are returned to the member’s incoming post-back URL and will always begin with txtMatch=<ClaimInvestigationAddRs>. The Rejection will contain a <MsgStatusCd> of “Rejected” followed by a text description of the error details in the <MsgStatusDesc> (See Appendix C – Edits). The MsgStatusDesc field can display up to 5 errors per ClaimsParty, and up to 8 errors for the entire claim. If 8 errors are reported, please review the whole claim for further errors that may not show on the Response file. It is up to the member company to correct the field(s) within their system and resubmit the claim for processing. When correcting an initial reporting error and resubmitting the record, please ensure the claim is sent as an Initial filing. The following Rejection Key Fields are provided (with all applicable codelistref’s and idref’s) back to the member company, if provided on the initial claim submission. The purpose of these fields is to assist in the identification of the claim within the member’s system. Although the fields displayed may contain the error(s) which caused the claim to reject, the full claim should be reviewed as fields outside of those shown may also contain reasons for rejection.

Data Element Location

MsgStatusCd ClaimInvestigationAddRs/MsgStatus = “Rejected”

MsgErrorCd ClaimInvestigationAddRs/MsgStatus = “DataError”

MsgStatusDesc ClaimInvestigationAddRs/MsgStatus (See Appendix C for full list of error codes”

Policy Number ClaimInvestigationAddRs/ Policy/ PolicyNumber

Policy Type ClaimInvestigationAddRs/ Policy/ LOBCd

Insuring Company ID ClaimInvestigationAddRs/ Policy/ MiscParty/ ItemIdInfo/ AgencyId and

ClaimInvestigationAddRs/Policy/MiscParty/MiscPartyRoleCd = “CarrierInsurer”

Claim Number ClaimInvestigationAddRs/ ClaimsOccurrence/ ItemIdInfo/ InsurerId

Date of Loss ClaimInvestigationAddRs/ ClaimsOccurrence/ LossDt

Claims Party ID ClaimInvestigationAddRs/ ClaimsParty/ @id (See Remark Text)

Claims Party Name ClaimInvestigationAddRs/ ClaimsParty/ GeneralPartyInfo/ PersonName or CommlName

Claims Party Role Code ClaimInvestigationAddRs/ ClaimsParty/ ClaimsPartyInfo/ ClaimsPartyRoleCd

Casualty Loss Info ID (If Applicable) ClaimInvestigationAddRs/ ClaimsParty/ ClaimsInjuredInfo/ @id (see Remark Text)

Property Loss Info ID (If Applicable) ClaimInvestigationAddRs/ PropertyLossInfo/ @id (see Remark Text)

Auto Loss Info ID(If Applicable) ClaimInvestigationAddRs/ AutoLossInfo/ @id (see Remark Text)

Remark Text (at Claim Level) ClaimInvestigationAddRs/ RemarkText (idref=ClaimsOccurrence) – up to 20 bytes

Remark Text (at ClaimsParty Level) ClaimInvestigationAddRs/ RemarkText (idref=ClaimsParty) – up to 5 bytes

Remark Text (at Coverage Level) ClaimInvestigationAddRs/ RemarkText (idref=ClaimsInjuredInfo, PropertyLossInfo,

or AutoLossInfo) – up to 20 bytes

56

<ClaimInvestigationAddRs> <RqUID>Request Identifier for this claim returned here</RqUID> <TransactionResponseDt>…</TransactionResponseDt> <CurCd>…</CurCd> <CodeListRef>…</CodeListRef> <MsgStatus> <MsgStatusCd>Rejected</MsgStatusCd> <MsgErrorCd>DataError</MsgErrorCd> <MsgStatusDesc>UO0103B – ADDRESS LINE 1 MISSING OR INVALID</MsgStatusDesc> </MsgStatus> <Policy> <PolicyNumber>…</PolicyNumber> <LOBCd>…</LOBCd> <MiscParty> <MiscPartyInfo> <ItemIdInfo>…</ItemIdInfo> <MiscPartyRoleCd>CarrierInsurer</MiscPartyRoleCd> <MiscPartyInfo> </Policy> <ClaimsOccurrence id =”id1”> <ItemIdInfo> <InsurerId>…</InsurerId> </ItemIdInfo> <LossDt>…</LossDt> </ClaimsOccurrence> <ClaimsParty id=”id2”> <GeneralPartyInfo> <NameInfo> <PersonName> <Surname>…</Surname> <GivenName>…</GivenName> </PersonName> </NameInfo> </GeneralPartyInfo> <ClaimsPartyInfo> <ClaimsPartyRoleCd>…</ClaimsPartyRoleCd> </ClaimsPartyInfo> </ClaimsInjuredInfo id=”id3”> </ClaimsParty> <ClaimsParty id=”id4”> <GeneralPartyInfo> <NameInfo> <CommlName> <CommercialName>…</CommercialName> </CommlName> </NameInfo> </GeneralPartyInfo> <ClaimsPartyInfo> <ClaimsPartyRoleCd>…</ClaimsPartyRoleCd> </ClaimsPartyInfo> </ClaimsParty> </PropertyLossInfo id=”id5”> </AutoLossInfo id=”id6”> <RemarkText idref=”id1”>…</RemarkText”> <RemarkText idref=”id2”>…</RemarkText”> <RemarkText idref=”id3”>…</RemarkText”> <RemarkText idref=”id4”>…</RemarkText”> <RemarkText idref=”id5”>…</RemarkText”> <RemarkText idref=”id6”>…</RemarkText”> </ClaimInvestigationAddRs>

57

Asynchronous Success Response ISO ClaimSearch creates an Asynchronous Success Response (aka Asynchronous Match Report) when an Initial, Replacement, or Research Request have been successfully received and processed in the system. The system will return this Response to the member’s incoming postback URL with a <MsgStatusCd> = Success. An Asynchronous Success Response will always begin with txtMatch=<ClaimInvestigationAddRs>. The Match Report will return an echo back of the claim that was submitted by the member company as well as any matching claims that have an ISO Received Date within the last 5 years on a rolling basis. For example, an Initial Request submitted on March 1, 2021, will retrieve all matches with an ISO Received Date back to March 2, 2016. Each matching claim will be within a separate <MatchDetails> aggregate. If there are no matches found within the last 5 years, then the system will send back only an echo of the claim as it was submitted by the member company. These are often referred to as a “No Match Report”. If no <MatchDetails> aggregate is present, then no matches were found. The Match Reports are logically connected through the use of the ISO File Number which uniquely identifies claims within the ISO ClaimSearch system. This value is returned on the echo of the claim in ClaimInvestigationAddRs/ ClaimsOccurrence/ ItemIdInfo/ AgencyId. The ISO File Number and the initial ISO Received Date are maintained throughout the life of the claim, even when Replacement or Update Requests are made against the same claim. NOTE: If optional data submitted on Request is not present on the Response, it either contained invalid data or id/idref/codelist/codelistref was not entered correctly and the data was dropped in processing. Effective 7/1/2019, all members must use visualized ClaimSearch as the only option to receive a formatted Match Report to view the echo of the claim and any matching claims. All previous formatted Match Report options have been discontinued. The raw XML Response will still be provided to members who wish to continue to receive the data for approved analytical purposes. Please refer to the Privacy & Security policy to ensure that your use of the data complies with the policy. If your company does not utilize the matching claim data for analytical purposes, and alternate version of the response (ECHO only) will be available in the future.

Summary of XML Success Response Aggregates in Schema Order

ClaimInvestigationAddRs Every XML transmission must contain at least one <ClaimInvestigationAddRs>. This aggregate indicates the

beginning and ending of the claim information. If additional security is requested by the member, the <com.iso_CustLoginId>, <com.iso_CustLoginPwd>, and/or

<com.iso_CustDomain> will be sent at the top of the file in order to facilitate logging into the member’s system. The RqUID for the ClaimInvestigationAddRq is returned on the ClaimInvestigationAddRs in order to tie the

response back to the request. In the case of a Research request (UpdateInd=4) or other system generated report, the RqUID of the last successful Initial or Replacement request will be sent instead.

All ids generated for the Response file will be in GUID format. Transaction Response Date will indicate when the Response was generated in ISO’s system.

CodeList All ISO generated codelists will be sent on every Response in a static list.

MsgStatus Element MsgStatusCd whether the Response is “Success” or “Rejected”.

Policy Return Echo of the Policy Number, Policy Type, and AgencyId submitted on Request Return Echo of the Physical Risk Address, Mailing Address, and SIU Investigator Information, if submitted on

Request.

58

ClaimsOccurrence Return Echo of the ClaimsOccurrence data submitted on Request, especially LossDt, InsurerId, and Location of

Loss Includes ISO FileNumber in ClaimsOccurrence/ ItemIdInfo/ AgencyId and ISO Received Date in

ClaimsOccurrence/ com.iso_ReceiveDt. These two fields do not change on the claim regardless of Replacement or Update transactions.

ClaimsParty Return Echo of the ClaimsParty information as submitted on Request. This can be repeated to include all involved

parties, service providers, alias information, or additional claimants as submitted on request. For auto theft claims, ClaimsParty information for Recovering Agency as submitted on Request by Insurer, or as

provided by police agencies or National Insurance Crime Bureau (NICB). For auto, boat, or mobile equipment salvage, ClaimsParty information for third-party salvage buyer with role code

“SalvageBuyer”. ClaimsInjuredInfo

− Return Echo of the ClaimsInjuredInfo information as submitted on Request. − May repeat for multiple casualty losses.

PartyInvestigationInfo − Includes SSN and TIN validation as well as Statement of Dispute information.

com.iso_AppendDS − Please see the Additional Optional Service – Append-DS for further information. − Returned within the ClaimsParty of the claimant searched against Public Records. − May be repeated up to 10 times, depending on the data found.

ClaimsPartyRelationship Return Echo of the ClaimsPartyRelationship aggregates that tie together involved parties and their associated

service providers, aliases, and additional claimants. This is not used to tie Recovering Agency or SalvageBuyer to an involved party.

AdjusterParty Return Echo of the AdjusterParty contact information as submitted on the Request. May repeat for multiple adjusters AdjusterPartyInfo

− Return Echo of the AdjusterPartyInfo as submitted on the Request − May refer to a ClaimsInjuredInfo id, PropertyLossInfo id, or AutoLossInfo Id

AutoLossInfo Return Echo of the AutoLossInfo as submitted on Request.

PropertyLossInfo May repeat if ClaimsSubjectInsuranceInfo and ItemInfo OR ClaimsSubjectInsuranceInfo and Watercraft are

reported on the same claim. PropertySchedule

− Return Echo of the PropertySchedule as submitted on Request − Exception: If IsSummaryInd was submitted as 1 or 0, it will return as X on Response

ItemInfo − Return Echo of the PropertyLossInfo/ItemInfo as submitted on Request

Watercraft − Return Echo of the PropertyLossInfo/Watercraft as submitted on Request

ClaimsSubjectInsuranceInfo − Return Echo of the PropertyLossInfo/ClaimsSubjectInsuranceInfo as submitted on Request − ClaimsSubjectInsuranceInfo may repeat for individual SubjectInsuranceCd values. − ClaimsPayment

♦ Return Echo for the General Property coverage (Building, Contents, Stock, Loss of Use, or Other) and the dollar amounts for Policy Amount, Reserve, Estimated Loss, or Payment Amount.

WorkCompLossInfo Return Echo of the WorkCompLossInfo as submitted on the Request May only refer to ClaimsInjuredInfo

59

ClaimsPayment Return Echo to identify the dollar amounts for Policy Amount, Reserve, Estimated Loss, or Payment Amount as

well as the Claim Status (ex. open, closed, closed without payment, etc.). This aggregate is used in for reporting the dollar amounts associated with ClaimsInjuredInfo, AutoLossInfo,

PropertyLossInfo/ItemInfo, and PropertyLossInfo/Watercraft. Please see Appendix E – Claims Payment and Status Reporting Rules for further information.

RemarkText Return Echo of RemarkText as submitted on the Request Uses ItemRef for Vehicle Theft Verification text from NCIC police data (up to 237 characters) Uses idref for all other references (5 characters in reference to ClaimsParty, 20 characters for all other references)

InvestigationInfo Return Echo of InvestigationInfo elements, includes VIN Validation Information. AutoInvestigationInfo

− Shipping information - Received from Vehicle Manufacturers when vehicles are shipped from assembly plants.

− This information will only be received by members who are members of both ISO ClaimSearch and the National Insurance Crime Bureau (NICB).

RecoveryInfo − Includes Theft Recovery information (as provided by Ins. Company, police agencies, or NICB). − May refer to a PropertyLossInfo id or AutoLossInfo id. − com.iso_TheftVerification

• Provides information on whether the Vehicle Theft has been reported to a police agency and entered into the NCIC system.

SalvageInfo − Return Echo of the vehicle, boat, or mobile equipment SalvageInfo as submitted on the Request

com.iso_VehRecall − This service has been temporarily suspended and may resume in the future.

RecoveryInfo Additional Theft Recovery and/or Impound information as reported by police agencies or National Insurance

Crime Bureau (NICB), only if there is data in one of the following fields: CannedRecoveryCd, RecoveryLocDesc, com.iso_RecoveryVehNumber (all for impounded vehicles), and com.iso_VehRecoveryInd.

com.iso_AddCovInfo com.iso_CovInfo1

− Return Echo of the com.iso_CovInfo1 as submitted on the Request − May refer to a ClaimsInjuredInfo id or an AutoLossInfo id − May be repeated for each com.iso_CovInfo1 submitted on Request

com.iso_CovInfo2 − Return Echo of the com.iso_CovInfo2 as submitted on the Request − May refer to a ClaimsInjuredInfo id or an AutoLossInfo id − May be repeated for each com.iso_CovInfo2 submitted on Request

com.iso_CMS − Warning regarding fields missing for CMS reporting. The presence of this aggregate does not stop the claim

from being sent to CMS at the next schedule Quarterly Reporting period. − Only provided on searchable involved parties marked as Medicare Eligible. If a claim is marked with

the <SuppressMatchInd>, no warning will be sent. Likewise, for Update Records which don’t perform searches (UpdateInd=1, 2, 3, 5 & 6), no Warnings will be provided.

MatchReportTypeCd Provides the Return Reason Code of the Asynchronous Match Report= I - Initial; P – Replacement; Q – Impound

Update; R – Research; S – Automatic Update; V – Recovery. com.iso_ClaimDirectorInd

Returned only if the com.iso_ClaimDirectorInd was populated with “1,” and your company has signed up for the ClaimDirector Optional Service.

60

com.iso_ClaimsScoringInfo Please see the Additional Optional Service – ClaimDirector for further information. Returned only if the com.iso_ClaimDirectorInd was populated with “1” and your company has signed up for

ClaimDirector This aggregate contains information regarding the actual scoring of the claim, such as the Score itself and the

number of times scored. com.iso_ClaimsHandlingCharacteristics

− May repeat if more than one claim handling characteristic was found for a claim. com.iso_ClaimDirectorRules

− May repeat if more than one claim handling rule was found for a claim. − If rule applies to the entire claim, idref will refer to ClaimsOccurrence. − If the rule applies to the involved party, idref will refer to ClaimsParty.

com.iso_ClaimsScoreReport − This aggregate will not always be present. − Provide the details of the first 15 matches which were included in the score. If more than 15 matches, this

record will be repeated with up to an additional 10 matches. The highest scores are sent first. MatchInfo/ AdditionalMatchInfo

This aggregate provides information on additional matches to the submitted data. For example, a claim is submitted to ISO ClaimSearch (Claim 1). Data in Claim 1 (for example, the claimant’s SSN) matches data in another claim (Claim 2). Other data in Claim 2 also matches other claims in the system. This aggregate provides notification that there are other claims that match Claim 2 in the system, the type of data matched on, and the value that was matched on.

In visualized ISO ClaimSearch, this is displayed with a statement following the Claim 2 data of “more matches found outside this report.”

LitigationInfo Return Echo of the LitigationInfo as submitted on the Request May only refer to ClaimsInjuredInfo

com.iso_RecallRqInd This service has been temporarily suspended and may resume in the future.

MatchDetails If no MatchDetails aggregate is present, this indicates “No Matches Found” at this time. This is often referred to

as a “No Match Report” and is the system working as designed. Matching Insurance Claims - Same aggregates and subaggregates as return echo aggregates in this order,

exceptions are in bold: Policy (includes Company contact information in place of AgencyId), ClaimsOccurrence (includes ISO FileNumber of matching claim), ClaimsParty, ClaimsInjuredInfo, ClaimsPartyRelationship, AdjusterParty, AdjusterPartyInfo, AutoLossInfo, PropertyLossInfo, WorkCompLossInfo, ClaimsPayment, MatchReasonInfo, com.iso_SumReasonInfo, LitigationInfo, and InvestigationInfo − MatchReasonInfo

• This aggregate contains information associating a ClaimsParty with the reason for match. • No Match Report: Since there is no ClaimsParty id to tie the MatchReasonCd value “NM” to, the

information is dropped in processing and no MatchDetails aggregate is returned. This is a limitation of the XML processing and other areas of the system reflect the “NM” code that is listed in Appendix A

− com.iso_SumReasonInfo • This aggregate includes the ISO FileNumber of up to 25 Matching Reports and up to five 2-byte codes

identifying the reason for match for each ISO FileNumber − AppraiserActivityInfo

• Provides Estimate, Appraisal, and/or Valuation information as provided by auto physical damage estimating information providers under its own MatchDetails aggregate.

• Data elements will include ISO FileNumber; Policy Type (Will use the MarketTypeCd codelist for LOBCd), Insurance Company Name; AppraiserActivityInfo with Activity Type (Estimate, Appraisal, or Valuation) and Activity Date; AdjusterPartyInfo with Coverage Code; and AutoLossInfo with VIN and Impact Point Code.

• Other data elements which are optional: Policy Number, Claim Number, Vehicle Year, Make, Model License Plate/State, Odometer Reading, Claim Amount, Insured Name.

61

Match Data through NICB Membership − There are specific types of matches that can be received on VIN searches, if the ClaimSearch member also

has a membership with National Insurance Crime Bureau (NICB). These MatchDetails aggregates contain additional VIN history information, including Export and Impound as outlined below. It also includes Vehicle Recovery Reports as reported by police agencies or NICB, and Shipping and Assembly information which are both returned within the echo information above (see InvestigationInfo/ RecoveryInfo and InvestigationInfo/ AutoInvestigationInfo above. See also Vehicle Recovery Reports, VIN Quality Control, and Impound Update Reports sections of the manual for further information. )

− Each will be returned within their own MatchDetails aggregate. − Each type of VIN history match will produce a different set of data elements. The lists below state which

elements are specific to that type of Response. − Export information

• Supplied by US Ports regarding vehicles leaving the country. • Data elements will include an ISO FileNumber; ClaimsParty with Export Port Name in the

CommercialName field; AutoInvestigationInfo with EventCd=”Export”, Export Date, and Delivery Destination; and AutoLossInfo with VIN, Year, Make, and Model.

− Impound Update Reports • Submitted by police agencies which will generate the Impound Automatic Update. This will be returned

with MatchReportTypeCd “Q” and an echo back of the initiating claim. • Data elements will include an ISO FileNumber; ClaimsParty with Role code “ImpoundFac” which only

includes the CommercialName and PhoneNumber of the Impound Location, and a ClaimsParty with role code “ImpouundAgcy” which only includes the CommercialName and Phone Number of the Impounding Agency; AutoInvestigationInfo with EventCd=”Impound”, Impound Date, Police Report Case Number, and Additional Impound Information; and AutoLossInfo with VIN, VIN Validation, Year, Make, Model, License Plate, and License Plate State. May also include 30 characters of Miscellaneous Text in a RemarkText field.

com.iso_SIUParty Return com.iso_SIUParty submitted on matching claim for SIU investigation elements only. CMS fields are not returned on matching claims. May be associated with an involved party, service provider, or additional claimant. May be repeated for each com.iso_SIUParty submitted on a single Match Will follow directly after the MatchDetails aggregate that it corresponds to May be followed by other MatchDetails aggregates

com.iso_SIUParty Return Echo of the com.iso_SIUParty submitted on Request, includes SIU investigation elements and CMS

required fields. May be associated with an involved party or service provider. May be repeated for each com.iso_SIUParty submitted on Request Will follow directly after the last MatchDetails or matching com.iso_SIUParty aggregate

com.iso_KeyReasonInfo Key Indicators for each involved party or service provider searched in the claim. Refers to individual ClaimsParty id.

62

<ClaimInvestigationAddRs> <RqUID>Request Identifier for this claim returned here</RqUID> <TransactionRequestDt>…</TransactionRequestDt> <CurCd>…</CurCd> <CodeList>……. </CodeList> <MsgStatus> <MsgStatusCd> Success </MsgStatusCd> </MsgStatus> <Policy>……</Policy> <ClaimsOccurrence>……</ClaimsOccurrence> <ClaimsParty>…</ClaimsParty <AdjusterParty>…</AdjusterParty> <AutoLossInfo>…</AutoLossInfo> <PropertyLossInfo>…</PropertyLossInfo> <RemarkText>..... </RemarkText> <InvestigationInfo>..... </ InvestigationInfo > <com.iso_AddCovInfo>…</com.iso_AddCovInfo> <MatchReportTypeCd>..... </MatchReportTypeCd> <MatchInfo> … </MatchInfo> <LitigationInfo>…</LitigationInfo <MatchDetails> <Policy>……</Policy> … … </MatchDetails> <com.iso_SIUParty> For Matching Claim SIU Information</com.iso_SIUParty> <MatchDetails> … </MatchDetails> <MatchDetails> … </MatchDetails> <com.iso_SIUParty> For Initial Claim SIU and CMS Information</com.iso_SIUParty> <com.iso_KeyReasonInfo>…</com.iso_KeyReasonInfo> </ClaimInvestigationAddRs>

Automatic Update Reports

Match Reports are reports generated by the member’s activity within the ISO ClaimSearch system either by entering a new claim or updating an existing one. This provides a snapshot of what is on the system at the time of the report. Automatic Update Reports are generated by the system when claim activity on the system by another member matches against a claim that you previously submitted. This can be due to another member entering a new claim, updating a previous claim within the system, or submitting additional vehicle information based on the VIN. This allows members to see new system activity without placing a Research to receive an updated Match Report. These can be received at any time (24/7/365); therefore, your system should be ready to receive XML messages even when your company is not submitting requests. Automatic Updates include your company’s initial claim and only the claim that generated the report. These reports can be recognized by an “S” in the return reason code <MatchReportTypeCd>. This will occur for the following specified time frames after initial reporting of a claim: Casualty – 1 Year Property – 60 Days Vehicle – 30 Days Automatic Update timeframes are based on the ISO Received Date <com.iso_ISOReceivedDt> of the INITIAL filing. Any Updates or Replacements of the initial claim filing continue to use the original date received of the initial claim. Updates and replacements do not restart the Automatic Update period. If your company is sending the <ClaimStatusCd> on each <ClaimsInjuredInfo>, <PropertyLossInfo>, or <AutoLossInfo> ClaimsPayment aggregate your company as a whole may choose to opt out of receiving Automatic Updates on Closed claims. Please have a home office representative of the member company contact [email protected] for further information on this option.


63

Vehicle Recovery Reports

For members who subscribe to both ISO ClaimSearch and National Insurance Crime Bureau (NICB), the system automatically generates a Vehicle Recovery Report when a vehicle theft claim submitted to the database by a member matches with a theft recovery notice submitted to the database by the National Crime Information Center (NCIC) system used by police agencies.

Special Programming Notes:

To generate a Vehicle Recovery Report on a stolen vehicle, an Initial Request should be sent with a CoverageCd of COMP (Comprehensive), GGKP (Garage Keepers), or OTAU (Other Auto) and the <com.iso_TheftTypeInd> must be set to T for Total Theft. The Vehicle Recovery Report is generated purely on an EXACT VIN match; therefore, it is critical to have a valid VIN submitted on the AutoLossInfo. If the VIN does not pass the validation check, it will “drop to QC” and delay the return of the Match Report. Please see VIN Quality Control (NICB) below for further information.

Vehicle Recovery Reports will appear the same as the Match Reports, except the <MatchReportTypeCd>=V and only

the initial claim and the recovery information will be included in the file.

If the NCIC information is on our database at the time of the Initial Request of a vehicle theft claim, the member will receive their Asynchronous Match Report with the <MatchReportTypeCd> =I (for initial) and this will be followed by a second Asynchronous Match Report with the <MatchReportTypeCd>=V and the vehicle recovery information.

A Vehicle Recovery Report may be received at any time on a vehicle theft claim regardless of the status of the claim.

At any time can mean 24/7/365, but also can be years after the initial claim report depending on when the recovery information enters the NCIC system.

If the claim contains multiple <AutoLossInfo> aggregates with unique VINs reported for a single ClaimsParty:

In the raw XML Response File, the RecoveryInfo/ RecoveryInfo @ItemRef will point to the AutoLossInfo whose VIN has been recovered and the RecoveryInfo/ com.iso_VehRecoveryInd = Y. − NOTE: This causes the RecoveryInfo to return OUTSIDE the InvestigationInfo aggregate.

In visualized ISO ClaimSearch, recovery notices will be provided as an actionable alert and/or can be viewed on the alerts dashboard.

Once a Vehicle Recovery Report has been received, the vehicle recovery should be echoed back to ISO each time a

replacement record is submitted. (Update records do not provide an echo back.) The vehicle’s condition at the time of recovery is an updateable field, and if known, should be reported, and then

included in replacement or update submissions. Classification is an updatable field, and if your company has authorized ISO to report theft/recovery information to NHTSA, then this field should also be reported in all submissions

Position of RecoveryInfo in the raw XML Asynchronous Response string:

If a recovery is received with data in any of the following fields, regardless of the data value received, the RecoveryInfo aggregate will generate at the ClaimInvestigationAddRs level (OUTSIDE the InvestigationInfo): CannedRecoveryCd, RecoveryLocDesc, com.iso_VehRecoveryInd, or com.iso_RecoveryVehNumber.

If a claim is received without data in any of these fields, but other recovery information is received, such as RecoveryDt, then the RecoveryInfo aggregate will generate at the ClaimInvestigationAddRs/ InvestigationInfo level. It is possible to have both types of information on the same Response file

If a recovery is received with a <CannedRecoveryCd> of 2, then the recovery information listed within that

<RecoveryInfo> can be completely updated. This is the only type of recovery, other than an insurer recovery, that permits all fields to be updated. The <CannedRecoveryCd> of 2 also allows a company to reinstate their vehicle to an active theft in ISO, when the recovery information is not echoed back.

If the company reinstates their claim as an active theft in ISO, it is the responsibility of the company to contact the

appropriate police agency to have the vehicle reinstated as an active theft in NCIC. If updates are necessary to the other types of recoveries, beyond condition and classification, the company should contact ISO Customer Support.

64

VIN Quality Control (NICB)

Due to the importance of finding a stolen vehicle as quickly as possible, ISO makes every attempt to correct an invalid VIN. If a Request is submitted with a loss type of Theft (THFT) and an invalid VIN on the <AutoLossInfo>, then the Request will “drop to QC” and follow the process below. When a vehicle theft comes into the system, it goes up against the VIN editing tables which consist of vehicle manufacturers' shipping & assembly information to determine if the VIN passes or fails. InvestigationInfo/ ValidVINInd will indicate if the VIN has passed (P) or failed (F). If the VIN is valid (passed), then it is echoed back in the AutoLossInfo/ VehInfo/ VehIdentificationNumber, and the

Response will be generated right away. If the VIN fails the edit, the record is sent to the NICB Quality Control unit (QC). The record is automatically added to the ISO database, but the Response will be delayed until the VIN has been manually reviewed and released by QC.

If the VIN failed but was corrected by QC, then the corrected VIN is in AutoLossInfo/ VehInfo/ VehIdentificationNumber,

and the failed VIN is in InvestigationInfo/ FailedVIN. The corrected VIN is searched in the ISO database and any matches are returned to the member. Note – Both VINs are provided so that the VIN may be corrected in your system. Vehicles with invalid VINs will not be sent to NMVTIS.

If the VIN is invalid (failed) and is not correctable, then it is released from QC without changes and searched by the original VIN submitted (AutoLossInfo/ VehInfo/ VehIdentificationNumber) and any matching information returned to the member.

Vehicle theft VINs are corrected on a daily basis during normal business hours (M-F, 8am-5pm Central Time). A Match

Report is generally returned within several business days of the date received. Please wait at least THREE (3) business days before reporting a “COMP/THFT” claim as missing its Match Report to allow for the possibility that the claim dropped to the QC process.

NOTE – All vehicles older than 1987 will always display as “failed” as this is when the current standardization of VINs started.

Impound Update Reports

ISO ClaimSearch automatically generates an Impound Update Report when a vehicle theft claim has received a Vehicle Recovery Report (see above) AND further information has been received that the vehicle has been impounded. This information is received from states participating in the NICB Impound Program. These records may be received at any time after the submission of a total theft claim by the member and recovery by a police agency. Order of Asynchronous Responses When the Vehicle Theft is recovered through an Impound Lot, then the member will receive a total of three Asynchronous Responses from the system. The ISO ClaimSearch Match Report will return as an Asynchronous Success Response with a MatchReportTypeCd

of I for Initial or P for Replacement, depending on the last transaction prior to the recovery. The Vehicle Recovery Report will return as an Asynchronous Success Response with the <MatchReportTypeCd>=V. Then the Impound Update Report will return as a separate Asynchronous Success Response with a

MatchReportTypeCd=Q, with the initial claim and the Impound information.

NOTE: The data in the Impound information is what is passed to ISO ClaimSearch from the NCIC system which in turn receives data from the Impound lots. The information is not validated by ISO ClaimSearch in any way and is simply passed through to aid in the ultimate recovery of the insured vehicle.

In visualized ISO ClaimSearch, impound updates will be provided as an actionable alert and/or can be viewed on the alerts dashboard.

65

ENTITIES

In all following tables, “Length” refers to the length of the field for ISO ClaimSearch processing purposes. ACORD Document Request Entity (%ACORDREQ)

Tag Type Usage Length Description

<SignonRq> Aggregate Required

<ClaimsSvcRq> Aggregate Required ACORD lists this as a repeating aggregate; ISO will only recognize the first one reported on the transaction.

Claims Investigation Information Entity (%CLAIMSINVESTIGATIONINFO)


<Policy> %PCPOLICY Required

<ClaimsOccurrence> Aggregate Required

<ClaimsParty> Aggregate Required

Repeating

ISO requires at least one insured to be reported on property claims, and one insured and one claimant or one claimant/insured to be reported on casualty or auto claims.

<ClaimsPartyRelationship> Aggregate Optional Repeating

Required for Service Provider and Alias Information

<com.iso_SIUParty> Aggregate Optional Request Only

To report special investigation details for an involved party and/or service provider or CMS required fields for an involved party.

This aggregate returns under ClaimInvestigationAddRs on Response.

<AdjusterParty> Aggregate Required Repeating

<AutoLossInfo> Aggregate Optional Repeating

ISO requires at least one LossInfo aggregate (Auto, Property, or ClaimsInjured) to be reported on each claim.

<PropertyLossInfo> Aggregate Optional Repeating with limitations

PropertyLossInfo may be reported multiple times per claim with limitations (see aggregate for details). ISO requires at least one LossInfo aggregate (Auto, Property, or ClaimsInjured) to be reported on each claim..

<WorkCompLossInfo> Aggregate Optional Repeating

To report fields specific to Workers Compensation claims associated with a ClaimsInjuredInfo.

<LitigationInfo> Aggregate Optional Request Only Repeating

To report litigation information associated with a ClaimsInjuredInfo for Request.

This aggregate returns under ClaimInvestigationAddRs on the Response.

<ClaimsPayment> Aggregate Optional Repeating

Note - Estimated Loss Amount is required for reporting Property Fire claims to State Fire Marshal Offices.

<RemarkText> ItemRef for <RecoveryInfo>

idref for any other aggregate

Optional Repeating

C-20 for request C-237 for response

When used on a request, ISO will only accept a max length of 20 characters. When used on a response, this element may have up to 237 characters when sent with ItemRef, or up to 20 characters when sent with idref.

66

Claims Message Request Information Entity (%CLAIMSMSGRQINFO) This entity contains the basic information required for all REQUEST messages.


<RqUID> Identifier Required Request Identifier. Sent by a client as a universally unique identifier for the message. Used to correlate responses with requests.

<TransactionRequestDt> DateTime Required The date/time the request was created. This is the client date. YYYY-MM-DDTHH:MM:SS

<CurCd> Open Code List Required Currency Code. Value=”US” for ISO ClaimSearch US members.

<CodeList> Aggregate Required Repeating

ISO-defined code lists are required on every claim submitted. See Appendix A for full listing. Do not submit for code lists marked as ACORD.

Claims Message Response Information Entity (%CLAIMSMSGRSINFO) This entity contains the basic information required for all RESPONSE messages.


<com.iso_CustLoginId> Element Extension

Optional Login ID sent from ISO to member on the response to aid member in validating for security purposes. ID is provided by member.

<com.iso_CustLoginPwd> Element Extension

Optional Login Password sent from ISO to member on the response to aid member in validating for security purposes. Password is provided by member.

<com.iso_CustDomain> Element Extension

Optional Login Domain sent from ISO to member on the response to aid member in validating for security purposes. Domain is provided by member.

<RqUID> Identifier Required

Echo

Request Identifier. Sent by a client as a universally unique identifier for the message. Used to correlate responses with requests.

<TransactionResponseDt> DateTime Required The date/time the request was created. This is the client date. YYYY-MM-DDTHH:MM:SS

<CurCd> Open Code List Optional

Echo

Currency Code. Value=”US” for ISO ClaimSearch US members.

<CodeList> Aggregate Required

Repeating

All ISO-defined CodeLists will be posted in a static list on each Successful Response file regardless of whether the CodeList is referred to within the file.

<MsgStatus> Aggregate Required

Currency (%Currency) The currency base class is used for all currencies within this business specification.


<Amt> Decimal Required C-11 The amount of money. Must be reported in whole dollars for ISO ClaimSearch. May be reported with dollars and cents for CMS Reporting on the <cov.iso_CovInfo1> only.

67

Duration (%DURATION) This base class captures either a generic or specific time period. It can be as generic as 15 days or as specific as a start and end date.


<EffectiveDt> Date Optional C-10 This is an effective date, the explicit meaning of which is implied by its parent or its usage. YYYY-MM-DD

<ExpirationDt> Date Optional C-10 This is an expiration or termination date, the explicit meaning of which is implied by its parent or its usage. YYYY-MM-DD

<DurationPeriod> %MEASUREMENT Optional C-5 The length of time spanning from start date to end date.

Measurement (%MEASUREMENT) This base class is used to capture both a measurement and the unit of measurement for all tags with this data type. For instance, <OdometerReading> would use this to show that the vehicle traveled 10,000 miles.


<NumUnits> Decimal Required C-Varies

The number of units, the meaning of which is implied by its usage. ISO USES WHOLE NUMBERS ONLY; LENGTH OF FIELD DEPENDS ON USAGE.

Property Casualty Policy Entity (%PCPOLICY)


<PolicyNumber> C-25 Required C-30 The unique number assigned to the policy, or submission, being referenced. ISO ALLOWS THIS ELEMENT TO BE 30 CHARS

<LOBCd> Code List Required C-4 A code identifying the line of business. See Appendix A and Appendix B - PolicyTypeCd code list. On Response, can also refer to MarketTypeCd code list for Appraisal Policy Type (Appendix A).

<ContractTerm> %DURATION Optional This indicates the period for the contract, policy, binder, etc.

<MiscParty> Aggregate Required This aggregate contains the ISO assigned Insurer Reporting Code, Physical Risk Address, Mailing Risk Address, SIU Contact Information, and NMVTIS Operator Entity ID.

<AssignedRiskInd> Boolean Optional C-1 Indicates if this policy is written under the assigned risk plan. 1 = yes; 0 = no

68

WRAPPER AGGREGATES

In all following tables, “Length” refers to the length of the field for ISO ClaimSearch processing purposes. ACORD Aggregate <ACORD> Tag Type Usage Length Description

(%ACORDREQ) Entity Required A request document must contain at least a Signon request.

Signon Aggregates Client Application Aggregate <ClientApp>


<Org> Assigned Identifier_NoIDoID

Required Organization. Value=”ISO” for ISO ClaimSearch US members.

<Name> C-40_NoID Required Client Application Name. Value=”AWS” for ISO ClaimSearch US members in both test and production.

<Version> NC-12_NoID Required Client Application Version. Value=”1.0” for ISO ClaimSearch US members.

Member Identification Aggregate <CustId> The <CustId> aggregate is used to uniquely identify the member who submits a request.


<SPName> Assigned Identifier

Required Service Provider name. Value=”iso.com” for ISO ClaimSearch US members.

<CustLoginId> Assigned Identifier

Required C-5 Member Login ID – ISO assigns a unique ID to each member. It is a 5-character code typically beginning with “X”

Member Password Aggregate <CustPswd>


<EncryptionTypeCd> Code List Required Encryption Type. Value=”NONE” for ISO ClaimSearch US members.

<Pswd> C-32_NoID Required C-8 Clear text Password. ISO assigns a default password that is non-expiring for XML submissions. The password will be encrypted by the SSL used in the transmission process

Signon Password <SignonPswd>


<CustId> Aggregate Required

<CustPswd> Aggregate Required

69

Signon Request <SignonRq> Tag Type Usage Length Description

<SignonPswd> Aggregate Required Contains ISO ClaimSearch assigned ID and Password

<ClientDt> DateTime_NoID

Required Client DateTime. Time according to the client. YYYY-MM-DDTHH:MM:SS

<CustLangPref> NC-11_NoID

Required Value=”en-US” for ISO ClaimSearch US members.

<ClientApp> Aggregate Required Claims Service

Request <ClaimsSvcRq>

ACORD allows this aggregate to repeat. ISO only accepts the first instance. All ids submitted within this aggregate must be unique across the entire transmission.


<RqUID> Identifier Required Request Unique Identifier. Sent by a client as a universally unique identifier for the individual transaction.

<ClaimInvestigationAddRq> Aggregate Required Claims Investigation Submission Messages

Request <ClaimInvestigationAddRq>

ACORD allows this aggregate to repeat. ISO only accepts the first instance.


(%CLAIMSMSGRQINFO) Entity Required This entity contains the basic information required for all claims request messages.

<ReplacementInd> Boolean Optional C-1 1=Indicates whether the information being submitted is intended to completely replace, not update, the existing information. ISO will find the initial claim, remove it from the database and replace with the claim that is submitted in this request. It is vital that the entire claim be contained within this request and not just tags that have changed since the last submission.

<com.iso_Update> Aggregate Optional This aggregate is used to change only portions of a claim or to research a claim without making changes. See Update Claims section for further information.

<SuppressMatchInd> Boolean Optional C-1 1=Indicates that the submitter only wants the data added to the database. No search will be completed; no Response will be generated unless the claim is rejected. CMS Warning Codes can only be provided as part of the search and Response processes.

<SearchBasisCd> Code List Optional A code identifying the basis for the search. This element uses the SearchBasisCd code list. (I = Individual; C = Entire Claim) Required for Research requests.

(%CLAIMSINVESTIGATIONINFO)

Entity Required

<InvestigationInfo> Aggregate Optional Repeating

Required for NMVTIS reporting

<com.iso_AddCovInfo> Aggregate Optional Required for CMS Medicare reporting

70

Request <ClaimInvestigationAddRq> (cont.) Tag Type Usage Length Description

<com.iso_ClaimDirectorInd> Boolean Extension

Optional C-1 1=submit ClaimDirector claim & receive score. (This is an optional service that companies may choose to add to their basic service. Populating this field means you will receive the ClaimDirector aggregates returned in the response.)

<com.iso_RecallRqInd> Boolean Extension

Optional C-1 This service has been temporarily suspended and may resume in the future.

Response <ClaimInvestigationAddRs>

The response to the investigation submission is often referred to as a Match Report. The Match Report begins at the ClaimInvestigationAddRs level and will only return one ClaimInvestigationAddRs in each Response. Update Requests using UpdateInds 1, 2, 3, 5, or 6 do not generate a Response, nor do Requests with the <SuppressMatchInd> set to “1” on the ClaimsOccurrence. These Requests will only receive the ClaimInvestigationAddRs if there is an XML Data Error.


(%CLAIMSMSGRSINFO) Entity Required This entity contains the basic information required for all claims response messages.

(%CLAIMSINVESTIGATIONINFO) Entity Required This is an echo back of the member’s initial claim information as it is stored on the ISO system.


This may contain both Echo back of the member’s initial claim information as well as additional Vehicle Shipping and Theft Recovery information.

<RecoveryInfo> Aggregate Optional This may contain Additional Theft Recovery Information if 1 of 4 marked fields contain data.

<com.iso_AddCovInfo> Aggregate Optional This contains Additional Coverage Info for CMS and Mass Tort Reporting.

<MatchReportTypeCd> Code List Required This element uses the MatchReportTypeCd code list.

<com.iso_WebOverlayInd> Element Optional

Response Only

C-1 Y = This claim has been touched on the ISO website. Information echoed back from the system may be different than what was sent. This element does NOT appear visualized ISO ClaimSearch and is intended as a system flag.

<com.iso_ClaimDirectorInd> Boolean Extension

Optional C-1 1=ClaimDirector claim sent & score returned

<com.iso_ClaimsScoringInfo> Aggregate Extension

Optional This contains information regarding the ClaimDirector searching and scoring information.

<MatchInfo> Aggregate Optional This aggregate contains information on additional matches that may be found in the system that were not returned on this report.

<com.iso_SIUParty> Aggregate Optional Response Only Repeating

This aggregate will echo back the member’s initial claim information for special investigation or CMS information following the last MatchInfo.

<LitigationInfo> Aggregate Optional Response Only Repeating

This is an echo back of the member’s initial claim information.

<com.iso_RecallRqInd> Element Optional This service has been temporarily suspended and may resume at a future date.

71

Response <ClaimInvestigationAddRs> (cont.) Tag Type Usage Length Description

<MatchDetails> Aggregate Optional Repeating

This is a report of the matching claim information as submitted by another member company or ISO associated organization.

If this aggregate is not present, then no matches have been found on this claim information.

<com.iso_SIUParty> Aggregate Optional

Response Only

Repeating

This aggregate will echo back the matching claim information for special investigation info and will follow the <MatchDetails> aggregate for the claim it belongs with. Other <MatchDetails> aggregates may follow this aggregate.

<com.iso_KeyReasonInfo> Aggregate Optional This aggregate contains key indicators for each involved party or service provider searched in the claim.

Miscellaneous Aggregates

Code List Aggregate <CodeList> A Code List declaration is needed for any code value that is not ACORD industry-standard codes. As used here, this aggregate is used to declare any ISO ClaimSearch specific code values. Please refer to Appendix A - Code Lists.


@id Identifier Type

Required This attribute is an identifier to a specific element.

<CodeListName> C-255 Required This is the name of the code list as found in Appendix A

<CodeListOwnerCd> Code List Required This is the owner of the code list being referenced, for instance: ACORD, NCCI, or WISe. Value=”ISOUS” for ISO ClaimSearch US members.

Message Status Aggregate <MsgStatus> This aggregate is used in a Response message to provide the complete status from the result of processing the matching request.


<MsgStatusCd> Code List Required The values returned are listed in the MsgStatusCd code list in the Appendix A

<MsgErrorCd> Code List Optional - see description

Required when <MsgStatusCd> is Rejected. This provides the overall error code for the message. This element uses the MsgErrorCd code list in Appendix C.

<MsgStatusDesc> C-Infinite Optional Message status description. This is only sent when <MsgStatusCd> is Rejected. The values are listed in Appendix C.

Status Aggregate <Status>


<StatusCd> Code List Required Framework Response Status Code. Valid values depend on context. See the ACORD standards for a list of the values and their context.

<StatusDesc> C-255_NoID

Optional Status Description, if StatusCd does not = 0.

72

AGGREGATES

All aggregates are listed in alphabetical order and may be used within multiple locations within a single claim transmission. In all following tables, “Length” refers to the length of the field for ISO ClaimSearch Basic Service maximum length of field. Characters submitted over this length will be dropped in the processing. Additional Information <com.iso_AddInfo>


<com.iso_EntityId> Assigned Identifier

Optional C-7 Assigned by ISO/NMVTIS. The Operator Reporting Entity ID used for NMVTIS reporting.

Additional Coverage Information <com.iso_AddCovInfo> This aggregate is optional for ISO ClaimSearch reporting, but contains fields required for CMS Medicare Reporting.


<com.iso_CovInfo1> Aggregate Optional Repeating

Required for CMS Reporting

<com.iso_CovInfo2> Aggregate Optional Repeating

For CMS Reporting – contains optional CMS fields

<com.iso_CMS> Aggregate Optional Repeating Response Only

Only displayed if CMS Warning message is present.

Additional Matches Aggregate <AdditionalMatchInfo> This aggregate provides information on additional matches to the submitted data. For example, a claim is submitted to ISO ClaimSearch (Claim 1). Data in Claim 1 (for example, the claimant’s SSN) matches data in another claim (Claim 2). Other data in Claim 2 also matches other claims in the system. This aggregate provides notification that there are other claims that match Claim 2 in the system, the type of data matched on, and the value that was matched on. On the website, this is displayed with a statement following the Claim 2 data of “more matches found outside this report.”


@idref Identifier Reference

Required This attribute is an identifier reference to claims data on which the match was made.

<MatchTypeCd> Code List Required This code list identifies the data elements upon which additional matches are found. See Appendix A - AdditionalMatchCd. Example: SSN = match on social security number.

<MatchData> Element Required C-255 Contains the value which resulted in a match. Example: If the match is SSN, this tag would contain the SSN number.

73

Address Aggregate <Addr> The Address Aggregate is used wherever a postal address, including any portion of such address, is needed. The REQUIRED fields listed below are for addresses associated with an involved party’s <ClaimsParty> aggregate. Addresses used elsewhere in the claim may require fewer fields. Please refer to the Required Elements section for further details. Note – for addresses located outside the United States, completing the CountryCd will fulfill the StateProvCd requirement – except for Canadian addresses where both elements are required.


<AddrTypeCd> Code List Optional

Repeating

Identifies the type of address in the Policy/MiscParty/GeneralPartyInfo to distinguish between Mailing and Physical Risk Addresses. Not used in other Address aggregates. See Appendix A – AddressType code list.

<Addr1> Element Required C-50 Address Line 1.

<Addr2> Element Optional C-50 Address Line 2.

<City> Element Required C-25 City.

<StateProvCd> Code List Required C-2 State code. See Appendix A

<PostalCode> Element Optional C-9 Postal Code.

<CountryCd> Code List Optional C-3 Country. See Appendix A

<com.iso_VerifiedAddrInd> Element Extension

Optional – Response Only

C-3 Yes – This address was verified. No – This address was not verified. This field is only returned if the company is signed up for the Append-DS Optional Service.

<com.iso_FirstDt> Date Optional – Response Only

Date first resided at address.

This field is only returned on response if the company is signed up for the Append-DS Optional Service.

<com.iso_LastDt> Date Optional – Response Only

Date last resided at address.

This field is only returned on response if the company is signed up for the Append-DS Optional Service.

Airbag Information Aggregate <AirbagInfo>


<AirbagTypeCd> Code List Optional A code indicating the type of airbag. See Appendix A - AirbagTypeCd code list.

<AirbagStatusCd> Open Code List

Optional A code indicating the status of an airbag following the incident. See Appendix A - AirbagStatusCd code list.

Adjuster Party Aggregate <AdjusterParty> This aggregate identifies the adjuster(s) assigned to this claim. There may be multiple adjusters based on line of business, coverage, location, Claims Party, and more; but each ClaimsInjuredInfo, AutoLossInfo, and PropertyLossInfo, may only associated with a single AdjusterParty/ GeneralPartyInfo


<ItemIdInfo> Aggregate Optional As used here, captures identification numbers assigned to the adjuster, in the event there is more than one adjuster on the claim.

<GeneralPartyInfo> Aggregate Optional Not required but recommended to assist in distribution of return information within your company.

<AdjusterPartyInfo> Aggregate Required Repeating

Contains the Coverage/Loss Information for the loss section of the claim. May be repeated for multiple losses handled by the same adjuster.

74

Adjuster Party Information Aggregate <AdjusterPartyInfo> This aggregate identifies which coverage and loss the adjuster(s) has been assigned on this claim. It may be repeated for multiple losses.


@AssignmentRef Identifier Reference

Required This attribute contains an identifier reference to AutoLossInfo, PropertyLossInfo, or ClaimsInjuredInfo to which this adjuster has been assigned.

<CoverageCd> Code List Required C-4 The specific coverage under the policy that the loss is applied against for ClaimsInjuredInfo, AutoLossInfo, PropertyLossInfo/ ItemInfo or PropertyLossInfo/ Watercraft.

PropertyLossInfo/ ClaimsSubjectInsuranceInfo does not use this element and therefore the element is listed as optional on the schema file.

See Appendix B – CoverageCd code list

<LossCauseCd> Code List Required C-4 A code that identifies the general cause of loss, occurrence, injury, or illness.

See Appendix B – LossTypeCd code list Appraiser Activity Information <AppraiserActivityInfo> This aggregate provides Estimate, Appraisal, and/or Valuation information as provided by auto physical damage estimating information providers. The information is returned on a Response in the ClaimInvestigationAddRs for the initiating claim and the MatchDetails for the matching claims.


<AppraiserActivityDt > Date Optional C-10 The date on which the activity occurred. YYYY-MM-DD

<AppraiserActivityCd> Code List Optional A code identifying the type of activity engaged in by the appraiser. See Appendix A - AppraiserActivityTypeCd code list.

<AppraisedValueAmt> %Currency Optional C-11 The monetary amount assigned to the item by the appraiser as a result of the estimation, appraisal, or valuation.

Auto Investigation Information Aggregate <AutoInvestigationInfo> This aggregate describes information provided by the National Insurance Crime Bureau (NICB). All elements in this aggregate are RESPONSE ONLY. Shipping information is returned in the ClaimInvestigationAddRs/ InvestigationInfo/ AutoInvestigationInfo. Impound and Export information are returned as part of the MatchDetails.


@ImpoundAgencyRef Identifier Reference

Required if there is data

This attribute is an identifier reference to an Impounding Agency. As used here, this references ClaimsParty id.

@ImpoundFacilityRef Identifier Reference


This attribute is an identifier reference to an Impounding Facility. As used here, this references ClaimsParty id

@PortOriginRef Identifier Reference


This attribute is an identifier reference to Port of Origin of a shipment. As used here, this references ClaimsParty id. The shipped item would be a vehicle.

<DeliveryDestinationDesc> Element Optional C-35 Location where the item is scheduled to be exported.

<ShippedConditionDesc> Element Optional C-50 Text message concerning the status of the vehicle

<EventInfo> Aggregate Optional Repeating

As used here, may capture the dates of shipment, impound, export, and/or original theft of a vehicle.

<com.iso_PoliceReportNo> Element Optional C-20 Impound Update Police Report No. (sent when MatchReturnReasonCd = Q)

<com.iso_ImpoundInfo> Element Optional C-100 Impound Update Additional Information (sent when MatchReturnReasonCd = Q)

75

Auto Loss Information Aggregate <AutoLossInfo> This aggregate may be repeated up to 100 times per ClaimsParty to provide information as long as each aggregate contains a unique VIN, coverage, and loss type combination. (i.e., One of the fields: VIN; Coverage type; or Loss type; must be unique within the repetition, or the claim will be rejected with an error for duplicate coverage and loss.) Note – @id, @ClaimsPartyRef, VIN, Year, and Make are required fields for 1st party auto physical damage or vehicle theft claims. If associated with 3rd party claimants with roles of CL, CD, or CP and the VIN, Year, and Make are not known, you must still report an AutoLossInfo with @id and @ClaimsPartyRef in order to apply the coverage and loss types to the correct ClaimsParty on the claim.


@id Identifier Required A document unique identifier – Required by ISO as reference point for coverage/loss information in AdjusterPartyInfo and ClaimsPayment Aggregates.

@ClaimsPartyRefs Identifier Reference

Required As used here, references the ClaimsParty associated with this vehicle. Only 1 ClaimsParty may be referenced per vehicle.

<VehInfo>

Aggregate Required – see description

This aggregate contains the VIN and Year which are required except for 3rd-party claimants with roles of CL, CD, or CP.

<ManufacturerCd> Code List Required – see description

C-4 The NCIC standard 4-character code for vehicle make (not required for 3rd-party claimants with roles of CL, CD, or CP). Contact ISO for a list of Make codes.

<ModelCd> Code List Optional C-3 The 3-character NCIC abbreviation for vehicle model. Contact ISO for a list of Make codes.

<InventoryNumberId> Element Optional Response Only

C-12 Reference number of a vehicle. Only for Impounded Vehicles.

<AirbagInfo> Aggregate Optional Repeating

<ImpactPointCd> Code List Optional A code that identifies the point of impact on the vehicle. See Appendix A - PointOfImpactCd code list.

Catastrophe Aggregate <Catastrophe> If the event giving rise to the claim involved a catastrophe, this aggregate contains a 3-digit code assigned by Insurance Services Office’s Property Claim Service (PCS) Unit to identify the catastrophe. Please contact ISO for the code list.


<CatastropheCd> Code List Optional C-3 A 3-digit code assigned by PCS to identify a catastrophe occurrence. Use for CAT losses prior to 2016. For CAT Losses starting in 2016, use new element <com.iso_NewCATCd>.

<CatastropheCdSourceName>

Element Optional C-3 The name of the entity or organization whose catastrophe code is being transmitted. Value=”ISO” for ISO PCS members

<com.iso_NewCATCd> Element Optional C-4 A 4-digit code assigned by PCS to identify a catastrophe. Claims Driver Information Aggregate <ClaimsDriverInfo>


<DriversLicense> Aggregate Optional This aggregate is used to report Driver’s License Number and State of the involved party.

<OperatorAtFaultInd> Boolean Optional 1=Indicates if the agency investigating an accident determined that the operator was at fault. 0= Indicates if the agency investigating an accident determined that the operator was not at fault.

76

Claims Injured Information Aggregate <ClaimsInjuredInfo> This aggregate is used to report losses related to a specific injury, liability (such as harassment or slander), or 3rd party property damage (such as a car drives into a building. The damage to the building is reported with the ClaimsInjuredInfo, not the PropertyLossInfo). This aggregate may be repeated to provide information regarding multiple losses as long as each aggregate is associated with a unique CoverageCd and LossCauseCd combination in the AdjusterPartyInfo aggregates.


@id Identifier Required A document unique identifier – Required by ISO as reference point for coverage/loss information in AdjusterPartyInfo and ClaimsPayment Aggregates.

<ICDDiagnosticCd> Code List Optional Repeating (max 5) – Request Only

C-6 A code indicating the diagnostic coding provided when medical treatment was rendered. The element uses the International Classification of Diseases (ICD-9) code list.

<com.iso_AmbulanceUsedInd> Boolean Extension

Optional – Request Only

Y–Ambulance service was used N–Ambulance service was not used

<com.iso_DisabledDueToAccidentInd>

Boolean Extension


Use this field for non-worker’s comp claims P–claimant is partially disabled T – claimant is totally disabled

<com.iso_CPT> Code List Optional – Request Only

Code identifying which current procedural treatment was used. Reported by the medical provider. See Appendix A - CPT code list.

<TimeLostPeriod> %DURATION

Optional C-5 for Duration Period

This entity is used to capture the loss time start date (EffectiveDt), loss time end date (ExpirationDt), and the total lost days (DurationPeriod)


As used here, captures the dates of attorney involvement, retirement, strike, and/or termination. See Appendix A - Event (ACORD) or EventCd code lists.

<ClaimsInjury> Aggregate Required Claims Injury Aggregate <ClaimsInjury> This aggregate provides information related to a specific injury, liability, or 3rd party property damage.


<InjuryNatureDesc> Element Required C-50 A description of the alleged injury or damage to property not owned by the insured.

<BodyPartCd> Code List Optional

C-2 A code that corresponds to the affected body part. See Appendix A - BodyPartCd code list.

<com.iso_ERISAClmInd> Boolean Extension

Optional C-1 Alternative plans that cover employees’ on-the-job injuries

Y - ERISA Type of Claim

N - not ERISA Type of Claim

77

Claims Occurrence Request Aggregate <ClaimsOccurrence> This aggregate contains the basic data relative to a claim as a whole.


@id Identifier Reference

Required A document unique identifier should only be present on an element when it is being referenced within the stream.

<PolicyRenewalInd> Boolean Optional Y – Renewal N - New

<com.iso_PoliceReportFiledInd> Boolean Extension

Optional Y – police report filed N – no police report filed

<ClaimsReported> Aggregate Optional Repeating

<LossDt> Date Required C-10 The date the loss occurred. YYYY-MM-DD CMS Field #13

<LossTime> Time Optional C-5 The time at which loss occurred. HH:MM

<IncidentDesc> Element Required C-50 A description of the loss resulting in the claim. If your loss description exceeds 50 bytes it is recommended to use the new element <com.iso_NewExtLossDesc> for additional Loss Description information.

<Addr> Aggregate Required As used here, the Location of Loss State or Country is required. Other address elements are optional. If the loss occurred on a vessel at sea, the WorkCompLossInfo/ VesselCallId may be used in place of the Location of Loss State/Country.

<Catastrophe> Aggregate Optional

<CatastropheLossInd> Boolean Optional 1=Indicates if this loss is associated with a specifically identified catastrophe. 0=the loss is NOT associated with a specifically identified catastrophe

<ProbableIncurredAmt> %Currency

idref

Optional

Repeating

Request Only

C-11 The estimate of the amount of damage/injury arising from a casualty or vehicle claim. idref references the id of the specific ClaimsInjuredInfo or AutoLossInfo aggregate the payment is being applied to. (Not used for PropertyLossInfo.)

<com.iso_SingleVehInvolvedInd> Boolean Extension

Optional Y – accident involved only one vehicle N – accident involved more than one vehicle

<com.iso_PhantomVehInd> Boolean Extension


Y – not known how or with whom vehicle was damaged N – known how or with whom vehicle was damaged

<com.iso_AccidentWitnessedInd> Boolean Extension


Y – Accident was witnessed. N – Accident was not witnessed

<com.iso_MoldInd> Boolean Extension

Optional Y – Claim involves MOLD N – Claim does not involve MOLD

<com.iso_HitAndRunInd> Boolean Extension

Optional Y – Hit and Run N – Not a Hit and Run

<com.iso_InsurerFraudRingInvestigation>

Boolean Extension

Optional –

Request Only

Y - A party in this claim is the subject of an insurer fraud ring investigation. N – A party in this claim is not the subject of an insurer fraud ring investigation

<com.iso_MassTortInd> Boolean Extension

Optional Y – Mass Tort Claim

78

Claims Occurrence Request Aggregate <ClaimsOccurrence> (cont.) Tag Type Usage Length Description <com.iso_SelfInsuredInd> Boolean

Extension Optional Y= the reportable event involves self-insurance as defined

by CMS. N= the reportable event does not involve self-insurance as defined by CMS. Required for reporting by TPAs for CMS for WC or Liability. For insurers and self-insureds, this will be derived by ISO. CMS Field#64

<com.iso_RRECd> Assigned Identifier

Optional C-9 COBC Assigned Section 111 Reporter ID CMS Field (Required for TPAs for reporting to CMS or for insurers/self-insurers with more than one CMS registration. For members with more than one RRE, if this code is not populated, the claim will not be sent to CMS. If a company only registers one RRE, this field may be derived.)

<TaxIdentity> Aggregate Optional C-9 TIN of the applicable plan. Required by CMS if RRE has registered more than one TIN for the reporting RRE. If a company only registers one TIN per RRE, this field may be derived. CMS Field #72

<com.iso_SiteId> Assigned Identifier

Optional C-9 CMS Site ID – Used for CMS to specify additional address associated with one TIN. Site IDs are assigned by RRE but must be provided to ISO before sending. Only required if RRE has set up more than one Site ID per TIN. If a company only registers one Site ID per TIN, this field may be derived. CMS Field #73

<com.iso_NewExtLossDesc> Element Optional C-200 Extended text description of the Loss. Can be used to continue the Loss Description from the <IncidentDesc>, or as a separate Loss Description information input.

Claims Occurrence Response Aggregate <ClaimsOccurrence> This aggregate contains the basic data relative to a claim as a whole.




<ItemIdInfo> Aggregate Required InsurerId is required to identify the insurer’s unique claim identifier. CMS Required Field #75. AgencyId is ISO ClaimSearch unique file number for claim on Response

<PolicyRenewalInd> Boolean Optional Y – Renewal N - New

<com.iso_PoliceReportFiledInd>

Boolean Extension

Optional Y – police report filed N – no police report filed

<ClaimsReported> Aggregate Optional Repeating

<LossDt> Date Required C-10 The date the loss occurred. YYYY-MM-DD CMS Field #13

<LossTime> Time Optional C-5 The time at which loss occurred. HH:MM

<IncidentDesc> Element Required C-50 If your loss description exceeds 50 bytes it is recommended to use the new element <com.iso_NewExtLossDesc> for additional Loss Description information.

<Addr> Aggregate Required As used here, the Location of Loss State or Country is required. Other address elements are optional. If the loss occurred on a vessel at sea, the WorkCompLossInfo/ VesselCallId may be used in place of the Location of Loss State/Country.

79

Claims Occurrence Response Aggregate <ClaimsOccurrence> (cont.) Tag Type Usage Length Description

<Catastrophe> Aggregate Optional

<CatastropheLossInd> Boolean Optional 1=Indicates if this loss is associated with a specifically identified catastrophe. 0=the loss is NOT associated with a specifically identified catastrophe

<com.iso_SingleVehInvolvedInd> Boolean Extension

Optional Y – accident involved only one vehicle N – accident involved more than one vehicle

<com.iso_MoldInd> Boolean Extension

Optional Y – Claim involves mold N – Claim does not involve mold

<com.iso_StatementOfDisputeInd>

Boolean Extension


Y – There is a citizen dispute on this claim

<com.iso_NICBReferralInd> Boolean Extension


Y - This claim has been referred to NICB

<com.iso_ReceiveDt> Date Required – Response Only

ISO Received Date. YYYY-MM-DD. This date is used for the Automatic Update process. It does not change for Replacement or Update transactions.

<com.iso_MassTortInd> Boolean Extension

Optional Y – Mass Tort Claim

<com.iso_SelfInsuredInd> Boolean Extension

Optional Y= the event involves self-insurance as defined by CMS. N= the event does not involve self-insurance as defined by CMS.

Required for reporting by TPAs for CMS for WC or Liability. For insurers and self-insureds, this will be derived by ISO. CMS Field#64

<com.iso_RRECd> Assigned Identifier

Optional C-9 COBC Assigned Section 111 Reporter ID CMS Field

(Required for TPAs for reporting to CMS or for insurers/self-insurers with more than one CMS registration. For members with more than one RRE, if this code is not populated, the claim will not be sent to CMS. If a company only registers one RRE, this field may be derived.)

<TaxIdentity> Aggregate Optional C-9 TIN of the applicable plan. Required by CMS if RRE has registered more than one TIN for the reporting RRE. If a company only registers one TIN per RRE, this field may be derived. CMS Field #72

<ProbableIncurredAmt> %Currency

idref

Optional

Repeating

Response Only

C-11 The estimate of the amount of damage/injury arising from a casualty or vehicle claim. idref references the id of the specific ClaimsInjuredInfo or AutoLossInfo aggregate the payment is being applied to. (Not used for PropertyLossInfo.)

<com.iso_SiteId> Assigned Identifier

Optional C-9 CMS Site ID – Used for CMS to specify additional address associated with one TIN. Site IDs are assigned by RRE but must be provided to ISO before sending. Only required if RRE has set up more than one Site ID per TIN. If a company only registers one Site ID per TIN, this field may be derived. CMS Field #73

<com.iso_NewExtLossDesc> Element Optional C-200 Extended text description of the Loss. Can be used to continue the Loss Description from the <IncidentDesc>, or as a separate Loss Description information input.

80

Claims Party Aggregate <ClaimsParty> This aggregate contains information regarding any party that has an “interest” or “involvement” in the claim (ex. insured, claimant, alias, service provider, witness, etc.), except for the Adjuster or Special Investigator. CMS Required Fields listed here are for Injured Parties. Please see Appendix D – Role Types for further information on specific Alias or Service Provider requirements.




<GeneralPartyInfo> Aggregate Required Name and Address are Required, SSN/TIN, Phone Numbers, Email Address are optional but searchable. CMS Required Fields #5-8, 69

<PersonInfo> Aggregate Optional CMS Required Fields #9, 10

<ClaimsPartyInfo> Aggregate Required This aggregate contains the ClaimsPartyRoleCd

<ClaimsDriverInfo> Aggregate Optional

<ClaimsInjuredInfo> Aggregate Optional

Repeating

Required if there is an injury, liability, or 3rd party property damage loss. May repeat to report multiple coverages/losses.

<PartyInvestigationInfo> Aggregate Optional

<com.iso_ClaimsPartyVehInfo> Aggregate Optional

<com.iso_ClaimDirectorRules> Aggregate Optional – Response only

This aggregate is only sent to members using the ClaimDirector Optional Additional Service.

<com.iso_AppendDS> Aggregate Optional – Response only

This aggregate is only sent to members using the Append-DS Optional Additional Service.

<com.iso_CSLNInd> Boolean Extension

Optional Y = Search CSLN, O = Search OCSE, B = Search Both CSLN and OCSE. Blank = No CSLN or OCSE Search See Additional Services - CSEA.

<com.iso_NewSOD> Element Optional C-200 Statement of Dispute. This field displays statements provided by citizens who dispute information on the claim in the system.

Claims Party Information Aggregate <ClaimsPartyInfo> This aggregate provides additional information about a claims party.


<ClaimsPartyRoleCd> Code List Required

A code identifying the role of the ClaimsParty. See Appendix A - ClaimsPartyRole (ACORD) or the ClaimsPartyRoleCd (ISO) code list.

<RelationshipToInsuredCd> Code List Optional A code identifying the relationship of the driver of the vehicle to the owner of the vehicle. See Appendix A - DriverRelationshipToOwnerCd code list.

<AccountNumberId> Assigned Identifier

Optional C-16 The loan number assigned by the financial institution.

<SuitFiledInd> Boolean

idref

Optional Repeating

1=Indicates if this party has filed a lawsuit. 0=Indicates party has NOT filed a lawsuit.

This references the ID of the specific ClaimsInjuredInfo, AutoLossInfo, or PropertyLossInfo aggregate to which the suit applies.

<ClosedDt> Date

idref

Optional Repeating

C-10 Date when this claims party’s portion of the claim was closed. YYYY-MM-DD

This references the ID of the specific ClaimsInjuredInfo, AutoLossInfo, or PropertyLossInfo) aggregate the payment is being applied to.

81

Claims Party Relationship Aggregate <ClaimsPartyRelationship> This aggregate captures information about the relationship between two parties. All fields are required for Alias or Service Provider information to identify the relationship with other parties on the claim. The Code List elements use the ClaimsPartyRole (ACORD) or ClaimsPartyRoleCd (ISO) code lists in Appendix A.

Claims Party Vehicle Information <com.iso_ClaimsPartyVehInfo> This aggregate contains information regarding the vehicle a claimant was a passenger in.


<com.iso_OccupantOfVIN> Element Extension

Optional C-20 The VIN of the vehicle that this party was the occupant of.

<com.iso_PhysicalDamageInd> Boolean Extension

Optional Y=There was physical damage to the vehicle this person was an occupant of. N= There was NO physical damage to the vehicle this person was an occupant of.

Claims Payment Aggregate <ClaimsPayment> This aggregate contains data regarding any reserves that were set, or any claims payments made, including to whom the payment was made. This aggregate is used under the ClaimInvestigationAddRq aggregate for ClaimsInjuredInfo, AutoLossInfo, PropertyLossInfo/Watercraft or PropertyLossInfo/ItemInfo claims, and under the PropertyLossInfo/ClaimsSubjectInsuranceInfo aggregate for general property. Please refer to Appendix A and Appendix E for further information.


idref Identifier Required

OR

This references the ID of the specific Loss Information aggregate the payment is being applied to. (Required for AutoLossInfo or ClaimsInjuredInfo. Not used for PropertyLossInfo.)

@ClaimsPartyRef Identifier Reference

Required OR

This references the ID of the specific ClaimsParty to whom the payment was made.

<PaymentTypeCd> Code List Optional Identifies the type of reserve or payment made. See Appendix A - PaymentType (ACORD) or PaymentTypeCd (ISO) code list.

<ClaimsPaymentCovInfo> Aggregate Optional Repeating

This contains the payment amounts per coverage code.

<TotalPaymentAmt> %Currency Optional C-11 Total amount of this payment in whole dollars for Casualty, Auto, Watercraft, and Mobile Equipment claims. Not used for Property claims.

<LossCauseCd> Code List Optional Required when a single claims party has multiple coverages and the coverage types are the same, but loss types are different. As used here, provides the specific loss code under which the payment is made. See Appendix B - LossTypeCd code list.

<PaymentDt> Date Optional C-10 Date on which the first claim payment took place. YYYY-MM-DD

Only used when PaymentTypeCd=FCP


@ClaimsParty1Ref ID Ref Required This attribute references the first ClaimsParty id.

@ClaimsParty2Ref ID Ref Required This attribute references the second ClaimsParty id.

<ClaimsPartyRole1Cd> Code List Required C-2 This is the role of the first claim party in this relationship.

<ClaimsPartyRole2Cd> Code List Required C-2 This is the role of the second claim party in this relationship

82

Claims Payment Coverage Info Aggregate <ClaimsPaymentCovInfo> This aggregate contains the payment amounts per coverage code. Please refer to Appendix A and Appendix E for further information.


<CoverageCd> Code List Required A code that identifies a type of coverage. This element uses the CoverageCd code list for casualty, vehicle, boat, or mobile equipment claims. The Risk (ACORD) code list is used for PropertyLossInfo/ ClaimsSubjectInsuranceInfo claims. As used here, provides the specific coverage code under which the payment is made.

<PaymentAmt> %Currency Optional C-11 Total amount of this payment in whole dollars for Property claims. Not used for Casualty, Auto, Watercraft, and Mobile Equipment claims.

<ClaimStatusCd> Code List Optional As used here the current status of this coverage on the claim. See Appendix A - ClaimStatusCd code list.

Claims Reported Aggregate <ClaimsReported> This aggregate is used to collect the information about when, by whom, and to whom a claim was reported. This aggregate is only used when you have the information about the date reported or the report number. For Workers’ Compensation claims, this aggregate may be used to indicate when the claim was first reported to the employer (Insured).


@ReportedByRef Identifier Reference

Required Or

This attribute is an identifier reference to a ClaimsParty that this claim was reported by.

@ReportedToRef Identifier Reference

Required Or

This attribute is an identifier reference to a ClaimsParty that this claim was reported to. If reported directly to Insurance company use "InsurerId"

<ReportedDt> Date Optional C-10 The date the incident/occurrence was reported to or by the party referenced above. YYYY-MM-DD

<ReportNumber> Assigned Identifier

Optional C-15 This element contains the official number of the vehicle incident report, filed by the police, fire, or other agency after an automobile accident.

Claims Subject of Insurance Information Aggregate <ClaimsSubjectInsuranceInfo> This aggregate is used for 1st Party General Property Losses including Fire, Theft, and Other Peril. It is not used for 3rd Party Property Losses.


<SubjectInsuranceCd> Code List Optional As used here, a code categorizing the item that is the subject of the claim described, such as building, contents, and stock. See Appendix A - Risk (ACORD).

<InsuranceAmt> %Currency Optional C-11 The monetary amount of insurance stated on the policy for this subject of insurance.

<ProbableIncurredAmt> %Currency Optional – see description.

C-11 The estimated total amount of a claim. This field is required for 1st party property fire claims if ISO is reporting the claims to a State Fire Marshal on member’s behalf.

<ClaimsPayment> Aggregate Optional Repeating

Use this ClaimsPayment to report payments under individual SubjectInsuranceCd’s (ex. one for building and repeated for contents.)

83

Commercial Name Aggregate <CommlName> Special characters should not be sent in name fields except for apostrophe [‘], hyphen [-], or ampersand [&]. See Appendix C – Edits for further information on how special characters are handled in XML and other restrictions on these fields.


<CommercialName> Element Required C-70 The name of a business. CMS Field #69 Communications Aggregate <Communications>


<PhoneInfo> Aggregate Optional Repeating

<EmailInfo> Aggregate Optional Submitted under <com.iso_SIUParty> for Involved Party or Service Provider. Submitted under <ClaimsParty> <GeneralPartyInfo> for Alias.

Coverage Information 1 <com.iso_CovInfo1> This aggregate is optional for ISO ClaimSearch reporting but contains fields required for CMS Medicare Reporting. This aggregate is not sent within the MatchDetails section of a Response.


@ItemRef Identifier Reference

Required Intended to refer to the ClaimsInjuredInfo. For companies reporting casualty losses on AutoLossInfo in order to provide the VIN on casualty losses, this may refer to an AutoLossInfo

<com.iso_CMSIncidentDt> Date Optional Date of Incident as defined by CMS – date of first exposure, first ingestion, or first implant. YYYY-MM-DD CMS Required Field #12

<Addr> Aggregate Optional As used here, only <StateProvCd> is required to report State of Venue. The state whose state law controls resolution of the claim. Insert “US” <CountryCd> where the claim is a Federal Tort Claims Act liability insurance matter or a federal WC claim. Insert “FC” <CountryCd> for foreign country.

CMS Required Field #17

<com.iso_NFLTLimit> %Currency Optional C-11 No Fault Insurance Limit Dollar amount of limit on no-fault insurance. Specify dollars and cents with implied decimal. Ex. $10,500.00 should be coded as 00001050000. Fill with all 9’s if there is no dollar limit. Fill with all 0’s for WC or Liability claims. Required by CMS for no-fault claims. CMS Field #81

<com.iso_ExhaustDt> Date Optional Exhaust Date for Dollar Limit for No Fault Insurance Date on which limit was reached or benefits exhausted for no-fault insurance limit. YYYY-MM-DD Leave blank if no-fault limit has not been reached/exhausted or if this is a WC or Liability claim. Required by CMS for no-fault claims if benefit limit is reached/exhausted. CMS Field #82

<com.iso_ORMInd> Boolean Extension

Optional Indication of whether there is On-Going Responsibility for Medicals (ORM). Y=there is on-going responsibility for medicals N=there is not on-going responsibility for medicals CMS Required Field #98

<com.iso_ORMDt> Date Optional Date on-going responsibility for medicals ended (termination date). YYYY-MM-DD

Only applies to claims submitted with <com.iso_ORMInd> = Y. CMS Field #99

84

Coverage Information 1 <com.iso_CovInfo1> (cont.)


<com.iso_TPOCDt> Date Optional Repeating Max 5

Total Payment Obligation to the Claimant (TPOC) Date. Initial date of total payment obligation to the claimant without regard to on-going responsibility for medicals. YYYY-MM-DD

Required by CMS except for the initial report of a claim reflecting ongoing payment responsibility. CMS Field #100

<com.iso_TPOCAmt> %Currency Optional Repeating

Max 5

C-11 Total Payment Obligation to the Claimant (TPOC) Amount Dollar amount of the total payment obligation to the claimant. Specify dollars and cents with implied decimal. EX: $10,500.00 should be coded as 00001050000. Fill with all 0’s when reporting claims reflecting ongoing payment responsibility unless the responsibility ended due to a settlement. Required by CMS if TPOC Date has been completed. CMS Field #101

<com.iso_TPOCStartDt> Date Optional Repeating

Max 5

Funding Delayed Beyond Total Payment Obligation to the Claimant (TPOC) Start Date. If funding for the total payment obligation to the claimant is delayed, provide actual or estimated date of funding. YYYY-MM-DD CMS Field #102

<ICDDiagnosticCd> Code List Optional Repeating

Max 19

C-6 ICD-9 Code as reported by medical provider. See Appendix A . CMS Field #18-36. Required by CMS for new claims on or after 1/1/11. If reported with decimal, ISO will strip the decimal before sending to CMS. Must be on CMS valid list, not on the excluded list, and must not begin with “E” or “V”.

<com.iso_ICD10Cd> Code List Optional Repeating

C-8 ICD-10 Code as reported by medical provider. See Appendix A . CMS Field #18-36. Required by CMS for injuries occurring on or after 10/1/15 but will be accepted by CMS beginning 10/1/14. Prior to 10/1/14, ICD-9 Codes are still required. If reported with decimal, ISO will strip the decimal before sending to CMS. Must be on CMS valid list, not on the excluded list, and must not begin with “V”, “W”, “X” or “Y”.

<InjuryNatureDesc> Element Optional C-50 Alleged Injuries – Description of Injuries

<com.iso_CauseofInjuryCd> Code List Optional C-5 ICD-9-CM External Cause of Injury Code, “E Code” describing the alleged cause of injury/illness. DO NOT INCLUDE DECIMAL. Must be on CMS valid list not on the excluded list and must begin with “E”. Optional for all CMS claims as of 4/22/13. See Appendix A CMS Field#15.

<com.iso_DeleteFromCMS> Element Optional Y – Send a delete transaction to CMS for this person/coverage. CMS Field #3 to remove a claim from the CMS system.

N – Must use “N” to remove the “Y” indicator if claim was touched on ClaimSearch website or system will not remove the “Y” indicator.

<com.iso_NotSendCovCMS>

Element Optional Y – Do not include this coverage in the CMS Quarterly Reporting N – Must use “N” to remove the “Y” indicator if claim was touched on ClaimSearch website or system will not remove the “Y” indicator.

85

Coverage Information 2 <com.iso_CovInfo2> This aggregate is optional for ISO ClaimSearch, but contains fields required for CMS Medicare reporting and Mass Tort. This aggregate is not sent within the MatchDetails section of a Response.




<com.iso_ProdLiabInd> Boolean Extension

Optional Product Liability Indicator. Indicates whether injury, illness or incident was allegedly caused by/contributed to by a particular product. CMS Field #58 – Currently not being sent to CMS. 1 = No; 2 = Yes, but not a mass tort situation. 3 = Yes and is a mass tort situation.

<com.iso_GenName> Element Optional C-40 Product Generic Name - Generic name of product alleged to be the cause of injury, illness, or incident. If no generic name, supply the brand name in this field. CMS Field #59 – Currently not being sent to CMS

<com.iso_BrandName> Element Optional C-40 Product Brand Name - Brand name of product alleged to be the cause of injury, illness, or incident. CMS Field #60– Currently not being sent to CMS

<com.iso_ProdMfr> Element Optional C-40 Product Manufacturer – Maker of Product. CMS Field #61 – Currently not being sent to CMS

<com.iso_AllegedHarm> Element Optional C-200 Description of harm allegedly caused by product. CMS Field #62 – Currently not being sent to CMS

<com.iso_ICD10CauseOfInjuryCd>

Element Optional C-7 This field is an optional CMS field, however if submitted it must be valid. Alleged Cause of Injury (E) codes can only be used when reporting ICD-9 diagnostic codes. Alleged Cause of Injury (V, W, X, Y) codes can only be used when reporting ICD-10 diagnostic codes. CMS Field #15.

Driver’s License Aggregate <DriversLicense> This can be submitted for Involved Party or Alias but is searched only if the Involved Party is searched.


<DriversLicenseNumber> Element Optional C-20 The number on this driver's license. Driver’s License will be masked on Response and Stylesheet files and will display in format XXXXXX123.

<LicenseClassCd> Element Optional C-2 A code used to identify Driver’s License Class Type. See Appendix A - LicenseClassCd code list.

<StateProvCd> Code List Optional See Appendix A – State Codes (no codelistref). As used here, the state where the driver’s license is issued.

Email Information Aggregate <EmailInfo> This aggregate is optional. It is used to populate the Email Address for an Involved Party, Service Provider, or Alias, depending on placement in XML string. When email address is available for ClaimsInjuredInfo, AutoLossInfo, or PropertyLossInfo you must use @idref.


@idref Identifier Reference

Optional @Idref is used only for ClaimsInjuredInfo, AutoLossInfo, or PropertyLossInfo references when email address is present.

<EmailAddr> Element Optional C-50 This element is searchable if provided. Must contain @ or the data will be considered invalid.

86

Employee Information Aggregate <EmployeeInfo> This aggregate provides additional information about an employee. This is typically used in Workers’ Compensation claims reporting and/or management to capture information about the employee at the time of the injury or illness.


@id Identifier Optional This attribute is an identifier to a specific element.

<HiredDt> Date Optional C-10 The date the employee began employment with the employer under which the claim is being filed.

<EmploymentStatusCd> OpenEnum Optional Indicates the employee’s primary work status at the time of the injury with the covered employer. See Appendix A - EmploymentStatusCd code list.

<com.iso_PreExistingDisabilityInd>

Boolean Extension


Y – Disability existed prior to the injury N – Disability did not exist prior to the injury U – Not known if the disability existed prior to the injury.

<com.iso_EmployedInd> Boolean Extension


Y – The person was employed by the insured N – The person was not employed by the insured.

Event Information Aggregate <EventInfo> This aggregate is used to collect the information about when a specific event occurred.


<EventCd> Code List Required A code identifying an event. Appendix A - EventCd code list.

<EventDt> Date Required C-10 The date on which the event took place. YYYY-MM-DD General Party Information Aggregate <GeneralPartyInfo> This aggregate provides general name, address, and communications information about a person(s) or organization(s).


<NameInfo> Aggregate See Description Repeating

Required for Claims Party and Service Providers; Optional for Alias Information or Adjuster Party

<Addr> Aggregate See Description Repeating

Address, City, State required for ClaimsParty; City and State required for Service Provider; Optional for Alias information or Adjuster Party. AddressTypeCd required for Mailing or Physical Risk Address under Policy/MiscParty, otherwise this element is not used.

<Communications> Aggregate Optional May be used to report Home Phone, Business Phone, Cell Phone, Pager +PIN, or Fax numbers. Only one of each number type may be reported per ClaimsParty. Fax number is Request Only.

Item Definition Aggregate <ItemDefinition> This aggregate is used in various places within the XML string for submitting first party property theft, boat, or mobile equipment claims. The required fields depend on what is submitted in the ItemTypeCd element.


<ItemTypeCd> Code List Required A code identifying the type of item being defined. This element uses the ItemDefinition (Watercraft or MoblEquip claim type) or SubjectInsuranceCd (Engine or Outdrive SerialIdNumber) code list. Please refer to the Appendix A.

<Manufacturer> Element Required – for boat

C-20 Enter the manufacturer of the boat or if the boat is homemade enter “Home Built”

<Model> Element Optional C-20 The manufacturer model name for this item. – Only use this element for reporting boat claims

87

Item Definition Aggregate <ItemDefinition> (cont.) Tag Type Usage Length Description

<SerialIdNumber> Element Required – for boat or mobile equipment

C-20 A unique number, typically the manufacturer’s serial number, identifying the item being described. (VIN/HIN/PIN)

<ModelYear> Long Required – for boat or mobile equip

C-4 The model year for this item. YYYY

<ManufacturerCd> Code List Required – for mobile equip

C-4 A code that identifies the make of the vehicle. Enter the NCIC standard 4-character code for vehicle make. If NCIC code is not available, please send 1st 4 characters of make.

<ModelCd> Code List Required – for mobile equip

C-3 A code that identifies the model of the vehicle. Enter the 3-character NCIC abbreviation for vehicle model. If NCIC code is not available, please send 1st 3 characters of model.

<BodyTypeCd> Code List Optional A code indicating the body style of this item. See Appendix A - WaterUnitTypeCd code list for boats/ VehTypeCd for mobile equipment.

<ChassisSerialNumber> Element Optional C-14 A unique number identifying the chassis of the item being described.

<EngineSerialNumber> Element Optional See Desc.

A unique number identifying the engine of the item being described. C-20 for Boat; C-14 for MoblEquip; See sample files for better understanding of reporting this element.

<TransmissionSerialNumber>

Element Optional C-14 A unique number identifying the transmission of the item being described.

<Registration> Aggregate Optional Item Id Information Aggregate <ItemIdInfo>


<AgencyId> Assigned Identifier

See description

C-9 MiscParty Aggregate on Request - An ID assigned by ISO to indicate company and office submitting a claim. Required ClaimsOccurrence/ItemIdInfo on Response – ISO ClaimSearch’s unique file number assigned to the claim. Required

<QueueId> Assigned Identifier

See description

C-4 This element is no longer used. It has been superseded by changes to ISO ClaimSearch backend processes.

<InsurerId> Assigned Identifier

See description.

C-30 MiscParty Aggregate on Request /Response – This element is NOT used within this aggregate. ClaimsOccurrence/ItemIdInfo on Request/Response - The insurer’s unique file number associated with this claim. Required

Item Information Aggregate <ItemInfo> This aggregate is used when reporting a mobile equipment claim.


<ItemDefinition> Aggregate Required Required if submitting a mobile equipment claim.

88

Investigation Information Aggregate <InvestigationInfo> This aggregate is used on both request and response messages, however some of the elements are only available on the response message from ISO ClaimSearch to your company. These are noted below. In these cases, the usage refers to whether the element is always present on the response or only present if information is available.



Required This references the ID for the specific AutoLossInfo or PropertyLossInfo (for Boat or Mobile Equipment claims).

<ValidVINInd> Boolean Required – response only

Indicates if ISO ClaimSearch has determined that the submitted VIN is valid. This applies to vehicles and mobile/ off road equipment.

<FailedVIN> Element Optional – response only

C-20 If ISO ClaimSearch has determined that the submitted VIN is invalid, contains the submitted invalid VIN. The corrected VIN is then returned in <VehIdentificationNumber>.

Claims with Failed VINs will not be sent to NMVTIS

<VINMissingInd> Boolean Optional 1=Indicates if the item’s VIN plate is missing.

<VehDispositionCd> Code List Optional Identifies the loss status of a vehicle. This applies to vehicles and mobile/ off road equipment. This uses the VehDispositionCd list.

<com.iso_TheftTypeInd> Boolean Extension

Optional P=Partial Theft, T=Total Theft of Vehicle The partial theft indicator should be used whenever contents of a vehicle or major parts are stolen. Partial thefts will not generate recoveries; total thefts will attempt to be recovered. Loss Type: partial=PTFT, total=THFT. Even though this information is not required, its use is important for the Recovery Process.

<EngineMissingInd> Boolean Optional 1=Indicates if the engine was missing at the time of the occurrence.

<TransmissionMissingInd> Boolean Optional 1=Indicates if the transmission was missing at the time of the occurrence.

<NCICStatusCd> Boolean Optional – Response (Echo) Only

A = Indicates that a vehicle theft is active in the NCIC system, and the vehicle has not yet been recovered.

<AutoInvestigationInfo> Aggregate Optional – response only

Identifies Impound, Export, or Shipping information. Shipping will return under ClaimInvestigationAddRs/ InvestigationInfo. Impound and Export will return under ClaimInvestigationAddRs/Match Details/ InvestigationInfo.

<RecoveryInfo> Aggregate Optional Required if any Recovery Information is reported

<SalvageInfo> Aggregate Optional Required if any Salvage Information is reported

<AppraiserActivityInfo> Aggregate Optional – response only

Identifies Estimation, Appraisal, or Valuation Information

<com.iso_VehRecall> Aggregate Optional Repeating (Max 10)– response only

This aggregate is only sent to members using the NHTSA Vehicle Recall Standard Additional Service.

<com.iso_SFNMVTIS> Aggregate Optional This aggregate is for an internal ISO process. It is not intended for external members.

<com.iso_NMVTISCheckInd>

Element Optional Response Only

E = This VIN failed validation but passed check digit validation. It is eligible to be sent to NMVTIS if all other reporting criteria are met.

<com.iso_NonStdVINVerify> Boolean Optional Echo Response Only

Y = VIN submitted is greater than or less than standard 17-digit VIN and therefore cannot be validated. . If value in <com.iso_NMVTISCheckInd> = F AND this field is populated, the vehicle may still be eligible to be sent to NMVTIS, if other NMVTIS criteria are met. Spaces will be sent in all other cases.

89

Key Reason Information Aggregate <com.iso_KeyReasonInfo> This aggregate is RESPONSE ONLY and contains information associating a claims party with common fraud indicators. This aggregate will only be returned if key indicators were present for an involved party or service provider.



Required This is required to report involved party information for SIU.

@ClaimsParty2Ref Identifier Reference

Optional This is required to report Service Provider information for SIU.

<com.iso_KeyReasonCd> Code List Required Repeating (Max 15)

C-2 A code identifying the fraud indicator(s) that exist for this party. See Appendix A - KeyReasonCd list.

Litigation Information Request Aggregate <LitigationInfo> This aggregate only refers to injury, liability, or 3rd party property damage claims where a ClaimsParty has filed a lawsuit. If the <PlaintiffRef> refers to an AutoLossInfo or PropertyLossInfo, the information provided will be dropped out in the processing of the claim and not stored on the ClaimSearch system. On Request, it is reported under the ClaimInvestigationInfo Entity.


@id Identifier Optional A document unique identifier should only be present on an element when it is being referenced within the stream.

<PlaintiffRef> Identifier Reference

Required Refers to the ClaimsInjuredInfo of the ClaimsParty that has filed the lawsuit.

<CourtName> Element Optional C-10 The text name of the court in which the action is to be filed. (ex. Supreme, Federal, District, etc.)

<Addr> Aggregate Optional As used here, to report the Court County <County> (C-25) and the Court State <StateProvCd>

<DocketNum> Element Optional C-22 Docket Number of the Court Case.

<ThresholdTypeCd> Code List Optional A code indicating the type of threshold applicable. This element uses the ThresholdType (ACORD) or the TortThresholdTypeCd (ISO) codelist.

<ThresholdStateProvCd> Code List Optional The state whose threshold laws are applicable. The source of this code list is the U.S. Postal Service.


Court Filed Date.

Litigation Information Response Aggregate <LitigationInfo> This aggregate is an echo back of the data that was sent on the Request. The elements are returned in a different hierarchal order under the ClaimInvestigationAddRs aggregate.


@id Identifier Optional A document unique identifier should only be present on an element when it is being referenced within the stream.

<PlaintiffRef> Identifier Reference

Required Refers to the ClaimsInjuredInfo of the ClaimsParty that has filed the lawsuit.

<CourtName> Element Optional C-10 The text name of the court in which the action is to be filed. (ex. Supreme, Federal, District, etc.)

<ThresholdTypeCd> Code List Optional A code indicating the type of threshold applicable. This element uses the ThresholdType (ACORD) or the TortThresholdTypeCd (ISO) codelist.

<ThresholdStateProvCd> Code List Optional The state whose threshold laws are applicable. The source of this code list is the U.S. Postal Service.

90

Litigation Information Response Aggregate <LitigationInfo> (cont.)



Court Filed Date.

<DocketNum> Element Optional C-22 Docket Number of the Court Case.

<Addr> Aggregate Optional As used here, to report the Court County <County> (C-25) and the Court State <StateProvCd>

Match Details Aggregate <MatchDetails> The aggregate is a RESPONSE ONLY aggregate and contains details about the matching claim, indicating why the matching claim matched the submitted claim. When a match is made, all of the claim details in each matching claim as submitted by other organizations are sent.


(%CLAIMSINVESTIGATIONINFO)

Entity Required

<MatchReasonInfo> Aggregate Required Repeating

<com.iso_SumReasonInfo> Aggregate Optional Repeating

Summary Information for Involved Party or Service Provider

<LitigationInfo> Aggregate Optional Repeating

This is the Response LitigationInfo for the Matching Claim listed above it.


Match Information Aggregate <MatchInfo> This aggregate is a RESPONSE ONLY aggregate and contains summary details of the match(es).


<AdditionalMatchInfo> Aggregate Optional Repeating

Match Reason Information Aggregate <MatchReasonInfo> This aggregate is a RESPONSE ONLY aggregate and contains information associating a claims party with the reason for the match.


@ClaimsPartyRef Reference Identifier

Required This attribute is an identifier reference to a ClaimsParty. As used here, references the party on which the match was made.

<MatchReasonCd> Code List Required Repeating

A code identifying the reason for this match. The source is the MatchReasonCd code list.

Miscellaneous Party Aggregate <MiscParty> This aggregate provides information about a miscellaneous individual or organization. ISO uses this aggregate to identify the insuring company and office that the claim is coming from. Matching claims on Response files will not display the ItemIdInfo/ AgencyId but will display the company name under GeneralPartyInfo instead.


<ItemIdInfo> Aggregate Required AgencyId required for ISO assigned company reporting code on Request and Response – echo of Initiating claim

91

Miscellaneous Party Aggregate <MiscParty> (cont.)


<GeneralPartyInfo> Aggregate Optional Request – used to report SIU Company Name, SIU Investigator Name, and SIU Investigator Business and Cell Phones.

Response - Company Name is provided for matching claims rather than the matching claims’ AgencyId.

<com.iso_SIUInfo> Aggregate Optional – Response Only

This aggregate contains Special Investigation Unit Contact Information for the claim as a whole on Response Only.

<com.iso_AddInfo> Aggregate Optional This aggregate contains the NMVTIS Operator Entity ID

<MiscPartyInfo> Aggregate Required Miscellaneous Party Information Aggregate <MiscPartyInfo> This aggregate provides additional information about a role for a miscellaneous individual or organization.


<MiscPartyRoleCd> Code List Required Value=”CarrierInsurer” for ISO ClaimSearch US members. Name Information Aggregate <NameInfo> Special characters should not be sent in name fields except for apostrophe [‘], hyphen [-], or ampersand [&]. See Appendix C – Edits for further information on other restrictions on these fields. CMS Required Fields are for Involved Party roles. See Appendix C – Role Codes for information specific to Service Providers.


<CommlName> Aggregate Required XOR

The name of any business or organization, unparsed up to 70 characters. CMS Field #69

<PersonName> Aggregate Required XOR

The name of an individual, parsed into first, middle, and surnames. CMS Required Field #6-8

<TaxIdentity> Aggregate Optional Repeating

Social Security Number (individual) or Tax Identification Number (organization) CMS Field #5, if individual

<NonTaxIdentity> Aggregate Optional Repeating

Professional License or Passport Number

Non-Tax Identity Aggregate <NonTaxIdentity> This aggregate contains the unique nontax id, such as a professional license or passport number.


<NonTaxIdTypeCd> Code List Optional A code identifying the type of nontax Id. This element uses the NonTaxIdType code list. Please refer to the Appendix A

<NonTaxId> Assigned Identifier

Optional See Desc.

A unique identification issued for other than tax purposes. C-15 – Prof. License C-9 – Passport Number

Party Investigation Information Aggregate <PartyInvestigationInfo>


<SuppressMatchInd> Boolean Optional 1=Indicates that the submitter only wants the data for this party added to the database. No search will be completed on this party. The Response will contain the MatchReasonCd of NS. CMS Warning Codes will still be generated for this party.

<SocialSecurityIssuancePeriod>

%DURATION

Optional – response only

The years in which the individual’s social security number was issued as provided to ISO ClaimSearch by the Social Security Administration and is provided on output only.

92

Party Investigation Information Aggregate <PartyInvestigationInfo> (cont.)


<SSNValidationCd> Code List Optional – response only

A code identifying the validity of a social security number as determined by the Social Security Administration. The source of this code list is SSNValidationCd code list. This element is provided on output only.

<TINValidationCd> Code List Optional – response only

A code identifying the validity of a social security number as determined by the Social Security Administration. The source of this code list is TINValidationCd code list. This element is provided on output only.

Person Information Aggregate <PersonInfo> CMS Required Fields are for Involved Party roles only.


<GenderCd> Code List Optional C-1 A code indicating gender. This element uses the ACORD Gender code list. CMS Required Field #9

<com.iso_Age> Element Extension

Optional - C-3 Only returned f the company is signed up for the Append-DS Optional Service. Response Only

<BirthDt> Date Optional C-10 The date of birth for this individual. Input and non-masked response format YYYY-MM-DD. CMS Required Field #10

<com.iso_MaskBirthDt>

Date Optional C-10 Masked date of birth for this individual. Response Only.

Returned on Echo and Match instead of <BirthDt>. YYYY.

<OccupationDesc> Element Optional C-50 A description of the party’s primary occupation or business.

<com.iso_1stDoctorDt>

Element Optional The date of the first visit to this doctor after the accident. YYYY-MM-DD. This element is restricted to specific Service Provider role codes, see Appendix D – Role Codes.

Personal Name Aggregate <PersonName> Special characters should not be sent in name fields except for apostrophe [‘], or hyphen [-], or ampersand [&]. See Appendix C – Edits for further information on how special characters are handled in XML and other restrictions on these fields. CMS Required Fields are for Involved Party roles. See Appendix D – Role Codes for information specific to Service Providers.


<Surname> Element Required C-30 The family name of an individual CMS Required Field #6

<GivenName> Element Required C-20 The first name of an individual CMS Required Field #7

<OtherGivenName> Element Optional C-20 The middle name of an individual CMS Field #8 Personal Vehicle Information Aggregate <PersVehInfo>


<OdometerReading> %MEASUREMENT

Optional C-10 The odometer reading at the time the insurance policy is applied for. As used here, miles.

<AntiTheftDeviceCd> Code List Optional This element uses the AntiTheftDeviceCd code list. Phone Information Aggregate <PhoneInfo>


<PhoneTypeCd> Code List Required if Phone # is submitted

The type of phone number. This element uses the PhoneTypeCd code list. Please refer to the Appendix A

<CommunicationUseCd> Code List Required if Phone # is submitted

This element describes where and when the communication method is used. This element uses the CommunicationUse code list. Please refer to the Appendix A.

93

Phone Information Aggregate <PhoneInfo> (cont.) Tag Type Usage Length Description

<PhoneNumber> Phone Number

Optional C-14 The phone number. +1-NNN-NNNNNNN

<com.iso_PhoneName> Element Extension


C-70 The name as it appears in phone directories. This field is only returned on response if the company is signed up for the Append-DS Optional Service.

<com.iso_PublishedInd> Boolean Extension


Y – The phone number is published N – the phone number is not published This field is only returned on response if the company is signed up for the Append-DS Optional Service.

Policy Aggregate <Policy> This “aggregate” has been defined as an entity under the heading Property Casualty Policy Entity (%PCPOLICY). It can be found under the Entity section of this manual. Property Loss Information Aggregate <PropertyLossInfo> This aggregate is used to report a first-party property loss. Multiple PropertyLossInfo aggregates may be reported on a claim; however, each PropertyLossInfo must contain only one <Watercraft> aggregate, OR one <ItemInfo>, OR one or more <ClaimsSubjectInsuranceInfo> aggregates. Note - Please see Summary of XML Request Aggregates in Schema Order for further rules on submitting property claims


@id Identifier Required Required by ISO as reference point for coverage/loss information in AdjusterPartyInfo and ClaimsPayment Aggregates.

@ClaimsPartyRefs Identifier Reference

Required This refers to the ID of the ClaimsParty that suffered the loss.

<ItemInfo> Aggregate Optional OR

Required if mobile equipment claim

<Watercraft> Aggregate Optional OR

Required if boat or watercraft claim

<PropertySchedule> Aggregate Optional Repeating

Required if property theft claim or Optional for reporting Scheduled Property. Can be repeated to report multiple categories of stolen items

<ClaimsSubjectInsuranceInfo>

Aggregate Optional Repeating OR

Required for 1st party property damage including fire, theft, or other peril for Property Coverages: Building, Contents, Loss of Use, Stock, or Other. May be repeated to indicate different Property coverage dollar amounts.

<RealEstateTypeCd> Code List Optional This element uses the RealEstateTypeCd code list. If “Other” is reported, this element will not be on the Response, only the “Other Desc” below will show.

<RealEstateTypeOtherDesc>

Element Optional C-35 The description of the building when the RealEstateTypeCd is “Other”.

<LossKindCd> Element Optional Y = This loss includes at least one scheduled item

<ObjectLossDesc> Element Optional C-35 Description of scheduled property

<OccupancyTypeCd> Code List Optional A code identifying the occupancy status of the particular structure. This element uses the OccupancyTypeCd code list.

<IncendiaryFireInd> Boolean Optional Indicates if the fire appears to be incendiary in nature.

<TheftLocationCd> Code List Optional This element uses the TheftLocationCd code list.

<com.iso_ContentTheftInd>

Element Optional Indicates whether contents were stolen from: R = Retail Store C = Cargo/Truck Loss Type must equal THFT. Population of this element will result in notification to CargoNet.

94

Property Schedule Aggregate <PropertySchedule> This aggregate identifies items that have been damaged or stolen. Required for 1st party property theft claim. Optional for all other loss types. Can be repeated to report multiple items.


<IsSummaryInd> Boolean Extension

See Desc. Indicates if item is scheduled, unscheduled or both. X = Unscheduled (default) S = Scheduled B = Both Required if loss type is theft, Optional for all other loss types

<ItemDefinition> Aggregate Required The SubjectInsuranceCd “for reporting theft of property” code list is used to identify stolen or damaged items. At least one category from this list must be selected when reporting a property theft claim.

Recovery Information Aggregate <RecoveryInfo> This aggregate may include data supplied by the insuring company on a request, or on a response it may contain data as provided by insurance company, police agencies, or National Insurance Crime Bureau (NICB).



Required This references the ID of the vehicle (AutoLossInfo) or boat (PropertyLossInfo) that was stolen.

@RecoveryAgencyRef Identifier Reference


This references the ID of the ClaimsParty that recovered the vehicle or boat.

<RecoveryStatusCd> Code List See Description

A code identifying the condition of the recovered vehicle. The source of this code list is the RecoveryConditionCd code list (Required for Recovery data) or the Recovery ClassificationCd code list (Optional for Recovery data). This element will repeat if both Condition and Classification are used. They will be distinguished by the Code List used.

<CannedRecoveryCd> Code List Extension

Required – response only

A code provided by the NCIC regarding the status of a recovered vehicle. This element uses the RecoveryStatusCd List. Information in this field will cause the RecoveryInfo to return outside the <InvestigationInfo> aggregate.

<RecoveryDt> Date Required C-10 The date on which the vehicle was reported as recovered. YYYY-MM-DD

<Addr> Aggregate Required As used here, this is the location where the vehicle was recovered. (Recovery State is required)

<RecoveryLocDesc> Element Required for impounds - response only

C-24 A description of the location where the vehicle was recovered, other than an address. Only for Impounded Vehicles. Information in this field will cause the RecoveryInfo to return outside the <InvestigationInfo> aggregate.

<Communications> Aggregate Optional As used here, provides contact information for the actual location of the recovery, as opposed to the recovery agency.

<com.iso_RecoveryVehNumber>

Element Extension

Optional – response only

C-12 As used here, impound reference number. Information in this field will cause the RecoveryInfo to return outside the <InvestigationInfo> aggregate.

<com.iso_TheftVerification>

Aggregate Optional – Response Only

Additional verification that the insured’s stolen vehicle has been reported to the police.

<com.iso_VehRecoveryInd>

Boolean Extension

Optional - Response only

Y = this is the Vehicle being recovered in a multi-VIN theft. Information in this field will cause the RecoveryInfo to return outside the <InvestigationInfo> aggregate.

95

Registration Aggregate <Registration>

Salvage Information Aggregate <SalvageInfo> This aggregate provides information regarding the salvage of a vehicle, boat, or mobile equipment. VIN is an optional field for most auto physical damage claims with a 3rd party (CL, CD, or CP) claimant role code; however, reporting SalvageInfo for this vehicle makes the VIN a required field.



Required As used here, this references the ID of the object being salvaged (AutoLossInfo or PropertyLossInfo).

@SalvageAgencyRef Identifier Reference


XOR

This attribute is an Identifier Reference to a salvage agency. As used here, this references ClaimsParty.

@BuyerRef Identifier Reference

Required

This is references the ClaimsParty that is the buyer of the salvaged vehicle, boat, or mobile equipment. Reference ClaimsParty who is owner where owner retains salvage.

<SalvageDt> Date Required C-10 The date when the vehicle was salvaged. YYYY-MM-DD

<ItemAppraisedValueAmt>

%Currency Optional C-11 The appraised value of the salvaged vehicle, provided by the salvage entity.

<ItemValuePriorToLossAmt>

%Currency Optional C-11 The actual cash value of the vehicle prior to the loss, as provided by the salvage entity. This is not necessarily the insured amount.

<ItemValueReceivedAmt>

%Currency Optional C-11 The amount of payment received for the vehicle, as provided by the salvage entity.

<OwnerRetainingSalvageInd>

Boolean Required 1=The owner is retaining the salvaged vehicle. Insured ClaimsParty will be used as Salvage Owner.

0=The owner is NOT retaining the salvaged vehicle. BuyerRef becomes Required if this value is submitted as well as a ClaimsParty with a SalvageBuyer role code.

If Insurance Company is retaining salvage, SalvageInfo aggregate is omitted.

Special Investigator Aggregate <com.iso_SIUInfo> This aggregate identifies the Special Investigator Contact Information for the claim as a whole. The entire aggregate is RESPONSE ONLY.


<GeneralPartyInfo> Aggregate Optional Physical Risk Address and Mailing Address

<com.iso_CommlName> Element Optional SIU Company Name

<com.iso_SurName> Element Optional SIU Investigator Last Name


<RegistrationTypeCd> Code List Optional – for vehicles only

As used here, this is a code identifying the type of specialty license plate on a vehicle, such an Antique Car, Diplomatic, etc. Uses the LicensePlateTypeCd code list

<RegistrationNumber> Identifier Optional See Desc.

The unique identifier assigned by the registering authority. As used here, License Plate for vehicles, Boat Registration Number for boats.

C-9 for boats C-10 for vehicles

<StateProvCd> Code List Required if Reg. No. is input

C-2 State code in which the vehicle or boat was registered. The source of the code list is the U.S. Postal Service.

<CountryCd> Code List Optional C-3 Country. Usage is the International Standards Organization code list.

<LastRegisteredYear> Date Optional C-4 The last year in which the item was legally registered. YYYY

96

Special Investigator Aggregate <com.iso_SIUInfo> Tag Type Usage Length Description

<com.iso_GivenName> Element Optional SIU Investigator First Name

<com.iso_OtherGivenName> Element Optional SIU Investigator Middle Name

<com.iso_SIUPhoneInfo> Element Optional SIU Phone Info +1-NNN-NNNNNNN

<com.iso_InsurerFraudRingInvestigation>

Boolean Extension

Optional Y/N. Claim is associated with insurer fraud ring investigation.

Special Investigation Details Aggregate <com.iso_SIUParty> This aggregate identifies special investigation details and email address that will be associated with either Involved Parties or Service Providers. It also contains CMS Reporting required fields for Claimant Role Codes



Required XOR

As used here, references the claims party associated with the Investigation Details.


Required XOR

As used here, references the service provider associated with the Investigation Details.

The following fields may be reported referencing either Involved Party (Insured or Claimant) or Service Provider

<com.iso_SIUInvolved> Boolean Extension

Optional Y – SIU is involved in the claim for this party. N – SIU is not involved in the claim for this party.

<com.iso_ClaimNotPaid>

Boolean Extension

Optional Y - Claim or part of claim for this party was not paid after investigation. N – Claim or party of claim for this party was paid after investigation.

<com.iso_EnforcementActionSubject>

Boolean Extension

Optional Y – Party was subject to an enforcement action (criminal indictment, professional disciplinary). N – Party was NOT subject to an enforcement action.

<com.iso_CriteriaForFraudBureau>

Boolean Extension

Optional Y – Claim for this party meets the criteria for fraud bureau reporting. N – Claim for this party does NOT meet the criteria

<com.iso_NICBAlert> Boolean Extension

Optional - Response Only

Y – Party associated with NICB alert. N – Party not associated with NICB alert. This will only appear on the Echo section of the Response.

The following fields may only be reported referencing a ClaimsParty with a Claimant role code (CI, CD, CE, CL, or CP)

<EventInfo> Aggregate Optional As used here, to report the Date of Death. Uses EventCd=Death. .

<com.iso_MedicareEligibleInd>

Boolean Extension

Optional Y=This involved party is Medicare eligible N= This involved party is NOT Medicare eligible Space=Unknown

***This field is the main trigger for reporting to CMS. Any time this indicator = Y and the claim meets other criteria for reporting, the party will be reported to CMS. If you do not want the party sent to CMS, you must populate <com.iso_NotSendToCMS> with “Y”. CMS Field

<com.iso_NotSendToCMS>

Boolean Extension

Optional Y = Do not send this party to CMS. Use this indicator if you do not want this party sent to CMS because the claim is below the threshold or for other reasons. CMS Field

N = Must use “N” to remove the “Y” indicator if claim was touched on ClaimSearch website or system will not remove the “Y” indicator.

<com.iso_HICN> Assigned Identifier

Optional C-12 Medicare Health Insurance Claim Number/Medicare Beneficiary ID (MBI). Required for CMS reporting if SSN is not provided. CMS Field #4

97

Special Investigation Details Aggregate <com.iso_SIUParty> (cont.) Tag Type Usage Length Description

<com.iso_StopCMSQuery>

Boolean Extension

Optional Y – Stop querying the CMS system to determine Medicare eligibility for this party. You may wish to stop the query if the claim is closed after the threshold dates and you do not expect to have further responsibility.

N = Must use “N” to remove the “Y” indicator if claim was touched on ClaimSearch website or system will not remove the “Y” indicator.

The following fields may be reported referencing either Involved Party (Insured or Claimant) or Service Provider

<Communications> Aggregate Optional As used here, will populate the Email Address for the above referenced <ClaimsParty>. This is not used for Alias Email Address.

Special Investigator Phone Information Aggregate <com.iso_SIUPhoneInfo> This aggregate contains phone information for the special investigator. The entire aggregate is RESPONSE ONLY.


<PhoneTypeCd> Code List Optional See Appendix A – PhoneTypeCd code list

<CommunicationUseCd> Code List Optional See Appendix A - CommunicationUse code list

<PhoneNumber> Phone Number

Optional The phone number for the special investigator. +1-NNN-NNNNNNN

Summary Reason Information Aggregate <com.iso_SumReasonInfo> This aggregate is RESPONSE ONLY and contains information associating a claims party with the reason for the match.



Required This is required to report Involved Party (Claims Party) information for SIU.


Optional This is required to report Service Provider Information for SIU.

<com.iso_SumIdentifier> Element Required Repeating

C-11 ISO File Number of Matching Report (Repeating Max 16)

<com.iso_SumReasonCd> Code List Required Repeating

C-18 See Appendix A – SumReasonCd code list. (Repeating Max 16)

<com.iso_TotalLossType> Element Optional C-2 Total # of Matches by Loss Type

<com.iso_TotalSIUInvolvement> Element Optional C-2 Total # of Matches for SIU Involvement

<com.iso_TotalName> Element Optional C-2 Total # of Matches by Name

<com.iso_TotalAddress> Element Optional C-2 Total # of Matches by Address

<com.iso_TotalSSN> Element Optional C-2 Total # of Matches by SSN

<com.iso_TotalPhone> Element Optional C-2 Total # of Matches by Phone

<com.iso_TotalDriversLic> Element Optional C-2 Total # of Matches by Driver’s License

<com.iso_TotalVIN> Element Optional C-2 Total # of Matches by VIN

<com.iso_TotalLicPlate> Element Optional C-2 Total # of Matches by License Plate Tax Identity Aggregate <TaxIdentity> This aggregate contains the unique tax ID assigned by government and associated with a person or organization.


<TaxIdTypeCd> Code List Required See Appendix A – TaxIdType code list.

<TaxId> Assigned Identifier

Required C-9 SSN or TIN. SSN and TIN’s will be masked on Response and will be returned in format >000001234< SSN =CMS Field #5

<StateProvCd> Code List See Desc C-2 The state where the ID was issued. (RESPONSE ONLY)

98

Vehicle Information Aggregate <VehInfo>


@id Identifier Optional

<Manufacturer> Element Optional C-35 A description of the make of either a vehicle, piece of machinery, boat, mobile home, etc.

<Model> Element Optional C-35 The manufacturer model name for this item.

<ModelYear> Long Required C-4 The model year for this item. YYYY (not required for 3rd party claimants with roles of CL, CD, or CP).

<VehBodyTypeCd> Code List Optional A code indicating the body type of this vehicle. This element uses the VehicleStyleCd code list.

<VehTypeCd> Code List Optional` A code identifying the predominant type of the vehicle. This element uses the VehicleTypeCd code list.

<Registration> Aggregate Optional

<VehIdentificationNumber>

Element Required C-20 Full VIN assigned to the vehicle by the manufacturer. This is not required for third-party claimants with roles of CL, CD, or CP, UNLESS • Loss Type is THFT • Multiple vehicles are reported for a single party • If this <AutoLossInfo> is referenced by <SalvageInfo> • If the claim is to be reported to NMVTIS

In these cases, VIN is required regardless of role code.

<ChassisSerialNumber> Element Optional C-14 Serial Number of the Chassis if not VIN derived.

<EngineSerialNumber> Element Optional C-14 Serial Number of the Engine if not VIN derived or not the original engine.

<TransmissionSerialNumber>

Element Optional C-14 Serial Number of the Transmission if not VIN derived or not the original transmission.

<ColorCd> Code List Optional A code identifying the color of the vehicle. This element uses the VehColorCd code list.

<PersVehInfo> Aggregate Optional

<com.iso_RentedVehInd>

Boolean Optional 1=Indicates that the vehicle was rented

Vehicle Theft Verification Aggregate <com.iso_TheftVerification> This aggregate will be returned to Auto participants authorized to receive LEMD (Law Enforcement & Manufacturer’s Data) with additional verification that their insured’s stolen vehicle has been reported to the police. After receipt of a theft claim, the National Crime Information Center (NCIC) database used by police agencies will be searched for information matching the VIN on the theft claim. When activity is found the Vehicle Theft Verification Aggregate will be returned. You will no longer receive this aggregate once a recovery has been made.


<com.iso_NCICDt > Date Required Date entered into the police system.

<com.iso_PoliceAgency> Element Required C-37 Police Agency who entered the NCIC record

<com.iso_OCA> Element Required C-15 Case number assigned by Police Agency

99

Watercraft Aggregate <Watercraft> This aggregate contains information relating to watercraft that have their own individual Boat policy. Smaller watercraft such as canoes or kayaks that are part of a Homeowners policy should be reported under general property using ClaimsSubjectInsuranceInfo aggregate. Only one watercraft loss may be reported per Request.

Workers Compensation Loss Information Aggregate <WorkCompLossInfo> This aggregate accumulates the data required to file a first report of injury for Workers’ Compensation.


@id Identifier Required if aggregate is used.

A document unique identifier – Required by ISO as reference point.

<WCClaimTypeCd> CodeList Optional Use this field for workers’ comp claims. A code that identifies the payment being made. This element uses the BenefitTypeCd code list.

<SecondInjuryFundInd> Boolean Optional Indicates if the employer was reimbursed by a second injury fund.

<EmployeeInfo> Aggregate Optional

<VesselCallId> Assigned Identifier

Optional A unique assigned radio call sign for a vessel. As used here, applies to losses under the Jones Act. May be used in place of Location of Loss State/Country reported on Claims Occurrence/Addr for losses occurring at sea..


<WaterUnitTypeCd> Code List Required See Appendix A – WaterUnitTypeCd code list.

<ItemDefinition> Aggregate Required – limited repeating

ISO extension allows this to be repeating to account for information such as multiple engines on a boat (Engine Manufacturer)

<Length> %Measurement

Optional C-2 The length of the boat in feet. If boat is larger than 99 feet, the field may be maxed out at 99 or not reported.

<Horsepower> %Measurement

Optional C-20 The numeric value of the horsepower of the engine/motor of the unit.

<HullMaterialTypeCd> Code List Optional C-2 See Appendix A – HullMaterialTypeCd code list.

<Registration> Aggregate Optional

<PropulsionTypeCd> Code List Optional C-2 See Appendix A – PropulsionTypeCd code list.

100

UPDATE REQUEST AGGREGATES

Claims Update Aggregate <com.iso_Update> This aggregate contains information indicating an update to a claim. The aggregates requiring an update should immediately follow this aggregate. (See Replacements and Updates for further information.)


<com.iso_UpdateInd> Element Extension

Required C-1 See Claims Update Indicators in code list section. Note this is not a code list.

<com.iso_OriginalFields> Aggregate Extension

Required – See description

Required for Indicators 2, 3, 5, or 6. Not used for Indicators 1 or 4.

Claims Update Original Fields Aggregate <com.iso_OriginalFields> This aggregate contains the original data for fields that will be updated in a Claims Update. The Key Fields aggregate is only used for UpdateInd 5 – Changing Key Fields. The name aggregates are only used for UpdateInds 2, 3 and 4 (for ClaimsParty search) to identify the claims party being updated. (See Replacements and Updates for further information). NAMES MUST BE SENT EXACTLY AS THEY RESIDE IN THE SYSTEM IN ORDER TO COMPLETE THE UPDATE REQUEST.


<com.iso_KeyFields> Aggregate Required This aggregate is REQUIRED if changing Key Field information (UpdateInd=5)

<CommlName> Aggregate Optional XOR

This aggregate is REQUIIRED if updating an individual claims party that is a business.

<PersonName> Aggregate Optional XOR

This aggregate is REQUIIRED if updating an individual claims party that is an individual.

Claims Update Original Key Fields Aggregate <com.iso_KeyFields> This aggregate contains the original data for ISO key fields that will be updated in a Claims Update. This aggregate is only used for UpdateInd 5 to identify the original information submitted on the claim. (See Replacements and Updates for further information.)


<PolicyNumber> Element Required C-30 Insurer’s Policy Number as originally submitted to ISO ClaimSearch

<ItemIdInfo> Aggregate Required C-30 Uses AgencyId to indicate the ISO Assigned reporting code to indicate the company and office the claim was originally reported under; and the InsurerId to indicate the insurer’s Claim Number as originally submitted to ISO ClaimSearch

<LossDt> Date Required C-10 Date of Loss as originally submitted to ISO ClaimSearch. YYYY-MM-DD

101

ADDITIONAL SERVICES

Additional Services are offered to all ISO ClaimSearch members. The Standard services listed below are part of the standard membership contract and are offered at no additional cost. These services may simply require additional programming to gain the benefits of this service. The Optional services require an additional signed agreement and may require additional programming to gain the benefits of the service. The sections that follow address the general purpose of the service, the technical aspects of how to program these services into your transmissions, and the aggregates used by those services. For pricing of the individual services, please contact your ISO ClaimSearch Account Representative. (If you do not know your ISO ClaimSearch Account Representative, please contact our Customer Service team at 800-888-4476 or [email protected].) Standard Additional Services Offered: Account Management Reports & Dashboards Mandatory – Statutory Reporting National Motor Vehicle Title Information System (NMVTIS) Optional Additional Services Offered: Append-DSSM Child Support Enforcement Agency (CSLN/OCSE) Reporting ClaimDirectorSM Marine Index Bureau Claims Medicaid Reporting Service (MAIS) Medicare Secondary Payer Reporting Service (CMS) OFAC Compliance Solutions


102

Standard Additional Services

Account Management Reports & Dashboards

As part of our continued efforts to provide clients with critical information in real time, ISO ClaimSearch offers the ability to view and download online management reports. Authorized management personnel can access and view management reports on the ISO ClaimSearch website. The following reports are currently available: ISO ClaimSearch Pinboards (available through the ISO ClaimSearch Insights tile on the ISO ClaimSearch Home Page)

Claims Inquiry Usage – provides insight into a company’s Claims Inquiry usage. Claims Reporting - provides insight into a company’s volume of claims reported at the involved party and coverage

level, as well as the company’s hit and match rate by line of business. Visualized ISO ClaimSearch Usage - highlights how often the visualized ClaimSearch reports are accessed by each

user. ClaimAlert – provides insight into the alerts that were triggered.

ISO ClaimSearch Dashboards and Reports (available through the ISO ClaimSearch Dashboard and Report tile on the ISO ClaimSearch Home Page)

Executive Analysis Report – a quarterly report that provides an accounting of claims reported to ISO ClaimSearch on a group and company level and compares (benchmarks) this experience against industry totals.

ISO ClaimSearch Billing Report - provides online access to the transaction-based billing detail in invoices for non-insurance company participants. All activities such as claims reporting and claims inquiry are itemized for each transaction processed through the system.

OPTIONAL SERVICES Medicare Secondary Payer Reports – Members who subscribe to the Medicare Secondary Payer Reporting Service

and have been given access to CMS Account Management will receive the results of the monthly CMS Query file and quarterly Acknowledgements and Errors generated as a result of the reporting to CMS. Recently added functionality will now show claimants who are marked as Medicare Eligible Indicator = Y, quarterly statistics, an Active Warning report, and a new dashboard for easier understanding.

ClaimDirector Account Management – Members who subscribe to the ClaimDirector Optional Service have access to

the ClaimDirector Customizer, SIU Triage Page, ClaimDirector Performance Management Dashboard (interactive dashboard to analyze claims scoring activity/trends by Line of Business, Region and Scoring Ranges plus the ability to analyze Rule activity), and ClaimDirector Billing Detail (for claims submitted for scoring via the website).

Decision Net® Account Management – Members who subscribe to the Decision Net Optional Service have access to

the Decision Net Billing Detail (monthly invoices showing the transactions per user per office). Service Information ISO ClaimSearch Core Services Management Reports are part of the standard ISO ClaimSearch membership agreement and only require access to the Account Management section of the ISO ClaimSearch website. ISO ClaimSearch Optional Services require subscriptions to the appropriate services as well as access to the Account Management section of the ISO ClaimSearch website. For further information on access requirements and authorization procedures, please contact ISO ClaimSearch Customer Support.

103

Mandatory – Statutory Reporting

Data Provided to State Agencies ISO ClaimSearch represents the industry and individual members in ongoing interaction with fraud bureaus and/or fire marshals. In addition, most fraud bureaus have direct access to the system for their investigations. Auto Reporting Services Theft and Salvage Claims Reporting to ISO ClaimSearch satisfies requirements for reporting theft and salvage claims in six states: California Massachusetts New York Connecticut New Jersey Rhode Island New York - Auto Physical Damage The state of New York requires reporting of all first party and third-party auto physical damage claims of $2,500 or more to a centralized database, such as ISO ClaimSearch, or direct to the State. Pennsylvania - Auto Liability Pennsylvania requires the membership in, and reporting of all motor vehicle insurance claims data to, a comprehensive database system. Participation in ISO ClaimSearch fulfills this requirement. New Jersey - Auto Accidents The New Jersey Office of the Insurance Fraud Prosecutor requires the reporting of all auto accidents to ISO ClaimSearch via the system's Universal Format. Casualty Reporting Services California Regulation 2698, Claims Analysis Bureau Reporting The ISO ClaimSearch system functions as a Claims Analysis Bureau (CAB) for the California Department of Insurance under California Insurance Law 953: Regulation 2698. The system maintains the required reporting of auto liability, medical payments, and uninsured motorist bodily injury claims on California auto policies. Statutory Reporting for New York State Department of Social Services In New York, reporting to ISO ClaimSearch meets the requirement to provide copies of all bodily injury claims (other than workers compensation, medical malpractice and no-fault) to the Department of Social Services to assist in the identification and reporting of all income for New York public assistance recipients. Statutory Reporting for Connecticut Department of Administrative Services Reporting to ISO ClaimSearch meets the requirement in Connecticut for all insurers to notify the Department of Administrative Services (DAS) when a liability claim that may result in a monetary award is filed by a resident of the state. ISO ClaimSearch provides the Connecticut personal injury and workers' compensation claims it receives to the DAS on behalf of participants. New Jersey - Auto Accidents The New Jersey Office of the Insurance Fraud Prosecutor requires all insurers that write in excess of $2,000,000 in personal auto coverage to report all auto accidents involving bodily injury claims and auto physical damage in excess of $2,000 to ISO ClaimSearch via the system's Universal Format. Pennsylvania- Motor Vehicle Insurance Claims Pennsylvania requires reporting of all auto insurance claims to a central database. Participation in, and reporting auto claims to, ISO ClaimSearch fulfills that requirement. Property Reporting Services ISO staff works with state fire marshals to report on behalf of members where there are mandatory reporting requirements for fire and other losses. Reporting to ISO ClaimSearch satisfies the fire reporting requirements in 21 states.

104

The states are: Alaska Idaho Massachusetts New Mexico Arizona Illinois Michigan New York Delaware Kansas Montana North Dakota Florida Kentucky Nebraska Tennessee Georgia Maryland New Hampshire Washington Fire Loss Reporting In 17 states, copies of Property reports are sent on behalf of members to the state fire marshal on a monthly or quarterly basis. Reports are provided in hard copy or electronically. The list below shows the states and indicates those that receive electronic (e) reports. Arkansas Kansas Michigan (e) New Mexico Delaware Kentucky (e) Montana North Dakota Georgia Maryland Nebraska (e) Tennessee (e) Idaho (e) Massachusetts (e) New Hampshire (e) Washington (e) West Virginia NOTE – Although Estimated Loss Amount is not required for ISO ClaimSearch, individual state fire marshals may require this field on all 1st party fire losses per state law. These state fire marshals may send their own rejection reports on claims that do not meet this requirement. Property System Participation In New York State, all companies licensed to write fire business must participate in ISO ClaimSearch - Property. Questionable Claims Reporting Referring to State Fraud Bureaus ISO ClaimSearch and NICB System participants can refer questionable claims through ISO ClaimSearch to the NICB's Questionable Claims Database, and through the NICB, to state fraud bureaus. Twenty-four states accept questionable claims referrals from the NICB: Alabama Idaho Missouri South Carolina Alaska Illinois** Montana South Dakota Arizona Indiana Nebraska Tennessee Arkansas Iowa Nevada Texas California Kansas New Hampshire Utah Colorado* Louisiana New Mexico Vermont Connecticut Maine North Carolina Virginia Delaware Maryland North Dakota Washington District of Columbia Massachusetts Ohio West Virginia Florida Michigan Oklahoma Wyoming Georgia Minnesota Oregon Hawaii Mississippi Puerto Rico * Questionable claims go to the Attorney General for investigation and prosecution, and it is not a substitution for the Department of Insurance requirements. ** NICB serves as the State of Illinois’ Questionable Claim Database Referring to State Fire Marshals Similarly, participants can refer questionable or suspicious fire claims to fire marshals in eight states: Illinois Louisiana New Mexico West Virginia Iowa Montana Texas Wyoming Service Information Mandatory-Statutory Reporting is part of the standard ISO ClaimSearch membership agreement. Any additional programming required is dependent on individual statutes and the types of claims reported to the database.

105

National Motor Vehicle Title Information System (NMVTIS)

Effective March 31, 2009, insurers are required to report vehicle total loss claims to NMVTIS. In order to comply with the NMVTIS final rule, we are providing the guidelines below for Universal Format submissions. ISO will report claims to NMVTIS on a daily basis. Claims will be sent 30 days after we receive the claim with a total loss indicator present on the <InvestigationInfo> (see Facts about NMVTIS Reporting below). Vehicles for the current model year and 4 prior years will be reported (i.e., in 2012, all vehicles from 2012 and going back to 2008 will be reported). Automobiles are defined as 4 wheels under 10,000 lbs. Companies may choose to opt-out of this service. However, in doing so, they are required to meet the statutory requirements through other means. ISO ClaimSearch recommends a review of this choice by the member company’s own legal advisors. If the determination is made to opt-out, please contact [email protected] to ask for an official request form. NMVTIS REQUIRED FIELDS: 1. Vehicle Identification Number of the total-loss automobile (AutoLossInfo/ VehInfo/ VehIdentificationNumber) 2. The date on which the automobile was obtained or designated as a junk or salvage automobile. ISO will report the

date that we receive the Vehicle Disposition (InvestigationInfo/ VehDispositionCd– requires codelistref) as “T” per our system tables.

3. The name of the individual or entity from whom the automobile was obtained (owner name or lien holder name and who possessed the automobile when it was designated a junk or salvage automobile). This name will be taken from the ClaimsParty record referenced by the AutoLossInfo marked as a Total Loss in the corresponding InvestigationInfo.

4. The name of the owner of the automobile at the time of the filing of the report with NMVTIS. This may be the owner, the insurance company, or a 3rd party salvage buyer. (See descriptions below for what is required in each of these cases.)

ISO ClaimSearch Requirements for NMVTIS Reporting The submission of an NMVTIS claim follows ISO ClaimSearch basic service rules. This includes Policy and ClaimsOccurrence aggregates for the Universal Common Elements, a ClaimsParty aggregate for each Involved Party to the loss, and at least one AutoLossInfo referring to the ClaimsParty aggregate of the individual or entity from whom the automobile was obtained. An InvestigationInfo/ SalvageInfo aggregate may also be required depending on who is the owner at the time of NMVTIS reporting. ISO REQUIRED FIELDS: Parties to loss (Insured, Claimant, Owner) Policy, Coverage, and Loss Types VIN (must pass validation edit and/or check digit) Total Loss Indicator Owner Retaining Salvage NMVTIS Required Fields (see Sample File – 1st Party Auto Salvage NMVTIS.xml) ClaimsParty aggregate for each involved party. This may include at least one for the insured and one for the claimant,

OR a single record for a claimant/insured. AutoLossInfo/ VehInfo/ VehIdentificationNumber must contain a valid VIN. (ISO is required in its consolidator function

to validate this information before sending it.) InvestigationInfo referencing the AutoLossInfo in #2 above.

VehDispositionCd MUST HAVE A CODELISTREF and must be set to T for Total Loss. NOTE – This is the trigger for ISO to identify a record that should be submitted to NMVTIS.

SalvageInfo/ OwnerRetainingSalvageInd must be set to “1” to show owner is retaining salvage.

3rd Party Salvage Buyer NMVTIS Required Fields (see Sample File – 3rd Party Auto Salvage NMVTIS.xml) The same as the Owner Retaining Salvage above EXCEPT SalvageInfo/ OwnerRetainingSalvageInd must be set to “0,” the SalvageInfo @BuyerRef should reference a ClaimsParty with the Salvage Buyer’s name and a ClaimsPartyRoleCd of “SalvageBuyer” (no codelistref). No <ClaimsPartyRelationship> aggregate is required. Insurance Company Owner NMVTIS Required Fields (see Sample File – Ins Co Auto Salvage NMVTIS.xml) The same as the Owner Retaining Salvage above, EXCEPT SalvageInfo IS NOT SENT in this case. If the Vehicle Disposition Field is set to T and no SalvageInfo is present, ISO will send the Insurance Company information to NMVTIS by default. The information is derived from the AgencyId submitted.


106

Programming Notes If you want to report the owner of the vehicle as neither an insured nor claimant you may submit a ClaimsParty with a ClaimsPartyRoleCd set to a role of OW referenced by the total loss AutoLossInfo. This role is in addition to the insured and claimant roles you must submit for the ISO ClaimSearch basic service. If you choose to submit an OW role, then the vehicle information will not be searched in the ClaimSearch database. To have the vehicle information searched you would need to submit a separate AutoLossInfo (without the VehDispositionCd set to T) referencing one of the other ClaimsParty aggregates with a searchable role type. ISO recognizes that some states include unrecovered theft as a total loss. For NMVTIS, we will not look at total theft. To ensure ISO sends a claim to NMVTIS, add total theft (THFT) as a loss type, with comprehensive (COMP) as coverage, but set the Theft Type Indicator (InvestigationInfo/ com.iso_TheftTypeInd) to “T” for total theft and the Vehicle Disposition (InvestigationInfo/ VehDispositionCd) to “T” for total loss. It is recommended that for Total Losses occurring as part of a General Liability claim, the vehicle loss should be reported as a CAPP, commercial auto policy type. NMVTIS may accept claims for vehicles which fail the overall VIN check, but the Check Digit value is correct, if all other reporting criteria are correct. To this end, ISO has now added a new indicator <com.iso_NMVTISCheckInd> that will display if the VIN meets this criterion. This indicator will display an “E” on the Response file or “VIN passed check digit” on the stylesheets. NMVTIS Options ISO ClaimSearch provides this service as part of our basic Auto layer. All insurers are automatically enrolled to send all required fields. However, you may choose to report only required fields, report required and optional fields, or to opt out of this service. If you choose to report only the required types, we will identify these by the Vehicle Type <VehTypeCd> in the VehInfo aggregate. The valid types are Light Truck (LT), Multi-Purpose (MP), Passenger Car (PC) and Truck (TK), or if the field is left blank. All other types will not be reported for companies who choose to report only the required vehicle types. If the Vehicle Make <ManufacturerCd>, Vehicle Model <ModelCd>, Vehicle Year <ModelYear>, Vehicle Style <VehBodyTypeCd>, Odometer Reading <OdometerReading>, and Cause of Loss <LossTypeCd> are present, they will be reported to NMVTIS as optional fields. Facts about ISO NMVTIS reporting The reporting requirements apply to insurers; self-insurers are not included in the legislation. Claims submitted by TPAs must be reported with the carrier’s ClaimSearch reporting code to be reported to NMVTIS. An Insurer Operator code assigned by ISO for NMVTIS purposes will identify each insurer for reporting. This will be assigned and maintained by ISO and will not have to be passed by insurers on the individual claims. ISO will report claims to NMVTIS on a daily basis. Claims will be sent 30 days after we receive the claim with a total loss indicator present on the InvestigationInfo aggregate. Reports will include all applicable vehicles for 30 days prior. This means on April 1st we would report March 1st reported total losses, April 2nd we would report March 2nd and so on. This provides users the opportunity to remove the total loss indicator if the vehicle is subsequently determined to not be a total loss. SALVAGE REPORTING Salvage companies (salvage pools, salvage yards, junk yards, crushers, etc.) are to report all salvage disposition under a salvage company code and operator code. The reporting of salvage after sale of salvage under current salvage procedure will not satisfy total loss reporting requirements. A separate layout is used by salvage companies.

107

Optional Additional Services

Append-DSSM

Append-DSSM is an optional service specially designed for members reporting claims system-to-system. Including a claimant’s Social Security Number (SSN) in search criteria on a claim can significantly increase the effectiveness of system searches and the amount of information returned for claim evaluation. Through the standard Append-DS service, if a claimant is reported without an SSN on an initial claim, Append-DS automatically triggers a public records search to find this key data. When available, the SSN is then used to enhance ClaimSearch database searches for matching claims. In addition to SSN’s, Append-DS will also retrieve other public record details available on the claimant, including the claimant’s current and previous addresses (up to four), phone number, age, and date of birth – and add that information to the Search Result report as well. This will cause SSN to show as a Reason for Match even if no SSN was submitted on the claim. NOTE – the SSN and other public records information is NOT automatically added to the claim information stored on our database. The Public Records Information is returned in the <com.iso_AppendDS> aggregate, so that the member’s claim system can be updated with the additional information. Users have the option of adding the Append-DS information to claim reports in the ISO ClaimSearch database by submitting a Replacement or Update with the additional information. Append-DS is designed to help members: streamline the claims-processing workflow and increase productivity; save time in searching for and retrieving public-records data; and access all available information from ISO ClaimSearch to help facilitate claims processing decisions and reduce claim losses. File Organization The Append-DS aggregate <com.iso_AppendDS> illustrates the layout for public records data returned on a claimant when an SSN missing on a claim is found in public records. It will be returned within the ClaimsParty aggregate that was searched. This aggregate may be repeated up to 10 times showing previous names, addresses, and phone information. Match File Hierarchy <ClaimInvestigationAddRs> … <Policy>…</Policy> <ClaimsOccurrence> <ClaimsParty> (insured)…</ClaimsParty> <ClaimsParty> (claimant) <GeneralPartyInfo>…</GeneralPartyInfo <PersonInfo>…</PersonInfo> <ClaimsInjuredInfo>…<ClaimsInjuredInfo> <com.iso_AppendDS>…</com.iso_AppendDS> </ClaimsParty> … <MatchReportTypeCd>…</MatchReportTypeCd>

108

Service Information Append-DS is an optional service and is available at an additional cost. To participate in this service, members must sign an Append-DS Product Supplement to the ClaimSearch agreement. Members can choose from the following service options for Append-DS: Append-DS Service Descriptions Standard Service: Claimants w/o SSNs on all Initial claims (Property, Casualty & Auto coverage) Customized Screening Options Option 1: Claimants without SSNs on all Initial and Replacement claims (Property, Casualty & Auto coverage) Option 2: Initial Casualty claims only (claimants w/o SSNs) Option 3: Initial Casualty claims only (claimants & insured parties w/o SSNs) Option 4: Initial & Replacement Casualty claims (claimants w/o SSNs) Option 5: Initial & Replacement Casualty claims (claimants & insured parties w/o SSNs) Option 6: Claimants w/o SSNs on all Initial claims (Auto coverage) Option 7: Claimants w/o SSNs on all Initial & Replacement claims (Auto coverage) Option 8: Claimants and Insured parties w/o SSNs on all Initial claims (Auto coverage) Option 9: Claimants and Insured parties w/o SSNs on all Initial & Replacement claims (Auto coverage) Further details on this service may be obtained by contacting your ISO ClaimSearch Account Representative.

109

Child Support Enforcement Agency (CSLN/OCSE) Reporting

The ISO Child Support Enforcement Agency Program (CSEA) cooperates with the Child Support Lien Network (CSLN) and Office of Child Support Enforcement (OCSE) in identifying delinquent child support obligors who have filed insurance claims. The CSEA program allows claims in the ISO ClaimSearch system to be matched against both the CSLN database and the OCSE database to support enforcement of child support obligations. Insurers, self-insurers, and third-party administrators can participate in the CSEA program on an individual state or “all states” basis for CSLN, OCSE, or both. When your company participates in the CSEA program in one or more states, currently claimants with bodily injury claims submitted to ISO ClaimSearch by participating companies are checked against the database of delinquent obligors maintained by CSLN and/or OCSE. If there is a match, the system will send the claim to CSLN or OCSE per member participation. If the claim qualifies, CSLN or OCSE will refer the claim to the appropriate state child support enforcement agency. That agency may, at its discretion, place a lien on the settlement of the claim. (No information on CSEA matches is returned directly to the insurer from the ClaimSearch database.) Because of some differences in the states participating in the OCSE and CSLN services and information that each maintains, it may benefit your organization to participate in both services in order to get the most comprehensive information about individuals who fail to pay court-ordered child support. Service Information There is no additional charge for the CSEA (CSLN/OCSE) service. To participate in this service, members must sign a CSEA Product Supplement to the ISO ClaimSearch agreement. To sign up for any of the CSEA (CSLN/OCSE) program services, please contact ISO ClaimSearch Customer Support at 1-800-888-4476 or send e-mail to [email protected]. File Organization If your company is an Insurer, Self-Insured, or a Third-Party Administrator reporting under the Insured’s Membership

code, there is no additional programming necessary. If your company is a Third-Party Administrator reporting under the TPA Membership code, you must indicate each

party to be searched against the CSLN/OCSE databases by populating each <com.iso_CSLNInd> with: “Y” for each ClaimsParty to be searched against the CSLN database “O” for each ClaimsParty to be searched against the OCSE database “B” for each ClaimsParty to be searched against both the CSLN and OCSE database.

For the mandatory states in participation with CSLN, no indicator is needed for the claim to be searched against the

CSLN database. The mandatory states currently are: NJ, OK, PA, RI, and TX.

110

ClaimDirectorSM

Introduction ClaimDirector delivers fast, automated, and intuitive detection of questionable claims. This solution enables automated alert creation to assist with straight through processing to get the claims to the appropriate resources. ClaimDirector leverages 1.5 billion industry-wide claims reported by 95 percent of the P&C industry, as well as NICB Alerts1 and other third-party data to create robust questionable claim loss detection scenarios. ClaimDirector’s advanced analytics produce propensity scoring based on the data for parties, vehicles, addresses, locations, phone numbers, and a host of other identifying data. The solution includes hundreds of customizable business rules, real-time SIU triage capabilities, business intelligence reporting, and create loss scenarios leveraging over. ClaimDirector Score ClaimDirector will generate a numeric score that will range from 0 – 999 based on match report information found in the system. ClaimDirector delivers the score in the Claims Scoring Information aggregate <com.iso_ClaimsScoringInfo> and a result report in the Claims Score Report aggregate <com.iso_ClaimScoreReport>. The result report will provide the company with the basis of the score (e.g., number and type of matches). High scores may indicate a significant number of matches were found in the database and/or the presence of other characteristics that suggest a heightened consideration of the need for further investigation. ClaimDirector currently scores Personal Auto Liability, Commercial Auto Liability, Auto Physical Damage, General Liability, Workers’ Compensation, and Homeowners claims. Future enhancements include the ability to score Disability claims. ClaimDirector scores will be based on matching claims that are within 5 years of the date of the ISO ClaimSearch submission with the exception of Workers’ Comp and VIN matches which will not be restricted by date. ClaimDirector will deliver up to 25 detailed score summaries where output is created. This will allow the system to provide the necessary detailed reports needed by carriers when additional investigation is required. ClaimDirector generates scores when Initial or Replacement Requests are submitted. ClaimDirector does NOT score on Update Requests or Research Requests. Searches ClaimDirector searches for claimants and insureds with coverage like ISO ClaimSearch Basic Service. It also searches on insureds without coverage for prior automobile, casualty & property claims, based on the name and address, SSN, VIN, driver’s license number, license plate number, and phone number. ClaimDirector also provides the number of searchable elements the claim was searched on (maximum 6). In other words, if all searchable elements are provided, the system will find all claims matched in the database. If some searchable elements are missing, some matches could also be missed. Customization Options In order to better meet your needs, ClaimDirector is designed to be highly customizable. The ClaimDirector Customizer, a web-based tool available via the ISO ClaimSearch portal, provides the ability to modify ClaimDirector settings, including adjusting rule thresholds and maintaining carrier-specific advisory lists. Settings in the Customizer also control what rule information is populated into third-party claims systems such as Guidewire. Administrative access to the Customizer is limited to several key decision makers within your organization. Any changes made by your company will affect all its scoring results for future claims. Service Information ClaimDirector is an optional service and is available at an additional cost. To participate in this service, members must sign a ClaimDirector Product Supplement to the ClaimSearch agreement. Please contact your ISO ClaimSearch Account Representative for further information on this service. If you do not know your Account Representative, please contact ISO ClaimSearch at 1-800-888-4476.

111

File Organization Request File ClaimDirector requires the same basic claim structure and required fields as ISO ClaimSearch Basic XML Requests. Any claim with a ClaimsInjuredInfo, an AutoLossInfo, and/or Investigation Information/Salvage Information Aggregate may be submitted as a ClaimDirector claim. All eligible Initial and Replacements will be scored upon receipt to our system. If the desire is not to score every claim, please advise your ISO ClaimSearch Testing Representative. You will then need to indicate that the claim being submitted is a ClaimDirector claim, the ClaimDirector <com.iso_ClaimDirectorInd> must be populated with a “1.” In addition to the fields required to submit a claim, optional fields should be provided in order to enhance the scores. Please refer to XML Customer Package/ Programming Documentation/ Other Important Info/ ClaimDirector Important Optional Fields.xls for a list of fields important when submitting ClaimDirector claims. Note: When receiving a ClaimDirector claim, the system will check the Key Fields <PolicyNumber>, <AgencyId>, <InsurerId>, and <LossDt> to see if this claim has already been reported. If the claim was previously reported (not through ClaimDirector), the member cannot submit an Initial ClaimDirector claim; it will reject as a duplicate. A ClaimDirector Replacement claim may be used for a previously reported XML Format claim. <ClaimInvestigationAddRq> … <Policy>……</Policy> <ClaimsOccurrence>…</ClaimsOccurrence> <com.iso_ClaimDirectorInd>1</com.iso_ClaimDirectorInd> </ClaimInvestigationAddRq> Response File (Asynchronous Match Report) If the ClaimDirector Indicator <com.iso_ClaimDirectorInd> is set to “1” on the input, the ClaimDirector Indicator and the Claims Scoring Information aggregates will be returned in your March Report. Within the Claim Scoring Information aggregate, the Claims Handling Characteristics, ClaimDirector Rules, and Claims Score Report aggregates are returned per the member’s Customization Options. Each of these three aggregates may be repeated multiple times. The Match Report will contain a score at the Claim level, in the initial claim.

<ClaimInvestigationAddRs> <RqUID>…</RqUID> <TransactionRequestDt>…</TransactionRequestDt> <CurCd>…</CurCd> <CodeList>……. </CodeList> <MsgStatus>…… </MsgStatus> <Policy>……</Policy> ….. <MatchReportTypeCd>…. </MatchReportTypeCd> <com.iso_ClaimDirectorInd>1</com.iso_ClaimDirectorInd> <com.iso_ClaimsScoringInfo> …. <com.iso_ClaimsHandlingCharacteristics>.... </com.iso_ClaimsHandlingCharacteristics> <com.iso_ClaimDirectorRules>.... </com.iso_ClaimDirectorRules> <com.iso_ClaimsScoreReport>.... </com.iso_ClaimScoreReport> </com.iso_ClaimsScoringInfo> <MatchInfo>… </MatchInfo> <MatchDetails> … </MatchDetails> …. </ClaimInvestigationAddRs>

Conde, Rafael

Companies no longer have to do this unless they do not want to score all of their claims or want to score only specific claims. The MM switch is all or none. It will score every eligible Initial or Replacement claim. Wordsmith however you feel fit.

112

Marine Index Bureau Claims

The Marine Index Bureau has served the US marine industry since 1937 as the central clearinghouse of bodily injury claims by maritime-industry personnel. The Marine Index Bureau has also been the industry’s repository on hull and machinery-loss information for commercial fishing vessels. ISO ClaimSearch has incorporated into its system the data formerly administered and maintained by the Marine Index Bureau. Members of the Marine Index Bureau will have the ability to add marine claims and obtain crossline searches including marine and casualty losses. Claims submitted to the Marine Index Bureau involve Longshore, Harborworkers & Jones Act as well as Protection & Indemnity (P&I) claims. Marine claims are most often associated with liability claims (P&I) or Workers’ Compensation. For reporting marine casualty claims in Universal Format, use policy types: COMR Commercial Ocean Marine for liability claims WCMA Workers’ Compensation Marine for Longshore & Harborworkers’ claims Coverage types and loss types are the same as other liability or WC claims. Although ClaimSearch Casualty fields of information are generally sufficient, there are a few fields that are specific to marine claims: Vessel /Call Number: Vessel information may be considered the location of loss for accidents that occur while the

ship is at sea. For cases involving losses off the vessel, for dockworkers, or other personnel associated with marine industry, but not actually on the ship, an actual location of loss is required. Selection of either vessel or location of loss is required. (ClaimInvestigationAddRq/WorkCompLossInfo/ VesselCallId>

8F Claims: 8F is a section of the Federal Longshore & Harborworkers Act that provides reimbursement for similar

previous injuries against a current injury involving Marine industry personnel. The 8F claim field is a Y/N field and is optional. (ClaimInvestigationAddRq/WorkCompLossInfo/SecondInjuryFundInd)

Passport Number: Passport Number of claimant regardless of issuing country.

(ClaimInvestigationAddRq/ClaimsParty/GeneralPartyInfo/NameInfo/NonTaxIdentity) Occupation/Rating: Rating has been added to the occupation field to identify marine employees.

(ClaimInvestigationAddRq/ClaimsParty/PersonInfo/OccupationDesc) NOTE: WCMA (Workers’ Compensation Marine for Longshore & Harborworkers’ claims) are searched against the entire ClaimSearch database. Searches are not limited to five years.

113

Medicaid Reporting Service (MAIS)

ISO ClaimSearch developed the ISO ClaimSearch Medicaid Reporting Service in 2012 in response to the Medicaid reporting and verification requirements in Rhode Island. The Rhode Island Executive Office of Health and Human Services (RI EOHHS) passed Article 11 as part of Title 27, chapter 57.1 — the Medical Assistance Intercept Act. Article 11 requires all insurers that write workers compensation or liability policies in Rhode Island to participate in a data match program called the Medical Assistance Intercept System (MAIS). MAIS recovers and intercepts Medicaid payments issued on behalf of Medicaid recipients if an insurer pays on a claim.

Insurers, self-insurers, and third-party administrators can participate in the Medicaid Reporting Service on an individual state-by-state basis or through automatic enrollment as additional states allow ISO’s solution to fulfill regulatory reporting requirements.

When a member company is participating in the Medicaid Reporting Service, casualty claims reported to ISO ClaimSearch are checked against the database of Medicaid recipients maintained by MAIS. If there is a match, the system will send the claim to MAIS per member participation. Information on Medicaid matches is not returned directly to the insurer from ISO ClaimSearch.

There are no additional programming changes for ClaimSearch members to participate in this data match program . The system will conduct searches of claimants against Rhode Island’s Medicaid Assistance Intercept System (MAIS) database using name and address, name and date of birth, and Social Security number.

The service will send matching claims to MAIS to verify that:

• the claimant is a Rhode Island Medicaid beneficiary with an open bodily injury claim against the insurer • Rhode Island Medicaid has made payments related to the accident • the Medicaid payments are related to the injury in the claim Once MAIS verifies that the claimant is a Medicaid recipient, MAIS will either issue a “lien” or “no lien” document. If MAIS determines that medical payments have been made in relation to a claim, then the initial document will be a lien notice with the lien amount. Both the lien and no lien document are good for 30 days. After expiration, the insurer or attorney can request an updated document.

Service Information: There is no additional charge for ClaimSearch members to participate in the Medicaid Reporting Service. To participate in this service, members must sign a Medicaid Reporting Service Product Supplement to the ISO ClaimSearch agreement. For interested participants to sign up for the service, please contact ISO ClaimSearch Customer Support at 1-800-888-4476 or send an e-mail to [email protected].


114

Medicare Secondary Payer Reporting Service (CMS)

Summary The ISO ClaimSearch Medicare Secondary Payer Reporting Service will help insurers comply with mandatory claim reporting requirements of Section 111 of the Medicare, Medicaid, and SCHIP Extension Act of 2007. The legislation could affect most bodily injury settlements that involve an insurance carrier or self-insurer and a Medicare-eligible claimant/plaintiff. Section 111 of the Act adds new mandatory reporting requirements for all Responsible Reporting Entities (RRE), group health plan arrangements, property casualty and workers compensation insurers, and self-insureds. The legislation requires reporting of bodily injury claims files by Medicare-eligible claimants to the U.S. Department of Health and Human Services Center for Medicare & Medicaid Services (CMS). Service Overview ISO ClaimSearch, in coordination with insurers and the insurance trade associations, worked with CMS to design a comprehensive Medicare Secondary Payer Reporting Service. The service will report Medicare-eligible claimants to CMS and report additional data elements to ISO ClaimSearch as required by CMS. The addition of the new data elements (more than 100 distinct fields) required by CMS will require some programming changes for system-to-system companies. ISO ClaimSearch also offers a web reporting option for companies that can’t capture the additional fields in their systems or don’t have the necessary programming resources for the system changes. The ISO ClaimSearch website contains all of the data fields CMS requires, and companies will see an indicator next to the CMS-Required fields. Benefits of the Service The ISO ClaimSearch Medicare Secondary Payer Reporting Service solution is integrated with the ISO ClaimSearch claim reporting process. By reporting through ISO ClaimSearch, companies will realize significant savings and workflow process efficiencies of adding to an existing process. The ISO ClaimSearch Medicare Secondary Payer Reporting Service offers: Help in identifying Medicare-eligible individuals through an optional monthly query function Timely quarterly reporting to CMS A process for notifying members of the claims CMS rejects and acknowledgements A process for correcting CMS rejections Timely warnings when claims with Medicare-eligible claimants are missing CMS-Required fields. Determining Medicare Eligibility through Monthly Query To help companies identify Medicare-eligible claimants, ISO will provide an optional query of the CMS database for each participating RRE. Using CMS software, the ISO ClaimSearch system will query your company’s entire history of claims that qualify for CMS reporting against the database every month. Note: All claims must contain the claimant’s name, Social Security Number (SSN) or Health Insurance Claim Number (HICN) or Medicare Beneficiary Identifier (MBI), date of birth, gender, and RRE code (if the group/company/office has more than one RRE code). ISO will post the positive results of the query to the Account Management section of the ISO ClaimSearch website so users can log in to check the Medicare-eligibility of claimants. The system will provide that information in a text file format (to be determined) as well as a Microsoft Excel spreadsheet. It is each company’s responsibility to update claims with the Medicare-eligible indicator to show which claims ISO ClaimSearch should send to CMS. ISO will also provide a supplemental query file containing data from the CMS PAID Act.

115

Quarterly Claim Reporting Companies will be able to report and update claims using either system-to-system connections to ISO ClaimSearch or the ISO ClaimSearch web reporting application. Members will need to complete additional fields of information required by CMS including an indicator to notify ISO of the Medicare-eligible claimants. ISO ClaimSearch will automatically forward any Medicare-eligible claimants to CMS on a quarterly basis. The quarterly reports will include the following: Ongoing Responsibility for Medicals (ORM), including no-fault and workers compensation; and Total Payment Obligation to the Claimant (TPOC) for all third-party liability cases resulting in “a single settlement, judgment, award, or other payment”. ISO ClaimSearch will determine when to include claims in the quarterly report to CMS as follows: Ongoing no-fault insurance and non-contested workers compensation claims (ORM) When your company first submits a claim with a Medicare-eligible indicator, ISO ClaimSearch will send the claim to

CMS. When your company updates any fields that CMS designates as “important,” ISO ClaimSearch will send the claim to

CMS again as an update. When your company provides the ORM (Ongoing Responsibility for Medicals) date, ISO ClaimSearch will send a final

claim to CMS. Single payment liability claims (TPOC) When your company marks the claim as Medicare-eligible and provides the TPOC (Total Payment Obligation to the

Claimant) date, ISO ClaimSearch will report the claim to CMS. When your company updates any fields that CMS designates as “important,” ISO ClaimSearch will send the claim to

CMS again as an update. Acknowledgement and Rejection Service CMS will provide ISO with a file showing the claims that CMS accepted and rejected. ISO will post the results of that file in the Reports section of the ISO ClaimSearch website so users can log in to see the accepted and rejected claims. ISO will also post the information in a Text file and Microsoft Excel spreadsheet for download. ISO will link the acknowledgements and rejections to existing claims in ISO ClaimSearch to help companies locate their claims in the database. Users can update and resubmit the rejected claims to ISO ClaimSearch. The system will resubmit the corrected claim to CMS during the next quarterly reporting period. Screening Service for Missing Data – Warning Indicators When companies mark claimants as Medicare-eligible and send a claim to ISO ClaimSearch, the system will screen the claims to identify missing CMS-Required fields. If fields are missing, ISO ClaimSearch will provide a warning indicator on the outgoing ISO ClaimSearch Response and/or as an alert in visualized ClaimSearch when the company first marks the claim as Medicare-eligible and when the company sends Replacements. Warnings are not provided on Update requests or requests marked with the <SuppressMatchInd> on the ClaimInvestigationAddRq because these Requests do not produce Response. The screening service includes rules for reporting contingent fields. For example, information on the claim representative isn’t required. However, if your company reports a representative, the name, address, and phone number are required. CMS Warning Indicators DO NOT prevent the claim from being reported to CMS in the quarterly reporting file. They are for informational purposes only and provide your company the chance to update the claim before the next scheduled CMS quarterly submission period. Service Information Medicare Secondary Payer Reporting Service (CMS) is an optional service and is available at an additional cost. To participate in this service, members must sign a CMS Product Supplement to the ClaimSearch Agreement. They must also submit claims using the ISO ClaimSearch Universal Format or the XML Format. Please contact your ISO ClaimSearch Account Representative for further information on this service. If you do not know your Account Representative, please contact ISO ClaimSearch at 1-800-888-4476 or [email protected].


Saad, Sandra A

Unless you have something stating otherwise?

Saad, Sandra A

What do you mean by this?

116

OFAC Compliance Solutions

The Office of Foreign Assets Control (OFAC) of the U.S. Department of Treasury administers and enforces economic and trade sanctions against certain foreign governments, organizations, and individuals. OFAC has compiled a master list of more than 5,000 “specially designated nationals and blocked persons.” U.S. insurance companies and their employees are responsible for screening claims against this master list. OFAC COMPLIANCE SOLUTIONS ISO currently offers several of OFAC service. The OFAC Lookup is provided as part of the ClaimSearch agreement at no additional charge. To participate in any of the other services below, members must sign an OFAC Product Supplement to the ClaimSearch agreement. Each service details whether the service is provided as part of the standard agreement or at an additional charge. OFAC Lookup This is a web-based search tool available on the ISO ClaimSearch website (https://claimsearch.iso.com). Members can search individual names in one-off searches in order to comply with legal requirements of the U.S. Treasury Department’s Office of Foreign Assets Control (OFAC). It also ensures that an organization does not pay out money to a person or organization involved in terrorism, international

narcotics trafficking, or activities related to the proliferation of weapons of mass destruction catches any individual or organization on the OFAC list early in the life of a claim to permit follow up with appropriate

due diligence research Results of the Lookup are returned in an OFAC Match Report on the website. If there is a match, scores are assigned to indicate the degree of validity. (For example, if the first and last name you enter matches the first and last name on the OFAC list exactly, the score would be 100. If the first name you entered was spelled differently than the listing, but the last name you entered was the same as on the list, you may get a score of 90.) Additional information is also provided in the report such as Associated Names, Date of Birth (DOB), Alternate Date(s) of Birth, Place of Birth (POB), Alternate Place(s) of Birth, etc., to assist in due diligence that the information you are querying on is, in fact, the same individual or organization. Standard OFAC Service ISO’s standard OFAC solution is an optional feature of the ISO ClaimSearch system. There are no additional fields or records that need to be programmed for the OFAC standard service. By signing the Product Supplement, all parties to a claim (insured, claimant and service providers) submitted to the ISO ClaimSearch database are automatically screened against the OFAC Specially Designated Nationals List. Should a match occur, contact person(s) specified in advance are notified by e-mail and directed to the secure ISO ClaimSearch website to view match results. ISO employs a special search algorithm when screening for OFAC matches. It is designed to recognize inverted letters, phonetic and cultural equivalents, and even misspellings. (For example, the submitted name of “Osama Ben Ladin” would trigger a match to the name “Osama Bin Laden.”) There is no additional charge and no additional programming for this service. Premium OFAC Service The Premium OFAC Service is identical to the Standard Service with one exception. A match to the OFAC Specially Designated Nationals List triggers a public records search on the matching name. Public record details are returned online with the OFAC Report; and are of particular value when reviewing information on some of the more common names found in OFAC. There is a charge for Premium Service and members must sign an OFAC Product Supplement. There is no additional programming for this service.

https://claimsearch.iso.com/

117

OFAC Historical Sweep ISO also offers an historical sweep of claims that members have previously submitted to the ISO ClaimSearch database over a specified period of time. Claims are searched in batch with matches displayed in a secure segment of the ISO ClaimSearch website. A designated contact person is notified of matches via e-mail, with a link provided to the secure ISO ClaimSearch website to view results. There is a charge for OFAC Historical Sweep and members must sign an OFAC Product Supplement. There is no additional programming for this service. OFAC Enterprisewide Solution ISO provides an enterprise wide OFAC solution that allows members to submit via FTP an electronic file of individual and business names they want screened against the OFAC List. Files are processed overnight and returned via FTP. Submissions are not limited to claims but may also include policyholders, vendors, marketing lists, job applicants and other entities. There is a charge for OFAC Enterprisewide Solution and members must sign an OFAC Product Supplement. OFAC Enterprisewide has its own file format for the submission of names. Please contact your ISO ClaimSearch Account Representative for further information on this service. If you do not know your Account Representative, please contact ISO ClaimSearch at 1-800-888-4476 or [email protected].


118

Additional Services Aggregates The aggregates that follow are used by the Additional (Standard and Optional) Services listed above. The description of each confirms to which service each applies.

Append-DS Aggregate <com.iso_AppendDS>

This aggregate is optional and will only be returned if your company is signed up for the Append-DS Optional Service. Tag Type Usage Length Description

<ADSResponseCd> CodeList Required C-2 This element uses the ADSResponseCd code list.

<GeneralPartyInfo> Aggregate Required

<PersonInfo> Aggregate Required

ClaimDirector Rules Aggregate <com.iso_ClaimDirectorRules>

This aggregate is optional and will only be returned if your company is signed up for the ClaimDirector Optional Service. Tag Type Usage Length Description

<com.iso_RuleCd> Element Extension Required C-4 Rule Number (provided by ISO ClaimSearch)

<com.iso_RuleTypeCd> Element Extension Required C-1 S=Single, C=Combo

<com.iso_RuleWeight> Element Extension Required C-4 Three-digit number and sign if a negative number (ex: -050)

<com.iso_RuleDesc> Element Extension Required C-475 Text Description

<com.iso_RuleWeight> Element Extension Required C-4 Three-digit number and sign if a negative number (ex: -050)

<com.iso_RuleDesc> Element Extension Required C-475 Text Description

Claims Handling Characteristics Aggregate <com.iso_ClaimsHandlingCharacteristics>


<com.iso_CharacteristicCd> Code List Required C-4 Please contact ISO ClaimSearch for a current list of IDs.

<com.iso_CharacteristicText> Element Extension Required C-475 Text of the Claim Handling Characteristic

Claims Party Scored Match Aggregate <com.iso_ScoredMatch>

This aggregate contains detailed information on a scored match for the ClaimDirector Optional Service. Tag Type Usage Length Description

<com.iso_MatchScoreRank> Element Extension Required C-2 Places ClaimDirector Scored Matches in order of score

<AgencyId> Aggregate Required C-11 AgencyId used indicate ISO File Number of this claim

<LossDt> Date Required C-10 The Date of Loss of the match YYYY-MM-DD

<CoverageCd> Code List Required C-4 See CoverageCd code list and Appendix B

<LossCauseCd> Code List Required C-4 See LossTypeCd code list and Appendix B

<com.iso_MatchScore> Element Extension Required C-3 Score.

119

Claims Score Report Aggregate <com.iso_ClaimScoreReport>


<com.iso_RawScore> Element Extension Required C-3 Raw score for this claims party.

<com.iso_AdjustedScore> Element Extension Required C-3 Adjusted score for this claims party that contributed to the total ClaimDirector Score

<NumMatches> Element Extension Required C-2 Number of matching claims

<com.iso_SearchableElementCd> Code List Required Repeating

This element may display up to 6 times – once for each searchable element that was provided on input. Please refer to the SearchableElementCd code list for all elements that may be searched.

<com.iso_ScoredMatch> Aggregate Extension Required Repeating

Max is 15. If more than 15 matches, an additional 10 matches may be displayed on a second Claim Sore Report Aggregate. Matches with highest scores are displayed first.

Claims Scoring Information Aggregate <com.iso_ClaimsScoringInfo>

The required fields below will be returned if the <com.iso_ClaimDirectorInd> is set to 1 on input. The optional fields will only be returned if your company is signed up for the ClaimDirector Optional Service.


<com.iso_ClaimDirectorScore> Element Extension Required C-3 ClaimDirector Score (000-999).

<com.iso_CharacteristicsFoundInd> Boolean Extension Required C-1 Y=Characteristics have been found in the claim

<com.iso_ExceededLifeofClaimInd> Boolean Extension Required C-1 Y=Claim was not scored because ClaimDirector life of claim exceeded. . Each claim may only be scored up to 6 times during the life of the claim.

<com.iso_EmailSentInd> Boolean Extension Required C-1 Y=ClaimDirector e-mail notification was sent on this submission or any other previous submission of this claim

<com.iso_NumberTimesScored> Element Extension Required C-2 Indicates the number of times a claim was scored

<com.iso_ClaimsHandlingCharacteristics> Aggregate Extension Optional Repeating

<com.iso_ClaimDirectorRules> Aggregate Extension Optional Repeating

<com.iso_ClaimsScoreReport> Aggregate Extension Optional Repeating

Max is 2. This aggregate provides the details of the first 15 matches which were included in the score. If more than 15 matches, this record will be repeated with up to an additional 10 matches. The highest scores are sent first.

120

AGGREGATES FOR CMS SERVICE Although the Medicare Secondary Payer Reporting (CMS) Service is an optional service, many of the elements, or the aggregates that the elements are included on, can be used for regular ISO ClaimSearch reporting as well. Therefore, we have chosen to include these in the listings for the core ISO ClaimSearch aggregates. Please see the ClaimsOccurrence, ClaimsParty, ClaimsParty Relationship, com.iso_AddCovInfo, com.iso_CovInfo1, com.iso_CovInfo2, and com.iso_SIUParty in the core ISO ClaimSearch aggregates as well as the com.iso_CMS aggregate below for “CMS specific” reporting elements. Please review all other aggregates for elements that are necessary for both ISO ClaimSearch and CMS reporting.

CMS Warning Aggregate <com.iso_CMS>

This aggregate is a RESPONSE ONLY aggregate and contains the Warning Messages for CMS Fields. ClaimSearch provides the warning for missing CMS required fields. If a field is invalid based on ClaimSearch requirements (such as missing or invalid data or missing XML references like AssignmentRef, idref, ItemRef, etc.), we will blank out the field. ClaimSearch is not validating fields based on CMS edits. The warnings are just to provide you with information on missing CMS required fields; it is not a guarantee that CMS will accept your claim once these fields are provided. NOTE - Warnings are only provided on Searchable claims. If a claim is marked with the <SuppressMatchInd> on the <ClaimInvestigationAddRq>, no warning will be sent. Likewise, for Update Requests using <com.iso_UpdateInd> 1, 2, 3, 5, or 6, which don’t provide a Successful Response, no Warnings will be provided.




<com.iso_CMSWarning> Code List Required Repeating

Max 70 Required CMS Fields Missing or Invalid. See Appendix A – CMSWarningCd

121

ANSWERS TO FREQUENTLY ASKED QUESTIONS

Included in this section are answers to frequently asked questions or important information that is sometimes missed or not considered during the development stages. Every claim must contain a role of CI or IN. Every claim must have at least one coverage record. A coverage record

is a ClaimsInjuredInfo, PropertyLossInfo, or AutoLossInfo Aggregate. • A coverage record is required for these roles: CD, CE, CL, CI, CP. • ClaimsInjuredInfo can only exist for roles CL, CP, CD, CI, IN, ID, IP, IE. • PropertyLossInfo can only exist for roles IN and CI and can exist only one time in a claim. • AutoLossInfo can only exist for roles CL, CP, CD, CI, IN, ID, or IP. • The roles IN, ID, and IP do not require a coverage record, but if they are sent with a casualty coverage record

(ClaimsInjuredInfo) and names are marked as individual, then the involved party will be searched.

The PropertyLossInfo/ClaimsSubjectInsuranceInfo does not have coverage reported but instead allows an entry in the amount of policy, loss estimate, reserve amount for building, contents, loss of use, stock, and other categories. The PropertyLossInfo/ItemInfo or PropertyLossInfo/Watercraft aggregates include boats and mobile equipment policies and does require coverage.

When reporting a loss on a watercraft under a homeowner policy not insured separately (i.e., a rowboat, canoe, or kayak), the loss is best reported using the PropertyLossInfo/ClaimsSubjectInsuranceInfo aggregate. It should be reported with a policy type of WCFT for watercraft in the Policy aggregate, using the loss types for Property found in Appendix B. The exposure/loss amount would be reported using either CONTENTS or the OTHER coverage amounts in the PropertyLossInfo/ClaimsSubjectInsuranceInfo aggregate.

When reporting a loss on a boat insured separately under an endorsement to a homeowner’s policy or another policy,

the loss is best reported using the PropertyLossInfo/Watercraft aggregate. It should be reported with a policy type of BOAT in the Policy aggregate. PropertyLossInfo/Watercraft is used for boat policies and HIN and model year are required. If you don’t have a HIN or model year, you probably do not have specific coverage on the boat. In the absence of these, an alternative is to use WCFT under PropertyLossInfo/ClaimsSubjectInsuranceInfo (see above).

Snowmobiles and jet skis should be sent as PropertyLossInfo/ItemInfo if possible so we can perform recoveries (if

licensed they should be reported as auto; if not licensed, report as property). The AgencyId should contain 1 alpha, 8 numeric characters. The last 5 digits of the AgencyId should have a value of

00001 or higher and are used to identify the postback URL for Asynchronous Response processing . If the last 5 digits are zero-filled (00000) or not present, then the system cannot return Responses.

Heavy equipment, if not licensed for road-use, should be marked as Commercial Inland Marine (CIMR) policy type

on the ClaimsOccurrence aggregate and the coverage is reported on the PropertyLossInfo/ItemInfo record. In property, lost or damaged contents pertaining to the structure would be reported under building. Items and property

within the structure would be reported as contents. Use and Occupancy is also known as Time Element - additional living expenses (personal) and business interruption (commercial).

Each ClaimsParty searched can retrieve up to 25 matches. Recoveries (return reason code- V) are sent whenever ISO receives a recovery notification from an agency other than

an insurance company. The notification is only sent once; not if you update or research a claim.

122

Crossline searches are performed against the lines that a company participates in. If a company is not a member of a specific line because they do not write business in that line but are still interested in the crossline searches, they can obtain the crossline searches for an additional fee.

For the MAKE codes, a table of valid Makes can be provided. Although ISO would like for you to map your system to

send the correct code, if you cannot, enter the first four characters of the Make of the vehicle. The system will not reject invalid entries but will reject the claim if the make is not provided at all.

For XML reporting, hits will be generated 24 hours a day, 7 days a week, 365 days a year (24/7/365) except for

a few hours a week of scheduled system outages. Scheduled maintenance windows are from midnight to 4am Eastern Time on Sundays and from 4-5am Eastern Time on Thursdays. During these windows, with few exceptions, ISO ClaimSearch will take in XML Requests, but hold the processing until all maintenance is completed for that particular window then release the claims for processing. This may cause Match Reports and Rejection Reports to take longer to return than during normal operating hours.

You may choose to Update or Replace a claim. Update Requests (com.iso_Update) can be used if you only want to

update a particular part of a claim. Searches are not performed on the Update Requests by default and therefore do not return an Asynchronous Match Report. Replacements may be sent in addition to or instead of Update Requests. On a Replacement the system essentially finds the original claim reported, deletes it, and adds a new claim in its place, thus it is important to send all parties and information involved in the claim again on the Replacement Request. Searches are performed on Replacements by default unless the ClaimInvestigationAddRq/ SuppressMatchInd=1.

Searches are performed with the following hierarchy: 1. Name/address/city & state 2. Numeric 3. Specific line

searches. Results are shown in order of the most recent claim appearing first and the oldest appearing last. ICD-9 and ICD-10 Codes are designated by the Centers for Disease Control (CDC) and the World Health Organization

(WHO) and can be found on the public internet. The rejection file will look similar to the match file but will contain <MsgStatusCd>Rejected</MsgStatusCd> with a

description of the rejection instead of the claim information. If you submit an entire claim as ‘NO SEARCH’ (ClaimInvestigationAddRq/SuppressMatchInd), you will not receive

any Response unless there is an error. If you submit a claim to be searched, but choose to submit an involved party as ‘NO SEARCH’ (ClaimsParty/PartyInvestigationInfo/SuppressMatchInd), you will receive all aggregates back with that <ClaimsParty> listed as ‘NS’ in the raw XML

Dollar amounts should be reported using whole dollars, except for the CMS fields on the <com.iso_CovInfo1>

aggregate which should contain dollars and cents. There can be up to 5 errors per involved party, but a limit of 8 errors per claim, returned in a Rejection Response. If 8

errors are returned, the entire Request should be reviewed as more errors may exist on the claim. When reporting Claim Number (ClaimsOccurrence/ ItemIdInfo/ InsurerId) and Policy Numbers (Policy/ PolicyNumber),

please do not include any spaces, dashes, or other special characters. As part of the processing of claims, spaces, dashes, and special characters will be removed when the claim is added to the ISO ClaimSearch database.

Update Requests using UpdateInds 1, 2, 3, 5, or 6 DO NOT Generate a Response, nor do Requests with the

<SuppressMatchInd> set to “1” on the ClaimsOccurrence. These Requests will only receive the ClaimInvestigationAddRs if there is an XML Data Error.

123

APPENDIX A – CODE LISTS

ISO ClaimSearch XML Package/ Programming Documentation/ Appendices A-D/ Appendix A – Code Lists.xlsx contains the full listing of Code Lists and their values. Within the Excel document, each Code List has its own tab which is labeled with the CodeListName. If the tab name includes (A) after the name, it is an ACORD code list and does not require a codelistref on elements that use this code list. The tabs are sorted in alphabetical order from AdditionalMatchCd through WaterUnitTypeCd. Special Programming Notes There are two types of code lists used in XML programming.

ACORD industry-standard code lists are always assumed and do not need to be declared. These are indicated with (A) on the tab name of the Excel spreadsheet.

ISO ClaimSearch code lists are created by ISO ClaimSearch for the processing of claim information into our

system. Each ISO ClaimSearch code lists must be declared with a <CodeList> aggregate at the top of the XML file. The CodeList id is then referenced throughout the file using “codelistref” attributes on every element where this code value is used. For example:

<CodeList id="ClaimsPartyRoleCd">

<CodeListName>ClaimsPartyRoleCd</CodeListName> <CodeListOwnerCd>ISOUS</CodeListOwnerCd>

</CodeList> <ClaimsPartyRoleCd codelistref="ClaimsPartyRoleCd">CL</ClaimsPartyRoleCd>

CodeListName and CodeListOwnerCd are case- and spelling-sensitive. If these are not submitted EXACTLY as described, the Code List declaration will be dropped from the processing, which may result in submitted fields of data being dropped in the processing and generating Asynchronous Rejection Reports for required fields even If the data submitted is valid.

The following code lists are required on every XML Request file, regardless of type of claim submitted, due to the ISO ClaimSearch Basic Claims Reporting Required fields that depend on these code lists: ClaimsPartyRoleCd PolicyTypeCd CoverageCd LossTypeCd

124

APPENDIX B – POLICY, COVERAGE, AND LOSS TYPES

ISO ClaimSearch XML Package/ Programming Documentation/ Appendices A-D/ Appendix B – Policy Coverage Loss Codes.xlsx contains the full listing of valid codes and their definitions. Within the Excel document, each coverage aggregate (AutoLossInfo, ClaimsInjuredInfo, PropertyLossInfo, etc.) has its own tab which is labeled with the aggregate name. The values that are included on that tab may be used in the <PolicyTypeCd>, <CoverageCd>, and <LossCauseCd> elements in aggregates that reference the aggregate name on that tab. Special Programming Notes Appendix B provides policy, coverage, and loss type selections for most policy types. If the appropriate policy,

coverage and/or loss type combination is not included in Appendix B, an entry of one of the “OTHER” policy, coverage or loss types (e.g., OTCA, OTLB, OTAU) is acceptable. We do recommend, however, that: The information be as accurate as possible. The options be closely reviewed for a choice that best describes your claim And the use of “other” is only used when more descriptive coverage and loss type choices are not available.

While ClaimSearch prefers loss type be limited to one coverage, multiple loss types are allowed provided the same

coverage and loss type is not repeated for a single involved party’s casualty or property coverage; or per VIN for a single involved party. For example, John Doe is injured in a car accident. He may have BODI/ BODI and MPAY/ MPAY applied to the

same claim, but he may not claim MPAY/MPAY and MPAY/MPAY twice as doing so will generate the “Duplicate coverage and loss combination code” error.

Some companies divide coverages into sub-coverages to respond to statutory requirements or endorsements. ISO

ClaimSearch expects these to be concatenated into a single report for the same Coverage and Loss Type applied. Property claims are policy level. There are policy segments (building, contents, loss of use, etc.) where dollar amounts

under policy, estimate of loss, reserve and amount paid can be entered to indicate coverage. As there is only one proximate cause of loss in property claims (PropertyLossInfo/ClaimsSubjectInsuranceInfo), only one policy type and loss type should be included in your report.

ISO ClaimSearch has attempted to include loss types that apply to the great majority of claims. This manual will be

updated with contemporary loss types requested by participating companies.

Personal Combination Policies that “bundle” homeowners and auto insurance into a single policy are accounted for under the “Combination Policies” tab of the Excel spreadsheet. Automobile loss types are included under property coverage to facilitate reporting of vehicle losses under the combination contract. Examples of these losses include insured vehicles damaged in fire losses at the insured residence, or vandalism of the house and vehicles on the premises. Likewise, Auto Policies that include collision and/or comprehensive coverage usually exclude non-auto property. However, for combination policies, we have added property loss types under auto coverage.

Not all Policy, Coverage, and Loss Types available in Appendix A are valid for CMS Reporting purposes. In the Excel

spreadsheet, there is a tab labeled “CMS Specific” for the combinations that are allowed. This tab has an additional column named “CMS”. An “O” in this field indicates that it may be used for an “ORM” claim. A “T” in this field indicates that it may be used for a “TPOC” claim. A “W” indicates that it is a Workers Compensation claim and may be ORM or TPOC, per CMS rules. An “X” in this field indicates that it uses ORM required fields and processes as an ORM claim but will be sent to CMS and show on the CMS Acknowledgement and Error files as a “Plan Type: L”.

125

APPENDIX C – FIELD AND RELATIONSHIP EDITS

ISO ClaimSearch XML Package/ Programming Documentation/ Appendices A-D/ Appendix C – Field and Relationship Edits contains the full listing of Error Codes and their definitions.

Within the Excel document, there are two tabs. One is “Field Specific Edits” and the other is “Relationship Edits”. Field Specific Edits are for individual fields used throughout the claim. Relationship Edits are for the overall claim and/or fields in combination with each other.

ISO ClaimSearch XML Package/ Programming Documentation/ Invalid Lists contains six (6) text files with the invalid lists that our system uses to determine that the data submitted does not meet our data quality standards. There is also one (1) Excel document with the same lists in an Excel format with each list on a separate tab within the worksheet.

Invalid Address – This list contains all the values not accepted in <Addr1> or <Addr2> fields. Invalid Claims – This list contains all the values not accepted in the <InsurerId> field. Invalid License Plates – This list contains all the values not accepted in the <RegistrationNumber> field. Invalid Names – This list contains all the values not accepted in <CommercialName>, <Surname>, <GivenName>, or

<OtherGivenName> fields. Invalid Numerics – This list contains all the values not accepted in fields designated as “Numeric” only and not

otherwise specified by an invalid list. Invalid Occupation – This file contains all the values not accepted in the <Occupation> field.

If ISO ClaimSearch finds a new data value that does not meet our data quality standards that is being submitted by multiple members in an effort to get around edits, then it may be added to the Invalid Lists at any time. Please contact [email protected] for the current Invalid List files if you believe yours to be out of date.

Special Programming Notes

The aggregates contain Usage information which can be interpreted as follows: Required – The claim will be rejected if data is not present and in the right format (e.g., the Name validation rules) Optional – The claim will not be rejected if data is not present. If data is not in the right format or is on the invalid

list, it will be blanked out and continue processing the claim. Request Only – This element is only present on the Request sent from the member to ISO ClaimSearch. Response Only – This element is only present on the Response sent from ISO ClaimSearch to the member

company. Repeating – This aggregate can be repeated to report multiples of the included data fields. This may require the

use of additional ids and references to clarify where to apply the data in the system. Max # - This element may be repeated up to the maximum number shown on this element.

XML has a special set of characters that cannot be used in normal XML strings. These characters are:1. & - &2. < - < Invalid: <Organization>IBM & Microsoft</Organization> 3. > - > Valid: <Organization>IBM & Microsoft</Organization> 4. " - "5. ' - '

It has also been found that other special characters will have issues within the XML processing as the encoding of the claims data transfers across several different platforms in the course of processing. It is best to omit all special characters, or to use HTML escapes for special characters if omission is not possible.

It is recommended for members/vendors to build front-end edits that utilize the Invalid Lists as provided by ISOClaimSearch. Many rejections can be avoided if the front-end system will not allow a claim to be submitted to ISOClaimSearch with a known “invalid” value in a Required field.


126

Date fields must be either blank or contain a valid date format : YYYY-MM-DD.

Dollar amounts must be reported using whole dollars (except for the amounts on the <com.iso_CovInfo1> aggregatewhich should be reported with dollars and cents).

When reporting Claim and Policy Numbers, please do not include any spaces, dashes, or other special characters.As part of the processing of claims, spaces, dashes, and special characters will be removed when the claim is addedto the ISO ClaimSearch database.

If the member organization does not utilize policy numbers, the claim number may be repeated in this field. If themember organization does not use claim number, the policy number may be repeated in this field.

ISO ClaimSearch performs a duplicate check on Initial Claims and the “New” values of an UpdateInd=5 (ChangingKey Fields) Request and will reject claims with the same <PolicyNumber>, <AgencyId>, <InsurerId>, and <LossDt>.

Replacement, Update and Research Requests must contain the EXACT <PolicyNumber>, <AgencyId>, <InsurerId>, and <LossDt> that are on the system or the Request will be rejected for “Initial Claim Not Found”. If the Request is toUpdate or Research a specific ClaimsParty, then the ClaimsParty Name must also match EXACTLY. If the Requestis to Update or Research a specific Claims Party and that ClaimsParty has previously been updated on the ISOClaimSearch website, then the ClaimsParty Name AND Role Code must match EXACTLY, or the Update Requestwill add a new ClaimsParty instead.

The following are editing rules for the name fields (Claimant Name, Insured Name, Alias Name, etc.).• Name fields should contain names, not other information.• The Claimant's Last Name field must contain at least two letters.• The Claimant's First Name field must contain at least one letter.• Abbreviations or substitutions such as: UNKNOWN, UNK, N/A, etc. will not be accepted by the system.• "Informational" entries such as: DAUGHTER, SAME, NONE, etc. will not be accepted by the system.• Special characters except for apostrophe ( ‘ ), hyphen (-), or ampersand (&), should not be sent in the name field.

When reporting Alias and Prior Address information associated with an involved party, you should report eachappropriate section of the record completely, i.e., if reporting an Alias name, submit the entire name (business or last& first); for a prior address, include street, city, and state. NOTE – ISO cross-searches all names and addressessubmitted on an involved party in all combinations. It is therefore not necessary to repeat the name of the Alias if ithas not changed from one address to another. Conversely, if the name has changed while the address has remainedthe same, it is also not necessary to report the address twice.

Claimant Street and Claimant City are required. The following values are invalid: only dashes, only x's, question marks, n/a, na, none, not known, not knwn, not-known, periods, same, uk, ukn, unk, unk., unkn, unknown. Addresses mustcontain at least two consecutive alpha characters, or a number followed by a space and an alpha character, or anumber followed by a space and then a number. A city must contain at least two alpha characters and no numbers.

Claimant State must be present and valid. Any state code you provide must be a valid US or Canadian postal serviceabbreviation. If the Country field is blank, US or Canada (CA), State will be edited, if other than blank, US or CA, noedit will be made on the State field. See Appendix A for valid State and Province codes.

Fields containing words such as n/a, na, none, not known, not knwn, not-known, same (for a name field), uk, ukn, unk, unk., unkn, unknown or variations of these words should be screened and removed. If the field is required andremoving the invalid data would cause the entire field to be blank, do not submit the claim, as it will reject.

All lower-case letters in data fields are converted by the ISO ClaimSearch system to upper case.

127

Entering “Invalid” Names

ISO ClaimSearch maintains a list of “names” that are considered to be invalid, such as NA, UNKNOWN, UNK, NO, etc., because they are usually entered when complete information is not available. We believe the edits are necessary to prevent incorrect data from being added to the database. However, we do realize that there are occasions when one of these entries is the individual’s real name. If your claim rejects for an invalid name and you have verified that it is correct, you may enter parentheses around the

name, for example, (NA), in order to get the name into the database.

The parentheses will be dropped when the claim is added to the database and will not display on any ISO formatted reports. For example, Na will be rejected as a form of “not applicable” or “not available” while (Na) will be entered into the system as Na.

The parenthesis may be used to report a verified name that is on the invalid list for any claimant name, insured name, alias name or additional claimant name.

Any future replacements or updates of this name must also contain the parentheses around the name. These names may be entered through your automated system, if you have the capability of doing so, or may be

entered through the ISO ClaimSearch website. NOTE: This process should be used only when you have verified the name. ISO randomly performs audits to check

for data quality issues. If we suspect that the new process is being used just to bypass edits, you will be contacted.

System Limitations

ISO ClaimSearch has a database limit of 600 lines per claim. The XML file equivalent is more difficult to calculate.

Some guidelines to assist in judging the size of an XML claim. The Policy aggregate and ClaimsOccurrence aggregate together count as one record. Each individual ClaimsParty will count as one record each. Each individual AutoLossInfo, PropertyLossInfo, or ClaimsInjuredInfo with its corresponding AdjusterPartyInfo will

count as one record each. Each individual SalvageInfo will count as one record each.

Please keep in mind that the ISO ClaimSearch website does have limitations for handling large claims. Although

system-to-system companies will be able to send these large claims, you will not be able to update those claims via the ISO ClaimSearch website. Future updates to those claims must be made through your system. In addition, when there are matches on the large claims via the web, Claims Reporting users will not be able to see all of the details on these large claims; you must retrieve the details through Claims Inquiry or via ISO ClaimSearch Customer Service.

ISO performs random audits to check for data quality issues. Members will be contacted if ISO ClaimSearch feels that

large claims are being sent with an excessive amount of unnecessary information.

ISO ClaimSearch can generate Asynchronous Response files as large as 6MB. Although it is difficult to generate such a large Responses in the Test environment, it is becoming increasingly common in the Production environment. It is recommended that member set their system to allow up to 6MB to be received back into their systems.

128

APPENDIX D – ROLE CODES

ISO ClaimSearch XML Package/ Programming Documentation/ Appendices A-D/ Appendix D – Role Codes.xlsx contains the full listing of Role Codes and their definitions. Within the Excel document, there is a tab for each category of <ClaimsParty> role code that may be submitted: Involved Party, Other Party (ACORD), Service Provider, Additional Claimant for CMS, and Legal Representative for CMS. The role codes and their definitions are provided as well as when coverage is provided, or searches will be performed. Special Programming Notes

Involved Party Role Codes

See also Appendix D- Role Codes.xlsx/ Involved Party tab. Involved Party is defined as an individual or organization that has a direct interest in the claim either as a named

insured of the policy or as a third-party claimant making a claim against the insured’s policy. All ClaimsPartyRoleCd values on this tab REQUIRE a codelistref on the <ClaimsPartyRoleCd> element in either the

<ClaimsParty> or <ClaimsPartyRelationship> aggregates. If a person qualifies for more than one role within a claim, for example, if they are an insured and an insured driver,

please only report the person once within the claim using the more specific role such as insured driver. If the person is the insured and is also making a claim, use the role CI instead of reporting the person twice, once as an insured and once as a claimant.

When a Request has multiple lines of business (Casualty, Property, and/or Auto) associated with a single ClaimsParty and at least one of those is identified as searchable, then the ClaimsParty will be searched across the multiple lines.

Service Provider Role Codes

See also Appendix D- Role Codes.xlsx/ Service Provider tab A Service Provider is anyone who has provided a service to an involved party due to the loss being reported. All Service Providers should be reported with its own <ClaimsParty> aggregate and use a value from this list. All Service Providers require a <ClaimsPartyRelationship> aggregate to link the Service Provider to the Involved Party

it provided a service for. The Involved Party should be ClaimsParty1, and the Service Provider should be ClaimsParty2.

Specific Medical Roles indicated in the Excel spreadsheet may include the Date of the First Doctor Visit <com.iso_1stDoctorDt> included in the information submitted for that Service Provider. If this field is submitted on a role that is not indicated, this information will be dropped from processing.

Additional Claimant Role Codes for Medicare Section 111 Reporting

See also Appendix D- Role Codes.xlsx/ Additional Claimant tab The Additional Claimant role codes are intended for Medicare Section 111 Reporting Only. All Additional Claimants should be reported with its own <ClaimsParty> aggregate and use a value from this list. All Additional Claimants require a <ClaimsPartyRelationship> aggregate to link the Additional Claimant to the Involved

Party it is associated with. The Involved Party should be ClaimsParty1, and the Additional Claimant should be ClaimsParty2.

Up to four (4) Additional Claimants may be reported per Involved Party. Each Additional Claimant may have its own Legal Representative.

This requires a <ClaimsPartyRelationship> aggregate to link the Legal Representative to the Additional Claimant. The Additional Claimant should be ClaimsParty1, and the Legal Representative should be ClaimsParty2.

Each Additional Claimant Legal Representative may have its own Alias. This requires a <ClaimsPartyRelationship> aggregate to link the Alias to the Legal Representative. The Legal Representative should be ClaimsParty1, and the Alias should be ClaimsParty2.

129

Legal Representative Role Codes for Medicare Section 111 Reporting

The Legal Representative role codes are intended for Medicare Section 111 Reporting Only. These roles are in addition to the legal representative roles (LC, LI, LM, LO, LR, or LW) listed with the Service

Providers. All Legal Representatives should be reported with its own <ClaimsParty> aggregate and use a value from this list. All Legal Representatives require a <ClaimsPartyRelationship> aggregate to link the Legal Representatives to the

Additional Claimant it is associated with. The Additional Claimant should be ClaimsParty1, and the Legal Representative should be ClaimsParty2.

Each Additional Claimant Legal Representative may have its own Alias. This requires a <ClaimsPartyRelationship> aggregate to link the Alias to the Legal Representative. The Legal Representative should be ClaimsParty1, and the Alias should be ClaimsParty2.

Other Party Role Codes

See also Appendix D- Role Codes.xlsx/ Other Party (ACORD) tab The role codes on this list are defined by ACORD as industry-standard role codes. Therefore, these role codes do

NOT use codelistrefs. All values on this list are case- and spelling-sensitive. NOTE: ImpouundAgcy has a double “u” in it, due to a typo of

the original ACORD coding. It is not a typo of this document and needs to be spelled accordingly. Alias is the only value on this list that requires a <ClaimsPartyRelationship> aggregate to link the Alias to the Involved

Party or Service Provider it is associated with. The Involved Party or Service Provider should be ClaimsParty1, and the Alias should be ClaimsParty2.

All other values are identified through individual element ids and idrefs.

130

APPENDIX E – CLAIMS PAYMENT AND STATUS REPORTING RULES

Claims Payment Reporting Rules Below are general rules for sending ClaimsPayment Information based on the type of payment being reported and the Line of Business (Casualty, Auto, Boat, Mobile Equipment, or General Property) that is being reported. For ALL claims payment types in the list below, if more than one payment amount is entered per Payment Type for a single coverage/loss, the first amount listed on the file is taken and the other(s) are dropped from the processing.

Casualty ONLY

The Paid Amount for Indemnity, Paid Amount for Medical Bills, and Total Paid Amount for Loss may be reported ONLY for Casualty line of business and MUST have an idref pointing to a ClaimsInjuredInfo. If the idref points to an AutoLossInfo or PropertyLossInfo, the information will be dropped in the processing of the claim.

Paid Amount for Indemnity

This dollar amount is intended to report the indemnity portion of the total paid amount (see below) on workers’ compensation claims.

This amount is a Request Only field.

Requires an idref to point to the ClaimsInjuredInfo id to link the dollar amount to the appropriate coverage record on the claim and a ClaimsPartyRef to link to the correct ClaimsParty on the claim.

PaymentTypeCd = IndemnityPd and uses codelistref=”PaymentTypeCd”

ClaimsPaymentCovInfo/ CoverageCd should be the same value as the AdjusterPartyInfo/ CoverageCd to which the dollar amount is being applied.

TotalPaymentAmt/ Amt should be the dollar amount in whole dollars and numerics only. NO decimal point or currency declaration is required.

At the ClaimInvestigationAddRq level: <ClaimsPayment idref="ClaimsInjury-01" ClaimsPartyRef="ClaimsParty-02"> <PaymentTypeCd codelistref=”PaymentTypeCd”>IndemnityPd</PaymentTypeCd> <ClaimsPaymentCovInfo> <CoverageCd codelistref="CoverageCdList">should be the same code as AdjusterPartyInfo/CoverageCd </CoverageCd> </ClaimsPaymentCovInfo> <TotalPaymentAmt> <Amt>dollar amount in whole dollars, numeric only</Amt> </TotalPaymentAmt> </ClaimsPayment>

131

Paid Amount for Medical Bills

This dollar amount is intended to report the medical bills portion of the total paid amount (see below) on workers’ compensation claims.



PaymentTypeCd = MedicalBillsPd and uses codelistref=”PaymentTypeCd”



At the ClaimInvestigationAddRq level: <ClaimsPayment idref="ClaimsInjury-01" ClaimsPartyRef="ClaimsParty-02"> <PaymentTypeCd codelistref=”PaymentTypeCd”>MedicalBillsPd</PaymentTypeCd> <ClaimsPaymentCovInfo> <CoverageCd codelistref="CoverageCdList">should be the same code as AdjusterPartyInfo/CoverageCd </CoverageCd> </ClaimsPaymentCovInfo> <TotalPaymentAmt> <Amt>dollar amount in whole dollars, numeric only</Amt> </TotalPaymentAmt> </ClaimsPayment>

Total Paid Amount for Loss

This dollar amount is intended to report the total paid amount on casualty claims. (If BI claim, report settlement amount, If PIP or WC claim, report total paid – excluding expenses.)



PaymentTypeCd = TotalLossPd and uses codelistref=”PaymentTypeCd”



At the ClaimInvestigationAddRq level: <ClaimsPayment idref="ClaimsInjury-01" ClaimsPartyRef="ClaimsParty-02"> <PaymentTypeCd codelistref=”PaymentTypeCd”>TotalLossPd</PaymentTypeCd> <ClaimsPaymentCovInfo> <CoverageCd codelistref="CoverageCdList">should be the same code as AdjusterPartyInfo/CoverageCd </CoverageCd> </ClaimsPaymentCovInfo> <TotalPaymentAmt> <Amt>dollar amount in whole dollars, numeric only</Amt> </TotalPaymentAmt> </ClaimsPayment>

132

Casualty, Auto, Boat, or Mobile Equipment

The following rules apply to all Casualty (ClaimsInjuredInfo), Auto (AutoLossInfo), Boat (PropertyLossInfo/Watercraft) and Off-Road/Mobile Equipment (PropertyLossInfo/ItemInfo) dollar amounts. First-Party General Property (PropertyLossInfo/ClaimsSubjectInsuranceInfo) uses different rules and are listed separately.

Estimated Loss Amount

The Estimated Loss Amount <ProbableIncurredAmt> is the dollar amount the loss is expected to total.

This field requires an idref to point to the ClaimsInjuredInfo id, AutoLossInfo id, PropertyLossInfo id (for Watercraft) or PropertyLossInfo/ItemInfo id (for Off-Road/Mobile Equipment) to link the dollar amount to the appropriate coverage record on the claim.

At the ClaimsOccurrence level: <ClaimsOccurrence id="ClaimsOccurrence"> <ItemIdInfo> <InsurerId>…</InsurerId> </ItemIdInfo> <LossDt>…</LossDt> <LossTime>…</LossTime> <IncidentDesc>…</IncidentDesc> <Addr>…</Addr> <ProbableIncurredAmt idref="id of the coverage aggregate this dollar amount should be applied to"> <Amt> dollar amount in whole dollars, numeric only </Amt> </ProbableIncurredAmt> </ClaimsOccurrence>

Reserve Amount

The Reserve Amount is the dollar amount the Insurance Company has set aside for the payment of the claim.

This dollar amount does not display to on reports to other users of the system.

Members also have the option to not display this amount on the reports their internal users receive. Please have a Home Office representative of your company contact [email protected] to request this option.

Requires an idref to point to the coverage aggregate id: ClaimsInjuredInfo id, AutoLossInfo id, PropertyLossInfo id (for Watercraft) or PropertyLossInfo/ItemInfo id (for Off-Road/Mobile Equipment) to link the dollar amount to the appropriate coverage record on the claim and a ClaimsPartyRef to link to the correct ClaimsParty on the claim.

PaymentTypeCd = LossResv which is an ACORD code and does NOT use a codelistref.

At the ClaimInvestigationAddRq level: <ClaimsPayment idref=" id of the coverage aggregate this dollar amount applies to " ClaimsPartyRef="id of the ClaimsParty this dollar amount applies to"> <PaymentTypeCd>LossResv</PaymentTypeCd> <ClaimsPaymentCovInfo> <CoverageCd codelistref="CoverageCdList"> should be the same code as AdjusterPartyInfo/CoverageCd </CoverageCd> </ClaimsPaymentCovInfo> <TotalPaymentAmt> <Amt>dollar amount in whole dollars, numeric only</Amt> </TotalPaymentAmt> </ClaimsPayment>


133

Settlement Amount

The Settlement Amount (aka Paid Amount) is the final concatenated dollar amount the Insurance Company has paid on the claim.


PaymentTypeCd is NOT used to report Settlement Amount. Total Payment Amount <TotalPaymentAmt> assumes Settlement as the default and PaymentTypeCd is used to declare when the dollar amount is “other than Settlement”.

At the ClaimInvestigationAddRq level: <ClaimsPayment idref=" id of the coverage aggregate this dollar amount applies to " ClaimsPartyRef="id of the ClaimsParty this dollar amount applies to"> <ClaimsPaymentCovInfo> <CoverageCd codelistref="CoverageCdList"> should be the same code as AdjusterPartyInfo/CoverageCd </CoverageCd> </ClaimsPaymentCovInfo> <TotalPaymentAmt> <Amt>dollar amount in whole dollars, numeric only</Amt> </TotalPaymentAmt> </ClaimsPayment>

Date of First Claim Payment

This is the DATE of the First Claims Payment, not the amount.

This can be reported ONCE per claim.

This is reported in its own ClaimsPayment aggregate without any dollar amount.


PaymentTypeCd = FCP and uses codelistref=”PaymentTypeCd”.

At the ClaimInvestigationAddRq level: <ClaimsPayment idref=" id of the coverage aggregate this dollar amount applies to " ClaimsPartyRef="id of the ClaimsParty this dollar amount applies to"> <PaymentTypeCd codelistref="PaymentTypeCdList">FCP</PaymentTypeCd> <PaymentDt>YYYY-MM-DD</PaymentDt> </ClaimsPayment>

134

First-Party General Property ONLY

The following rules apply to First-Party General Property (PropertyLossInfo/ClaimsSubjectInsuranceInfo) dollar amounts.

All Casualty (ClaimsInjuredInfo), Auto (AutoLossInfo), Boat (PropertyLossInfo/Watercraft) and Off-Road/Mobile Equipment (PropertyLossInfo/ItemInfo) uses different rules and are listed separately.

First-Party General Property does not use the CoverageCd element to declare the coverage type on property claims. Instead, it uses the SubjectInsuranceCd “Risk” code list to declare the Policy Section coverage that the claim is being applied to: Building (BLDG), Contents (C), Loss of Use/Occupancy (UseOccupancy), Stock (Stock), and Other (OT), plus any dollar amounts reported under each of those coverages.

ISO ClaimSearch XML Package/ Programming Documentation/ Appendices A-E/ Appendix E – Property Claims Payment Grid.xlsx demonstrates the grid of 20 dollar amount values that can be used to declare coverage on a First-Party General Property claim.

The ISO ClaimSearch XML Package/ Sample Files/ Request Samples/ Property-Fire-Payment.xml demonstrates all twenty (20) dollar amount values coded in a single XML file and demonstrates the order of elements within a single <ClaimsSubjectInsuranceInfo> as well as at what level the information may be repeated for the different payment types.

The ClaimsSubjectInsuranceInfo may repeat up to five times, once for each value of the SubjectInsuranceCd “Risk” code list values of BLDG, C, UseOccupancy, Stock, or OT. (The columns of the grid) If the same “Risk” code list value is used more than once for the same dollar amount payment type (the rows of the grid), only the first value for that “Risk” code list value and payment type will populate the claims payment grid. All subsequent dollar amounts for the same “Risk” code list value and payment type will be dropped from the processing.

In XML Programming terminology, all twenty (20) amounts are listed as optional as not every value is a part of every property claim. For example, there is no Building dollar amount when a laptop computer is stolen (theft of Contents). However at least ONE dollar amount out of the 20 possibilities needs to be reported in order to demonstrate which coverage the loss is being applied to and the general value of the claim. For example, is this a $5000 “small kitchen” fire or a $500,000 “house burned to the ground” fire?

Estimated Loss Amount is not required by ISO ClaimSearch Basic Claims Reporting; however, it is recommended to report this value because:

It is a value that is often received soon after First Notice of Loss.

It is a value displayed to other insurers on the Matching Claims section of the Match Report which provides guidance in their own handling of claims.

It is required by some State Fire Marshalls for the reporting of Fire claims to their state. If the value is present, ISO ClaimSearch will pass it on to the State Fire Marshalls on the member’s behalf. If it is not present, the member may receive a Rejection Notice from the State Fire Marshall indicating that this is a required field for their reporting requirements.

135

Policy Amount

This is the full amount of the policy as underwritten by the Insurance Company.

This is reported in General Property ONLY.

This dollar amount is reported INSIDE the <PropertyLossInfo> aggregate itself and therefore uses the PropertyLossInfo id and ClaimsPartyRef to link the dollar amount to the appropriate coverage and ClaimsParty on the claim.

SubjectInsuranceCd = BLDG, C, UseOccupancy, Stock, or OT. This uses the Risk ACORD Code List and does NOT use a codelistref.

At the PropertyLossInfo level, demonstrating the repeating of <ClaimsSubjectInsuranceInfo> for different SubjectInsuranceCd coverage types, may repeat up to 5 times, but only once per SubjectInsuranceCd value.

<PropertyLossInfo id="PropertyLossInfo id inserted here" ClaimsPartyRefs="ClaimsParty id inserted here"> <ClaimsSubjectInsuranceInfo> <SubjectInsuranceCd>BLDG</SubjectInsuranceCd> <InsuranceAmt> <Amt> dollar amount in whole dollars, numeric only </Amt> </InsuranceAmt> </ClaimsSubjectInsuranceInfo> <ClaimsSubjectInsuranceInfo> <SubjectInsuranceCd>C</SubjectInsuranceCd> <InsuranceAmt> <Amt> dollar amount in whole dollars, numeric only </Amt> </InsuranceAmt> </ClaimsSubjectInsuranceInfo> … … </PropertyLossInfo>

Estimated Loss Amount

The Estimated Loss Amount <ProbableIncurredAmt> is the dollar amount the loss is expected to total.



At the PropertyLossInfo level, demonstrating the repeating of <ClaimsSubjectInsuranceInfo> for different SubjectInsuranceCd coverage types, may repeat up to 5 times, but only once per SubjectInsuranceCd value. <PropertyLossInfo id="PropertyLossInfo id inserted here" ClaimsPartyRefs="ClaimsParty id inserted here"> <ClaimsSubjectInsuranceInfo> <SubjectInsuranceCd>BLDG</SubjectInsuranceCd> <ProbableIncurredAmt> <Amt> dollar amount in whole dollars, numeric only </Amt> </ProbableIncurredAmt> </ClaimsSubjectInsuranceInfo> <ClaimsSubjectInsuranceInfo> <SubjectInsuranceCd>C</SubjectInsuranceCd> <ProbableIncurredAmt> <Amt> dollar amount in whole dollars, numeric only </Amt> </ProbableIncurredAmt> </ClaimsSubjectInsuranceInfo> … … </PropertyLossInfo>

136

Reserve Amount

The Reserve Amount is the dollar amount the Insurance Company has set aside for the payment of the claim.

This dollar amount does not display to on reports to other users of the system.

Members also have the option to not display this amount on the reports their internal users receive. Please have a Home Office representative of your company contact [email protected] to request this option.



PaymentTypeCd = LossResv which is an ACORD code and does NOT use a codelistref.


<PropertyLossInfo id="PropertyLossInfo id inserted here" ClaimsPartyRefs="ClaimsParty id inserted here"> <ClaimsSubjectInsuranceInfo> <SubjectInsuranceCd>BLDG</SubjectInsuranceCd> <ClaimsPayment> <PaymentTypeCd>LossResv</PaymentTypeCd> <ClaimsPaymentCovInfo> <CoverageCd codelistref="CoverageCdList">BLDG</CoverageCd> <PaymentAmt> <Amt> dollar amount in whole dollars, numeric only </Amt> </PaymentAmt> </ClaimsPaymentCovInfo> </ClaimsPayment> </ClaimsSubjectInsuranceInfo> <ClaimsSubjectInsuranceInfo> <SubjectInsuranceCd>C</SubjectInsuranceCd> <ClaimsPayment> <PaymentTypeCd>LossResv</PaymentTypeCd> <ClaimsPaymentCovInfo> <CoverageCd codelistref="CoverageCdList">C</CoverageCd> <PaymentAmt> <Amt> dollar amount in whole dollars, numeric only </Amt> </PaymentAmt> </ClaimsPaymentCovInfo> </ClaimsPayment> </ClaimsSubjectInsuranceInfo> … … </PropertyLossInfo>


137

Settlement Amount

The Settlement Amount (aka Paid Amount) is the final concatenated dollar amount the Insurance Company has paid on the claim.



PaymentTypeCd = Payment which is an ACORD code and does NOT use a codelistref.


<PropertyLossInfo id="PropertyLossInfo id inserted here" ClaimsPartyRefs="ClaimsParty id inserted here"> <ClaimsSubjectInsuranceInfo> <SubjectInsuranceCd>BLDG</SubjectInsuranceCd> <ClaimsPayment> <PaymentTypeCd>Payment</PaymentTypeCd> <ClaimsPaymentCovInfo> <CoverageCd codelistref="CoverageCdList">BLDG</CoverageCd> <PaymentAmt> <Amt> dollar amount in whole dollars, numeric only </Amt> </PaymentAmt> </ClaimsPaymentCovInfo> </ClaimsPayment> </ClaimsSubjectInsuranceInfo> <ClaimsSubjectInsuranceInfo> <SubjectInsuranceCd>C</SubjectInsuranceCd> <ClaimsPayment> <PaymentTypeCd>Payment</PaymentTypeCd> <ClaimsPaymentCovInfo> <CoverageCd codelistref="CoverageCdList">C</CoverageCd> <PaymentAmt> <Amt> dollar amount in whole dollars, numeric only </Amt> </PaymentAmt> </ClaimsPaymentCovInfo> </ClaimsPayment> </ClaimsSubjectInsuranceInfo> … … </PropertyLossInfo>

Date of First Claim Payment

This is the DATE of the First Claims Payment, not the amount.

This can be reported ONCE per claim.

This is reported in its own ClaimsPayment aggregate without any dollar amount.

PaymentTypeCd = FCP and uses codelistref=”PaymentTypeCd”.

At the ClaimInvestigationAddRq level, OUTSIDE the PropertyLossInfo aggregate: <ClaimsPayment idref=" id of the coverage aggregate this dollar amount applies to " ClaimsPartyRef="id of the ClaimsParty this dollar amount applies to"> <PaymentTypeCd codelistref="PaymentTypeCdList">FCP</PaymentTypeCd> <PaymentDt>YYYY-MM-DD</PaymentDt> </ClaimsPayment>

138

Claims Status Reporting Rules Below are general rules for how to submit a ClaimStatusCd based on the type of payment being reported and the Line of Business (Casualty, Auto, Boat, Mobile Equipment, or General Property) that is being reported. The system default for all claim types is a claim status of “Open”. Casualty, Auto, Boat and Mobile Equipment claims - ClaimStatusCd is submitted as part of the ClaimInvestigationAddRq/ ClaimsPayment/ ClaimsPaymentCovInfo. It must be sent WITH CoverageCd and WITHOUT PaymentTypeCd. If a Settlement Amount (using TotalPaymentAmt) exists on the claim, then ClaimStatusCd should be sent in the same ClaimsPayment aggregate. See example below:

<ClaimsPayment idref=" id of the coverage aggregate this claim status applies to " ClaimsPartyRef="id of the ClaimsParty this claim status applies to"> <ClaimsPaymentCovInfo> <CoverageCd codelistref="CoverageCdList"> should be the same code as AdjusterPartyInfo/CoverageCd </CoverageCd> <ClaimStatusCd codelistref="ClaimStatusCdList">C</ClaimStatusCd> </ClaimsPaymentCovInfo> <TotalPaymentAmt> <Amt>2000</Amt> </TotalPaymentAmt> </ClaimsPayment>

If no Settlement Amount exists on the claim, then the ClaimStatusCd can be sent by itself. <ClaimsPayment idref=" id of the coverage aggregate this claim status applies to " ClaimsPartyRef="id of the ClaimsParty this claim status applies to"> <ClaimsPaymentCovInfo> <CoverageCd codelistref="CoverageCdList"> should be the same code as AdjusterPartyInfo/CoverageCd </CoverageCd> <ClaimStatusCd codelistref="ClaimStatusCdList">C</ClaimStatusCd> </ClaimsPaymentCovInfo> </ClaimsPayment>

Property - ClaimStatusCd is submitted as part of the PropertyLossInfo/ ClaimsPayment/ ClaimsPaymentCovInfo. It does not require CoverageCd. It can be sent with any PaymentTypeCd and TotalPaymentAmt. If multiple ClaimStatusCd elements are submitted on a single Request, the first ClaimStatusCd submitted on the Request will be the one stored. <ClaimsPayment> <ClaimsPaymentCovInfo> <ClaimStatusCd codelistref="ClaimStatusCdList">C</ClaimStatusCd> </ClaimsPaymentCovInfo> </ClaimsPayment>

139

WHO TO CALL

Please contact your assigned ISO ClaimSearch Testing Representative as your first point of contact for any questions related to ISO ClaimSearch. . If you do not you know who your assigned representative is, please contact the group email address below, and the next available Representative will assist you with this information.

Manager: Jonathan Brown 201-240-1250 [email protected] Nancy Chayka 201-469-3401 [email protected] Hiuyee (Jess) Lee 201-469-2233 [email protected] Jose Lopez 201-469-2147 [email protected] Shirley Maldonado [email protected] Anita Polk 201-469-3083 [email protected] Katya Stambler 201-469-3075 [email protected] Brian Thompson 201-469-3084 [email protected]

ISO ClaimSearch Database Development Group If your assigned representative is out of the office and you require assistance before their return, please contact the group email address: [email protected].

As we try to meet the needs of all members, ISO ClaimSearch staff will make every effort to respond to requests within 1 business day but may take up to 3 business days for investigation, troubleshooting, and the processing of test files as necessary. Please keep this in mind as you contact ISO ClaimSearch.

If you have questions regarding communications options, setups, or troubleshooting, please contact the ISO ClaimSearch XML Support Team members below or use the group email address.

Dean Coelho 201-469-3541 [email protected] Rebecca Farlow 201-469-3636 [email protected] Margarita Plavnik 201-469-3099 [email protected]

ISO ClaimSearch XML Support Team: If the team member you are trying to reach is out of the office and you require assistance before their return, please contact the group email address: [email protected].

Additional Contact Information

ISO ClaimSearch Customer Support 800-888-4476 or [email protected]

Verisk Analytics Technical Operations Center (TOC) 201-469-3300 - Emergency Off-Hours Production Support Only (See Production Support for further information)

ISO ClaimSearch 545 Washington Boulevard, 22-8 Jersey City, NJ 07310-1686















address aggregate

Documents