The ClickClaims CMS application supports Focus’ PolicyPort API, enabling claims created within the PolicyPort application to import into CMS for claims management.  Additionally, if your company utilizes the optional Financials module within CMS, reserve and payment data can be sent back to PolicyPort.   The information contained within this article details the ClickClaims / Tiva PolicyPort workflow.

Claim Creation

1. Once created and assigned in PolicyPort, the claim is eligible to be processed by ClickClaims.
   1. Note:  If the claim does not contain a “Date Assigned” value in PolicyPort, the claim cannot be processed by ClickClaims.

2. ClickClaims queries the Tiva REST API service for all claims assigned in PolicyPort since yesterday approximately every 15 minutes.

3. If new claims are located, they will be imported into the ClickClaims CMS application.

1. Note:  If the “Mark-Off”flag is set on a claim in CMS within 48 hours of it being imported, this may result in a duplicate claim being created in CMS.
   1. Duplicate claims are detected by the “Client #” (Claim ID) and “Client”.
   2. The “Mark-Off” flag is set by authorized users within the claim’s “Review” tab in CMS to identify a duplicate/erroneous claim.

4. Upon import, a new, unassigned claim will be created in ClickClaims CMS with a file status of “Open – Not Assigned”.

1. Note:  The eligible fields will be populated within the claim’s applicable tabs including coverage limits, reserves and deductibles.
2. Note:  See the “Mapped Fields” section below for details.
3. Note:  See the “Coverage Mapping” section below for details.

5. All deductibles will be imported into the “Stated Amount ($)” or “Stated Amount (%)” field within the “Deductibles” section of the claim’s “Policy” tab for AOP, Hurricane, and Sinkhole on all claims.

7. The following documents will be uploaded within the claim’s “Documents”tab:

1. FNOL.pdf:   This is the claim’s related “Acord FNOL”document generated by PolicyPort.   
   1. The file name will be “FNOL-”, followed by the claim’s Client #/Claim ID (as generated in PolicyPort).
      1. Example:  If the claim’s Client #/Claim ID is 12379, the file name will be “FNOL-12379.pdf”.
   2. Note:  This document will be located within the claim’s “Documents” tab only if it was generated in PolicyPort prior to the claim’s import into the ClickClaims CMS application.
2. Policy Dec.pdf:  This is a .pdf of claim’s related “Policy Declarations”form generated by PolicyPort.  
   1. The file name will be “Policy Dec –“, followed by the claim’s Client #/Claim ID (as generated in PolicyPort).
      1. Example:   If the claim’s Client #/Claim ID is 12379, the file name will be “Policy Dec-12379.pdf”.
   2. Note:  This document will be located within the claim’s “Documents” tab only if it was generated in PolicyPort prior to the claim’s import into the ClickClaims CMS application.
3. Loss Notice.txt:  This is a .txt file of the FNOL and the claim .XML data as received from Tiva’s API.        
   1. The file name will be the claim’s Client #/Claim ID (as generated in PolicyPort).
      1. Example:   If the claim’s Client #/Claim ID is 12379, the file name will be “12379.txt”.

8. Once the new claim has been successfully imported, no new claim information will be imported by ClickClaims.  Revisions to this data will need to be performed manually with in both systems, as needed.  Only reserves and payments data is synched back to PolicyPort from CMS.  

1. Note:  Currently, closing or re-opening a claim in CMS will not update the claim’s status in PolicyPort, and vice versa.  The claim must be closed / re-opened within both applications independently.  

Mapped Fields

The table below contains a list of fields that are mapped from PolicyPort to ClickClaims CMS.

Optional Mapping

Below are optional configuration settings that can be mapped from PolicyPort to ClickClaims CMS, but are not mapped by default.

• Journals:
  1. If Journals are configured to import into ClickClaims CMS, they will be added as claim notes within the claim’s “Notes” tab.
• Default Vendors:
  1. This is a vendor that should be associated to every claim imported into ClickClaims CMS from PolicyPort.  
• Transaction Voids:
  1. This allows transactions voided within ClickClaims to be synched as voided to PolicyPort instead of requiring the action to be manually performed in both systems independently.
     • If enabled for your company’s Tiva/PolicyPort EDI, a “Void Payment Transactions”special permission setting is visible in the ClickClaims user record for eligible user roles (Claims Supervisor; Company Examiner; File Reviewer; Accounting).   This setting must be enabled within that user’s record before they are able to void a transaction on the claim’s “Payments” tab in ClickClaims.
       • Users associated with the “Owner” or “Administrator” role have access by default so no special permission setting is necessary for these users.

1. When this optional EDI setting is enabled, the authorized user can utilize the  button, located on the claim’s “Payments” tab, to void an eligible payment transaction record in ClickClaims.  
2. If the payment has already been successfully sent to PolicyPort prior to the void (see the Payment Sent to TIVA” column on the claim’s “Payments” tab), a message is sent from ClickClaims to PolicyPort in order to automatically void the payment in that system as well.  
   • If the payment transaction record has not been sent to PolicyPort, it can still be voided in ClickClaims, but it will not be automatically updated in PolicyPort.
3. The value within the “Void Sent to TIVA” column of the “Payments” tab is updated to show the current status.
   • Blank = A void has not occurred on that payment transaction record.
   • No = The void was processed before the transaction was sent to PolicyPort.
   •  = Pending (Void has been sent to PolicyPort and is pending a successful confirmation from that system.)
   •  = Successful (Void has been successfully processed, per PolicyPort.)
   •  = Failed (Per PolicyPort, the void failed to process properly in that system.)
4. The “Payment Status” column is updated to “Voided”.
5. The “Voided Date”, “Last Updated Date”, and “Authorized/Denied By” columns update with the pertinent value.

Coverage Mapping

The table below shows how the PolicyPort coverages are mapped to the ClickClaims CMS coverages.

Vendors and Contacts

Businesses, such as mortgage companies and adjusting firms, are configured as “Vendors” in ClickClaims whereas individuals are configured as “Contacts”.  As part of the initial integration process, the company contact information and “Tiva Payee ID” for vendor records will be extracted from PolicyPort and imported into CMS as global “Vendors”.  

1. When a claim is imported into CMS with a claimant of type “Vendor”, the system will compare the “Tiva Payee ID” value of the claim’s associated parties, with the “TIVA ID” value of all existing CMS “Vendor” records.  
2. If a “Vendor” record match is located, the associated party record(s) will be added to the claim in CMS within the claim’s “Vendors” tab.  

3. If no existing “Vendor” record could be located in CMS at the time of the claim’s import/creation, the associated party record(s), including their “Tiva Payee ID”, will be added to the claim in CMS within the claim’s “Contacts/Claimants” tab as a non-global “Contact” of type “Vendor”.   

1. Note:  Do not modify the “Contact Type” for these “Contact” records or payment synch issues will occur.  
2. Note:  PolicyPort sends 4 claimant types (Claimant, Other, Vendor and Vendor/Claimant)
   1. PolicyPort “Claimant” equals CMS “Insured”
   2. PolicyPort “Other” equals CMS “Other Contact”
   3. PolicyPort “Vendor” and “Vendor/Other” equals CMS “Vendor” or contact type of “Vendor”.
      1. Based on 2. and 3. above.

c. Note:  New vendor records must be created manually in both applications as “Vendor”records do not imported into CMS from PolicyPort.

1. First, an authorized user should create the new vendor record in PolicyPort, making sure to take note of the “Tiva Payee ID” that is associated to the record upon its creation.
2. Next, an authorized user should create the new “Vendor” record in CMS, via the “Vendors” menu bar button, ensuring that the “Global” checkbox is selected and that the value entered within the “TIVA ID” field matches the “Tiva Payee ID” value in PolicyPort.  

4. If a party needs to be associated to the claim after it has already been imported into CMS, the “Contact” / “Vendor”must be added/associated to the claim manually in both the PolicyPort and CMS applications.

1. Note:  The additional party should be added to the claim in PolicyPort first so that the “Tiva Payee ID” from PolicyPort can be populated within the “TIVA ID” field of the CMS “Contact” record when adding it from within the claim’s “Contacts/Claimants”tab.  
   1. Note:  If the “TIVA ID” field within the “Contact” record CMS is invalid, meaning it is null or doesn’t match a record in PolicyPort, this “Contact” cannot be added as a payee when issuing a payment on the claim in CMS.

Managing Reserves and Payments 

Policy data will be imported into CMS from PolicyPort upon claim creation and will display within the claim’s “Policy” tab.  After which, reserves are managed and payments issued within the ClickClaims CMS application.  Synch issues commonly occur if reserves and/or payment data is updated directly within PolicyPort.

Note:  The information below provides details regarding the financial data synch process between ClickClaims and PolicyPort.   Please refer to the “ClickClaims Financials (Reserves and Payments) User Guide.pdf” for detailed instructions for managing reserves and payments within the ClickClaims CMS application.  

Reserves:

1. Reserves are exported from ClickClaims to PolicyPort approximately every 15 minutes.
   1. Note:  Updating Reserves directly within PolicyPort will result in synching issues between ClickClaims and PolicyPort.  If this occurs, a manager will need to submit a ClickClaims CMS Helpdesk support ticket for resolution.  
      1. A process will be ran to overwrite all of the claim’s financial data in ClickClaims with the claim’s financial data in PolicyPort.  This will include any pending reserve and/or payment requests.

Payments:

1. Any Payments submitted on the claim in CMS will be reflected on the claim in PolicyPort.
   1. TIP:   You cannot issue a payment in CMS unless the “Payee” selected has a value within the “TIVA ID” field of their “Contact” / “Vendor” record. Attempting to do so will cause a validation message to display upon clicking the button stating, “TIVA ID is required for primary payee” or “A Validation Error Has Occurred.  Additional Payee: ------- must have a TIVA ID.”

b. TIP:   In order to issue a payment to a mortgage company, the mortgage company must be set up as a “Vendor” in PolicyPort AND in CMS and must be associated to the claim on the “Vendors” tab with a “TIVA ID”.  Otherwise, the payment will not synch.

c. TIP:   The “Payable To” field in ClickClaims is read-only because PolicyPort looks at the TIVA ID of the payee and uses the name associated with that ID in PolicyPort when creating checks.  So, PolicyPort would override any changes that would be made within this “Payable To” field.

d. TIP:   The text entered within the “Remarks” field within the “Payment Request”section of CMS must be unique on each claim as this is used to identify unique transactions to prevent duplication if the payment needs to be stop paid or reissued.

1. If the text within the “Remark” field matches an existing payment transaction record on this claim for the same coverage and of the same amount, a validation message will display upon clicking the button stating, “There is already a payment for this claim with the same amount and remarks.  Please enter unique Remarks.”  

2. Once the payment has been sent to PolicyPort from CMS, the “Sent to TIVA” column within the claim’s “Payments” tab, as well as the “Financial” report, will contain an  icon if the synch was successful.

1. Hovering your mouse over this icon will display a tooltip stating, “Successful”.

b. If the payment did not successfully synch to PolicyPort, an icon will display within the “Sent to TIVA” column of the claim’s “Payments” tab, as well as the “Financial”report.

1. Hovering your mouse over this  icon will display a tooltip providing the error message received by PolicyPort detailing the reason for the failure.

1. Note:  The most common cause for a payment synch to fail is due to the TIVA ID either missing from the “Contact” / “Vendor” record in CMS or a mismatch between the “TIVA ID” field in CMS and the “TIVA Payee ID” in PolicyPort.
   1. To resolve this, locate the record in PolicyPort and make note of the “TIVA Payee ID”.
   2. Within CMS, correct the value within the related “Contact” / “Vendor” record.
   3. The payment will attempt to synch again the next time the importer processes.
2. Note:  Another common cause for a payment synch to fail is if the user submitting or approving reserves/payments in CMS does not have sufficient rights to change the financial data in PolicyPort.

3. ClickClaims queries PolicyPort regularly to see if previously exported payments have been updated in PolicyPort.  

1. VOID:  Payments with a “Voided” status in PolicyPort will only update the payment’s status to “Void” in ClickClaims if the payment has already been exported to PolicyPort as “Paid”.  Payments voided directly in ClickClaims will not update the payment’s status in PolicyPort to “Voided”.
   1. Note:  Even though voiding a payment in PolicyPort can update the payment’s status in CMS, the suggested workflow is that the voiding of a payment be manually completed first within ClickClaims CMS followed by manually voiding the payment within PolicyPort to prevent possible synch issues from developing.
      1. Important: An optional setting can be enabled which allows transactions voided in ClickClaims to be automatically synced back to PolicyPort. (See “Optional Mapping” above.)

4. Checks are issued in PolicyPort.  Once the check has been issued, the “Check #” and “Check Date”will be imported into ClickClaims.

1. Upon successful import, the payment’s status will be updated to “Paid” in CMS and the check information will display within the “Check Date” and “Check #” columns located within the claim’s “Payments” tab as well as the “Financial” report data grid.

Payment Items that Do Not Synch to PolicyPort

1. Credits (Subrogation/Salvage):  Credits will not synch between CMS and PolicyPort.   Credits should be issued in both applications independently.
2. Manual Check:  Submitting a payment as a “Manual Check” will not synch from CMS to PolicyPort.  If a manual check payment is submitted in CMS, this will also need to be reflected in PolicyPort manually.
3. Stop Payment:  Stop Payments will not synch between CMS and PolicyPort.  If a Stop Payment needs to be issued on a payment record, this must be completed within both applications independently.  

Out of Sync Financials

As stated previously in this guide, reserves should be managed and payments issued solely within the ClickClaims CMS application.  If reserves are modified or a payment issued directly in PolicyPort, for example, a synch issue will occur between the two systems causing conflicting financial data.    If financial data becomes out of synch, a ClickClaims CMS Helpdesk Support ticket should be submitted by an authorized user.  When applicable, E-Claim will utilize a tool which, when run, will void any outstanding payment transaction, including pending reserve and payment requests, and will overwrite the claim’s financials in CMS with the financial data located in PolicyPort.  Below are common causes of synch issues.

1. A claim is Closed within both systems, but then Re-Opened in PolicyPort only.
2. Reserves are modified in PolicyPort instead of CMS.
3. Payments are issued in PolicyPort instead of CMS.
4. A user issuing or authorizing Reserves/Payments in CMS doesn’t have the sufficient rights to do so in PolicyPort.