Allows a Prescriber to Cancel 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 - CancelRx: a request from the prescriber to the pharmacy to not fill a previously sent prescription. Must contain pertinent information for the pharmacy to be able to find the prescription in their system (patient, medication (name, strength, dosage form, prescriber, prescription number if available). Changes can be indicated in the MessageRequestCode in the CancelRx transaction. CancelRxResponse: a response from the pharmacy to the prescriber to acknowledge a CancelRx. Used to denote if the cancellation is Approved or Denied. DenialReasonCode should be sent when a CancelRx is denied. When a Long-Term Care (LTC) prescriber has the need to modify an order and notify the pharmacy, the prescriber system will always send a CancelRx and a NewRx, regardless of the type of change. Both the prescriber and the pharmacy 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 -
  - CancelRx: a request from the prescriber to the pharmacy to not fill a previously sent prescription.
    - Must contain pertinent information for the pharmacy to be able to find the prescription in their system (patient, medication (name, strength, dosage form, prescriber, prescription number if available).
    - Changes can be indicated in the MessageRequestCode in the CancelRx transaction.
  - CancelRxResponse: a response from the pharmacy to the prescriber to acknowledge a CancelRx.
    - Used to denote if the cancellation is Approved or Denied.
    - DenialReasonCode should be sent when a CancelRx is denied.
  - When a Long-Term Care (LTC) prescriber has the need to modify an order and notify the pharmacy, the prescriber system will always send a CancelRx and a NewRx, regardless of the type of change.
Both the prescriber and the pharmacy 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 2.