Switches work with the Facilitator to help support
the success of the Medicare Part D program. They also provide
Medicare Part D related services to their customers.
This section defines the business and technical
relationship between Switches in the pharmacy industry and the
Medicare Part D TrOOP Reporting and Eligibility Facilitator.
Information on this site has been compiled after
consultation with the Switch community and the Center for Medicare
and Medicaid Services (CMS).
The BIN/PCN table is being defined by the TrOOP Facilitator and will schedule meetings with the switch community to discuss the definition and use of the table. It is not being defined by CMS.
The image below illustrates the transaction flow
between Switches and the Medicare Part D Facilitator (Facilitator).
During this process the Facilitator creates TrOOP Reporting transactions
and sends them to the Prescription Drug Programs (PDPs).
This transaction flow accomplishes the following
goals:
- Minimizes the development to switches
- Avoids switch service level to their customers
- Ensures that reject transactions are not sent to the Facilitator

Switch Transaction Flow
- The Pharmacy sends the Request to the Switch.
- The Switch receives and then sends the Request to the Payer.
- The Payer receives the Request and then sends a Response to
the Switch.
- The Switch receives the Response and then sends the Request
and Response in one transaction (Request/Response) to the Facilitator
within five seconds of receiving the Response from the Payer.
See the Message
Header Specification for details of the transfer of the
Request transaction.
- The Facilitator acknowledges the Request/Response from the
Switch and sends a captured response to the Switch within five
seconds.
See Standard
Captured Response.
Note: The Facilitator
will not reject a Request/Response sent by the Switch. See Threading |
- The Switch
may send the Response to the Pharmacy at any time before, during,
or after steps 4 or 5. This flexibility allows the Switch to
control the timing of the delivery of the Response to the Pharmacy.
| Note: If multiple Switches are involved in routing a transaction
from the pharmacy to a payer then, only the Switch that receives
the transaction from the pharmacy receives payment for sending
the Request/Response. |
The process above describes the normal flow of
transactions. In practice, Switches and the Facilitator will encounter
exceptions to this normal flow. These exceptions are listed below
along with the process to handle those exceptions.
Default Exception : Unknown Error
Although some problems can be foreseen, unexpected
events and formats may cause the Facilitator to be unable to create
a reasonable response. Because of this, each Switch should handle
the case where a particular transaction does not get a response.
The Switch should make best efforts to deliver the transaction
and should retry the transaction 3 times with a 30 second delay
between each attempt. If the transaction still does not get a
response please contact the Facilitator to have the transaction
traced.
| Note: This default exception handling applies only to transactions
which are having problems. If the Facilitator is down, it's
not necessary to go through this default exception handling. |
Exception 1 : Facilitator is Not Available
If the Facilitator is down and cannot accept Request/Response
transactions, then the Switch must:
- Store these transactions for up to 48 hours.
- When the Facilitator becomes available; the Switch will send
the Requests/Responses to the Facilitator as if they were being
sent in real-time. The transactions will be sent in the order
that the Switch received them from the pharmacy.
| Note: The Switch must ensure that any older transactions
are sent before any of the new transactions received in
real time. This will help process will ensure that the
ordering of transactions will be maintained when the Reporting
Transactions are sent to the PDPs by the Facilitator.
This process does not require a single-threaded approach
to send the transactions. The transactions can be delivered
multi-threaded, in 32 transaction increments. |
Exception 2 : Too Many Threads
If the Switch sends more than 32 transactions
at a time, then the Facilitator sends the reject message as indicated
in Reject
- Too Many Threads for each transaction after 32.
|