Skip to main content


         This documentation site is for previous versions. Visit our new documentation site for current releases.      
 

Intake

Updated on December 10, 2021

The Smart Claims Engine supports a variety of claim intake mechanisms from 837 (Professional, Institutional and Dental), X12 and XML formats, APIs to create the claim, and user screens to manually enter claim data for adjudication. As part of intake, the claim internal control number (ICN) and appropriate receipt dates are assigned for SLA management.

The SCE has two versions of claims for adjudication: a production claim and a test claim. Once the claim intake has been completed, a work object is created, and an Object ID is created for the claim (prefixed as CLM- or TST-). Attachments (images or files) can be added to the claim as part of intake through client extension.

EDI/XML/API

The SCE supports electronic integration through file processing (837 EDI and XML) or via APIs.

  • Claim Files – The SCE supports files containing a batch of claims or a single claim. There are two steps to the file claims intake:
    • Parsing of claim files (batch or single claim) into a staging table.
    • Claim work object creation (once the claim is parsed successfully and all the appropriate X12 elements exist).
  • APIs - The SCE has two key APIs for claims intake. PostClaim and PutClaim. These APIs enables external systems to submit claim data to the SCE for new claim processing or perform an update to an existing claim.
Manual entry

The SCE has a user interface on the claims examiner portal enabling claims examiners to key a new claim in the system for adjudication. The ICN can be generated automatically or entered manually by the claim examiner.

Field validation

The SCE validates fields submitted on the transactions as part of intake to ensure that the claim can be created successfully. The types of errors validated during parsing include the following:

  • Data formatting – ensures that fields align to their type. For example, a date is correct, or that a string is not submitted in an integer field.
  • Data validation – where appropriate, data is also reviewed to ensure that the codes or qualifiers are correct. For example, the payer name entity qualifier is a 2, or that the individual relationship code is on the standard X12 list. More complex data validation, for example validating procedure codes or revenue codes is performed in the pre-adjudication.

Errors in parsing are logged for further review. Fields are also validated during manual entry and warnings and errors are displayed as part of the claim creation. Claims failing parsing validation are not submitted for adjudication.

Claim resubmission

The SCE identified if the claim being submitted is for a resubmission (adjustment or replacement) and will perform extra steps to match to the original claim and then perform, if appropriate, a void of the original claim, so that the replacement can be processed.

Have a question? Get answers now.

Visit the Support Center to ask questions, engage in discussions, share ideas, and help others.

Did you find this content helpful?

Want to help us improve this content?

We'd prefer it if you saw us at our best.

Pega.com is not optimized for Internet Explorer. For the optimal experience, please use:

Close Deprecation Notice
Contact us