Claim Status Inquiry and Response Standard

Follow

UHIN Claim Status Inquiry and Response Standard is compatible with all HIPAA requirements.

Purpose: The purpose of this Standard is to detail the Standard transactions for the transmission of health care claim status inquiries and response in the state of Utah. This transaction is intended to allow the provider to reduce the need for claim follow-up and facilitate the correction of claims.

Applicability: This Standard applies to all electronically submitted claim status inquiries and responses.

Detail:

The purpose of this standard is to (1) lay out general recommendations to payers and providers about handling the Claim Status Inquiry and Response (termed the 276/277) transactions, (2) set out the minimum data set that providers will submit in the 276 claim status inquiry, and (3) set out the minimum data set that payers will return on the 277 claim status response (4) reduce phone calls and encourage adoption (5) provide guidance for mapping internal codes to ANSI claim status codes.

  1. Standard Claim Transactions:

The UHIN Standard for electronic claim status inquiries and responses is the HIPAA ASC X12 276/277 005010X212 Health Care Claim Status Request and Response Implementation Guide.

See the Washington Publishing Company web site (http://www.wpc-edi.com) to purchase copies of the implementation guides in Adobe Acrobat.

  1. Addenda:

Utah will implement the Errata corrections for the Claim Status Request and Response implementation guides 005010X212.

  1. Definitions: For clarification the following are definitions used in this standard.
    • Tracking Number (TRN02 ): in the 276 is the provider key that the information contained in the claim is unique to the specific claim/inquiry used in CLM01 in the 837. This number could be the ‘invoice’ number or could be the provider account number. This number is returned to the provider to match inquiries with responses.
    • Date Range: refers to the date(s) that are sent on a claim where the service may span more than one calendar day.
    • Range of Dates: refers to a span of dates which includes more than one calendar day and may include several claims.
    • Payer Claim Control Number: Interchange Control Number also known as Payer Assigned Claim Number, Document Control Number, and Transaction Control Number etc.
  1. Detail
  • Providers are required to submit a Claim Status Tracking Number Segment (TRN02). This number is used to match the response to the inquiry.
  • Current status codes must be sent in both the request and response. Use of invalid codes may result in a transaction being rejected.
  • Processing Batch and Real-time All payers must support both real-time and batch submissions from providers. Response time for Real-Time transactions must be 20 seconds or less as per the CORE operating rules. Response time for Batch transactions must be 24 hours or less.
  1. Building a Request Transaction

In the Claim Status Request Transaction the provider must send certain information to the payer in order for the request to be matched in the payer’s system. This matching process may be done differently by each payer. However there are several common data elements that payers have agreed are of critical value. Table I identifies the general matching elements. Table II has a complete listing of the ‘Required’ elements in a request. Table III of the Standard has the ‘Required’ elements of a Claim Status Response.

  • There are several ways for a provider to try and match a claim in the payers system. The key for matching an inquiry to a specific claim in the payers system would be to send in the inquiry the Payer Claim Control Number /Internal Control Number (ICN). This is the payer’s assigned Claim Control Number (CCN), also known as, Document Control Number (DCN). The ICN is sent to the provider when claims have been accepted into the payer’s adjudication system in the Claim Acknowledgment Transaction (277CA – see UHIN Claim Encounter/Acknowledgement Standard).
  • If providers keep the ICN and includes the number in the Claim Status Request Transaction then they will increase the probability of matching the request to the claims in the payers system.

 

Table I - General matching elements

 

Request includes

Matching Process

 

1

  • ICN (when known) Primary Key to Payers System
  • Additional required elements
    • Information Receiver ID
    • Information Source ID
    • Provider/Organization Name
    • National Provider Identifier or Atypical Provider Identifier
    • Subscriber ID
    • Patient Last Name, First Name, Date of Birth (Send for Subscriber when Subscriber is the Patient)
    • Date of Service
    • Claim Status Tracking Number (TRN02)

Matching requests to specific claims in the payers system requires that the request passes several levels of matching.

Level I Matching:

  1. The Information Receiver ID (Requester)*
  2. The information Source ID (Payer)*

Level II Matching

  1. Provider/Organization Name
  2. National Provider Identifier or Atypical Provider Identifier

Level III Beneficiary Matching

  1. Subscriber Id
  2. Patient demographics

Level IV Claim Matching

  1. ICN
  2. Any of the other required elements

Level V Line Level Matching

  1. ICN
  2. Total Charge (CLM02)
  3. Service line detail as outlined in box #3

 

 

 

 

 

 

*Currently this data is the Trading Partner ID

 

2.

When Request Does not include ICN

  1. All of the additional required elements in Box 1.
  2. Total Charges (CLM02)

 

3.

Request is for a specific service line

All of the items in Box 1 and / or in Box 2

And the following items as submitted on the original claim

a.    Procedure code

b.    Modifiers

c.    Line item charge

d.    Revenue Code

e.    Line Item Control Number

f.     Line level Date of Service

 

  1. Building a Response Transaction

The goal of a response is to clearly identify to the provider what has happened to the claim at the point in time that the inquiry was received. The response should inform the provider of the status and why the claim is in the current status. If a pending code is being sent in the response, then all the information for why the claim is pending should be sent in order to convey all information required for claims processing, (if there are multiple pended reasons, then multiple STC segments must be sent). When a denied status is sent then the reason for the denial must be returned in the 277. See examples in Appendix A.

 

Table II - Minimum and Recommended Data Set for 276 Claim Status Request

Claim Status Inquiry (276) – Required Elements

Name of Data

X12 Loop--Seg-element

Comments

Payer ID

2100A--NM108-09

REQUIRED DATA ELEMENT

Use PI in NM108, Use UHIN

Trading Partner Number in NM109

Information Receiver ID

2100B--NM108-09

REQUIRED DATA ELEMENT

Use 46 in NM108, use UHIN Trading Partner Number in NM109.

 

This is who should receive the 277 response

Service Provider Name

2100C—NM101-03

REQUIRED DATA ELEMENT Provider should use whatever was on the submitted claim.

Service Provider ID

2100C—NM108-09

REQUIRED DATA ELEMENT

This is the National Provider Identifier or the Atypical Provider Identifier for the provider sent in the service Provider Name field.

Trace Number

2200D/E—TRN segment

REQUIRED DATA ELEMENT

As a minimum the sender, should provide a unique request trace number or a unique provider assigned claim number

Payer Claim Control Number (ICN)

2200D/E – REF02

when REF01 =1K

Required to be sent when available. [For UHIN payers this claim identifier is sent to the provider in the 277CA for accepted claims.]

Total submitted charges

2200D/E – AMT segment

when AMT 01 =T3

Required if no payer claim control number is sent. This value is not precluded from being sent when the claim number is used.

**This would be the total charges reported on the original claim (CLM02).

Claim service date

2200D/E – DTP segment

Required if no payer claim control number is sent. This value is not precluded from being sent when the claim number is used.

The service line information below would only be used if the provider were inquiring about the status of specific service lines. However, not all provider systems will be able to inquire about specific lines (e.g., some institutional providers)

Service Line information

2210D/E – SVC segment

Required if the provider has an inquiry about specific service lines.

Line Item Control Number

2210D/E – REF segment

Required if the provider sent this on the claim

Service line date

2210D/E – DTP segment

Required if the 2210 loop is used.

 

Table III - Minimum and Recommended Data Set for 277 Claim Status Response

Included in Appendix A of this document are examples of responses. The examples focus on the use of codes in the STC segments and concepts for responding to a request. They are not to be considered required for implementation. They have been created for demonstration purposes only.

 

Claim Status Response (277) – Required Elements

Name of Data

X12 Loop—Seg-element

Comments

Payer ID

2100A--NM108-09

REQUIRED DATA ELEMENT

Use PI in NM108, use UHIN Trading Partner Number in NM109

Payer Contact Information

2100A-- PER segment

REQUIRED DATA ELEMENT

This is individual/department the payer wants the provider to contact if there is a question regarding the status

Information Receiver ID

2100B--NM108-09

REQUIRED DATA ELEMENT

Use 46 in NM108, use UHIN Trading Partner Number in NM109

Subscriber Name

2100D--NM101-03

REQUIRED DATA ELEMENT

Payer will pull the information from their own files to populate.

Subscriber ID

 

2100D--NM108-09

REQUIRED DATA ELEMENT

UHIN recommends that payer should create a policy on returning the subscriber ID from the payer system if the providers send an incorrect number.

Dependent Name

2100E--NM101-03

Required if dependent loop is used. Payer will pull the information from their own files to populate.

Trace Number

2200D/E—TRN segment

REQUIRED DATA ELEMENT

Payer must send back what was sent in 276

 

This is the number used to link a 276 to a corresponding 277.

Payer Claim Number

2200D/E REF

REQUIRED when known

When request data is sent that allows for an incomplete match in the payer’s system, (i.e. data required by the payer to finalize the match such as incorrect DOB) using “E0” in STC01-1 is recommended. In this case, STC01-2 should be specific to the missing data.

 

Example:     STC01-1 = E0 Response not possible - error on submitted request data

STC01-2 = 158 Entity’s Date of Birth

STC01-3= QC Patient

When a request is sent without a payer claim number and the payer finds the claim the responding 277 contains:

REF01=1K and the REF02 = payer claim number

When a request is sent and the payer can match some of the data elements but cannot find a claim for the information sent, it is recommended an “A4” be used in STC01-1. In this case, STC01-2 should be as specific as possible.

Example:

STC01-1 = A4 Acknowledgement/Not Found-The claim/encounter cannot be found in the adjudication system.

STC01-2 = 35 Claim/Encounter not found

Medical Record Number

2200D/E REF

Required if sent on 276

The service line information below would only be used if (1) the provider sent an inquiry about specific service lines, (2) if the claim has been split by the payer (‘split’ meaning financially split into two or more separate checks/payments/EOBs), or (3) if the payer has information about the status of specific service lines that is different than the status of the entire claim.

Service Line information

2220D/E—SVC segment

If the request was claim level and the payer is returning line level status information, then pull the data from the claim.

Line item control number

2220D/E REF

If the request was claim level and the payer is returning line level status information, then pull info from claim.

Service line date

2220D/E DTP

If the request was claim level and the payer is returning line level status information, then pull info from claim.

 

  1. IMPLEMENTATION ISSUES

General

  • One goal of this standard is the reduction of claim status phone calls for both the payer and provider. When providers ask about a claim they may already know the status of the claim. The question that is really being asked is; What can/needs to be done to
    • Get the claim processed if pended, or
    • Get the claim reprocessed and paid if it was originally denied?
  • In the Request and Response transactions not all service line information is required to be sent or responded to.
    • While providers may do a specific line inquiry on one or more lines of a claim, payers may choose to respond only at the claim level. Payer system support and policies can impact whether the response is provided at the claim level or line level.
    • If the information at the claim level provides the same response for one or more lines of service, the payer may choose to report only those lines that are problematic rather than on every individual line of service.
  • There is a direct correlation between the response process time and adoption/usage of the transaction. The recommendation from the Claim Status Subcommittee is to return all batch responses immediately.
    • If a real-time response is desired by the provider then a real-time request must be sent in.

Payers

  1. It is recommended that payers understand current processes used for responding to inquiries through the phone or other methods.
  2. It is recommended that the bench mark for the electronic process is to equal what the current manual process is today. The electronic process should equal or exceed the information that is available via other methods (phone) in order to encourage adoption.
  3. It is recommended that payers try to match requests using the ICN (when possible) and some combination of other data elements sent in the request (see Table I General Matching Elements- Matching Process). Payers may want to create a process that balances business needs with the goals of reducing phone calls.
  4. It is recommended that payers consider Matching Policies for these types of situations
  • Mismatch: Payers should consider what to do when the provider sends incorrect matching data elements. For example if the ICN, Trading partner and Subscriber can be matched, but not the Provider NPI to the provider name. 

STC01-1=E0 Response not possible - error on submitted request data

STC01-2 = 562:1P Entity’s National Provider Identifier (NPI): Provider

  • Partial Match: Payers should consider what to do when the provider sends most or part of the matching data elements. If the payer can make an accurate match with 3 out of 4 data elements
    • Returned Information: The payer has the option of returning a response with corrected information as opposed to returning what was received in the request.
    • Range of Dates: Types of claims may impact the response returned when a date is part of the matching process. Claims may have a wider date range than the request contained.
  • It is required that when the Status Code being used has the word “entity” in the description then the payer must provide the appropriate entity code in the STC segment. An entity code can be used if appropriate even when the word entity does not appear in the claim status description.

Example:

P3:123:IL

Pending/Requested Information – the claim or encounter is waiting for information that has already been requested from entity: Insured or Subscriber

The word “entity” in the status code description should be able to be replaced with the entity code description. The response will be read as:

Pending/Requested Information – the claim or encounter is waiting for information that has already been requested from Insured or Subscriber

Incorrect usage:

When the payer is trying to let the provider know that their provider Id is invalid, often times the entity code used is incorrect. For example:

          A3:124:40

Acknowledgement/Returned as unprocessable claim-The claim/encounter has been rejected and has not been entered into the adjudication system; Entity's name, address, phone and id number: Receiver.

The response will be read as

Acknowledgement/Returned as unprocessable claim-The claim/encounter has been rejected and has not been entered into the adjudication system; Receiver name, address, phone and id number.

Response should be sent as

A3:124:1P

Acknowledgement/Returned as unprocessable claim-The claim/encounter has been rejected and has not been entered into the adjudication system; Provider name, address, phone and id number.

  • Payers will cross walk their internal claim denied codes/edits to the claim status codes.

Requests for new or changes to existing Claim Status Codes should be brought to the Standards Committee for coordination and support from payers and providers.

Payers may reject inquiries that do not have an NPI number or an Atypical Provider Identifier that can be matched in the payer system. Providers should make every effort to send NPI numbers identifiers known to the receiving payer.

 

Providers

  1. A caution to providers: When conducting an inquiry for Range of dates;
    • Some payers may only match exact dates of service in a request and all range of date inquiries may be returned as not found.
    • Alternatively the payer may choose to respond with information for all claims that fall within the range of dates of the inquiry. When the 276 does not uniquely identify the claim within the payer’s system the response may include multiple claims that meet the identification parameters supplied by the requester.
  2. If the search is complicated or has to be completed by searching several databases (archived claims) then the payer may need to return a response that states that the claim is “not available electronically” and the request needs to be conducted through another media – phone, or letter.
    • For this response the Category “A4” [Acknowledgement/Not Found-The claim/encounter cannot be found in the adjudication system.] with a Status Code of “0” [Cannot provide further status electronically] could be used.

 

 

 

Original

A* 1 V2.1

A* V 2.2

V3

A* V

3.1

V.2

ORIGINATION DATE

03/23/01

06/19/03

6/29/05

10/14/09

04/18/2011

1/8/2015

APPROVAL DATE

09/09/02

11/12/03

6/08/06

11/3/2010

5/18/2011

5/6/2015

EFFECTIVE DATE

10/09/02

12/13/03

7/08/06

12/3/2010

6/18/2011

6/6/2015

 

 

 

 

 

APPENDIX A

Examples

The implementation guide only requires that the Claim Level (2200D) STC segment be returned. When creating the STC segment the payer can choose to use a combination of the STC01, 10 or 11 elements to create a response. In addition the only codes required to be used in the STC elements are the Category and Status Codes. The Entity Code is optional, unless the Status Code used has the word ‘entity’ and then the Entity Code is required.

The manner in which these codes are used is partially dependent upon the payer’s business policies and system support. Any one status or edit could generate several different responses. The different responses can provide different meaning to the provider thereby facilitating different actions. Payers should use codes that best explain the status and any follow-up action needed from the provider.

Please note that these codes are updated three times a year and any code may become discontinued or changed after this writing. These examples are only for demonstration purposes and should not be considered required.

 

This table illustrates responses to incomplete or invalid inquiries where the payer cannot match a claim based upon the information sent in the inquiry. It is important to note that since the request would not be matched only a Claim Level Response (2200D) could be returned.

Table II - Incomplete or invalid requests

 

Response

Payer Edit

1.      

Request is too general – e.g. Range of dates rather than a specific date

A4:485

Acknowledgement/Not Found – the Claim encounter cannot be found in the adjudication system: More information than can be returned in real time mode. Narrow your current search criteria.

A4:187

Acknowledgement/Not Found – the Claim encounter cannot be found in the adjudication system: Date(s) of service.

Specific claim cannot be matched with a range of dates.

TRN*Trace Number~

STC*A4:485*20120701**50*0*****A4:187~

2.      

Provider is not identifiable

A4:21

Acknowledgement/Not Found – the Claim encounter cannot be found in the adjudication system: Missing or invalid information.

D0:135

Entity not found – change search criteria: Entity’s commercial provider id.

Request is missing provider number

TRN*2*Trace Number~

STC*A4:21*2003*0701**125*0*****D0:135~

 


Table III illustrates responses for Claim and Line level responses using one or more STC segments and one or more STC elements. Using a combination of segments and elements can help separate different status concepts that may need to be relayed. It is critical that the “one status concept per STC segment” be maintained so that the receiver of the 277 knows when a concept begins and ends in their translation of the codes for additional explanation see Section 6 page 3. The examples in Table III include a combination of repeating loops and elements to illustrate a clear response to the provider.

Table III - Claim and Line Level Responses (claim remains whole)

 

Response

Status - Claim

1.      

Additional information was not previously requested.

P1:21

Pending/In Process – the claim or encounter is in the adjudication system: Missing or invalid information.

P1: 218

Pending/In Process – the claim or encounter is in the adjudication system: NDC number.

This claim is being pended for a missing or invalid NDC Code. This claim is pended until this information is received.

 

CLAIM LEVEL RESPONSE EXAMPLE

TRN*2*Trace Number~

STC*P1:21*20030701**100*0****P1:218~

This response does not designate which line the requested information applies to.

---------------------------------------------------------------------------------------

CLAIM LEVEL AND LINE LEVEL EXAMPLE

TRN*2*Trace Number~ STC*P1:21*20030701**100*0~

SVC*PLACE HOLDER FOR LINE DETAIL~

STC*P1:218*20030701~

This response applies the request to a specific line.

                                               

 

Response

Status - Claim

2.      

Additional information was previously requested.

P3: 21

Pending\Requested Information – The claim or encounter is waiting for information that has already been requested: Missing or invalid information.

R3:254

Requests for additional information/claim/line-requests for information that could normally be submitted on a claim: Primary diagnosis code.

R1:123:1P

Requests for additional information/Entity Requests : Additional information requested from entity : Provider

The principle diagnosis on this claim cannot be used. This claim is pended until the provider resubmits a valid principle diagnosis.

CLAIM LEVEL EXAMPLE

TRN*2*Trace Number~

STC*P3:21*20030701**100*0****R3:254*R1:123:1P~

 

Additional information was not previously requested.

P1: 21

Pending\In process – the claim or encounter is in the adjudication system: Missing or invalid information.

P1:254

Pending\In process – the claim or encounter is in the adjudication system: Primary diagnosis code.

CLAIM LEVEL EXAMPLE

TRN*2*Trace Number~

STC*P1:*20030701**100*0****P1:254~

3.      

Additional information was previously requested.

P3: 21

Pending\Requested Information – The claim or encounter is waiting for information that has already been requested. Missing or invalid information.

P3:298

Pending\Requested Information – The claim or encounter is waiting for information that has already been requested. Operative Report.

R1:123:1P

Requests for additional information/Entity Requests : Additional information requested from entity : Provider

Claim is pended waiting for an operative report from the provider

CLAIM LEVEL EXAMPLE

TRN*2*Trace Number~

STC*P3:21*20030701**100*0****P3:298*R1:123:1P~

 

 

 

Response

Status - Claim



4.      

This response includes the request

P1:21

Pending/In Process – the claim or encounter is in the adjudication system: Missing or invalid information.

R4:298

Requests for additional Information/Documentation-Requests for additional supporting documentation: Operative report

Claim is pended, waiting for an operative report from the provider.

CLAIM LEVEL EXAMPLE

TRN*2*Trace Number~

STC*P1:21*20030701**125*0*****R4:298~

------------------------------------------------------------------------------------------

CLAIM AND LINE EXAMPLE

TRN*2*Trace Number~

STC*P1:21*20030701**125*0~

LINE LEVEL

SVC*PLACE HOLDER FOR LINE DETAIL~

STC*R4:298*20030701~


5.      

This response includes a request

P1:21

Pending/In Process – the claim or encounter is in the adjudication system: Missing or invalid information

P1:318

Pending/In Process – the claim or encounter is in the adjudication system: X-ray.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - -

R4: 318

Requests for additional Information/Documentation – Requests for additional supporting documentation: X-rays.

Claim is pended waiting for Dental x-rays from the provider

CLAIM LEVEL EXAMPLE

TRN*2*Trace Number~

STC*P1:21*20030701**100*0****P1:318~

TRN*Same trace number as above~

STC*R4:318*20030701**100*0~

------------------------------------------------------------------------------------------

CLAIM LEVEL AND LINE LEVEL EXAMPLE

TRN*2*Trace Number~

STC*P3:21*20030701**100*0****P3:318~

SVC*PLACE HOLDER FOR LINE DETAIL~

STC*R4:318*20030701~

 

Table IV illustrates responses for split claims using both the Claim Level (2200D) and Service Line loops (2220D).

Table IV provides examples of ‘split’ claims. Example 1 demonstrates a claim that has not received payment. Example 2 demonstrates a claim that has received partial payment.

Table IV - Split Claim Responses

 

Response

1.      

Claim level response without line item detail and repeating STC Segment

Claim Level Response

A5:11

Acknowledgement/Split Claim – The claim

Encounter has been split upon acceptance into the adjudication system: Claim contains split payment.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

R4 :298

Requests for additional Information/Documentation: Operative report.

CLAIM LEVEL EXAMPLE

TRN*2*Trace Number~

STC*A5:11*20030701**100*0~

TRN*Same trace number as above~

STC*R4:298*20030701**100*0~

 

2.      

Claim level response with line item detail

----------------------------------------CLAIM LEVEL-------------------------------------------

A5:72

Acknowledgement/Split Claim – The claim

Encounter has been split upon acceptance into the adjudication system: Claim contains split payment.

F1:47

Finalized/Payment – the claim/line has been paid: Internal review/audit - partial payment made.

------------------------------------------LINE LEVEL-------------------------------------------

LINE 1

P0:95

Pending Adjudication Details: Requested additional information not received.

R4 :298

Requests for additional Information/Documentation: Operative report.

LINE 2

F1:67

Finalized/Payment – the claim/line has been paid: Payment made in full.

CLAIM LEVEL WITH LINE ITEM DETAIL EXAMPLE

TRN*2*Trace Number~

STC*A5:72*20030701**100*0~

STC*F1:47*20030701**100*0~

SVC*PLACE HOLDER FOR LINE 1 DETAIL~

STC*P0:95*20030701*** ~

STC*R4:298*20030701~

SVC*PLACE HOLDER FOR LINE 2 DETAIL~

STC*F1:67*20030701**25*15~

 

 

 

 

One Concept response

More than one concept response

EDIT: This claim is pended as the primary diagnosis on this claim cannot be used. The provider must submit the diagnosis or illness for each service rendered.

EDIT: This claim is pended until the patient sends information as to how, when, and where the accident occurred. If this is auto related, the name of the auto carrier is needed.

P1 :21

Pending/In Process – the claim or encounter is in the adjudication system: Missing or invalid information.

P3:254

Pending/Requested Information – the claim or encounter is waiting for information that has already been requested Primary diagnosis code.

P3:123:QH

Pending/Requested Information – the claim or encounter is waiting for information that has already been requested: Additional information requested from entity: Physician

P1:21

Pending/In Process – the claim or encounter is in the adjudication system: Missing or invalid information.

P4:248

Pending/Patient Requested Information: Accident date, state, description and cause

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 

P3:171:

Pending/Requested Information – the claim or encounter is waiting for information that has already been requested: Other insurance coverage information (health, liability, auto, etc.)

P3:123:IL

Pending/Requested Information – the claim or encounter is waiting for information that has already been requested from entity: Insured or Subscriber

STC*P1:21*20030701**50*0*****P3:254*P3:123:QH~

STC*P1:21*20030701**50*0*****P3:123*QC*P4:248~

STC*P3:171*20030701**50*0*****P3:123*IL~

 

Recommendation for use of pending category codes:

P0 - Pending: Adjudication/Details-This is a generic message about a pended claim. A pended claim is one for which no remittance advice has been issued, or only part of the claim has been paid.

This code is not recommended to be used in a 277 response. This code may be better used in a 277 Claim Acknowledgement.

P1 - Pending/In Process-The claim or encounter is in the adjudication system.

This category code should be used when the payer wants to let the provider know that the claim is in the regular adjudication cycle. Contact from the provider is not necessary and will not speed up the processing of the claim.

P2 - Pending/Payer Review-The claim/encounter is suspended and is pending review (e.g. medical review, repricing, Third Party Administrator processing).
This category code should be used when the claim is waiting for internal review or processing before the claim is finalized. Contact from the provider is not necessary and will not speed up the processing of the claim.

P3 - Pending/Provider Requested Information - The claim or encounter is waiting for information that has already been requested from the provider. (Note: A Claim Status Code identifying the type of information requested, must be reported)
This category code should be used when the payer is requiring the provider to provide the additional information before further processing of the claim can be done.

P4 - Pending/Patient Requested Information - The claim or encounter is waiting for information that has already been requested from the patient. (Note: A status code identifying the type of information requested must be sent)

This category code should be used when the payer is notifying the provider that a request has been sent to the patient. The provider may want to follow-up with the patient to complete  processing of the claim.

P5 - Pending/Payer Administrative/System hold

This category code is sent when the payer is pending the claim for an internal reason and the provider follow-up action is to contact the payer.

 

 

Click below to download a copy of this document.

0 out of 0 found this helpful

Comments

0 comments

Article is closed for comments.