Allows for Communication of Prescription Information Between Prescribers and Dispensers

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 10.6	Final	Production		No	$	N/A
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 NCPDP SCRIPT Version 2017071 Implementation Guide supports the following transactions: Ask the Mailbox if there are any transactions (GetMessage) This transaction is used by the prescriber or pharmacy asking the mailbox if there are any transactions. It is at the heart of the mechanism used by a pharmacy or prescriber system to receive transactions from each other or from a payer or the Risk Evaluation and Mitigation Strategy (REMS) Administrator via a Switch, acting as a Mailbox. Please note that the adoption level of the GetMessage transaction is not reflected above. GetMessage transaction adoption is currently lower than that of the other communication transactions below (Status, Error, and Verify). Relay acceptance of a transaction back to the sender (Status) This transaction is used to relay acceptance of a transaction back to the sender. A Status in response to any applicable transaction other than GetMessage indicates acceptance and responsibility for a request. A Status in response to GetMessage indicates that no mail is waiting for pickup. A Status cannot be mailboxed and may not contain an error. Respond that there was a problem with the transaction (Error) This transaction indicates an error has occurred, indicating the request was terminated. An Error can be generated when there is a communication problem or when the transaction actually had an error. An error can be mailboxed, as it may be signifying to the originator that a transaction was unable to be delivered or encountered problems in the acceptance. The Error must be a different response than a Status, since the communication between the system and the Mailbox must clearly denote the actions taking place. An Error is a response being delivered on behalf of a previous transaction, and the Status signifies no more mail. Respond that a transaction requesting a return receipt has been received (Verify) This transaction is a response to a pharmacy or prescriber indicating that a transaction requesting a return receipt has been received. Verifications results when a “return receipt requested” flag is set in the original request. Upon receiving a transaction with ReturnReceipt set, it is the responsibility of the receiver to either generate a Verify in response to the request (recommended) or generate a Status in response to this request, followed subsequently by a free standing Verify. This transaction notifies the originator that the transaction was received at the software system. It is not a notification of action taking place, since time may elapse before the ultimate answer to the transaction may take place. 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 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 NCPDP SCRIPT Version 2017071 Implementation Guide supports the following transactions:
- Ask the Mailbox if there are any transactions (GetMessage)
  - This transaction is used by the prescriber or pharmacy asking the mailbox if there are any transactions. It is at the heart of the mechanism used by a pharmacy or prescriber system to receive transactions from each other or from a payer or the Risk Evaluation and Mitigation Strategy (REMS) Administrator via a Switch, acting as a Mailbox. Please note that the adoption level of the GetMessage transaction is not reflected above. GetMessage transaction adoption is currently lower than that of the other communication transactions below (Status, Error, and Verify).
- Relay acceptance of a transaction back to the sender (Status)
  - This transaction is used to relay acceptance of a transaction back to the sender. A Status in response to any applicable transaction other than GetMessage indicates acceptance and responsibility for a request. A Status in response to GetMessage indicates that no mail is waiting for pickup. A Status cannot be mailboxed and may not contain an error.
- Respond that there was a problem with the transaction (Error)
  - This transaction indicates an error has occurred, indicating the request was terminated. An Error can be generated when there is a communication problem or when the transaction actually had an error. An error can be mailboxed, as it may be signifying to the originator that a transaction was unable to be delivered or encountered problems in the acceptance. The Error must be a different response than a Status, since the communication between the system and the Mailbox must clearly denote the actions taking place. An Error is a response being delivered on behalf of a previous transaction, and the Status signifies no more mail.
- Respond that a transaction requesting a return receipt has been received (Verify)
  - This transaction is a response to a pharmacy or prescriber indicating that a transaction requesting a return receipt has been received. Verifications results when a “return receipt requested” flag is set in the original request. Upon receiving a transaction with ReturnReceipt set, it is the responsibility of the receiver to either generate a Verify in response to the request (recommended) or generate a Status in response to this request, followed subsequently by a free standing Verify. This transaction notifies the originator that the transaction was received at the software system. It is not a notification of action taking place, since time may elapse before the ultimate answer to the transaction may take place.
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 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 2024-08-13

NCPDP Comment

NCPDP recommends removing NCPDP SCRIPT Standard, Implementation Guide, Version 2022011, as this version was never implemented. NCPDP SCRIPT Standard Implementation Guide, Version 2023011 is the next version named by ASTP/ONC and Medicare. Federally required should be changed to a Yes for the NCPDP SCRIPT Standard Implementation Guide, Version 2023011.
NCPDP recommends that ASTP/ONC sunset NCPDP SCRIPT Standard, Implementation Guide, Version 10.6, as this version is no longer supported by the industry.

Submitted by pwilson@ncpdp.org on 2022-09-30