Allows a Prescriber or a Pharmacy to Request a Patient’s Medication History

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: RxHistoryRequest: a request from a prescriber or a pharmacy for a list of medications that have been prescribed, dispensed, claimed or indicated (OTCs) by a patient. This patient-specific transaction supplies enough information to uniquely identify the patient. RxHistoryResponse: A response to an RxHistoryRequest containing a patient’s medication history; includes the medications that were dispensed or obtained within a certain timeframe, and also optionally includes the prescriber's name. The receiver must evaluate the Consent for accurate reporting. Returns with loops of Medication, HistorySource, Prescriber, Pharmacy, and Patient elements when appropriate. HistorySource and FillNumber elements are included, when appropriate, so prescribers are able to de-duplicate records from multiple sources that reflect the same medication dispensing, and to help determine patient compliance with a prescription. Helps the prescriber determine if follow-up contact is required regarding the medication records. RxHistoryRequest and RxHistoryResponse may be sent directly or through an intermediary. Medication history transactions may be exchanged among prescribers, pharmacies, or payers, and may include adjudicated claims and/or pharmacy dispensed/point of sale prescription information. It is recommended that prescribers request Medication History from all applicable sources, whenever appropriate, to ensure the most complete view of a patient’s medication history. The Medication History may be reconciled with the prescriber’s patient record for improved medication management and to assist in clinical decision support. Both the sender and receiver 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. This may also include hospitals and/or Accountable Care Organizations (ACOs).	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:
- RxHistoryRequest: a request from a prescriber or a pharmacy for a list of medications that have been prescribed, dispensed, claimed or indicated (OTCs) by a patient.
  - This patient-specific transaction supplies enough information to uniquely identify the patient.
- RxHistoryResponse: A response to an RxHistoryRequest containing a patient’s medication history; includes the medications that were dispensed or obtained within a certain timeframe, and also optionally includes the prescriber's name.
  - The receiver must evaluate the Consent for accurate reporting.
  - Returns with loops of Medication, HistorySource, Prescriber, Pharmacy, and Patient elements when appropriate.
  - HistorySource and FillNumber elements are included, when appropriate, so prescribers are able to de-duplicate records from multiple sources that reflect the same medication dispensing, and to help determine patient compliance with a prescription.
    - Helps the prescriber determine if follow-up contact is required regarding the medication records.
RxHistoryRequest and RxHistoryResponse may be sent directly or through an intermediary.
Medication history transactions may be exchanged among prescribers, pharmacies, or payers, and may include adjudicated claims and/or pharmacy dispensed/point of sale prescription information.
It is recommended that prescribers request Medication History from all applicable sources, whenever appropriate, to ensure the most complete view of a patient’s medication history. The Medication History may be reconciled with the prescriber’s patient record for improved medication management and to assist in clinical decision support.
Both the sender and receiver 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. This may also include hospitals and/or Accountable Care Organizations (ACOs).

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 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.

Submitted by pwilson@ncpdp.org on 2023-10-06

NCPDP Comment

NCPDP recommends that ONC sunset NCPDP SCRIPT Standard, Implementation Guide, Version 10.6 as this version is no longer supported by the industry.

Submitted by shellyspiro on 2023-10-02

Pharmacy HIT Collaborative (PHIT) comment

PHIT supports NCPDP’s recommendation to sunset NCPDP SCRIPT Standard, Implementation Guide, Version 10.6.

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

NCPDP Comments

NCPDP recommends to sunset NCPDP SCRIPT Standard Implementation Guide Version 10.6

Submitted by pwilson@ncpdp.org on 2021-09-29

NCPDP Comments

Sunset NCPDP SCRIPT Implementation Guide Version 10.6

Submitted by MJA33 on 2021-07-13

RX History

Does the provider have to have written authorization from the patient to obtain RX history

Submitted by NecoleRodgers1984 on 2023-06-07

Provider history for Necole Rodgers

This is my request to get my prescription history sent to me for the last five years. I hope this is enough to get my history sent to me without extra paperwork from my end. I'm not sure what I'm doing so disregard it this request is doing wrong.

Thanks

Necole rodgers

Submitted by pwilson@ncpdp.org on 2020-11-07