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.
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
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.
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:
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.
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.
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.
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)
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.
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.
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.
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.
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.
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.
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:
|
Plan |
Jan |
Feb |
Mar |
Apr |
May |
Jun |
Jul |
Aug |
Sep |
Oct |
|---|---|---|---|---|---|---|---|---|---|---|
|
Plan A 1/1/12 – 3/31/12 |
100 |
200 |
50 |
|||||||
|
Plan B 4/1/12 – 7/31/12 |
75 |
120 |
180 |
50 |
||||||
|
Plan A 8/1/12 – 9/30/12 |
100 |
200 |
||||||||
|
Plan C 10/1/12 – open ended |
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:
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.
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.
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.
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.
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:
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.
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:
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.
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:
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:
|
Date of Data Change |
Coverage Effective Date |
New Contract/PBP |
New BIN/PCN |
New FIR Sequence |
Comments |
|---|---|---|---|---|---|
|
1/1/10 |
6/1/09 (carryover) |
H1234/010 |
12345/ABC |
None |
Only one plan so far, so no FIR sequence |
|
2/1/10 |
6/1/09 (carryover) |
H1234/020 |
12345/ABC |
None |
PCN changed but neither BIN nor PBP did, so no sequence |
|
2/15/10 |
3/1/10 (see Comments) |
H5678/020 |
12345/ABC |
H1234/020 to H5678/020 |
Contract changed so FIR sequence begins (on one day before 3/1) |
|
3/15/10 |
3/1/10 |
H5678/020 |
12345/LMN |
H1234/020 to H5678/020 |
PCN changed but not Contract or PBP, so no sequence change |
|
4/1/10 |
3/1/10 (see Comments) |
H1479/010 |
56789/PQR |
H1234/020 to H5678/020 toH1479/010 |
New Contract H1479 with retro effective date. H5678 audits off (still in sequence) |
|
6/1/10 |
3/1/10 |
H1479/020 |
56789/XYZ |
H1234/020 to H5678/020 toH1479/010 toH1479/020 |
Contract stays same but PBP and PCN both change, so new sequence |
|
9/1/10 |
9/1/10 |
H2580/020 |
56789/XYZ |
H1234/020 to H5678/020 toH1479/010 toH1479/020 toH2580/020 |
New Contract so new sequence begins (even though BIN/PCN did not change) |