Allows a Pharmacy to Request a Change to a Prescription

Type	Standard / Implementation Specification	Standards Process Maturity	Implementation Maturity	Adoption Level	Federally required	Cost	Test Tool Availability
Implementation Specification	NCPDP® SCRIPT Standard, Implementation Guide, Version 2017071	Final	Production		Yes	$	Yes
Implementation Specification	NCPDP SCRIPT Standard, Implementation Guide, Version 2023011	Final	Feedback requested	Feedback Requested	Yes

Limitations, Dependencies, and Preconditions for Consideration	Applicable Security Patterns for Consideration
Please refer to CMS.gov for more information regarding Medicare Part D electronic prescribing requirements and sign up to receive the latest announcements. The following transactions need to be implemented for interoperability purposes: NCPDP SCRIPT 2017071 - RxChangeRequest, originated from the pharmacy to request: A change in the original prescription (new or fillable). Validation of prescriber credentials. A prescriber to review the drug requested. Prior authorization from the payer for the prescription. 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. RxChangeResponse, originated from the prescriber to respond: To a prescription change request from a pharmacy. To a request for a prior authorization from a pharmacy. To a prescriber credential validation request from a pharmacy. Options allowed when generating an RxChangeResponse in response to an RxChangeRequest from a pharmacy: Approved: Grant the RxChangeRequest when the prescriber concurs with the request. The prescriber must submit an RxChangeResponse equal to what the pharmacy requested. ApprovedWithChanges: When the information submitted in the RxChangeRequest does not include all elements constituting a fillable prescription; the prescriber should include all information. Denied: Denies the RxChangeRequest with information that explains the denial. Validated: Sent by the prescriber system in response to an RxChangeRequest for prescriber authorization. When drug allergies and/or drug-drug interactions initiate a prescription change request, best practice is to alert the ordering provider and the pharmacy so that they may document these events in their respective systems for future error avoidance. The receiving pharmacy should handle Approved, ApprovedWithChanges, and Validated responses as a fillable NewRx where the original linked prescription/order is discontinued. A Denied response should be directed to a review queue where the Denial reason code is displayed. 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.	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.

Limitations, Dependencies, and Preconditions for Consideration

Applicable Security Patterns for Consideration

Please refer to CMS.gov for more information regarding Medicare Part D electronic prescribing requirements and sign up to receive the latest announcements.
The following transactions need to be implemented for interoperability purposes:
- NCPDP SCRIPT 2017071 -
  - RxChangeRequest, originated from the pharmacy to request:
    - A change in the original prescription (new or fillable).
    - Validation of prescriber credentials.
    - A prescriber to review the drug requested.
    - Prior authorization from the payer for the prescription.
  - 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.
  - RxChangeResponse, originated from the prescriber to respond:
    - To a prescription change request from a pharmacy.
    - To a request for a prior authorization from a pharmacy.
    - To a prescriber credential validation request from a pharmacy.
  - Options allowed when generating an RxChangeResponse in response to an RxChangeRequest from a pharmacy:
    - Approved: Grant the RxChangeRequest when the prescriber concurs with the request. The prescriber must submit an RxChangeResponse equal to what the pharmacy requested.
    - ApprovedWithChanges: When the information submitted in the RxChangeRequest does not include all elements constituting a fillable prescription; the prescriber should include all information.
    - Denied: Denies the RxChangeRequest with information that explains the denial.
    - Validated: Sent by the prescriber system in response to an RxChangeRequest for prescriber authorization.
When drug allergies and/or drug-drug interactions initiate a prescription change request, best practice is to alert the ordering provider and the pharmacy so that they may document these events in their respective systems for future error avoidance.
The receiving pharmacy should handle Approved, ApprovedWithChanges, and Validated responses as a fillable NewRx where the original linked prescription/order is discontinued. A Denied response should be directed to a review queue where the Denial reason code is displayed.
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.

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.

Comment

Submitted by pwilson@ncpdp.org on 2017-11-20

NCPDP - Comments on Version 10.6

The adoption level should be modified to a 3.