- 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.
- 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.
|
Submitted by pwilson@ncpdp.org on 2022-09-30
NCPDP Comments
NCPDP recommends to sunset NCPDP SCRIPT Standard Implementation Guide Version 10.6