Allows a Pharmacy to Request Additional Refills

Printer Friendly, PDF & Email
Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Emerging Implementation Specification
Feedback requested
Feedback Requested
Implementation Specification
Rating 4
Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • The following transactions need to be implemented for interoperability purposes:
    • SCRIPT 10.6 -
      • Refreq, originated from the pharmacy to the prescriber requesting additional refills.
      • Refres, originated from the prescriber to the pharmacy with a Rx authorization for refills; the response to a Refreq message.
    • SCRIPT 2017071 -
      • RxRenewalRequest, originated from the pharmacy to request additional refills beyond those originally prescribed
        • FollowUpRequest, originated from the pharmacy to:
          • notify prescribers that this is a follow-up RxRenewalRequest or RxChangeRequest transaction, when the prescriber has not responded to the first RxRenewalRequest or first RxChangeRequest transaction in a reasonable amount of time.
          • not sent on the original request of the RxRenewalRequest or RxChangeRequest transaction
      • RxRenewalResponse, originated from the prescriber to respond to the request 
        • Options allowed when generating an RxRenewalResponse to an RxRenewalRequest from a pharmacy:
          • Approved: Grant the RxRenewalRequest as requested by the pharmacy, or, when the pharmacy does not request a specific number of fills (PharmacyRequestedRefills is not present) and the prescriber approves any number of fills
          • ApprovedWithChanges: Grant the RxRenewalRequest, approving a NumberOfRefills different than the number requested by the pharmacy or when the information submitted in the RxRenewalRequest does not include all elements constituting a fillable prescription; the prescriber should include all information
          • Denied: Deny the RxRenewalRequest as requested by the pharmacy 
            • In a Denied response, the only new meaning that should be conveyed to the pharmacy is information that explains the denial. It is recommended that the prescribing software update the NumberOfRefills to zero and leave all other data as is in the RxRenewalResponse
          • Replace: Data is allowed to be changed except the patient DateOfBirth. If patient DateOfBirth changes, a Denied response would be sent, and then a NewRx would follow
        • The receiving pharmacy might handle each of these responses differently. Approved, ApprovedWithChanges, and Replace responses might be directed to a fulfillment queue, where a Denied response might be directed to a review queue
        • The Replace response should be used if there are any changes beyond what is outlined in the Response Element
      • RxRenewalRequest should never be responded to with a NewRx, as this would result in duplicate valid prescriptions
      • DeniedNewPrescriptionToFollow response is not to be sent in an RxRenewalResponse for this version of SCRIPT. However, the DeniedNewPrescriptionToFollow response could be received in an RxRenewalResponse from a previous version of SCRIPT and is included for backwards compatibility. DeniedNewPrescriptionToFollow response only exists for entities that need to map this version to a previous version of SCRIPT that does not support a Replace.
  • Both the pharmacy and the prescriber 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 Communication – create a secure channel for client-to- server and server-to-server communication.
  • 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.