|Type||Standard / Implementation Specification||Standards Process Maturity||Implementation Maturity||Adoption Level||Federally required||Cost||Test Tool Availability|
|Limitations, Dependencies, and Preconditions for Consideration||
Applicable Security Patterns for Consideration
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 REMS Administrator via a Switch, acting as a Mailbox.
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.