Allows a Pharmacy to Request, Respond to, or Confirm a Prescription Transfer

Printer Friendly, PDF & Email
Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Implementation Specification
Final
Feedback requested
Feedback Requested
No
$
No
Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration

 The following transactions need to be implemented for interoperability purposes:

  • RxTransferRequest: Used when the pharmacy is asking for a transfer of one or more prescriptions for a specific patient to the requesting pharmacy
    • The transfer is for a fillable prescription which may be:
      • yet to be filled
      • on hold
      • open (active) fills
      • current therapy (defined as drug therapy that, based upon the most recent fill date, quantity and instructions, should still be active)
      • allowed to be transferred by law/regulation
    • If multiple specific prescriptions are to be transferred, but not all prescriptions, a separate RxTransferRequest must be sent for each specific prescription
  • RxTransferResponse: The response from the transferring pharmacy to the requesting pharmacy to the RxTransferRequest which includes the prescription(s) being transferred or a rejection of the transfer request
  • RxTransferConfirm: Used by the pharmacy receiving (originally requesting) the transfer to confirm that the transfer prescription has been received and the transfer is complete
  • The RxFill Transaction <FillStatus><Transferred> is originated by the transferring pharmacy once the <RxTransferConfirm> is received from the transfer to pharmacy. This transaction is used to notify the prescriber when a prescription has been transferred to another pharmacy and can no longer be filled at the original pharmacy. The RxTransfer transaction will identify if the receiving pharmacy supports RxFill.
  • Both pharmacies must have their systems configured for the transaction in order to facilitate successful exchange, including the ability to send or receive verify, status, or error transactions.
  • See NCPDP projects in the Interoperability Proving Ground.

 Secure Message Router – securely route and enforce policy on inbound and outbound messages without interruption of delivery.

  • Authentication Enforcer – centralized authentication processes.
  • Authorization Enforcer – specifies access control policies.
  • Credential Tokenizer – encapsulate credentials as a security token for reuse (e.g., – SAML, Kerberos).
  • Assertion Builder – define processing logic for identity, authorization and attribute statements.
  • User Role – identifies the role asserted by the individual initiating the transaction.
  • Purpose of Use - Identifies the purpose for the transaction.

Comment