• Why are manual retriggers only allowed through May 31st for a prior plan year when plan have until June 30th to complete reconciliation?
• FIR Reports-Why are there more FIR rejections on the new Daily Cumulative FIR Aging Report than on the old Bi-monthly Exceptions Report?
• FIR Reports-Why am I receiving two FIR reject reports and which one should I use?
• FIR Reports-Will I get a report or notification if I do not have any rejected FIRs to report on the Daily Cumulative FIR Aging Report?
• FIR Reports-The Reject Code Description Field on my Daily Cumulative FIR Aging Report says "Unexpected Reject Code". What does this mean?
• FIR Reports-Why is the Reject Code field blank on my Daily Cumulative FIR Aging Report?
• FIR Reports-What does XXX reject mean (on the FIR Cumulative Aging Report) and how do I resolve the reject?
• How does a plan handle retroactive disenrollments that require CMS' vendor (i.e. Reed & Associates, etc) to drop the record from MARx?
• How should plans handle a FIR transaction from a prior plan(s) that have TrOOP amounts that exceed the TrOOP limit?
• I have had changes in my member's TrOOP balance since responding to a FIR request. How do I report these changes?
• If there are multiple plans involved in the sequence, each showing TrOOP and TGCDC values, are we to assume that a balance transfer between the two plans was never performed? Or should we assume that the transfer was done reflecting Plan A's values?
• I know the beneficiary changed plans, why am I not receiving FIR transactions?
• Why is my plan getting included in a FIR Sequence more than once with the same transaction ID?
• As a plan of record, I am having system problems that result in rejected FIRs due to eligibility data mismatches (between plan/processor and CMS). Can the transaction facilitator update the eligibility they have on file?
• What are the Part D Plan's responsibilities related to TrOOP Balance Transfers (FIR)?
• We have a member who is disputing their TrOOP amounts. What is the protocol for this type of situation?
• How do I correct a member who was never a member of record however, it is known that they did accrue TrOOP dollars under my plan?
• How can I change my password on my secure emails?
• The information we have on this member matches what is in MARX. Why are we still getting a rejection?
• Where does the BIN and PCN (cardholder ID etc.) information comes from that is included on FIR transactions?
• What kinds of changes do and do not trigger a FIR sequence?

---

Why are manual retriggers only allowed through May 31st for a prior plan year when plan have until June 30th to complete reconciliation?

The industry decided to stop manual FIR retriggers at the end of May to allow plan to have time to reprocess, reconcile and restack claims and submit PDE changes. 30 days was deemed enough time to complete these activities and have time to work any PDE errors that might occur with the adjustments.

Top

FIR Reports-Why are there more FIR rejections on the new Daily Cumulative FIR Aging Report than on the old Bi-monthly Exceptions Report?

For the old reports, FIRs that were previously accepted, but were later rejected

• were reported on the daily report
• were not reported on the bi-monthly

The new cumulative report, in addition to other improvements, was also designed to close this gap and eliminate the need for plans to consult two different reports to determine the status of FIR transactions. The new Daily Cumulative FIR Aging Report now contains any FIR that is rejected by the plan and is still in a rejected status as of the report date.

Top

FIR Reports-Why am I receiving two FIR reject reports and which one should I use?

Beginning in January 2013, Part D Plans will be considered out of compliance if they do not successfully transfer TrOOP accumulator data within 15 days of the effective date of the new enrollment or, if later, the date of the initial FIR transaction.

To assist Part D Plans/Processors in monitoring FIR transactions the industry has developed a new Daily Cumulative Aging Report that will identify every beneficiary with an unsuccessful FIR transaction as of the report date. This report will also provide information regarding the length of time the beneficiary has not had a successful FIR transaction, in addition to other data elements. The Daily Cumulative Aging Report will be available starting the morning of April 2, 2013.

The New Daily Cumulative Aging Report was designed to incorporate all of the data elements from each of the reports below into one report. Therefore the following reports will be discontinued as of 8-1-2013:

1. TBT Report - Email ALT.010 Report
   • daily*
   • Rejected FIR Transactions for POR's from the Previous Day
2. TBT Report - Email ALT.020 Report
   • daily*
   • Rejected FIR Transactions for Non-POR's from the Previous Day
3. TBT Report - Email RPT.080 Report
   • 1st and 16th of Month
   • Report of FIR Exceptions, by 1st and contract, that have been unresolved for 15 days or more

We highly recommend that you begin exclusively using the new Daily Cumulative FIR Aging Report as it contains rejects that were not previously reported under the old reports.

Top

FIR Reports-Will I get a report or notification if I do not have any rejected FIRs to report on the Daily Cumulative FIR Aging Report?

Plans that do not have any FIR rejects to report on a particular day's Daily Cumulative FIR Aging report will receive an email notification indicating there was nothing to report.

Top

FIR Reports-The Reject Code Description Field on my Daily Cumulative FIR Aging Report says "Unexpected Reject Code". What does this mean?

If the Reject Description Field States "Unexpected Reject Code" and the Reject Code field is blank this indicates that there was a failure somewhere within the Plan/Processor's system (unusually a front end failure).

If the Reject Description Field States "Unexpected Reject Code" and the Reject Code field contains a value a this indicates that the reject code the Plan/Processor has returned is not a valid NCPDP reject code.

Top

FIR Reports-Why is the Reject Code field blank on my Daily Cumulative FIR Aging Report?

If the Reject Code field is blank and the Reject Description states "Unexpected Reject Code" as the description, this indicates that there was a failure somewhere within the Plan/Processor's system (unusually a front end failure)

Top

FIR Reports-What does XXX reject mean (on the FIR Cumulative Aging Report) and how do I resolve the reject?

Most reject codes that appear on Daily Cumulative FIR Aging Report indicates the reject code that was returned to Transaction Facilitator by a PBM. Find a list and brief description of reject codes here.

In addition, some issues in the structure or content of a FIR Response may cause the Transaction Facilitator validity check (edit) to fail. These will always appear on an exception report with a reject code that begins with the "T*" as the first two characters. Find a description of those edit failure codes here. The Transaction Facilitator codes are listed on the last page of the FIR Reject Code document.

Top

How does a plan handle retroactive dis-enrollments that require CMS' vendor (i.e. Reed & Associates, etc) to drop the record from MARx?

These are retroactive dis-enrollments that are received after the beneficiary was active and eligible in the plan. This was not caused by a new plan taking over the enrollment period. It was most likely caused by the beneficiary notifying the plan that they did not want to enroll. When this occurs the plan dis-enrolls the beneficiary in their system and notifies the CMS' vendor to drop the record from MARx.

1. Until CMS receives and processes the Plan B retroactive dis-enrollment, Plan B is still the plan of record and must not reject the FIR.
2. Once CMS processes the Plan B retroactive disenrollment, then Plan B becomes an audit off record. Plan B can choose one of the following options for the audit off record.
   1. If there are no paid claims by Plan B, they can request a proxy delete of the audit off record or they can continue to process FIRs if their system is set up to handle FIRs regardless of effective period.
   2. If there are paid claims by Plan B, they must respond to the FIRs.
    

Top

How should plans handle a FIR transaction from a prior plan(s) that have TrOOP amounts that exceed the TrOOP limit?

CMS has guidance on this—Sponsors should not question excessive of maximum. Pass on the information. By the time of the next sequence, plan would be in a position to report the amended amounts.

Plans need to be aware and have processes in place to ensure that their claims utilize only up to the TrOOP limit, regardless of what is submitted on a FIR transaction.

Top

I have had changes in my member's TrOOP balance since responding to a FIR request. How do I report these changes?

If you are still within the FIR Series period, you will be able to report the new TrOOP amounts when you receive the next automated FIR request.

If you are past the last FIR Sequence date, CMS allows FIRs to be triggered manually up to May 31st following a Plan Year. More information on requesting a Manual FIR Retrigger.

Top

If there are multiple plans involved in the sequence, each showing TrOOP and TGCDC values, are we to assume that a balance transfer between the two plans was never performed? Or should we assume that the transfer was done reflecting Plan A's values?

An F2 will include all monthly values from all prior plans when there are multiple plans. Section 7.1.1.2 of the NCPDPFIR implementation guide can be referenced for the accumulator month count scenario for all transaction types.

Top

I know the beneficiary changed plans, why am I not receiving FIR transactions?

If any plan prior to coverage under your plan, rejects a FIR transaction, the transaction will stop with the rejecting plan. Once the rejecting plan correctly responds to a FIR (assuming no other prior plans reject), you will receive the FIR transaction.

With CMS' reduction in the compliance period to 15 days, downstream plans should receive a successful FIR earlier than in the past.

Top

Why is my plan getting included in a FIR Sequence more than once with the same transaction ID?

If a member is in a plan for multiple non-consecutive periods, each period will be included in the sequence. For example:

NOTE: In this instance we are seeing processors that are handling this request incorrectly by actually doubling the values returned in the last response.

The recommended method to respond to all FIRs sent to the plan with multiple non-consecutive periods is as follow:  

• First response should be for all months January through March and August and September
• Second response should include the same values returned in the first response for January -March and August-September plus Plan B values for April-July. Note that the values sent in the second response from Plan A are the same as what was sent in the first response.

The Financial Information Reporting Inquiry response from the oldest plan must contain the financial accumulator fields for every month for which the oldest plan has claim activity for the requested Accumulator Year (65Ø-S1). If there is no claim activity, the oldest plan must return one month (the Accumulator Month Count (656-S7) = 1), the beginning coverage month in Accumulator Month (655-S6), and the financial information accumulators must be zeroes.

Also note, that in either instance if there are accumulators reported by a contract ID other than yours for any overlapping months you must include those amounts in your responses.

Top

As a plan of record, I am having system problems that result in rejected FIRs due to eligibility data mismatches (between plan/processor and CMS). Can the transaction facilitator update the eligibility they have on file?

No, the only method for updating eligibility is via an eligibility file submission to CMS.

Top

What are the Part D Plan's responsibilities related to TrOOP Balance Transfers (FIR)?

The expectation is that all plans correctly report any TrOOP to any subsequent plan when a FIR transaction request is received. For new plans of record, systems must be in place to correctly apply any TrOOP amounts received from prior plans to the current plan accumulators for TrOOP.

In the event that a FIR transaction is rejected by the plan, CMS expects the plan causing the rejection to work to resolve the rejection within 15 days of the first FIR transmission.

Top

We have a member who is disputing their TrOOP amounts. What is the protocol for this type of situation?

As the Transaction Facilitator, we pass accumulators between plans but do not get involved in actual calculations of those values. We only do basic "reality" checks like ensuring that a supplied TrOOP value is not negative.

Dealing with questionable balances passed from another plan is similar to the protocol before Automated TrOOP Balance Transfers began in 2009–contact the other "upstream" plan directly to research to variance. However, do not manually update your TrOOP-related accumulators based on such discussions. Instead, once any incorrect values are corrected by an upstream plan, send a request to RelayHealth to manually trigger a FIR sequence to move those new balances from the upstream plan to your plan. To do this, follow the instructions on the Manual FIR Retrigger page.

Top

How do I correct a member who was never a member of record however, it is known that they did accrue TrOOP dollars under my plan?

The Plan accruing the dollars would need to complete a Proxy Add form. See Non Plan of Record for more information on this process.

Download and complete the Proxy Add Form which requires the following information:

• HICN
• BIN
• PCN
• Group ID
• Cardholder ID
• Contract ID
• PBP
• Beginning date of the first month for which claims were paid
• Ending date of the last month for which claims were paid.

Top

How can I change my password on my secure emails?

Submit a request to TBTSupport@RelayHealth.com indicating your need to reset your password.

Also indicate the email address used to receive the secure emails from RelayHealth.

Top

The information we have on this member matches what is in MARX. Why are we still getting a rejection?

Typically, if the 4Rx information provided to CMS by a plan is incorrect (or otherwise does not match what is in the processor/PBM's system), the processor system will probably reject the FIR transaction because their data for that beneficiary does not match the CMS data we use. If the CMS and PBM versions of the 4Rx data appear to exactly match, there are three likely causes of ongoing rejections:

1. If the plan returning a reject is audited off (non plan of record) for the member (in which case the reject will appear on the Daily Cumulative FIR Reject Report), you need to directly notify RelayHealth of the correct 4Rx for the member for that audited off plan. See Non Plan of Record for additional information.
2. It may be that the PBM is rejecting for reasons other than mismatched 4Rx data.
3. It is also possible that a code or configuration issue exists that is preventing the PBM's system from locating the member even though the CMS and PBM versions of the 4Rx data match exactly.

Top

Where does the BIN and PCN (cardholder ID etc.) information comes from that is included on FIR transactions?

The FIR transactions use the BINs/PCNs that are part of the nightly Medicare Enrollment feed from CMS's MBD (Medicare Beneficiary Database) to RelayHealth. MBD in turn reflects the 4Rx Part D enrollment data reported by plan sponsors to CMS MARX system on plan-generated enrollment transactions (or created by CMS in CMS-generated enrollments).

If the 4Rx data (BIN, PCN, Group, and Cardholder ID) that CMS has on file for a beneficiary in MARX does not match what the plan's PBM has on its system for that same beneficiary and plan, it is almost certain that any FIR transactions for that member will be rejected by the PBM (since they will not recognize the 4Rx in the FIR transaction). It is therefore incumbent upon plan sponsors to make corrections as needed to ensure that the 4Rx data for a member in CMS's MARX system and the corresponding 4Rx data in the PBM's system are both accurate and match exactly.

Top

What kinds of changes do and do not trigger a FIR sequence?

The Transaction Facilitator will generate a new FIR sequence based on certain changes in a beneficiary's coverage during a plan year. In general, these sequences are triggered in cases where the change in enrollment data indicates that a member changed to a different contract at one or more points during the year. In some cases, sequences can also be triggered when a change in enrollment data indicates that a member changed to a new Plan Benefit Program (PBP) within the same Contract and that change also corresponds with a possible change in Processor (PBM).

Specifically, these are the rules:

• If during a plan year a member changes to a new Contract ID, this will ALWAYS trigger a new FIR sequence to transfer TrOOP data from the old contract to the new.
• If during a plan year a member changes to a new Plan Benefit Program (PBP) within the same Contract ID, this will trigger a FIR sequence ONLY if the associated BIN and or PCN also changes. This occurs because this scenario makes it likely that the member may have changed processors or sponsors as well, so a FIR sequence is needed to transfer TrOOP data from the old Contract processor/sponsor to the new one.

Note: These rules apply both to plans of record and audited off plans (non plans of record) during a plan year.

The table below gives some examples of enrollment changes that would and would not trigger a FIR sequence:

Additionally, the following scenarios cause a FIR to be Triggered

1. 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.
2. 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.
3. A retrigger request, from any plan the beneficiary may have had during the plan year, will initiate a new sequence.
4. A beneficiary that has a FIR series "in flight" that also has a 4Rx or DOB change will generate a one time, on demaid, FIR sequence on the day prior to the effective date of the change or the date of receipt of the change (whichever is later) if a FIR sequence is not already in queue on that day.

Top