Historical claims
The SCE provides two mechanisms for sending historical claims to ClaimsXten. One is through the claim interface with the current claim, and the other is through the batch paid feed process.
Claim interface historical claimsThe Smart Claims Engine can send history claims with the current claim to ClaimsXten to support clinical editing. To identify the claims in the members history, SCE maps each claim line with a service group (also known as a service/benefit category) code based on the service group code defined in the Pega Foundation for Healthcare (PFHC).
Once the service group code is mapped for each line on the claim, SCE identifies and sends claim history based on the SCE system settings and configuration for ClaimsXten outlined below.
The ClaimsXten system settings available in the Business analyst and System manager portals provide the following settings to control the history claim submitted with the claim.
- ClaimsXten, send history – This defines if the SCE will send members history claims with the current claim through the interface. If this is switched on, then the history claims are retrieved and submitted.
- Allowed history claim lines – This defines the maximum number of claim lines allowed when sending history claims. If the claim lines retrieved exceed the maximum configured, an event code (SCX-0361) is raised on the claim. This is used to help limit the maximum payload size that can be sent to ClaimsXten to improve performance.
- Send history, max lines exceeds – This allows the historical claims to still be
submitted to ClaimsXten. The event code SCX-0361 is still raised on the claim
for review if appropriate.
If history claims are to be submitted, the CXTHistoryConfig decision table provides the configuration to determine which claims are to be retrieved based on the current claim.
The following conditions are configurable and use the
fields of the current claim to identify the type of history to retrieve:
- Service code groups. The SCE can also identify history claims when no service code group is present on the current claim. In this situation, the service group code is set to NONE.
- Claim form type
- Type of bill (2nd and 3rd Character of the bill type)
- Frequency code (4th Character of the bill type)
- Place of service
- Type of service
This table can be extended to add other fields as appropriate to the criteria.
Note: if any claim line is assigned more than one service group code, SCE will raise event code SCX-0115.
The CXTHistoryConfig decision table also defines the criteria to filter the history claims to send. The return actions include:
- Return – Include History or No History Required. If no history is required, then the claim will be submitted to ClaimXten without any history claims
- DaysAhead / DaysBehind – The history retrieval will filter claims based on the number of days ahead and/or days behind the current claim’s from and to service dates
- Service code groups – Filtering claims based on the listed service group codes. The SCE will also consider all service groups in the historical claims by using ALL.
- Across provider - If Across provider is set to N, only history claims with the same rendering provider at the claim header level as the current claim are sent. If Across provider is set to Y, the rendering provider is not considered when identifying the history claims.
- Claim status to include – Identify which claim statuses are used in the set of history claims.
The SCE will select the appropriate history claims to send based on the decision table return criteria.
Batch file for paid claimsThe SCE can also send a batch of paid and denied claims as part of the implementation. In this situation, the SCE has two configurations. In the ClaimsXten configuration screen in the portal, the claim statuses to include and claim line statuses to exclude for this batch feed can be identified. The activity CXT_BuildInboundXML_PaidFeed is used to create the batch file. This will need to be scheduled. The FTP application and dynamic system settings are used to configure the appropriate end points for ClaimsXten to receive these files. If the DSS setting IsCXTftpEnabled is set to true, the SCE will copy the outbound back file from the local Pega server to the ClaimsXten server in the configured folder.
![ClaimsXten historical claim status configuration](https://docs-previous.pega.com/sites/default/files/drupal/dita/out/3401/strategic-apps-user-guide/Content/SCE/Images/historical_claims2.jpg)
Once the data transform is executed, SCE generates the ClaimsXten request file for the paid (history claims) feed. The XML request file is generated in a batch mode so that it can be sent in a scheduled and systematic fashion to ClaimsXten.
SCE generates two files for the batch feed. One file is the batch paid file containing multiple history claims. The second file is an empty control file. ClaimsXten configuration employs a control file methodology to ensure the proper delivery and processing of files.
The control file is necessary for files sent to or from ClaimsXten. The control file is an ASCII text file (zero byte length is ideal) associated with every data file posted in the staging area. The control file is given the same name as its corresponding data file, but with the addition of the suffix (“.ctl.new”).The control file is used to trigger the file watcher to pick up the batch file and start processing. Each file sent to ClaimsXten must have a unique name.
Note:
- Claims are selected from last run of the batch paid feed to current send date, so that only new claims are added to the file.
- If present on the claim, the paid amount and paid date are sent would be on the populated paid feed.
- The SCE provides an extension point (CXT_DT_ClaimData_Paid_EXT) for any customer extensions needed for the paid feed.
Previous topic ClaimsXten integration points Next topic ClaimsXten response processing