Financial Information Reporting (FIR) Daily Cumulative FIR Aging Report Guide with MBI. This report will be effective starting

Transcription

1 Financial Information Reporting (FIR) Daily Cumulative FIR Aging Report Guide with MBI This report will be effective starting FIR Report Guide Page i

2 Table of Contents 1 BACKGROUND PURPOSE REPORT NAME & PURPOSE REPORT SCHEDULE REPORT DELIVERY INQUIRIES EXPLANATION OF A FIR SERIES AND A FIR SEQUENCE EVENTS THAT CAUSE A FIR TO BE TRIGGERED FIR TRANSACTION TIMING AND PROCESS FLOW TIMING FOR THE FIRST FIR SEQUENCE FIR TRANSACTION TIMING PROCESS FLOW AND DIAGRAM ASSUMPTIONS EXAMPLES FOR THE DAILY CUMULATIVE FIR AGING REPORT SCENARIO ONE: SCENARIO TWO: SCENARIO THREE: SCENARIO FOUR: SCENARIO FIVE: SCENARIO SIX: SCENARIO SEVEN: REPORT FIELD DEFINITIONS REJECT CODES GENERATED BY PLAN OR TRANSACTION FACILITATOR GENERATED BY PLAN GENERATED BY TRANSACTION FACILITATOR...21 FIR Report Guide Page ii

3 1 Background When a patient changes to a new Part D plan during a plan year, the previous plan/plans are no longer the plan of record responsible for maintaining the current overall TrOOP and Gross Covered Drug Cost balance for the patient for that plan year. In some infrequent cases, a patient may have multiple prior plans within a single year. The new plan of record must receive the amount of the patient s TrOOP and total Gross Covered Drug Cost balance from the old plan/plan s record, for the appropriate month(s). The new plan then becomes the plan of record (current plan) that is responsible for maintaining the overall TrOOP and Gross Covered Drug Cost balance for the patient. When a patient s plan changes and reporting of TrOOP balance is necessary, the old plan may still receive financial activity related to their period of coverage for the patient (e.g., after-the-fact Information Reporting transmissions for updating TrOOP, claims/reversals or adjustments can be processed causing TrOOP or the Gross Covered Drug Cost amounts to change). The old plan therefore must continue to maintain an internal TrOOP and Gross Covered Drug Cost balance during the old plan s coverage period. They will be adjusting the balance accordingly by month if applicable Information Reporting transactions, Claim Reversals or adjustments are processed after their reporting of TrOOP and Gross Covered Drug Cost balances. This allows the old plan to refer to this internal TrOOP and Gross Covered Drug Cost balance by month to determine the proper compensation level for any transactions received after the reporting of TrOOP balance information. These transactions may be used to report any accumulation amounts, including retroactive changes to eligibility that make it appear that the patient was never effective in the plan. If a patient changes to a new Part D plan and the processor is the same for the new and old plan, the processor will receive transmissions from the Facilitator for the new and old plan. For example, if the patient moved from A to B, and the Facilitator is aware of the change in Part D plans via eligibility information received by the Facilitator from CMS, the Facilitator will submit a Financial Information Reporting Inquiry (F1) for A, A responds to the Facilitator with current Accumulated Patient True Out of Pocket Amount (652-S3) and Accumulated Gross Covered Drug Cost Amount (653-S4) for the appropriate month(s). The Facilitator then provides these amounts to B. The Facilitator when sending Financial Information Reporting Update or Exchange transmissions will always provide the total accumulated amounts for appropriate month(s) they have received as of that point in time. The s are F1 Financial Information Reporting Inquiry F2 Financial Information Reporting Update F3 Financial Information Reporting Exchange FIR Report Guide Page 1

4 2 Purpose The purpose of this document is to provide instruction on the use of the, Daily Cumulative FIR Aging Report and includes functionality of the report, examples of common scenarios that may be reported and definition of the report fields. 3 Report Name & Purpose The Daily Cumulative FIR Aging Report provides unresolved FIR rejections as of the report run date. It can be used to track compliance with the CMS requirement that all FIRs are processed correctly within 15 days of the beneficiary s effective date or receipt date of the beneficiary s change in eligibility. 4 Report Schedule The Daily Cumulative FIR Aging report will be generated daily, and contains FIR rejections that have not been resolved as of the report generation. 5 Report Delivery The Daily Cumulative FIR Aging report is sent via secure to addresses associated with the CMS for which the report is generated. The Daily Cumulative FIR Aging report for a plan year will encompass data through the end of May for the prior plan year. The last report will be run June 1 st for a prior plan year. 6 Inquiries Any questions regarding this report or FIR transactions should be submitted to TBTSupport@relayhealth.com. If Protected Health Information (PHI) is included, please send your in a secure manner to protect the PHI. 7 Explanation of a FIR Series and a FIR Sequence 1. A series an event that starts a pre-defined number of sequences a. Triggered for example when there is a plan change. b. The automated schedule is reflected in section A sequence when a FIR is triggered. a. A Sequence Send Count (The number of times the sequence has been sent), restarts when a new FIR series is started because of a new event (i.e. a change in beneficiary s plan, or a plan s change in processor with a new BIN). b. The request of a manual FIR after an automated series has completed contains a Sequence Count of 99. FIR Report Guide Page 2

5 8 Events that cause a FIR to be triggered 1. Any beneficiary that has a change in during a plan year will initiate a new FIR series. 2. Any beneficiary that has a change in PBP with a change in BIN, PCN or both will initiate a new FIR series. 3. Any beneficiary for which a proxy add was requested, by any plan that may have paid claims on behalf of the beneficiary, will always initiate a new series. 4. Any beneficiary for which a proxy edit was requested will trigger a FIR Sequence if a series is already under way. However if there is not an active series for the beneficiary a new series will be initiated. 5. A retrigger request, from any plan the beneficiary may have had during the plan year, will initiate a new sequence. 9 FIR Timing and Process Flow 9.1 Timing for the First FIR Sequence Timing of the first sequence is on the effective date or one day prior to the effective date if eligibility is available. The one day prior is to allow the balances to be available to the plan when the beneficiary is effective (e.g. a claim is filed for the beneficiary on the first date of the month). The expectation is that these balances will be applied ahead of time. Capturing this data ahead of time assists the plan in not having to do adjustments for the first days of the eligibility period if claims are filed during these first days. 9.2 FIR Timing There are many events that occur that result in a change to the way a claim originally processed. These events may occur even after the beneficiary has disenrolled from a plan. For example, a plan may receive a retroactive change to the Low Income Cost Sharing that requires claims to be adjusted. Other examples may be the receipt of latent supplemental payer information (N transactions), paper claims submitted by the beneficiary, reversal or non-coverage of claims previously paid, and end of year reconciliation, all of which can impact the beneficiary s accumulators. To account for these changes, the Facilitator automatically submits FIR sequences multiple times, as defined in the schedule below, to all plans to communicate any changes to the beneficiary s accumulators. FIR Report Guide Page 3

6 FIR sequences are sent based on the following schedule, which is called a Series unless a new event (e.g. beneficiary moves to another plan) restarts the Series at which time the schedule restarts based on that new event. The specific timing of each sequence in a series is listed below: 1 day prior to effective date if eligibility is received prior to effective date ( Facilitator refers to this as minus 1) Day 1 Effective date (or receive date if received after effective date) ( Facilitator refers to this as day 0) Day 8 (seven days from the effective date) Day 10 Day 12 Day 14 Day 21 Day 28 Day 73 Day 118 December 1 January 15 of subsequent year February 28 of subsequent year Mass retriggers. For mass retrigger timing please see: Note: Aging on the FIR rejections age from the first fail date. 9.3 Process Flow and Diagram The Facilitator receives a nightly eligibility data file from CMS that indicates a new Part D plan for a patient. a) Facilitator determines if the new plan will become effective in the future or is already effective. If the plan is already effective, the Facilitator sends an F1 to the first plan for the calendar year. b) If the plan will become effective in the future, the Facilitator schedules the delivery of the F1 to the first plan for the calendar year one day before the plan becomes effective. If the response to the F1 is a rejection, the Sequence stops. The rejection is reported on the rejecting plans Daily Cumulative Exception Report. Until the rejection is resolved, the beneficiary s accumulators will not be transferred to any plans after the first plan in the calendar year. If the F1 is accepted, the Facilitator will send a FIR transaction to the next plan in line. If there is only one additional plan, that transaction will be an F2, if there is more than one additional plan, the transaction will be an F3. FIR Report Guide Page 4

7 a) There is only one additional plan. The Facilitator sends an F2 transaction. This transaction contains the accumulators from the prior plan. If the F2 is accepted, the plan receiving the F2 will update the beneficiary s accumulators with information provided by the prior plan. b) There is more than one additional plan The Facilitator sends all additional plans except the plan that cause the FIR sequence to be initiated (the most current plan of record) an F3 transaction. This transaction contains accumulators from all plans prior to the plan receiving the F3. If the F3 is accepted, the plan receiving the F3 will respond to the F3. The response will either mirror back what prior plans have reported (if receiving plan does not have any dollars to report for the month) or will contain the sum of prior plans and current plan accumulators (if prior plans had dollars to report and receiving plan has dollars to report in the same month). Additionally, the Part D plan should update their systems to reflect any dollars provided from prior plans. Each additional plan except the plan that caused the FIR sequence to be initiated (the most current plan of record) will receive an F3. If there are no additional plans other than the most current plan of record the Facilitator will send an F2 containing all prior plan dollars to the most current plan of record. FIR Report Guide Page 5

8 FIR Sequence Series Work Flow Eligibility file reflects a FIR triggering beneficiary event A FIR series is started Is this the first Sequence in the series? Yes Was the sequence successful? Yes Beneficiary will be queued for the next FIR sequence No A No Reported on daily cummulative report Is this the last Sequence? Yes Was the sequence successful Yes End of Series A No No Beneficiary reported on the daily cumulative report with a sequence count =99 IS 99 FIR in an unsuccessful status with Pre- F=Y? No FIR was unsuccessful due to prior plan Yes Prior needs to correct issue and request manual trigger needs to correct issue and request manual trigger 10 Assumptions 1. CMS will receive a copy of the Daily Cumulative FIR Aging report on the 1 st and 16 th of each month. The data reported will be all outstanding exceptions by as of the date of the report. 2. A blank report will be sent to signify there is no data to report for that day. 3. The report reflects data for a 24 hour period, (mid-night to mid-night of a day). 4. The FIR sequence starts on or around the same time each day for that day s scheduled FIR transactions. s are scheduled as a result of either the CMS Eligibility File received or requests received for manual retriggers by plans, payers, or processors. 5. Any FIR exceptions (rejections) for a prior benefit plan year that are still in a rejected status after March 31 of the subsequent year (the last FIR trigger date of the automated FIR process), will require a manual retrigger request. FIR Report Guide Page 6

9 6. Any Proxy Add, Edit, or Delete requests received after the March 31 (for the prior plan year) will require a manual retrigger request. 7. Manual FIR retriggers may be requested anytime during the year the plan year or up to May 31 st of the following year for a given plan year. The most likely occurrence for this need is after a FIR series has completed. 8. The Daily Cumulative FIR Aging report for a plan year will encompass data through the end of May for the prior plan year. The last report will be run June 1 st for a prior plan year. 11 Examples for the Daily Cumulative FIR Aging Report Note that in all examples, during the CMS Social Security Removal Initiative transition period, both the and the MBI fields will be populated. After the transition period has ended the will no longer be reported in the field and it will remain blank. Only the MBI(s) and associated effective and termination dates will be reported. The field will not be removed to eliminate the need to recode a new layout Scenario One: The beneficiary left H1234 and is effective with S /1/2013. A FIR series is started 03/1/2013. (Series = F1 to H1234; F2 to S5678) H1234 is effective for the same beneficiary 01/01/2013. The plan has a termination date of 02/28/2013. The FIR (F1) processed the first time 03/01/2013 successfully. The FIR (F1) rejected the second time it was run on 03/08/2012. S5678 is effective for the same beneficiary 03/01/2013. The plan has no termination date (open-ended). The FIR (F2) rejected the first time 03/01/2013. The FIR cannot process second time it was run, (03/08/2013) because H1234 rejected (F1) on 03/08/2013. The results are as follows: 1. There is no report to H1234 on 03/02/2013 because the FIR processed. 2. Daily Cumulative FIR Aging Report to S5678 on 03/02/2013 (report date) Last ed Last Successful ed Pre-F Indicator Z N F2 S Daily Cumulative FIR Aging Report to H1234 on 03/09/2013 Last ed Last Successful ed Pre-F Indicator Z N F1 H Daily Cumulative FIR Aging Report to S5678 on 03/09/2013 Last ed Last Successful ed Pre-F Indicator Z Y F2 S5678 FIR Report Guide Page 7

10 The ed Pre-F Indicator (value Y) indicates that a FIR (F2) was previously rejected by S5678, however since that time a prior plan (H1234) has rejected the FIR (F1) and therefore S5678 cannot determine whether or not the fix was successful. This beneficiary still does not have a successful FIR Scenario Two: Assume any problems identified in scenario one have been resolved. This is specific to a FIR generated on 07/01/2013. The beneficiary left H1234, went to S5678 and then returned to H1234 in the same year. A new FIR series is started 07/01/2013 because a new plan (H1234) is effective 07/01/2013. The original FIR series started 03/01/2013 is terminated. H1234 is effective for the same beneficiary 01/01/2013. The plan has a termination date of 02/28/2013. The FIR (F1) processed the first time 07/01/2013 successfully. S5678 is effective for the same beneficiary 03/01/2013. The plan has a termination date of 06/30/2013. The FIR (F3) rejected with the first run 07/01/2013. H1234 is effective for the same beneficiary 07/01/2013. The plan has no termination date (open-ended). The results are as follows: 1. There is no report to H1234 on 07/02/2013 because the FIR processed. 2. Daily Cumulative FIR Aging Report to S5678 on 07/02/2013 (report date) Last ed Last Successful ed Pre-F Indicator Z N F3 S Scenario Three: This example is built on Scenario Two and is specific to a FIR generated on 07/08/2013 The beneficiary left H1234, went to S5678 and then returned to H1234 in the same year. A FIR series is started 07/01/2013, the following sequence in the series is run 07/08/2013. H1234 is effective for the same beneficiary 01/01/2013. The plan has a termination date of 02/28/2013. The FIR (F1) processed the first time 07/01/2013 successfully. The FIR (F1) rejected the second time it was run on 07/08/2013. S5678 is effective for the same beneficiary 03/01/2013. The plan has a termination date of 06/30/2013. The FIR (F3) rejected with the first run 07/01/2013. H1234 is effective for the same beneficiary 07/01/2013. The plan has no termination date (open-ended). The results are as follows: 1. Daily Cumulative FIR Aging Report to H1234 on 07/09/2013 (report date) FIR Report Guide Page 8

11 Last ed Last Successful ed Pre-F Indicator Z N F1 H Daily Cumulative FIR Aging Report to S5678 on 07/09/2013 (report date) Last ed is 07/01/2013 for S5678 since prior H1234 has rejected. S5678 has not been able to successfully respond to a FIR since that time period, because a prior plan (H1234) is stopping the transaction. The aging continues even if the prior plan continues to stop the transaction. Last ed Last Successful ed Pre-F Indicator First in a Z Y F3 S5678 H Scenario Four: All FIRs in this scenario have been sent and received successfully as of 07/10/2013. The beneficiary left H1234, went to S5678 and then returned to H1234 in the same year. A FIR series is started 07/01/2013, the following sequence in the series is run 07/08/2013. On 07/10/2013, the third sequence in the series is run. H1234 is effective for the same beneficiary 01/01/2013. The plan has a termination date of 02/28/2013. The FIR (F1) processed the first time 07/01/2013 successfully. The FIR (F1) rejected the second time it was run on 07/08/2013, when the FIR (F1) processed third time on 07/10/2013, it was processed successfully. S5678 is effective for the same beneficiary 03/01/2013. The plan has a termination date of 06/30/2013. The FIR (F3) processed successfully 07/10/2013. H1234 is effective for the same beneficiary 07/01/2013. The plan has no termination date (open-ended). The results are as follows: Nothing will be reported on the Daily Cumulative FIR Aging Report on 07/11/2013 for these FIRs as they were all successful Scenario Five: This is specific to a FIR generated on 07/08/2013. The beneficiary left H1234, went to S5678 and then returned to H1234 in the same year. This is a scenario where the same plan is a plan of record twice in the same benefit plan year. A FIR series is started 07/01/2013, the following sequence in the series is run 07/08/2013. H1234 is effective for the same beneficiary 01/01/2013. The plan has a termination date of 02/28/2013. The FIR (F1) processed the first time 07/01/2013 successfully. The FIR (F1) rejected the second time it was run on 07/08/2013. FIR Report Guide Page 9

12 S5678 is effective for the same beneficiary 03/01/2013. The plan has a termination date of 06/30/2013. The FIR (F3) processed the first time 07/01/2013 successfully. However, the plan never received a FIR transaction (F3) on 07/08/2013 due to the H1234 rejection. H1234 is effective for the same beneficiary 07/01/2013. The plan has no termination date (open-ended). The results are as follows: 1. Daily Cumulative FIR Aging Report to H1234 effective 01/01/2013 on 07/09/2013 (report date) Last ed Last Successful ed Pre-F Indicator Z N F1 H There is no report to S5678 on 07/09/2013 because the FIR for the prior plan rejected. H1234 will receive the report that reflects the rejection of the F1 for the plan period effective 01/01/2013 through 02/28/2013. H1234 will not receive the F2 expected for the plan period beginning 07/01/2013, due to S5678 not receiving the F3 due to the prior plan rejection Scenario Six: This scenario is specific to a FIR transaction scheduled for 03/08/2013 run, however the FIR is actually sent after midnight. The beneficiary left H1234 and is effective with S /01/2013. A FIR series started 03/01/2013. H1234 is effective for the same beneficiary 01/01/2013. The plan has a termination date of 02/28/2013. The FIR (F1) rejected the first time sent on 03/01/2013. The FIR (F1) rejected the second time it was run on 03/08/2012. The results are as follows: 1. Daily Cumulative FIR Aging Report to H1234 on 03/02/2013 (report date) Last ed Last Successful Next Scheduled Automated Send Count Z F1 H Daily Cumulative FIR Aging Report to H1234 on 03/09/2013 (report date) Note: S5678 will not receive a report due to the FIR (F2) would not be received due to the upstream plan is rejecting. Last ed Last Successful Next Scheduled Automated Send Count FIR Report Guide Page 10

13 Z F1 H1234 Note: Since the FIR transaction actually processed on 03/09/2013 due to volumes (missed cutoff), the Next Scheduled Automated will reflect the next date based on the FIR schedule (0308/2013) and Send Count on the 03/09/2013 report will not reflect that FIR transaction because the FIR was actually sent on 03/09/ Daily Cumulative FIR Aging Report to H1234 on 03/10/2013 (report date) Last ed Last Successful Next Scheduled Automated Send Count Z F1 H1234 On the 03/10/2013 report the Send Count will reflect the fact that the FIR was actually sent on 03/09/2013. The Next Scheduled Automated will still reflect the date based on the FIR schedule (03/10/2013) 11.7 Scenario Seven: This scenario is specific to a rejected FIR transaction for a previous benefit plan year corrected after the automated period of 03/31/2013. Any FIR exceptions (rejections) for a prior benefit plan year corrected after the automated period through March 31 of the subsequent benefit plan year, will require a manual retrigger request. The period available to request a manual retrigger for the prior plan year is April 1 through May 31. Until this manual retrigger is requested, the report will continue to report the rejection and the rejection will continue to age. Additionally the next Scheduled Automated will be blank as the automated timeframe expired as of 03/31/2013. H1234 is effective the beneficiary 07/01/2012, and an automated trigger (F2) was done on 03/31/2013, resulting in a rejection. The plan corrects the rejection on 04/01/2013. The plan requests a manual retrigger 04/03/2013 and the FIR (F2) was successful. The results are as follows: 1. Daily Cumulative FIR Aging Report to H1234 on 04/01/2013 Last ed Last Successful Next Scheduled Automated Send Count Z F2 H Daily Cumulative FIR Aging Report to H1234 on 04/02/2013 Last ed Last Successful Next Scheduled Automated Send Count FIR Report Guide Page 11

14 Z F2 H Daily Cumulative FIR Aging Report to H1234 on 04/03/2013 Last ed Last Successful Next Scheduled Automated Send Count Z F2 H1234 The 04/03/2013 report reflects transactions as of 04/02/2013. There is no Daily Cumulative FIR Aging report to H1234 on 04/04/2013 due to the FIR (F2) was successful. 12 Report Field Definitions Field Name Definition Example Max Format Length Report of report (CCYYMMDD) Numeric Current Benefit (CCYY) Numeric Health Insurance Claim Number Note that in all examples, during the CMS Social Security Removal Initiative transition period, both the and the MBI fields will be populated. After the transition period has ended the will no longer be reported in the field and it will remain blank. Only the MBI(s) and associate effective and termination dates will be reported. The field will not be removed to eliminate the need to recode a new layout Z 11 Alpha/Numeric A unique identifier sent by the Facilitator on all FIR transactions A 21 Alpha/Numeric of the First FIR in the First time the series was sent, even if this F Series could not be sent. (CCYYMMDD) Numeric First ed First time this FIR was sent and rejected. (CCYYMMDD) Numeric Last ed Last time this FIR was sent and rejected. (CCYYMMDD) Numeric Last Successful Last time this FIR succeeded. (CCYYMMDD) Numeric of Last This is the most recent date the series being Numeric reported was run. (CCYYMMDD) FIR Report Guide Page 12

15 Field Name Definition Example Max Format Length Next Scheduled Automated ed Pre-F Indicator Next time the series being reported on will run. (CCYYMMDD) Thi fi ld ill b bl k h This indicator is Y when a FIR rejected Y 8 1 Numeric Alpha/Numeric because of a prior plan. Value: Report generation date minus most recent 22 3 Numeric. Number of Pre-F s for this Series of last Pre-F Number of FIR s sent to prior plan for this series where ed Pre-F Indicator = Y 2 3 Numeric (reject by prior plan) is based upon the First FIR in the series. of last FIR sent to prior plan where Numeric prior plan rejected. (CCYYMMDD) Send Count Sequence Send Count Number of Automated Tries Left Processor Name The number of times this FIR has been sent. The number of times the sequence has been sent. The number of remaining FIR transmissions for the series. The name that RelayHealth has associated with the Bank Identification Number (BIN) 3 3 Numeric 1 3 Numeric 2 3 Numeric ABC Health 50 Alpha/Numeric PBP BIN The assigned by CMS to the health plan when contracted for Part D Medicare Part D Benefit Package assigned by CMS for the Benefit Package The Bank Identification Number (BIN) is the identifier number for the payer. A Alpha/Numeric Alpha/Numeric Numeric PCN Processor Control Number is the identifier bb 10 Alpha/Numeric number for the processor. Group group identifier assigned by plan Alpha/Numeric Cardholder Beneficiary identifier assigned by plan Alpha/Numeric of Birth Beneficiary date of birth (CCYYMMDD) Numeric NCPDP reject reason code Alpha/Numeric FIR Report Guide Page 13

16 Field Name Definition Example Max Format Length Description Definition of the M/I Processor Control 100 Alpha/Numeric Number The type of FIR transaction (F1, F2, or F3) F1 2 Alpha/Numeric LIS Indicator Non- of Record Non- of Record Effective This indicator is Y when a beneficiary has Low Income Subsidy effective coverage. This information is valid as of the date and delivery of the report. Value: Y = Yes N = No A=Audit-off (Indicates is a current non plan of record for the beneficiary) (Automated from CMS Eligibility File) The effective date of the Non- of Record.(CCYYMMDD) Y 1 Alpha/Numeric P 1 Alpha/Numeric Numeric Non- of Record Termination Of Record 1 The termination date of the Non- of Record. (CC ) of Record (POR), which means the plan was listed in the most recent update from CMS (not necessarily the current active plan). The first in the send order of the s listed at RelayHealth effective for the benefit plan year Numeric Y 1 Alpha/Numeric A Alpha/Numeric The second in the send order of the s listed at RelayHealth effective for the benefit plan year. The third in the send order of the s listed at RelayHealth effective for the benefit plan year. The fourth in the send order of the s listed at RelayHealth effective for the benefit plan year. The fifth in the send order of the s listed at RelayHealth effective for the benefit plan year. B Alpha/Numeric FIR Report Guide Page 14

17 Field Name Definition Example Max Format Length 6 The sixth in the send order of the s listed at RelayHealth effective for the benefit plan year. 7 The seventh in the send order of the s listed at RelayHealth effective for the benefit plan year. 8 The eighth in the send order of the s listed at RelayHealth effective for the benefit plan year. 9 The ninth in the send order of the s listed at RelayHealth effective for the benefit plan year The tenth in the send order of the s listed at RelayHealth effective for the benefit plan year. The eleventh in the send order of the s listed at RelayHealth effective for the benefit plan year The twelfth in the send order of the s listed at RelayHealth effective for the benefit plan year. The thirteenth in the send order of the s listed at RelayHealth effective for the benefit plan year. The fourteenth in the send order of the s listed at RelayHealth effective for the benefit plan year The fifteenth in the send order of the s listed at RelayHealth effective for the benefit plan year. The sixteenth in the send order of the s listed at RelayHealth effective for the benefit plan year. Gender Gender of the Patient 1 1 Numeric Current MBI Current Medicare beneficiary identifier. AB Alpha/Numeric FIR Report Guide Page 15

18 Field Name Definition Example Max Format Length Effective Current MBI effective date. (CCYYMMDD) Numeric MBI Medicare beneficiary identifier. AB Alpha/Numeric Effective MBI effective date. (CCYYMMDD) Numeric Termination MBI termination date. (CCYYMMDD) Numeric MBI Medicare beneficiary identifier. AB Alpha/Numeric Effective MBI effective date. (CCYYMMDD) Numeric Termination MBI termination date. (CCYYMMDD) Numeric MBI Medicare beneficiary identifier. AB Alpha/Numeric Effective MBI effective date. (CCYYMMDD) Numeric Termination MBI termination date. (CCYYMMDD) Numeric MBI Medicare beneficiary identifier. AB Alpha/Numeric Effective MBI effective date. (CCYYMMDD) Numeric Termination MBI termination date. (CCYYMMDD) Numeric MBI Medicare beneficiary identifier. AB Alpha/Numeric Effective MBI effective date. (CCYYMMDD) Numeric Termination MBI termination date. (CCYYMMDD) Numeric 13 s Generated by or Facilitator Note: 13.1 Generated by 1) If the field is blank and the Description states Unexpected as the description, this indicates that there was a failure somewhere within the /Processor s system (usually a front end failure) FIR Report Guide Page 16

19 2) If the field contains a value and the Description States Unexpected as the description, this indicates that the reject code the /Processor has returned is not a valid NCPDP reject code. Description Field in Facilitator Responsible Payer Responsible Comments Error Ø1 M/I Bin Number 1Ø1-A1 Processor data does not Ø2 M/I Version/Release Number 1Ø2-A2 Processor is not accepting mandated version- Ø3 M/I 1Ø3-A3 if = F1, F2, F3 the processor needs to contact RelayHealth Ø4 M/I Processor Control Number 1Ø4-A4 Processor data does not Ø6 M/I Group 3Ø1-C1 Processor data does not Ø7 M/I Cardholder 3Ø2-C2 Processor data does not Ø8 M/I Person 3Ø3-C3 Processor data does not Ø9 M/I Of Birth 3Ø4-C4 Processor data does not 1R 1S 1T 1U 1V 1X 1Ø Version/Release Not Supported / Not Supported PCN Must Contain Processor/Payer Assigned Value Count Does Not Match Number of s Multiple s Not Supported Vendor Not Certified For Processor/Payer M/I Patient Gender 1Ø2-A2 1Ø3-A3 1Ø4-A4 1Ø9-A9 Indicates Facilitator Processor is not accepting mandated version- if = F1, F2, F3 the processor needs to contact RelayHealth Processor data does not 1Ø9-A9 Indicates Facilitator 11Ø-AK If Vendor is not = MEDDFTROOP this indicates that the transaction is coming from an entity other than RelayHealth. Notify RelayHealth immediately 3Ø5-C5 Processor data does not 51 Non-Matched Group 3Ø1-C1 Processor data does not 52 Non-Matched Cardholder 53 Non-Matched Person 6J Insurance Segment Required For Adjudication 3Ø2-C2 3Ø3-C3 111-AM Indicates Facilitator Processor data does not Processor data does not 6K Patient Segment 111-AM Indicates Facilitator If the plan is rejecting FIRs with MEDDFTROOP, processor must insure that vendor is loaded into their system FIR Report Guide Page 17

20 Description Field in Error Required For Adjudication 65 Patient Is Not Covered 3Ø3-C3, 3Ø6-C6 Facilitator Responsible Payer Responsible Comments Processor data does not 7D Non-Matched DOB 304-C4 Processor data does not 7G 7H Future Not Allowed For DOB Non-Matched Gender 83 Duplicate Paid/Captured Claim 304-C4 Processor data does not 3Ø5-C5 2Ø1-B1, 4Ø1-D1, 4Ø2-D2, 4Ø3-D3, 4Ø7-D7 Indicates Facilitator Processor data does not 85 Claim Not Processed None These will show up on the exception report and plan should research reason for reject 9Ø Host Hung Up FIR will be retried for 2 days. After that, it will be retried in the next cycle. If the cycle is complete and final FIR has rejected, plan must resolve issue and contact RelayHealth for retrigger (if within 15 months of beginning of PY) 91 Host Response Error FIR will be retried for 2 days. After that, it will be retried in the next cycle. If the cycle is complete and final FIR has rejected, plan must resolve issue and contact RelayHealth for retrigger (if within 15 months of beginning of PY) 92 System Unavailable/Host Unavailable FIR will be retried for 2 days. After that, it will be retried in the next cycle. If the cycle is complete and final FIR has rejected, plan must resolve issue and contact RelayHealth for retrigger (if within 15 months of beginning of PY) *95 Time Out FIR will be retried for 2 days. After that, it will be retried in the next cycle. If the cycle is complete and final FIR has rejected, plan must resolve issue and contact RelayHealth for retrigger (if within 15 months of beginning of PY) *96 Scheduled Downtime FIR will be retried for 2 days. After that, it will be retried in the next cycle. If the cycle is complete and final FIR has rejected, plan must resolve issue This would only happen if the time stamp for both FIRs is exactly the same. Processor should use other more specific reject codes if possible. FIR Report Guide Page 18

21 Description Field in Error and contact RelayHealth for retrigger (if within 15 months of beginning of PY) *97 Payer Unavailable FIR will be retried for 2 days. After that, it will be retried in the next cycle. If the cycle is complete and final FIR has rejected, plan must resolve issue and contact RelayHealth for retrigger (if within 15 months of beginning of PY) *98 Connection To Payer Is Down Facilitator Responsible Payer Responsible Comments FIR will be retried for 2 days. After that, it will be retried in the next cycle. If the cycle is complete and final FIR has rejected, plan must resolve issue and contact RelayHealth for retrigger (if within 15 months of beginning of PY) 99 Host Processing Error FIR will be retried for 2 days. After that, it will be retried in the next cycle. If the cycle is complete and final FIR has rejected, plan must resolve issue and contact RelayHealth for retrigger (if within 15 months of beginning of PY) 598 More Than One Patient Found Unique eligibility could not be confirmed based on patient data submitted. Refine patient data attributes. AK M/I Software Vendor/Certification AM M/I Segment Identification A9 M/I Count 1Ø9-A9 Indicates Facilitator M6 Host Eligibility Error Indicates Facilitator MS More Than One Cardholder Found Narrow Search Criteria 11Ø-AK If Vendor is not = MEDDFTROOP this indicates that the transaction is coming from an entity other than RelayHealth. Notify RelayHealth immediately 111-AM Indicates Facilitator 302-C2 Processor data does not N1 No Patient Match Found 302-C2 Processor data does not PB Invalid Count For This 1Ø3-A3, 1Ø9-A9 Indicates Facilitator PJ M/I Request Insurance 111-AM Indicates Facilitator Segment PK M/I Request Patient 111-AM Indicates Facilitator Segment PS M/I Header 111-AM Indicates Facilitator Segment P9 Field Is Non-Repeatable Varies Indicates Facilitator If the plan is rejecting FIRs with MEDDFTROOP, processor must insure that vendor is loaded into their system FIR Report Guide Page 19

22 RU R7 Description Mandatory Data Elements Must Occur Before Optional Data Elements In A Segment Repeating Segment No Allowed In Same Field in Error Varies Varies Facilitator Responsible Payer Responsible Comments Indicates Facilitator Indicates Facilitator R8 Syntax Error Varies Indicates Facilitator SØ Accumulator Month 656-S7 Indicates Facilitator Count Does Not Match Number of Repetitions S1 M/I Accumulator 65Ø-S1 Indicates Facilitator S2 M/I 651-S2 Indicates Facilitator Identifier S3 M/I Accumulated Patient 652-S3 Indicates Facilitator True Out Of Pocket Amount S4 M/I Accumulated Gross Covered Drug Cost Amount 653-S4 Indicates Facilitator S5 M/I Time 654-S5 Indicates Facilitator S6 M/I Accumulator Month 655-S6 Indicates Facilitator S7 M/I Accumulator Month 656-S7 Indicates Facilitator Count S8 Non-Matched 651-S2 Indicates Facilitator Identifier S9 M/I Financial 111-AM Indicates Facilitator Information Reporting Header Segment SW TØ T1 Accumulated Patient True Out of Pocket must be equal to or greater than zero Accumulator Month Count Exceeds Number of Occurrences Supported Request Financial Segment Required For Financial Information Reporting M/I Request Reference Segment 652-S3 Indicates Facilitator 656-S7 Indicates Facilitator 111-AM Indicates Facilitator T2 111-AM Indicates Facilitator T3 Out of Order Time 654-S5 Indicates Facilitator T4 Duplicate Time 654-S5 Indicates Facilitator W9 Accumulated Gross 653-S4 Indicates Facilitator Covered Drug Cost Amount Must Be Equal To Or Greater Than Zero XE X1 X2 X3 M/I Clinical Information Counter Accumulated Patient True Out of Pocket exceeds maximum Accumulated Gross Covered Drug Cost exceeds maximum Out of order Accumulator Months 493-XE Indicates Facilitator 652-S3 Indicates Facilitator 653-S4 Indicates Facilitator 656-S7, 655-S6 Indicates Facilitator FIR Report Guide Page 20

23 X4 X5 X6 X7 ZX ZY ZZ Description Accumulator not within ATBT Timeframe M/I Financial Information Reporting Request Insurance Segment M/I Request Financial Segment Financial Information Reporting Request Insurance Segment Required For Financial Reporting M/I CMS Part D MI/ Medicare Part D Benefit Package (PBP) Cardholder Submitted Is Inactive. New Cardholder On File Field in Error 65Ø-S1 111-AM 111-AM 111-AM Facilitator Responsible Payer Responsible Comments Indicates Facilitator Indicates Facilitator Indicates Facilitator Indicates Facilitator A33-ZX Processor data does not A34-ZY Processor data does not 302-C2 Processor data does not Note: According to NCPDP guidelines (see the Extended List), 90 Series Connectivity Errors have very specific meaning and purpose. In particular, it indicates that the host system encountered some type of problem so severe or long-term that the sender should not try to resend the transaction. For any reject codes within the 90 series, the FIR series will replay four times every four hours until successful or for a total of two days. Where "Indicates Facilitator " is noted, Facilitator has hardcoded system to not generate these types of errors; therefore we do not ever expect to receive these errors from the plan/processor. If processor is returning this error, they need to contact the facilitator to determine if there is a code problem on the processor side Generated by Facilitator These T* reject codes appear on a FIR Exception report because the Payer Response failed a RelayHealth edit. In other words, the Response sent back by the processor failed to meet one or more FIR specification requirements or business rules, as indicated in the table below based on the T* code. This indicates that the processor system has a problem with building Responses that needs to be fixed by the processor. Description Comments T*01 Syntax Error The response was malformed in a way that prevented it from being parsed correctly. T*S1 M/I Accumulator Must equal the requested year. Must be current or prior year. T*S2 M/I Identifier Must equal the value in request. T*S3 M/I Accumulated Patient True Out Of Pocket Must be present and non-negative. Amount T*S4 M/I Accumulated Gross Covered Drug Cost Must be present and non-negative Amount T*S6 M/I Accumulator Month Must be present, >0 AND <=12, and Month must not repeat. T*S7 M/I Accumulator Month Count Must be present, >0 AND <=12, and match number of Month values. T*SW Accumulated Patient True Out of Pocket must be Must be zero or positive. equal to or greater than zero T*W9 Accumulated Gross Covered Drug Cost Amount Must be zero or positive. Must Be Equal To Or Greater Than Zero. T*Z1 Troop Amount greater than Gross Amount The TrOOP Accumulator amount in a given month must be less than or equal to the corresponding Drug Spend amount. FIR Report Guide Page 21

24 Description Comments T*Z2 Troop and/or Gross Amount reduced The TrOOP and Drug Spend amounts returned in an F3 response for a given month must be greater than or equal to the corresponding amounts sent in the F3 request. Note. Per the FIR Implementation guide, if the recipient of an F3 Request has activity in an accumulator month sent in that Request (i.e. an overlap month), they should add their own activity to those accumulator *M/I = Missing/Invalid Note: In the event that a beneficiary has not incurred any reportable claims the processor must return a FIR containing the first month the beneficiary was with the plan (in the accumulator month), an accumulator month count =1, the accumulated TROOP =zero and the accumulated GCDC=zero. FIR Report Guide Page 22