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

Printer Friendly, PDF & Email
Type Standard / Implementation Specification Standards Process Maturity Implementation Maturity Adoption Level Federally required Cost Test Tool Availability
Rating 2
Rating 1
Limitations, Dependencies, and Preconditions for Consideration
Applicable Security Patterns for Consideration
  • 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, optionally including the prescriber that prescribed it
      • 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). 
  • See NCPDP projects in the Interoperability Proving Ground
  • 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.


NCPDP - Comment on Version 10.6

The second bullet under Limitations, Dependencies, and Preconditions for Consideration should be modified to include Hospitals and Accountable Care Organizations (ACOs).

Pharmacy HIT Collaborative's Comments on ONC's Proposed 2018 ISA

The Pharmacy HIT Collaborative supports the move to NCPDP SCRIPT Version 2017071 as soon as participants can reasonably be ready to implement such a change.  The Collaborative supports the use of NCPDP Script Standard, Implementation Guide, Version 10.6.

NCPDP Comment

  1. NCPDP supports the use of the NCPDP SCRIPT RxHistoryRequest/RxHistoryResponse transactions for PDMP.