Home Contact Us
   
 
 
 
 
Overview
Programmer Details
BIN/PCN Requirements
Connectivity to Facilitator
Legal Agreements
Financial Terms
Testing Process
Milestone Schedule
Support
Industry Call

Switches

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.

Transaction Flow

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

  1. The Pharmacy sends the Request to the Switch.

  2. The Switch receives and then sends the Request to the Payer.

  3. The Payer receives the Request and then sends a Response to the Switch.

  4. 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.

  5. 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


  6. 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.


Exceptions

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:

  1. Store these transactions for up to 48 hours.

  2. 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.

 

 
© 2008 RelayHealth. All Rights Reserved.