Best Practice Recommendation for

Transcription

1 Best Practice Recommendation for Requesting and Receiving Claim Status Information ( Transaction & Web Access) For use with ANSI ASC X12N 276/277 (005010X212) Health Care Claim Status Request and Response Technical Report Type 3 Version 1.8

2 Issue Date Version Explanation Initial Release (Clarification amendments possible as validation methodology is developed) Health plans will respond with a 999 Acknowledgement (pg 11) Clarification of a unique claim (page 9) Clarify that any BPR information available from customer service must match the BPR information that is on the web and in the transaction. However, customer service is not required to have all of the BPR information. (pg 3) Clarify that summary information will be displayed for all matching claims up to any system limitation. If limitation, then a message will also be displayed (page 11) Correct 1 st bullet point under #3 so that it says response rather than inquiry (pg 8) Remove notes about previous method of validation and pre-5010 implementation comment (pgs. 5-6) Add provider wait 72 hours before sending When matching requests to claims - the health plan will use the NPI submitted on the 276 as both the Rendering Provider and the Billing Provider to try to find a valid match to a submitted claim. (pg 6) A program of the Washington Healthcare Forum operated by OneHealthPort i

3 Table of Contents Access Methods: Web Site & HIPAA Transaction:... 2 Transaction Compliance with HIPAA Mandated TR3:... 2 Intended Scope of the Claim Status Interaction:... 3 Best Practices for Provider Organizations:... 4 Best Practices for Health Plans... 5 Matching Logic:... 6 Reporting Status Information:... 8 Web Based Access to the Information: Transaction Exchange of the Information: Appendix: Status Coding by Business Scenario: A program of the Washington Healthcare Forum operated by OneHealthPort ii

4 Best Practice Recommendation (BPR) Requesting and Receiving Claim Status Information Topic: Goals: Summary: Applicability: Notes: Minimum standard set of claim status information 1) Define acceptable inquiry and response information that will allow a provider to determine the processing status of a previously submitted claim 2) Reduce the need for telephone calls to get information about a claim This document outlines the minimum standard set of a) claim status inquiry information for matching a status request to a previously submitted claim, and b) status information for the claim. The information and matching logic should guide provider-health plan interaction using the health plan's web site directly or using the 5010v of the HIPAA transaction set. All providers and health plans are encouraged to follow these Recommended Best Practices. However, providers should be aware that interaction with the following organizations may not be consistent with this best practice: Providers and Medicare: Information about this programs is available at: Providers and Clearinghouses: Providers should note that clearinghouses, and other intermediaries, may implement the transaction differently than what is outlined in this BPR Document. The clearinghouse may reformat the health plan s transaction before passing it along to the provider. This reformatting may add unforeseen complexity to the process of transaction exchange Self-funded plans FEP Blue Card NASCO And there may be others 1) The terms health plan, payer and payor will be used interchangeably throughout this document to refer to an organization that, in some way, processes claims that are submitted by provider organizations. A program of the Washington Healthcare Forum operated by OneHealthPort 1

5 Access Methods: Web Site and HIPAA Transaction This BPR outlines a set of claim status information, and associated matching logic, that should be communicated between health plans and provider organizations. This information will be communicated via two different methods: a) on the health plan s web site, and b) in a HIPAA transaction exchange This full set of BPR information must be available on the web site and in the transaction and it must match. Some or all of the BPR information may be also available from a Customer Service type department. Whatever BPR information is available from customer service must match the BPR information that is on the web and in the transaction. The information outlined in the BPR must be communicated via a health plan's transaction and web site, though the formatting/presentation of the information may vary depending upon the method. For a specific patient at a given point in time, the information presented in the transaction and on the web must match, though there doesn't need to be a specific field on the web site that exactly corresponds to every field in the transaction. As an example, the BPR calls for the health plan to provide status information. In the transaction, status information will be communicated by using codes in STC01-1 & STC01-2. On the web site, there may not be a field for a coded value. Rather, that same information may be communicated using a text description that corresponds to the HIPAA code. The web site content is not limited to the information that can be contained in the transaction. A health plan's web site and their transaction must convey the set of information outlined in this BPR. However, on their web sites, health plans may expand beyond the set of information that can fit in the transaction. All of the claim status information that is displayed on a health plan's web site should be clearly conveyed and easily accessible to a provider. Bottom line: The BPR outlines a set of information that must be available in a consistent manner on the web site and in the HIPAA transactions. Some or all of that information may also be available from a customer service type department (if one exists). Whatever BPR information is available from customer service must match the BPR information on the web and in the transaction. Information available from any of the above sources is not limited to BPR information and one source may have information that is not available from another source. However, all reported BPR information must be consistent across the different sources from which it is available. Transaction Compliance with the HIPAA Mandated TR3 This BPR Document is intended to accompany the Technical Report Type 3 (TR3), previously referred to as Implementation Guide, for the ASC X12N Health Care Claim Status Transactions. A complete version of the TR3s can be purchased at A program of the Washington Healthcare Forum operated by OneHealthPort 2

6 Health plans must be able to receive a compliant 276 transaction and produce and send a compliant 277 to the provider or clearinghouse. The HIPAA mandated TR3 specifies the complete set of requirements that must be met in order to be compliant. One of the objectives of this BPR document is to recommend practices for how the transactions should be used to accomplish specific business objectives related to the processing and reporting of claim status information. This document assumes that: 1. The reader is familiar with the HIPAA transaction and the related X12 TR3 and has experience implementing the transaction. 2. The creation and exchange of the transactions by the health plan and provider organization will comply with all requirements laid out in the TR3. As such, the intent of this BPR document is to expand upon and NOT to repeat the requirements contained in the TR3. However, requirements from the TR3 will be included in this document when the requirement was in the 4010A1v but was typically not followed OR is new to the 5010v and, as such, may be overlooked in the implementation process, AND would significantly enhance administrative simplicity if it was followed. In these cases, the appropriate section of the TR3 will be referenced, but the details of the requirement will not be repeated. Intended Scope of the Claim Status Interaction Within Scope of this Document: Via this interaction, Claim Status information will be exchanged for claims that have been accepted for processing by the health plan. In addition to confirming receipt of their claim, it is expected that providers will be able to request and receive answers to the following questions: What is the status of my claim, and the associated claim lines, in your system? Is there anything I need to do to get my claim processed? It is expected that providers can retrieve information on any submitted claims. This includes claims that were submitted on paper as well as those that were submitted electronically. Health Plans will provide status information on claims that are on file in their system. Health Plans will attempt to identify a previously submitted claim using the information that is submitted in the 276 request. The likelihood of a Health Plan identifying the right claim the first time will be increased to the extent that the conventions outlined in this document are followed by providers in preparing a 276 request. The information provided will reflect the status of the claim and/or claim line(s) at the point in time the request is made. The status of the claim, or claim line, may change. A program of the Washington Healthcare Forum operated by OneHealthPort 3

7 Outside Scope of this Document: Some health plans may automatically send claim status information to providers without the providers making a specific claim status inquiry. However, that capability is outside the scope of this BPR. Detail information explaining how the claim was adjudicated or why certain amounts were/were not paid WILL NOT be provided. Answers to those types of questions will be contained in the Remittance Advice (835) transaction. While detailed financial information will only be provided in the Remittance Advice (835) transaction, the Health Care Claim Status s will provide general information about how the claim was adjudicated or why it was denied. In some cases, a claim that was electronically submitted by a provider may not be accepted for processing by the health plan's system. In these situations, health plans may/may not transmit reports to the submitting provider about these claims (e.g. accept/reject reports.) This practice is outside the scope of this BPR. Information about the health plan policy/practice in this regard will be available from the health plan. Best Practices for Provider Organizations Prior to submitting a 276 transaction for a submitted claim, providers will wait at least 72 hours after receipt of the 999 transaction that is associated with that accepted claim. The inquiry should contain the minimum necessary information to get the exact information that is wanted. If the inquiry information is general, status information on a broad set of claims is likely to be returned. If the inquiry information is very specific, status information on a more select set of claims is likely to be returned. Information such as the following will typically be submitted to identify a claim: Provider of Service - Either the entity that originally submitted the claim (Billing Provider) or the entity that provided or participated in some aspect of the health care (Rendering Provider). Patient Name Patient Control Number (a claim specific number for a unique patient that was assigned by the provider and submitted on the claim) Patient Date of Birth Health Plan's Member Identification Number (assigned by the health plan for the subscriber or dependent as appropriate to the health plan) Date(s) of Service A program of the Washington Healthcare Forum operated by OneHealthPort 4

8 Considerations when inquiring about claims: The response time to complete the inquiry will be impacted by the amount of information requested. For example, the fewer claims requested in an inquiry, the faster the response time. Including the payor's claim number in the inquiry, if it is available, will help to insure an exact match to a previously submitted claim. However, if the payor's claim number is entered in the inquiry, information on any associated split claims or adjusted claims may not be found and returned. Including more specific information, such as 'Claim Amount', can result in the desired claim not being found, e.g. if the health plan split their claim. Considerations when a match is not found If the inquiry does not result in a match to a submitted claim, o Claims may be submitted to a health plan for a member that no longer has eligibility coverage. The health plan may delete that claim from their system and send the provider a notification letter. This claim will not be found with a claim status inquiry. o Some or all of the patient's identifying information entered on the inquiry may be different than the identifying information contained in the health plan's system, e.g. there may be a variation in the patient's name and/or date of birth. The next step would be to verify eligibility information in order to identify any discrepancies between the provider and health plan systems. When inquiring on a claim, providers should use the patient's identifying information contained in the health plan system to ensure that a match is found. If an inquiry using rendering provider does not result in a match, using the billing provider instead may result in a match. This situation occurs most frequently when lab, radiology, etc. services were provided by an ancillary service provider rather than in a physician's office. Best Practices for Health Plans In a number of cases a health plan will be able to match a provider's inquiry to one or more claims that are in their system without using all data elements submitted in the inquiry. In these situations a match may be made even if the claim information doesn't exactly match every data element submitted by the provider. If a provider includes a Patient Control Number in their claim status inquiry, the emerging best practice is for the health plan to only return a claim if there is a match on Patient Control Number. Further experience with Patient Control Number as a search criteria element will be of value in assessing the usefulness of this practice. A program of the Washington Healthcare Forum operated by OneHealthPort 5

9 If the information submitted by the provider in the inquiry matches the information that was submitted on the associated claim, the health plan should respond with status information for the associated claim. One exception may be the case where the patient identifying information in the provider's system does not match the identifying information in the health plan's system. In these cases, the identifying information in the health plan's system must be used in the inquiry to ensure a match. Matching Logic The Health Plan's claims processing system will use the set of inquiry information to try to match a claim status inquiry to a previously submitted claim. At least the minimum set of inquiry information must be available to the health plan to ensure that a claim can be found. Additional information contained in the inquiry may be used by the health plan to determine the specific information to be returned. 1. If the inquiry CONTAINS the patient control number, the health plan uses the patient control number as part of their search criteria, and the other data elements used by the health plan to ensure patient privacy match... This inquiry will only return status information on the claim or claims that are associated with the provider assigned patient control number. For example, more than one claim may be returned if the originally submitted claim was split or adjusted by the health plan. If the health plan cannot match the patient control number contained in the inquiry to a claim within their system, a not found status will be returned. 2. If the inquiry DOES NOT CONTAIN the patient control number or the health plan s identifying claim number, OR the inquiry does contain one of these and the health plan does not use it as part of their search criteria... A combination of provider-of-service AND patient AND date(s) of service on the inquiry MUST MATCH a combination of a provider-of-service AND patient AND date(s) of service on a submitted claim. For a specific patient, multiple matches by provider and dates of service are possible. a. When matching for a provider-of-service, The provider-of-service in the inquiry must match the billing/rendering provider on the claim. Since the TR3 allows for the NPI of either the Billing Provider or the Rendering Provider to be submitted on the 276, the health plan will use the NPI submitted on the 276 as both the Rendering Provider and the Billing Provider to try to find a valid match to a submitted claim. A program of the Washington Healthcare Forum operated by OneHealthPort 6

10 b. When matching for a patient, The health plan will check for that patient within their claims system as both a subscriber and a dependent, regardless of whether the patient was indicated as a subscriber or dependent in the inquiry. More specifically, if a match on patient and date exists, the response will contain status information for that claim even if the inquiry specifies the patient as a dependent and the health plan system has the patient as the subscriber, or visa versa A response will only contain information about the claim(s) for the individual that was specified as the patient in the inquiry. c. When matching for date, If a single date of service was entered in the inquiry and it exactly matches a date of service on a submitted claim for that patient-provider combination, a response will be created for that claim(s) AND for any other claim(s) that may be a result of a claims split. If a date range was entered in the inquiry and any of the dates in that range match the date(s) of service on a submitted claim(s) for that patient-provider combination, a response will be created for all claims with a date of service that falls within the range entered in the inquiry. If the health plan cannot match the data elements contained in the inquiry to a claim within their system, a not found status will be returned 3. If the inquiry CONTAINS the health plan s identifying claim number, and the other data elements used by the health plan to ensure patient privacy match... The response will only return status information on the claim that is associated with the health plan s identifying claim number. If the health plan cannot match the claim number contained in the inquiry to a claim within their system, a not found status will be returned A program of the Washington Healthcare Forum operated by OneHealthPort 7

11 Reporting Status Information Claim status information will be reported for those claims that are in the health plan's claims processing system AND match the inquiry information. 1. To find claims that match the inquiry information, health plans will search claims that were received within at least 12 calendar months of the date of inquiry. 2. An inquiry on any and all claims received by a health plan within at least the past 12 calendar months will receive a response. This includes claims that were forwarded to another health plan, e.g. claims for Blue Card members, claims that were repriced before being sent to the payer, etc. Either the receiving plan will respond that the claim was forwarded or the forwarded plan will respond with status information. 3. For each unique claim, as defined by the provider's inquiry/look-up criteria, the health plan will respond with only the current status, i.e. one status for one unique claim. Note - in the following situations, the health plan's system may have multiple unique claims when the provider's system only has one. The health plan is likely to return the current status on each of these unique claims. a. A claim that was split is considered two unique claims. Health Plans split some of the claims that they receive. For example, claims for services that cross benefit years are typically split into one claim for each benefit year. In those cases when a health plan splits a claim, each separate part of the split claim is considered one unique claim, each will have a separate payor claim number, and each will contain the same patient control number that was on the claim that was originally submitted. This means that a single claim inquiry within a 276 may return statuses on multiple claims within a 277 response. b. If a provider submits (and health plan receives) the same claim multiple times and the health plan stores that claim in their adjudication system, each of those submitted claims is considered a unique claim. Some health plans may create a unique claim for each submitted claim that was a duplicate to a previously submitted claim. Each unique claim will have a separate payor claim number, and may or may not have the same patient control number that was on the claim that was originally submitted, depending upon how it was submitted by the provider. c. Each adjustment of a claim may result in a unique claim. If a claim was adjusted, for example in the case of a corrected claim, some health plans may create a unique claim for the adjusted claim as well as for the originally submitted A program of the Washington Healthcare Forum operated by OneHealthPort 8

12 claim. In those situations, each unique claim will have a separate payor claim number. <<in validation, special mention will be made if the current status of only the most recent instance of the adjusted claim is returned>> 4. The information listed below represent the minimum set of response information to be provided by a health plan. a. The data elements entered in the inquiry will be returned on the response, and some of those data elements will contain the information as stored in the health plan's system. For example, the patient name or date of birth in the health plan's system may be different than what is contained in the provider's system. b. The most recent status information will be provided for the claim. For all professional claims and for any other claim that the health plan adjudicated the claim at the line level, the most recent status information will be returned for each and every line on the claim as it appears in the health plan's system. For example, every line item could have the same status category of pended and the same explanatory description. c. The status information will contain sufficient level of response detail to eliminate back and forth exchange between provider and health plan. (Section of TR3) Web-Based Access to the Information The Best Practices outlined above will be operationalized in a web-based claims status interaction. Web-based claims status practices will be consistent with transaction-based claim status practices. Web-based capabilities may go beyond what is doable with the HIPAA transactions, but they cannot be in conflict with transaction capabilities. More specific best practice requirements associated with the browser interaction include: Single sign-on: The health plan's site should be accessible using a OneHealthPort (OHP) credential. Since the OHP credential is associated with the provider's tax id number, the tax ID number can be used "behind the scenes" by the web site to identify the organization making the inquiry. In situations where a tax ID number may be associated with more than one provider, some health plans may present a list of providers and ask for one specific provider to be selected. This selection process will typically occur after the sign on process and before entering information for a claim search. Number of 'clicks': The provider should be able to get to the status information with as few 'clicks' as possible. A program of the Washington Healthcare Forum operated by OneHealthPort 9

13 Options for Claim Search. The web site should offer providers multiple ways to "lookup" a Claim. Each of the look-up options will be a different combination of data elements from the following list. o Patient Control Number o Health Plan's Identifying Claim Number o Subscriber/Member ID o First Name o Last Name o Patient Date of Birth o Date of Service (or range of dates) Each option should require the provider to enter a minimum number of data elements (up to 5 of the 7) that is consistent with the health plan's patient privacy & security requirements per HIPAA regulations. If the information entered in the "look-up" does not uniquely identify a single claim, summary information for matching claims will be listed up to any system limitation. If all matching claims cannot be displayed due to a system limitation, this will be conveyed via an appropriate message. Minimum summary information to be displayed for each listed claim is: Summary Information Always Displayed Comment Patient Name See Comment Only needs to be displayed if patient identifying information was not entered in the "lookup" Patient Control Number See Comment Always displayed if submitted on the claim Health Plan Claim Number es Date of Service (range of dates) es $ Amount of Billed Charges es Link to detail status information es Time Period: The health plan's system should respond to each query in no longer than 20 seconds from the point that their system receives the query. (A query is initiated when the provider enters "enter", "submit" or other similar command on their web browser.) Time periods may appear longer to the provider depending upon the type of computer they are using, type of browser, speed of the internet, etc. Status Information. Status information available on the web site will be equivalent to the information available in the HIPAA 277 transaction. A program of the Washington Healthcare Forum operated by OneHealthPort 10

14 Printer-Friendly Report. The provider should be able to easily print out a readable, paper version of the information that is on the web site Transaction Exchange of the Information The Best Practices outlined above will be operationalized in the Real Time and Batch Exchange of the HIPAA Health Care Claims Status Inquiry and Response transaction set. More specific best practice requirements associated with the transaction include: Performance Best Practices The provider organization will send the 276 Inquiry transaction and health plans will reply with the 277 Response transaction. When receiving a batch transmission of the 276 Inquiry transaction, health plans will respond with a 999 Acknowledgment transaction prior to processing the 277 Response. Time Period Health plans will respond, with one or more 277 transactions, to every claim status inquiry contained in a 276 transaction, as soon as possible and not later than a) 20 seconds after receiving a Real Time 276 transaction, and b) 24 hours after receiving a Batch 276 transaction. The time period starts when the health plan receives the 276 transaction and ends when all claim status requests pertaining to that health plan's members contained in the 276 transaction are answered, i.e. via the sending of one or more 277 transactions. The time period does not include any processing/wait time by clearinghouses or intermediary organizations between the provider and the health plan. Note: The 20 second timeframe will be impacted by the breadth and depth of information requested in the inquiry. When validating the 20 second timeframe, the inquiry will have a service date range of less than 30 days. Returned Information Within the time period, the returned information will include a reply to every request for information that is contained within the 276 transaction and that is not forwarded to another health plan. The reply will be appropriate, e.g. a 'Not Found, or status, system unavailable message, etc. Information may/may not be returned on a request that is forwarded to another health plan, e.g. Blue Card or FEP. Most of the time, claim status inquiries contained in a 276 will all appear on the same 277. However in the following situations, claim status inquires contained in a 276 may appear on different 277s. A program of the Washington Healthcare Forum operated by OneHealthPort 11

15 The 276 contains claims status inquiries that are processed by different system platforms. The 276 contains a status inquiry for claims that have dual coverage within the health plan, e.g. a husband and wife are both covered by the health plan, but under different contracts Data Content Best Practices 1. If the provider's 'Patient Control Number' was submitted on the claim, that number must be included in the 277 response transaction from the health plan. 2. As described in 3c above under 'Reporting Status Information', adjusted claims may have different payor claim numbers and different status information. To help a provider determine which status is the most recent, STC02 in Loop 2200D must contain the date that the claim was placed in that current status. 3. Where business scenarios as defined in the Appendix are applicable, the associated claim status category codes and claim status codes will be used in STC01-1 & STC01-2 of the transaction. A program of the Washington Healthcare Forum operated by OneHealthPort 12

16 Appendix Status Coding by Business Scenarios A program of the Washington Healthcare Forum operated by OneHealthPort 13

17 Status Coding by Business Scenarios HIPAA provides myriad codes for reporting claim status information. Given the breadth and variety of available codes, there is significant risk that these codes will not be used in the same way by all health plans. This lack of standardization will make it difficult for providers to use the transaction to automatically update their systems. The following business scenarios were created to foster standardization. The scenarios are intended to address common status reporting situations or problematic situations where there is likely to be wide variation in which codes are used by the health plans. The intent of these scenarios is not to limit the use of status codes to just those codes listed below. Rather, the intent is to standardize coding in those situations when specific business scenarios arise. The objectives that were used for creating these business scenarios and selecting appropriate codes is as follows: 1. Include as few codes as possible in each business scenario so as to minimize the need for health plans to determine which code takes precedence if multiple codes apply. 2. Each status code within a category should correspond to a unique action by the provider organization. 3. Only report information that is appropriate to this transaction and is not otherwise addressed by another HIPAA transaction. Information about the processing status of a claim/claim line is appropriate to this transaction. Information about "how" or "why" a claim/claim line was adjudicated is not appropriate to this transaction as it is addressed by the 835 transaction. (A Best Practice Recommendation is for health plans to make 835-related information available via their web site as well as via the HIPAA transaction) 4. Status information reported by this transaction should be limited to: a. Confirming receipt of a claim and identifying the entity responsible for adjudication b. Providing status of the claim within the adjudication process, If the claim has been pended, providing enough information so that the provider knows why the claim is pended and what, if anything, they or the patient can do to move it out of the pended status If the claim has completed the adjudication process, report information that is consistent with objective #2 above. To reduce unnecessary variation on 277s, health plans will use the following HIPAA Claim Status Category - Claim Status combinations when reporting claim status for the business scenarios outlined below. Multiple business scenarios may apply to a single claim. For example, one line on a claim may fall into Scenario #2 and another line on the same claim may fall into Scenario #3. This document assumes that all coding conventions outlined in X12N TR3 will be followed. This includes, but is not limited to, the use of valid Claim Status Category s and A program of the Washington Healthcare Forum operated by OneHealthPort 14

18 Claim Status s. The list of valid claim status category codes/descriptions can be found at The list of valid claim status codes/description can be found at Business Scenarios Scenario #1: Inquiry Status Available Received - No Status Available Scenario #2: Claim Finalized Coverage Applies Scenario #3: Claim Denied No Payment Will Be Made Scenario #4: Claim Pended Scenario #5: Errors Business Scenario Description This scenario applies when the health plan that received the claim from the provider will not process the claim or report status information on it. This scenario applies when adjudication of the claim has been finalized by the health plan, the patient's coverage applies to the service billed and a payment will be made to the provider in the amount of $0.00 or more. (For example, a $0 payment will result when coverage amount is applied to the patient's cost share.) This scenario applies when adjudication of the claim has been finalized by the health plan, the patient's benefit coverage does not apply and no payment will be made to the provider. This scenario applies when the adjudication of a claim has been suspended by the health plan for various reasons. Suspended (pended) claims have not completed the adjudication process and/or the payment cycle. This scenario applies when the health plan encounters system or processing errors not included in the Business Scenarios above. Such errors may be the result of system or application errors or the inability of the health plan to accurately identify the patient. A program of the Washington Healthcare Forum operated by OneHealthPort 15

19 Business Scenario #1: Inquiry Received - No Status Available This scenario applies when the health plan that received the claim from the provider will not process the claim or report status information on it. Claim Status Category A0 A4 Scenario #1: Inquiry Received - No Status Available Category Description Acknowledgement/Forwarded-The claim/encounter has been forwarded to another entity. Acknowledgement/Not Found-The claim/encounter cannot be found in the adjudication system. Claim Status Status Description 16 Claim/encounter has been forwarded to entity. 35 Claim/encounter not found. Entity Required by 5010 Note: For health plans that support the 277CA transaction, these codes may be used on that transaction A program of the Washington Healthcare Forum operated by OneHealthPort 16

20 Business Scenario #2: Claim Finalized Coverage Applies This scenario applies when adjudication of the claim has been finalized by the health plan, the patient's coverage applies to the service billed AND a payment will be made to the provider in the amount of $0.00 or more. (For example, a $0 payment will result when coverage amount is applied to the patient's cost share.) This scenario covers the case when a check has yet to be cut AND the case when a check has been cut. Since the only difference in these two cases is whether a check has been cut, the same codes apply to both scenarios. Claim Status Category F0 F1 F3 Scenario #2: Claim Finalized Coverage Applies Category Description Finalized-The claim/encounter has completed the adjudication cycle and no more action will be taken. Finalized/Payment-The claim/line has been paid. Finalized/Payment-Adjudication information has been changed To be used when the claim was processed as an adjustment to a previous claim to which coverage applied. Note: it will not be possible to distinguish when a claim has been adjusted multiple times. Claim Status Status Description 3 Claim has been adjudicated and is awaiting payment cycle. 98 Charges applied to deductible 100 Pre-certification penalty taken. 105 Claim/line is capitated. 106 This amount is not entity's responsibility. 65 Claim/line has been paid 98 Charges applied to deductible 100 Pre-certification penalty taken. 105 Claim/line is capitated This amount is not entity s responsibility 3 Claim has been adjudicated and is awaiting payment cycle. 65 Claim/line has been paid 98 Charges applied to deductible 100 Pre-certification penalty taken. 105 Claim/line is capitated This amount is not entity s responsibility Entity Required by 5010 Note: Detail information about how the claim was adjudicated may be found on the 835 transactions and/or related web site. A program of the Washington Healthcare Forum operated by OneHealthPort 17

21 Business Scenario #3: Claim Denied No Payment Will Be Made This scenario applies when adjudication of the claim has been finalized by the health plan, the patient's benefit coverage does not apply and no payment will be made to the provider. Claim Status Category F2 F3 Scenario #3: Claim Denied - No Payment Will Be Made Category Description Finalized/Denial-The claim/line has been denied. Finalized/Payment-Adjudication information has been changed To be used when the claim was processed as an adjustment to a previous claim, that may have been Claim Status Status Description 21 Missing or invalid information. Note: At least one other status code is required to identify the missing or invalid information. 27 Policy canceled. 54 Duplicate of a previously processed claim/line. 81 Contract/plan does not cover pre-existing conditions. 83 No coverage for newborns. 84 Service not authorized. 88 Entity not eligible for benefits for submitted dates of service. 89 Entity not eligible for dental benefits for submitted dates of service. 92 Entity does not meet dependent or student qualification. 94 Entity not referred by selected primary care provider. 95 Requested additional information not received. 107 Processed according to contract provisions (Contract refers to provisions that exist between the Health Plan and a Provider of Health Care Services) 116 Claim submitted to incorrect payer. 171 Other insurance coverage information (health, liability, auto, etc.). 474 Procedure code and patient gender mismatch 682 Cosmetic procedure 21 Missing or invalid information. Note: At least one other status code is required to identify the missing or invalid information. 27 Policy canceled. Entity Required by 5010 A program of the Washington Healthcare Forum operated by OneHealthPort 18

22 Claim Status Category Scenario #3: Claim Denied - No Payment Will Be Made Category Description paid or denied. Note: it will not be possible to distinguish when a claim has been adjusted multiple times. Claim Status Status Description 54 Duplicate of a previously processed claim/line. 81 Contract/plan does not cover pre-existing conditions. 83 No coverage for newborns. 84 Service not authorized. 88 Entity not eligible for benefits for submitted dates of service. 89 Entity not eligible for dental benefits for submitted dates of service. 92 Entity does not meet dependent or student qualification. 94 Entity not referred by selected primary care provider. 95 Requested additional information not received. 107 Processed according to contract provisions (Contract refers to provisions that exist between the Health Plan and a Provider of Health Care Services) 116 Claim submitted to incorrect payer. 171 Other insurance coverage information (health, liability, auto, etc.). 474 Procedure code and patient gender mismatch 682 Cosmetic procedure Entity Required by 5010 A program of the Washington Healthcare Forum operated by OneHealthPort 19

23 Business Scenario #4: Claim Pended This scenario applies when the adjudication of a claim has been suspended by the health plan for various reasons. Suspended (pended) claims have not completed the adjudication process and/or the payment cycle. Claim Status Category P1 P3 Category Description Pending/In Process-The claim or encounter is in the adjudication system. Pending/Provider Requested Information - The claim or encounter is waiting for information that has already been requested from the provider. (Note: A Claim Status identifying the type of information requested must be reported.) Scenario #4: Claim Pended Claim Status Status Description 3 Claim has been adjudicated and is awaiting payment cycle. 40 Waiting for final approval. 45 Awaiting benefit determination. 41 Special handling required at payer site. 45 Awaiting benefit determination. 46 Internal review/audit. 52 Investigating existence of other insurance coverage. 55 Claim assigned to an approver/analyst. 56 Awaiting eligibility determination. 110 Claim requires pricing information. 123 Additional information requested from entity. 171 Other insurance coverage information (health, liability, auto, etc.). 290 Pre-existing information. 297 Medical notes/report. 317 Patient's medical records. 218 NDC number. 290 Pre-existing information. 286 Other payer's Explanation of Benefits/payment information. 297 Medical notes/report. 306 Detailed description of service. 317 Patient's medical records. 331 History and physical. 171 Other insurance coverage information (health, liability, auto, etc.). 286 Other payer's Explanation of Benefits/payment information. 363 Will worker's compensation cover submitted charges? 366 Is injury due to auto accident? Entity Required by 5010 A program of the Washington Healthcare Forum operated by OneHealthPort 20

24 Business Scenario #5: Errors This scenario applies when the health plan encounters system or processing errors not included in the Business Scenarios above. Such errors may be the result of system or application errors or the inability of the health plan to accurately identify the patient. Claim Status Category E0 E1 Category Description Response not possible - error on submitted request data. Response not possible - System Status. Scenario #5: Errors Claim Status Status Description 21 Missing or invalid information. Note: At least one other status code is required to identify the missing or invalid information. 33 Subscriber and subscriber id not found. 97 Patient eligibility not found with entity. 484 Business Application Currently Not Available Entity Required by 5010 A program of the Washington Healthcare Forum operated by OneHealthPort 21