Medication History Early Adopter Draft Companion Guide

Medication History Early Adopter Draft Companion
Guide 3.0
Based on NCPDP SCRIPT Version 2017071
October 1, 2018
THIS IS AN EARLY ADOPTER GUIDE. REQUIREMENTS ARE SUBJECT TO CHANGE.
MEDICATION HISTORY EARLY ADOPTER DRAFT COMPANION GUIDE 3.0
PUBLISHED BY
SURESCRIPTS, L.L.C.
920 2ND AVENUE S.
MINNEAPOLIS, MN 55402
PHONE: 866-267-9482
FAX: 651-855-3001
2800 CRYSTAL DRIVE

ARLINGTON, VA 22202
PHONE: 866-797-3239
FAX: 703-921-2191
WWW.SURESCRIPTS.COM
Copyright© 2018 by Surescripts, LLC.
All rights reserved. Proprietary and Confidential.
This document and all other documents, materials, and information, transmitted or orally communicated by
Surescripts® in the course of the parties’ dealings constitute and are hereby designated as proprietary and
confidential information of Surescripts, and may not be reproduced or distributed (in whole or in part) without the
express written consent of Surescripts.
FOR SECTIONS OF THIS CUSTOMER GUIDE

PERTAINING TO NCPDP STANDARDS:
Materials Reproduced With the Consent of
©National Council for Prescription Drug Programs, Inc.
NCPDP
NCPDP is a registered trademark of the National Council for Prescription Drug Programs, Inc. Membership of
NCPDP acknowledges your support and commitment to implement these standards as specified in the standards
documentation. You further acknowledge that the Council’s standards documents and their predecessors include
proprietary material protected under the U.S. Copyright Law and that all rights remain with NCPDP.
Medication History EA Draft CG 3.0 Table of Contents
TABLE OF CONTENTS
Section 1: Product Overview 5
1.1 About Medication History 5
1.2 About This Guide 5
1.3 Examples Disclaimer 6
1.4 Guide Disclaimer 6
1.5 Document References 6
Section 2: Product Integration & Production 8
2.1 Integration Process 8
2.2 Terminology Usage 9
2.3 Transition to Production 9
2.4 Communication Rules 9
2.5 Synchronous Processing 9
2.6 UTC Time Format 10
2.7 Character Set 10
2.8 Compliance 11
Section 3: Messages Overview 12
3.1 Message Descriptions 12
3.2 Medication History Request/Response Message Flow 13
3.2.1 Example Response Scenarios for Multiple Sources of Data 15
3.3 Acknowledgement Messages 16
3.3.1 Status 16
3.3.2 Status Best Practice 16
3.3.3 Error 16
3.3.4 Acknowledgment Message Table 17
3.3.5 Error Codes 17
3.3.6 Error Text Table 18
3.3.7 Message Workflow Scenarios 19
3.4 Message Validation 22
Section 4: Message Definition 23
4.1 Requirement Designation 23
P UBLISHED 10/01/2018 COPYRIGHT © 2018 BY S URESCRIPTS, LLC. P AGE 3

A LL RIGHTS RESERVED . P ROPRIETARY AND CONFIDENTIAL
Medication History EA Draft CG 3.0 Table of Contents
4.2 Message Header 24

4.2.1 Message Header XML Requirements 24
4.3 Medication History Request 26
4.3.1 RxHistoryRequest XML Requirements 26
4.4 Medication History Response 28
4.4.1 RxHistoryResponse XML Requirements 28
Section 5: Medication History XML Examples 31
5.1 RxHistoryRequest – Provider Vendor to Surescripts 31
5.2 RxHistoryRequest – Surescripts to PBM/Payer 33
5.3 RxHistoryResponse – PBM/Payer to Surescripts 34
5.4 RxHistoryResponse – Surescripts to Provider Vendor 37
5.4.1 RxHistoryResponse Note Description 40
5.4.2 Codified Field Usage for Federal Medication Terminologies (FMT) Codes 41
Section 6: Application Certification Requirements 42
Appendix A: Translation 44
Appendix B: Document Change Log 45

Medication History EA Draft CG 3.0 Section 1: Product Overview
SECTION 1: PRODUCT OVERVIEW
1.1 ABOUT MEDICATION HISTORY

The Surescripts Medication History services provide prescribers with the electronic delivery of
PBM/payer claim data and/or pharmacy fill data.
l The Surescripts Medication History for Ambulatory services are designed to allow
authorized health care providers and their authorized agents to electronically access a
patient's medication history, including but not limited to, PBM/payers and retail pharmacies
only in connection with and in conjunction with the treatment of a specific patient in a
scheduled visit or walk-in outpatient visit or another specific treatment event.
l The Surescripts Medication History for Reconciliation Services are designed to allow
authorized health care providers and their authorized agents in the Acute Care and Long
Term Post Acute Care (LTPAC) settings to electronically access a patient’s medication
history, including but not limited to, information from PBM/payers and retail pharmacies for
the purpose of medication reconciliation.
l The Surescripts Medication History for Populations – Panel History is designed to assist
authorized health systems, hospitals, risk-bearing groups and their authorized agents to
electronically access a patient’s medication history, including but not limited to, PBM/payers
and retail pharmacies only in connection and conjunction with the treatment of a specific
patient and for the purposes of better managing the health of patient populations.
1.2 ABOUT THIS GUIDE

This Surescripts Medication History Companion Guide was created to assist customers in
developing and transmitting messages needed to provide medication history to physicians in
Ambulatory or Acute settings and LTC facilities. This document represents XML implementations
as XML is the sole language supported for Medication History through Surescripts.
Note: The terms "message" and "transaction" are used interchangeably throughout this guide.
"Transaction" is used when referencing language pulled directly from a standards organization
document which uses the term "transaction".

1.3 EXAMPLES DISCLAIMER

Examples provided throughout this Guide are not intended to be all-inclusive. This pertains to
example workflows, element-specific (field) examples, or message examples. Customers should
not restrict coding to the examples used herein.
When developing, this Guide should be used along with the accompanying schema file, additional
documentation referenced, and applicable customary XML coding standards.
1.4 GUIDE DISCLAIMER

In the event that Customer chooses to make any changes to Customer’s software recommended in
this guide, Customer acknowledges and agrees that (1) Surescripts shall bear no responsibility or
liability for Customer’s changes or any effects thereof and (2) Customer shall be required to
transition to the new guide at such time as said guide is published, which may involve different or
additional parameters than are published in this guide.
1.5 DOCUMENT REFERENCES

Please reference the following documents when reading this Companion Guide:
Surescripts Provided Materials

Surescripts Connectivity and Authentication Implementation Guide
Medication History 3.0 Translation Matrix
Surescripts Eligibility and Formulary: Eligibility Companion Guide
External materials to be obtained by the customer (available at www.NCPDP.org)
NCPDP SCRIPT Standard 2017071 package: Includes the XML Schemas, Implementation Guide, XML
Standard Guide, and SCRIPT Standard Examples Guide V13
NCPDP SCRIPT Implementation Recommendations Version 1.45
NCPDP External Code List 201707 (NCPDP online tool)
This Guide utilizes the NCPDP messaging standard version 2017071 as a baseline. Members of
NCPDP can access standards at http://ncpdp.org/Standards/Standards-Info. To become a
member, please go to https://ncpdp.org/membership/Apply-Online.aspx.
The NCPDP SCRIPT Standard 2017071 package contains a complete list of fields and additional
requirements. Customers should read and comprehend the associated standards prior to reading
this Guide.

NCPDP is an American National Standards Institute (ANSI) accredited Standard Development

Organization. The NCPDP SCRIPT standard is a copyrighted document and may be obtained by
contacting:
NCPDP
9240 E. Raintree Drive
Scottsdale, AZ 85260-7518
Phone: (480) 477-1000
Fax: (480) 767-1042
http://www.ncpdp.org

Medication History EA Draft CG 3.0 Section 2: Product Integration & Production
SECTION 2: PRODUCT INTEGRATION &

PRODUCTION
2.1 INTEGRATION PROCESS

Once Surescripts assigns an Integration resource, customers will be contacted to begin the project
(s) and will be guided through the Surescripts Integration process. The Integration resource will
provide Surescripts documentation, product education, access to the Surescripts staging
environment, assistance during design and development phases and testing to prepare for
certification. The Integration resource will perform certification testing, and once successful, will
provide access to the Surescripts production environment.
Note: The time frame of the project can vary depending on your resource allocation for the
project.
Meeting Requirements
During Integration, customers undergo certification testing to demonstrate all requirements are
met. Certification focuses on message format, and when appropriate, application workflow and
display in accordance with Surescripts documentation and the associated Application Certification
Requirements (ACRs). Upon successful completion of certification and, when applicable, other
pre-production network requirements (e.g., Identity Proofing, DEA audit), customers may
transition to production.
For requirements, consider the following:

l Surescripts ACRs are required to be met to achieve production status on the Surescripts
network and will be enforced as part of certification.
l Surescripts business rules are data validations applied by Surescripts beyond the schema
requirements that will cause a message to be successful or rejected.
l Surescripts test cases do not cover all possible scenarios in production. Customers are
responsible for testing all scenarios specific to their production environment.
l In accordance with customer’s legal agreement with Surescripts, each customer is
responsible for ensuring compliance with all applicable laws including, but not limited to, local
and state laws/regulations where doing business.

2.2 Terminology Usage

For terminology usage throughout this guide, consider the following:
Term Term Usage

must Requirements that are enforced as part of the production code or Surescripts business rules.
shall Requirements customers are required to meet in order to be certified on the Surescripts network.
These requirements will be enforced as part of certification.
should Used for guidance and best practices. Customers are encouraged, but not required, to meet best
practices in order to be certified on the Surescripts network.
M.### Designates a Surescripts Medication History ACR.
S.### Designates an ACR that is shared with other Surescripts products.
2.3 TRANSITION TO PRODUCTION

Once certification is complete and all Surescripts requirements have been met, the customer is
ready to move into production. Surescripts will configure the production connection and validate
successful operations with the customer. Once production is activated and validated, Surescripts
Account Management will schedule a hand-off meeting for the customer and Surescripts to discuss
the following:
l Lessons Learned and/or Satisfaction Survey
l Production support contacts (from both Surescripts and the customer)
l Support process and training
l Support hours
2.4 COMMUNICATION RULES

Please refer to the Connectivity and Authentication Guide for additional connectivity and
authentication information. For the network to be reliable, there are communication rules to which
all customers must adhere.
2.5 SYNCHRONOUS PROCESSING

Each message that Surescripts submits to a customer has a time-out parameter. If Surescripts
does not get a response from the customer within the specified time period, the message times out.
If the timeout occurs, an error message will be returned to the sender as the reply. If the sender has
timed out, the message is discarded.

l When sending a message to Surescripts, the provider vendor system should set the http
timeout to no less than 30 seconds.
l A receiving system must reply with a valid response within 10 seconds.
2.6 UTC TIME FORMAT

By using Universal Time Coordinated (UTC), the receiver of a message will know the time
regardless of their time zone. For example: If a message was sent from Boston at 5:30PM EDT
(Eastern Daylight Time), the time would be sent as 21:30 UTC time. If this message was received
in Chicago CDT (Central Daylight Time), the 21:30 UTC could be converted to the local CDT time
of 4:30PM. Refer to http://en.wikipedia.org/wiki/Coordinated_Universal_Time, or
http://www.w3.org/XML/ for more information. Synchronize UTC time with NIST (National Institute
of Standards and Technology). Drift of no more than one minute will be acceptable.
When sending only a Date (not Date and Time), it should be sent in your local time zone, and the
receiver should interpret it in their local time. Neither party should attempt to convert the Date to
UTC.
All standard programming languages should have a function for generating a date in the UTC time
zone or displaying a date in the local time zone. The format of the date/time fields in the XML
schema must use the xsd:dateTime format. Examples of that format are: CCYY-MM-
DDTHH:MM:SS.FZ, where the UTC time zone may be specified as Z, + 00:00, or - 00:00. For
example, 2013-01-01T16:09:04.5Z, or 2013-01-01T16:09:04.5-00:00, or 2013-01-
01T16:09:04.5+00:00, where 16:09:04.5Z would be 16 hours, 09 minutes, 04 seconds, 5 fractional
seconds. UTC time is denoted by either the “Z” in the first example or the “-00:00” in the second
example, or the “+00:00” in the third example. The fractional seconds is not required. Refer to
xsd:dateTime for more information.
For simple date fields that do not include the time portion, the format is: CCYY-MM-DD.
2.7 CHARACTER SET

The character set contains ASCII values 32 – 126, which include:
Symbols ! " # $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~
Numerals Ø to 9
Letters, upper and lower case A to Z, a to z
Unprintable characters, such as control characters, are not used within the field sets. Defined
unprintable characters are used as delimiters.
UTF-8 is the required character encoding for XML. Other encoding formats are not supported by
Surescripts. It is recommended that customers declare their UTF-8 formatting in the message
header.

2.8 COMPLIANCE
Surescripts goal is efficiency and consistency across the network so that all customers can meet
the highest measures of patient safety, end-to-end reliability, and quality. To ensure that customers
comply with, and adhere to, the approved certification requirements, Surescripts:
l initiates a remediation process for identified compliance issues, and
l monitors customers in production to ensure all network customers remain in compliance with
certification requirements and contractual terms.
Customers agree to notify Surescripts when they have altered, reconfigured or disabled any
portion of a Surescripts certified software product or module, before moving such changes into
production, as they may create a circumstance of non-compliance with the Surescripts certification
issued. In those instances, Surescripts will work with the customer to perform a timely re-
certification, if required, to ensure network compliance and safety.
This Guide is intended for certification on our network only and is not intended to ensure
compliance with state and federal law. In accordance with customer’s legal agreement with
Surescripts, each customer is responsible for conducting its own due diligence to ensure
compliance with all applicable laws and requirements, including, but not limited to, local and state
laws and regulations in which the customer’s application is deployed and used.
As a reminder, Surescripts conducts certification with customers to ensure the application adheres
to network requirements. Surescripts will enforce mandatory fields as required by the Standards
body and Surescripts guide requirements. To maximize interoperability, customers are
recommended to support optional fields that have been created to address gaps in discrete data
needs and the many solutions that are in place for the benefit of the receiver. Surescripts
encourages, but does not guarantee the use of optional discrete fields to support end user
workflows.

Medication History EA Draft CG 3.0 Section 3: Messages Overview
SECTION 3: MESSAGES OVERVIEW
3.1 MESSAGE DESCRIPTIONS

RxHistoryRequest
The provider sends patient demographic information in the RxHistoryRequest message. Providers can request for up to 12 months of
history from the date of the request.
RxHistoryResponse
The RxHistoryResponse message returns information about outpatient prescriptions that the patient’s PBM/payer has paid for over a
selected period of time and contains retail fill data from pharmacies connected to Surescripts for Medication History.
Up to the last 300 medications are returned, starting with the most recent.
Note: When more medications are available, a More Medications Available response is returned in the Approved/ReasonCode (AQ -
More Medication History Available) and then another RxHistoryRequest can be sent to obtain additional medication history.
P UBLISHED COPYRIGHT © 2018 BY S URESCRIPTS, LLC. P AGE 12

10/01/2018 A LL RIGHTS RESERVED . P ROPRIETARY AND CONFIDENTIAL
3.2 MEDICATION HISTORY REQUEST/RESPONSE MESSAGE FLOW

The graphic below depicts the optimal message flow between customers.

The following steps depict the basic workflow of a Medication History message:
*1. Medication History for Ambulatory: The Eligibility Request (270) is sent by the provider vendor system to Surescripts to obtain eligibility
information. The Interchange Control Number (ISA13) from the Eligibility Request (270) is sent in the RxHistoryRequest.
Note: This also applies to Medication History for Reconciliation customers who perform an eligibility request (270).
2. Provider vendor system sends an RxHistoryRequest message to Surescripts.
3. Provider vendor system receives a ‘Status 000’ response from Surescripts acknowledging receipt.
4. PBM/payer system receives an RxHistoryRequest message from Surescripts.
5. PBM/payer system sends a synchronous RxHistoryResponse message to Surescripts.
6. Provider vendor system receives an asynchronous aggregated RxHistoryResponse message (including both fill and claim records)
from Surescripts.
Note: In cases where the patient was found and no medications were available, the provider vendor system will receive an
asynchronous RxHistoryResponse message from Surescripts with Response/Approved/ReasonCode = ‘DJ’ and Note = "Although a
patient record was found, no medications were available.”
7. Provider vendor system sends a synchronous ‘Status 010’ response to Surescripts acknowledging receipt.

3.2.1 EXAMPLE RESPONSE SCENARIOS FOR MULTIPLE SOURCES OF DATA

RxHistoryRequest Data Sources RxHistoryResponse (Aggregated Response)
Prescription PBM/ PBM/ Response
Message Description Additional Messaging Elements
Fill Payer-1 Payer-2 Segment
Valid RxHistoryRequest: Medications Medications No All Approved

Medications Medications
Patient has coverage with
Found
two
PBM/Payers and may Medications No Error All Approved Approved/Note = Not all medication history
have Medications Medications sources were accessible at this time.
pharmacy fill medications. Found
No No Error No Approved Approved/ReasonCode = ‘DM’ AND Note = A

Medications Medications Medications processing error occurred. No medication history
was returned.
No No No No Approved Approved/ReasonCode = ‘DJ’ AND Note =

Medications Medications Medications Medications Although a patient record was found, no
medications were available.
Error Error Error No Approved Approved/ReasonCode = ‘DM’ AND Note = A

Medications processing error occurred. No medication history
was returned.
Valid RxHistoryRequest: N/A N/A N/A No Approved Approved /ReasonCode = ‘DJ’ AND Note =
Medications Patient Not Found.
Patient is not found within
any
of the data suppliers
(PBM/Payers or
Pharmacies).

3.3 ACKNOWLEDGEMENT MESSAGES

This section contains acknowledgment details, workflows, and scenarios.
3.3.1 STATUS
Status is used to indicate to the sender that the message was accepted for processing. A Status is always a synchronous response.
Provider vendors are required to send a Status 010 in response to an RxHistoryResponse indicating that the message processing is
complete and was successful.
Status 000 indicates the process is not complete. A subsequent RxHistoryResponse message should be expected.
3.3.2 STATUS BEST PRACTICE

DescriptionCode is an optional element that contains codes suitable for use on error messages only. DescriptionCode element should not
be used on a Status message.
3.3.3 ERROR
This message indicates that an error has occurred. An error can be generated when there is a communication problem or when an error
occurs during the processing of the message.

3.3.4 ACKNOWLEDGMENT MESSAGE TABLE

Message
Code Meaning(s) As Sender As Receiver
Type
Status 000 The transmission has been accepted for Surescripts sends a An RxHistoryResponse message is expected to follow a
processing, but has not yet reached its final synchronous Status Status 000. If it is not received, no assumption should be
status. There should be an 000 upon receiving the made as to whether the original message has been
RxHistoryResponse message forthcoming. RxHistoryRequest. received successfully or not.
Status 010 Confirms successful delivery and Synchronous response Subsequent acknowledgement message should not be
acceptance of a message to its final indicates the process is expected.
destination. complete.
The final acknowledgement message to
close the transaction workflow.
No further acknowledgement message
should follow.
Error 600, Can be generated when there is a Send to communicate After receiving an Error, do not expect subsequent
601, communication problem or when an error that the transaction acknowledgement messages.
602, occurs during the processing of the failed.
Do not respond to an Error message with an Error
700, message.
Do not send if a message.
900
Closes the transaction workflow. transaction workflow
Subsequent acknowledgement messages has already been
should not be expected. closed (Status Code
010).
3.3.5 ERROR CODES

For a full list of NCPDP Error codes (e.g. TransactionErrorCode) and their descriptions, see the online NCPDP External Code List
201707 or NCPDP XML schema.

3.3.6 ERROR TEXT TABLE

The error codes below are tied to codes from the NCPDP External Code List 2017071. When applicable, Surescripts will send the code
along with an error message. The table below details example error messages.
Note: The table below does not capture every error situation. Error descriptions are subject to change.
Code Error Description

900 Found {#} NCPDP 2017071 schema validation error{s}. {Description of the schema errors}
900 Sender ID Not In Directory.
900 Sender portal is inactive.
900 Sender portal not authorized to send RxHistoryRequest messages.
900 Sender organization is inactive.
900 Sender not authorized to send this type of message.
900 Portal config not found for sender.
900 No active medhistory portal config found for sender specified version.
900 Portal configuration error, please contact support.
900 The received message type is an invalid message type for this service.
900 The message format is not recognized as valid for this service.
900 RxHistoryRequest requires an Eligibility - Interchange Control Number (ISA13) in the RelatesToMessageID field.
900 Invalid recipient identifier used in the RxHistoryRequest.
900 Date of birth is required.
900 Full Patient LastName is required.

Code Error Description

900 Full patient MiddleName is required if initial is sent in the FirstName field.
900 Consent not given.
900 Requested StartDate cannot be in the future or more than one year in the past.
900 Requested StartDate cannot be after EndDate.
900 Facility NPI is required.
900 NPI in Facility is not a valid NPI.
900 NPI in Prescriber is not a valid NPI.
900 Either Prescriber or Facility must be included in the request.
900 Prescriber must be included in Medication History for Ambulatory RxHistoryRequest.
900 Authorization Failed. Sender account not authorized to send with this certificate.
900 Authentication Failed. No valid account matches sender certificate.
900 {#} url format error{s}. {Description of the errors}
900 Url id parameter value of {Id from Url} does not match message id value of {Id From Message Header} from message header.
900 Surescripts messaging version specified in the url {Version from Url} does not match version of the message {Version from Message}.
900 Medication History requests sent directly to PBMs are not supported at Surescripts.
900 Sender portal not authorized to send Medication History for Ambulatory RxHistoryRequest messages.
900 Sender portal not authorized to send Medication History for Reconciliation RxHistoryRequest messages.
602 Surescripts system error.
3.3.7 MESSAGE WORKFLOW SCENARIOS

The following workflows depict various scenarios in response to an RxHistoryRequest message.

Scenario 1 – Message errors at Surescripts
1a). Provider vendor system sends an RxHistoryRequest message to Surescripts.

1b). Provider vendor system receives an error response from Surescripts.
Scenario 2 – Surescripts has no patient record


2b). Provider vendor system receives a ‘Status 000’ response from Surescripts acknowledging receipt.
2c). Provider vendor system receives an asynchronous RxHistoryResponse message from Surescripts with
Response/Approved/ReasonCode = ‘DJ’ and Note = “Patient not found”.
2d). Provider vendor system sends a ‘Status 010’ response to Surescripts acknowledging receipt.
Scenario 3 – PBM/Payer Responding System returns error

3b). Provider vendor system receives a ‘Status 000’ response from Surescripts acknowledging receipt.
3c). PBM/payer system receives an RxHistoryRequest message from Surescripts.
3d). PBM/payer system sends an error to Surescripts or Surescripts is unable to connect to the PBM/payer system.

3e). Provider vendor system receives an asynchronous RxHistoryResponse message from Surescripts with
Response/Approved/ReasonCode = ‘DM’ and Note = "A processing error occurred. No medication history was returned."
Notes:
If some medications are returned but not all sources were accessible, provider vendor system will receive an asynchronous
aggregated RxHistoryResponse message from Surescripts with Response/Approved/Note = “Not all medication history sources were
accessible at this time.”
If PBM/payer system sends an error Code ‘900’ to Surescripts with a description = “Patient not found.”, then the provider vendor
system receives an asynchronous RxHistoryResponse message from Surescripts with Response/Approved/ReasonCode = ‘DM’ and
Note = "A processing error occurred. No medication history was returned."
3f). Provider vendor system sends a ‘Status 010’ response to Surescripts acknowledging receipt.
3.4 MESSAGE VALIDATION

Surescripts will ensure that customers are in compliance with the message specifications outlined in this Guide during Integration Testing
and will continue to enforce once in production.
At a minimum, Surescripts validations include:

l XML schema validation
l The sender identification and authentication
l The recipient identification
l Syntax of the message, including field lengths, data types, and code values
l Surescripts business rules
Note: Surescripts ACRs are not enforced as part of validations, but instead through the certification process.

Medication History EA Draft CG 3.0 Section 4: Message Definition
SECTION 4: MESSAGE DEFINITION
4.1 REQUIREMENT DESIGNATION

Element Attributes
Code Description
M Required/Mandatory - the element must be used per the specification (e.g., XML schema
validation).
B Required - the element must be used per the Surescripts business rule.
C Situational/Conditional – the element must be used if conditions are met. Some fields do not have
specific conditions. Data should be sent if available.
Where comments are “Not used by Surescripts for medication history”, information will be passed
on, but not used, by Surescripts for processing.
X Not used, will be rejected if sent.
Note: This Guide includes data elements only where Surescripts has specific requirements or
further explains the field usage. Refer to the schema for a complete list of fields.

4.2 MESSAGE HEADER
4.2.1 MESSAGE HEADER XML REQUIREMENTS

M/C ELEMENT COMMENT
M To This field contains the identification of the receiver. This field is used in
conjunction with To/@Qualifier, which qualifies which ID was used.
Medication History for Ambulatory

Requests
Request messages from provider vendors to Surescripts will contain
“S00000000000001”.
Request messages from Surescripts to the PBM/payer will contain the
PBM/payer Participant ID.
PBM/Payer Responses for Claim History
Response messages from PBM/payers will contain the Provider Vendor ID
assigned by Surescripts.
Medication History for Reconciliation

Requests
Request messages from provider vendors to Surescripts will contain
“S00000000000002”.
Request messages from Surescripts to the PBM/payer will contain the
PBM/payer Participant ID.
Response messages from PBM/payers will contain the Provider Vendor ID
assigned by Surescripts.
Medication History for Populations

Response messages from PBM/payers will contain “S00000000000003”.
M @Qualifier Values:
ZZZ = Mutually Defined

M/C ELEMENT COMMENT

M From This field is used in conjunction with From/@Qualifier, which qualifies which
ID was used.
Medication History for Ambulatory, Reconciliation, and Populations
Requests
Request messages from provider vendors will contain the Provider Vendor
ID assigned by Surescripts.
Request messages to the PBM/payer for Medication History for Populations
can contain S00000000000003.
Responses for Claim History
Response messages from PBM/payers to Surescripts will contain the
PBM/Payer ID.
Response messages from Surescripts to the provider vendor will contain
either S00000000000001 or S00000000000002.
M @Qualifier Value:
ZZZ = Mutually defined
M MessageID The sender should ensure the combination of the From and MessageID
elements is unique for at least 18 months. Surescripts recommends an
unformatted Globally Unique Identifier (GUID).
B RelatesToMessageID Required for Medication History for Ambulatory requests.

Contains the Interchange Control Number from the ISA13 in the Eligibility
Request (270).
M SentTime Date of the transmission. Please see UTC Time Format section.
C Security/Sender/ Medication History for Ambulatory

TertiaryIdentification
Requests
Request messages from Surescripts to the PBM/payer will contain
“S00000000000001”.
Medication History for Reconciliation

Requests
“S00000000000002”.
Medication History for Populations

Requests
“S00000000000003”.

M/C ELEMENT COMMENT

C TestMessage When sent, allowable values must match platform that message is being
sent to.
Values:
1 = Test (Required in staging environment.)
All other values = Live (Production)
It is recommended not to send this field when in production.
4.3 MEDICATION HISTORY REQUEST

Medication History request for a patient is sent to Surescripts.
4.3.1 RXHISTORYREQUEST XML REQUIREMENTS

M/C Field Name Details
BenefitsCoordination
Note: Surescripts requires the BenefitsCoordination in the RxHistoryRequest.
M Consent Patient Consent Indicator

Note: Values 'N', 'P', 'Z' and 'TPO' will be treated as no consent and a
900 synchronous error will be returned "Consent not given".
C PBMMemberID Surescripts will populate.
Facility
Note: Facility is required when the Prescriber element is not provided for Medication History for
Reconciliation RxHistoryRequests.
M Identification
B NPI Facility NPI is required if Facility element is included.

The NPI check digit will be validated using the LUHN formula. For
specific information see:
https://www.cms.gov/Regulations-and-Guidance/Administrative-
Simplification/NationalProvIdentStand/Downloads/NPIcheckdigit.pdf
Patient
X NonHumanPatient Surescripts does not support the NCPDP SCRIPT elements for
nonhuman patients.
M HumanPatient
M Name


C MiddleName Recommended to send to aid in patient matching.
C Suffix Recommended to send to aid in patient matching.
C Address Recommended to send to aid in patient matching.
C City Recommended to send to aid in patient matching.
C StateProvince Recommended to send to aid in patient matching.
C PostalCode Recommended to send to aid in patient matching.
Prescriber
Note: Prescriber element is required for all Medication History for Ambulatory RxHistoryRequests and for
Medication History for Reconciliation RxHistoryRequests where the Facility is not provided.
X Veterinarian Surescripts does not support the NCPDP SCRIPT elements for
veterinarian prescribers.
M NonVeterinarian
M Identification
M NPI The NPI check digit will be validated using the LUHN formula. For
specific information see:
https://www.cms.gov/Regulations-and-Guidance/Administrative-
Simplification/NationalProvIdentStand/Downloads/NPIcheckdigit.pdf
RequestedDates
M StartDate StartDate is the beginning date for the desired history (up to 1 year ago
from today’s date).
If the RxHistoryResponse indicates more medications are available
(Response/Approved/ReasonCode = ‘AQ’) and the requestor desires to
make a subsequent request for additional medications within the dates
of the original request, a new RxHistoryRequest will need to be sent with
the StartDate equal to the original StartDate.
M EndDate EndDate is the end date for the desired history (e.g., today’s date).
EndDate must be after the StartDate.
If the RxHistoryResponse indicates more medications are available
(Response/Approved/ReasonCode = ‘AQ’) and the requestor desires to
make a subsequent request for additional medications within the dates
of the original request, a new RxHistoryRequest will need to be sent with
the EndDate equal to the LastFillDate of the oldest medication returned
in the RxHistoryResponse.

4.4 MEDICATION HISTORY RESPONSE

This response is sent from Surescripts back to the prescriber vendor and includes the patient’s
medication history.
4.4.1 RXHISTORYRESPONSE XML REQUIREMENTS

Response
Note: Either Approved or Denied must be sent.
M Approved Either an Approved or Denied response must be sent.
C ReasonCode AQ (More History Available) is sent to indicate that another

RxHistoryRequest is needed to obtain additional available
medication history.
If the original requestor would like to receive the additional
medications within that given timeframe, the original
requestor will need to send a subsequent
RxHistoryRequest with the:
RequestedDates/StartDate = [StartDate of the original
request]
RequestedDates/EndDate = [FillDate of oldest medication
returned in RxHistoryResponse]
DJ - No Data Found. Sent to indicate that no medications
are returned in the RxHistoryResponse.
DM - Error. Sent to indicate that an error was encountered
in the processing of the message where additional
medications may be available.
C Note The Note field may be used for Approved responses.
M Denied Either an Approved or Denied response must be sent.
B DenialReason DenialReason field is used for Denied responses. A

“Denied” response must be accompanied by Free Text
since there is not a valid ReasonCode.
MedicationDispensed
Note: MedicationPrescribed and MedicationDispensedAdministered are not used for Surescripts
Medication History.


M DrugDescription Drug name.
The item or drug description field should include the
standardized drug name including strength and form from a
Surescripts approved drug compendia.
C DrugCoded
C ProductCode Drug identifier.
M Code When sending, the NDC shall be an 11 digit NDC in the 5-

4-2 format; no dashes and no suppression of leading
zeros. The drug description of the product must match the
description of the drug identifier (e.g. NDC, RxNorm).
Example: 00143314250
Note: When this is all 9s for the NDC and this is for fill
data, this means that the prescription is a compound.
M @Qualifier Values:
ND = NDC11 (Should be sent)
C Strength/StrengthForm
M Code See Codified Field Usage for Federal Medication

Terminologies (FMT) Codes for details.
C Strength/StrengthUnitOf
Measure
M Code See Codified Field Usage for Federal Medication

Terminologies (FMT) Codes for details.
M Quantity
M QuanityUnitOfMeasure/ See Codified Field Usage for Federal Medication

Code Terminologies (FMT) Codes for details.
C HistoryPrescriberOrderNumber If sent, this is the Prescriber Order Number (PON) from the
prescription.
C HistorySource This is the source and fill number information for the
medication listed.
M Source
C SourceDescription Name of medication history source. Participant Name.


M SourceQualifier Qualifies the Source Description.
P2 – Pharmacy
PY – Payer (PBM/payer should populate the
SourceQualifier = ‘PY’)
PC – Prescriber (Not used by Surescripts for medication
history).
C SourceReference Prescription Number associated to medication history

record.
If the submitter chooses to send this field and
SourceQualifier is “P2”, then it should be populated with
the pharmacy prescription number.
If the submitter chooses to send this field and
SourceQualifier is “PY”, then it should be populated with
prescription number from PBM/Payer system from claims
processing.
C FillNumber Defines the dispensing episode as an initial fill or an

authorized refill.
If this field is sent for fill data, it will contain the fill number
from the pharmacy.
If this field is sent for claim data, it will contain pharmacy’s
fill number from the PBM/payer system from claims
processing
Values:
00 = Initial fill
01 = First refill
02 = Second refill, etc.
Allowed values 00 thru 99

Medication History EA Draft CG 3.0 Section 5: Medication History XML Examples
SECTION 5: MEDICATION HISTORY XML

EXAMPLES
These examples are above and beyond those found in the NCPDP Examples. Please note that the
XML examples in this section are Medication History for Reconciliation examples.
Note: In the example(s) below the version is 20170714 which is a republication of version
2017071.
5.1 RXHISTORYREQUEST – PROVIDER VENDOR TO SURESCRIPTS

<?xml version="1.0" encoding="UTF-8"?>
<Message TransportVersion="20170714" DatatypesVersion="20170714" TransactionDomain="SCRIPT"
TransactionVersion="20170714" StructuresVersion="20170714"
ECLVersion="20170714"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="transport.xsd">
<Header>
<To Qualifier="ZZZ">S00000000000002</To>
<From Qualifier="ZZZ">T00000000000109</From>
<MessageID>43ae6504fdef481faa1641dc4700e669</MessageID>
<SentTime>2018-07-20T08:03:07.895Z</SentTime>
<SenderSoftware>
<SenderSoftwareDeveloper>SoftwareDev</SenderSoftwareDeveloper>
<SenderSoftwareProduct>443</SenderSoftwareProduct>
<SenderSoftwareVersionRelease>2.1</SenderSoftwareVersionRelease>
</SenderSoftware>
<TestMessage>1</TestMessage>
</Header>
<Body>
<RxHistoryRequest>
<BenefitsCoordination>
<Consent>Y</Consent>
</BenefitsCoordination>
<Patient>
<HumanPatient>
<Name>
<LastName>Doe</LastName>
<FirstName>Jane</FirstName>
<MiddleName>Ann</MiddleName>
<Suffix>Sr</Suffix>
</Name>
<Gender>F</Gender>
<DateOfBirth>
<Date>1983-02-22</Date>
</DateOfBirth>
<Address>
<AddressLine1>123 Main St</AddressLine1>
<City>Anytown</City>
<StateProvince>MN</StateProvince>

<PostalCode>543215151</PostalCode>
<CountryCode>US</CountryCode>
</Address>
<CommunicationNumbers>
<PrimaryTelephone>
<Number>9528553055</Number>
<Extension>1234</Extension>
<SupportsSMS>Y</SupportsSMS>
</PrimaryTelephone>
<ElectronicMail>myemail@aol.com</ElectronicMail>
</CommunicationNumbers>
</HumanPatient>
</Patient>
<Prescriber>
<NonVeterinarian>
<Identification>
<DEANumber>MJ2746581</DEANumber>
<NPI>1234567893</NPI>
</Identification>
<PracticeLocation>
<BusinessName>Test Clinic</BusinessName>
</PracticeLocation>
<Name>
<LastName>Johnson</LastName>
<FirstName>John</FirstName>
<MiddleName>Joe</MiddleName>
<Suffix>Jr</Suffix>
<Prefix>Dr</Prefix>
</Name>
<Address>
<AddressLine1>272 E Central St</AddressLine1>
<AddressLine2>Ste #1322</AddressLine2>
</Address>
<PrimaryTelephone>
</PrimaryTelephone>
<Fax>
<SupportsSMS>N</SupportsSMS>
</Fax>
</NonVeterinarian>
</Prescriber>
<RequestedDates>
<StartDate>
<Date>2017-08-13</Date>
</StartDate>
<EndDate>
<Date>2018-08-13</Date>
</EndDate>
</RequestedDates>
</RxHistoryRequest>
</Body>
</Message>

5.2 RXHISTORYREQUEST – SURESCRIPTS TO PBM/PAYER

TransactionVersion="20170714" StructuresVersion="20170714"
ECLVersion="20170714"xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="transport.xsd">
<Header>
<To Qualifier="ZZZ">D00000000009945</To>
<From Qualifier="ZZZ">T00000000000109</From>
<MessageID>db3f628595714eddb88592d028ca91aa</MessageID>
<RelatesToMessageID>43ae6504fdef481faa1641dc4700e669</RelatesToMessageID>
<Security>
<Sender>
<TertiaryIdentification>S00000000000002</TertiaryIdentification>
</Sender>
<Receiver/>
</Security>
<SenderSoftware>
<SenderSoftwareDeveloper>PBMTest</SenderSoftwareDeveloper>
<SenderSoftwareProduct>PBMMeds</SenderSoftwareProduct>
</SenderSoftware>
</Header>
<Body>
<RxHistoryRequest>
<PBMMemberID>ZZQ-88-10011-261</PBMMemberID>
<Patient>
<HumanPatient>
<Name>
<Suffix>Sr</Suffix>
</Name>
<Gender>F</Gender>
<DateOfBirth>
<Date>1983-02-22</Date>
</DateOfBirth>
<Address>
</Address>
<PrimaryTelephone>
</PrimaryTelephone>
<ElectronicMail>myemail@aol.com</ElectronicMail>
</HumanPatient>
</Patient>
<Prescriber>

<NonVeterinarian>
<Identification>
<NPI>1234567893</NPI>
</Identification>
<PracticeLocation>
</PracticeLocation>
<Name>
<Suffix>Jr</Suffix>
<Prefix>Dr</Prefix>
</Name>
<Address>
</Address>
<PrimaryTelephone>
</PrimaryTelephone>
<Fax>
</Fax>
</NonVeterinarian>
</Prescriber>
<RequestedDates>
<StartDate>
<Date>2017-08-13</Date>
</StartDate>
<EndDate>
<Date>2018-08-13</Date>
</EndDate>
</RequestedDates>
</RxHistoryRequest>
</Body>
</Message>
5.3 RXHISTORYRESPONSE – PBM/PAYER TO SURESCRIPTS

TransactionVersion="20170714" StructuresVersion="20170714" ECLVersion="20170714"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="transport.xsd">
<Header>
<To Qualifier="ZZZ">T00000000000109</To>
<From Qualifier="ZZZ">D00000000009945</From>
<MessageID>a68b98181cd34f95a2776f16976a980e</MessageID>
<RelatesToMessageID>db3f628595714eddb88592d028ca91aa</RelatesToMessageID>
<Security>
<Sender>

<TertiaryIdentification>S00000000000002</TertiaryIdentification>
</Sender>
<Receiver/>
</Security>
<SenderSoftware>
<SenderSoftwareDeveloper>SoftwareDev</SenderSoftwareDeveloper>
<SenderSoftwareProduct>443</SenderSoftwareProduct>
</SenderSoftware>
</Header>
<Body>
<RxHistoryResponse>
<Response>
<Approved/>
</Response>
<Patient>
<HumanPatient>
<Name>
<Suffix>Sr</Suffix>
</Name>
<Gender>F</Gender>
<DateOfBirth>
<Date>1983-02-22</Date>
</DateOfBirth>
<Address>
</Address>
</HumanPatient>
</Patient>
<Prescriber>
<NonVeterinarian>
<Identification>
<NPI>1234567893</NPI>
</Identification>
<PracticeLocation>
</PracticeLocation>
<Name>
<Suffix>Jr</Suffix>
<Prefix>Dr</Prefix>
</Name>
<Address>
</Address>
<PrimaryTelephone>

</PrimaryTelephone>
<Fax>
</Fax>
</NonVeterinarian>
</Prescriber>
<MedicationDispensed>
<DrugDescription>Cefdinir 125 MG/5 ML suspension</DrugDescription>
<DrugCoded>
<ProductCode>
<Code>65862021801</Code>
<Qualifier>ND</Qualifier>
</ProductCode>
<Strength>
<StrengthValue>125</StrengthValue>
<StrengthForm>
<Code>C68981</Code>
</StrengthForm>
<StrengthUnitOfMeasure>
<Code>C91131</Code>
</StrengthUnitOfMeasure>
</Strength>
<DrugDBCode>
<Code>309054</Code>
<Qualifier>SCD</Qualifier>
</DrugDBCode>
</DrugCoded>
<Quantity>
<Value>200</Value>
<CodeListQualifier>87</CodeListQualifier>
<QuantityUnitOfMeasure>
<Code>C28254</Code>
</QuantityUnitOfMeasure>
</Quantity>
<DaysSupply>10</DaysSupply>
<LastFillDate>
<Date>2018-06-16</Date>
</LastFillDate>
<Substitutions>0</Substitutions>
<Diagnosis>
<ClinicalInformationQualifier>1</ClinicalInformationQualifier>
<Primary>
<Code>J0100</Code>
<Qualifier>ABF</Qualifier>
<Description>Acute maxillary sinusitis, unspecified</Description>
</Primary>
</Diagnosis>
<HistorySource>
<Source>
<SourceQualifier>PY</SourceQualifier>
</Source>
</HistorySource>
</MedicationDispensed>
<DrugDescription>Amoxicillin 125 MG/5 ML suspension</DrugDescription>
<DrugCoded>
<ProductCode>
<Code>65862070655</Code>
</ProductCode>

<Strength>
<StrengthForm>
<Code>C68981</Code>
</StrengthForm>
<Code>C91131</Code>
</Strength>
<DrugDBCode>
<Code>313797</Code>
</DrugDBCode>
</DrugCoded>
<Quantity>
<Value>100</Value>
<Code>C28254</Code>
</Quantity>
<LastFillDate>
<Date>2018-06-15</Date>
</LastFillDate>
<Diagnosis>
<Primary>
<Code>H6504</Code>
<Description>Acute serous otitis media, recurrent, right ear</Description>
</Primary>
</Diagnosis>
<HistorySource>
<Source>
</Source>
</HistorySource>
<RequestedDates>
<StartDate>
<Date>2017-08-13</Date>
</StartDate>
<EndDate>
<Date>2018-08-13</Date>
</EndDate>
</RequestedDates>
</RxHistoryResponse>
</Body>
</Message>
5.4 RXHISTORYRESPONSE – SURESCRIPTS TO PROVIDER VENDOR

TransactionVersion="20170714" StructuresVersion="20170714" ECLVersion="20170714"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation="transport.xsd">
<Header>
<To Qualifier="ZZZ">T00000000000109</To>
<From Qualifier="ZZZ">S00000000000002</From>
<MessageID>fc7c398293a2445582944d62002a15e0</MessageID>
<RelatesToMessageID>43ae6504fdef481faa1641dc4700e669</RelatesToMessageID>

<SenderSoftware>
<SenderSoftwareDeveloper>Surescripts</SenderSoftwareDeveloper>
<SenderSoftwareProduct>Medication History</SenderSoftwareProduct>
<SenderSoftwareVersionRelease>1.0.0.127</SenderSoftwareVersionRelease>
</SenderSoftware>
</Header>
<Body>
<RxHistoryResponse>
<Response>
<Approved/>
</Response>
<Patient>
<HumanPatient>
<Name>
<Suffix>Sr</Suffix>
</Name>
<Gender>F</Gender>
<DateOfBirth>
<Date>1983-02-22</Date>
</DateOfBirth>
<Address>
</Address>
</HumanPatient>
</Patient>
<Prescriber>
<NonVeterinarian>
<Identification>
<NPI>1234567893</NPI>
</Identification>
<PracticeLocation>
</PracticeLocation>
<Name>
<Suffix>Jr</Suffix>
<Prefix>Dr</Prefix>
</Name>
<Address>
</Address>
<PrimaryTelephone>

</PrimaryTelephone>
<Fax>
</Fax>
</NonVeterinarian>
</Prescriber>
<DrugDescription>Cefdinir 125 MG/5 ML suspension</DrugDescription>
<DrugCoded>
<ProductCode>
<Code>65862021801</Code>
</ProductCode>
<Strength>
<StrengthForm>
<Code>C68981</Code>
</StrengthForm>
<Code>C91131</Code>
</Strength>
<DrugDBCode>
<Code>309054</Code>
</DrugDBCode>
</DrugCoded>
<Quantity>
<Value>200</Value>
<Code>C28254</Code>
</Quantity>
<LastFillDate>
<Date>2018-06-16</Date>
</LastFillDate>
<Diagnosis>
<Primary>
<Code>J0100</Code>
<Description>Acute maxillary sinusitis, unspecified</Description>
</Primary>
</Diagnosis>
<HistorySource>
<Source>
</Source>
</HistorySource>
<DrugDescription>Amoxicillin 125 MG/5 ML suspension</DrugDescription>
<DrugCoded>
<ProductCode>
<Code>65862070655</Code>
</ProductCode>
<Strength>
<StrengthForm>

<Code>C68981</Code>
</StrengthForm>
<Code>C91131</Code>
</Strength>
<DrugDBCode>
<Code>313797</Code>
</DrugDBCode>
</DrugCoded>
<Quantity>
<Value>100</Value>
<Code>C28254</Code>
</Quantity>
<LastFillDate>
<Date>2018-06-15</Date>
</LastFillDate>
<Diagnosis>
<Primary>
<Code>H6504</Code>
<Description>Acute serous otitis media, recurrent, right ear</Description>
</Primary>
</Diagnosis>
<HistorySource>
<Source>
</Source>
</HistorySource>
<RequestedDates>
<StartDate>
<Date>2017-08-13</Date>
</StartDate>
<EndDate>
<Date>2018-08-13</Date>
</EndDate>
</RequestedDates>
</RxHistoryResponse>
</Body>
</Message>
5.4.1 RXHISTORYRESPONSE NOTE DESCRIPTION

The events shown in the table below will not cause an Error to be sent to the customer, but instead
will return a note in the RxHistoryResponse/Response field.
Note Sent in
Event Comments
RxHistoryResponse
Surescripts cannot find the patient Patient Not Found.
identified.

Note Sent in
Event Comments
RxHistoryResponse
Surescripts cannot obtain results A processing error An error occurred while processing the
from any source due to any occurred. No report. No medication history was returned.
Surescripts or Source error occurring medication history
Examples of errors include, but are not
while attempting to get results. was returned.
limited to:
- Error response
- Timeout from a data source
Surescripts gets results from one, Not all medication Not all available results may be present in
but not all information sources. history sources were this report. Not all information sources were
accessible at this accessible at this time.
time.
Patient was found, but no Although a patient A patient record was found, but no
medications were found for the date record was found, no medication(s) were found or the medication
range specified. medications were (s) that could be found are for dates outside
available.” the range provided by customer.
5.4.2 CODIFIED FIELD USAGE FOR FEDERAL MEDICATION TERMINOLOGIES (FMT)

CODES
Note: For a list of FMT codes, go to: http://evs.nci.nih.gov/ftp1/NCPDP/About.html. Use the

valid value from the appropriate row of the downloaded data. This list should be updated on a
monthly basis.
The table below includes some example fields.
Codified Field/Field Code Comment

StrengthForm/Code Use the NCPDP StrengthForm Terminology rows from the downloaded
data. This list should be updated on a monthly basis.
StrengthUnitOfMeasure/Code Use the NCPDP StrengthUnitOfMeasure Terminology rows from the

downloaded data.
QuanityUnitOfMeasure/Code Use the NCPDP QuantityUnitOfMeasure Terminology rows from the

downloaded data.
DoseUnitOfMeasure/Code Use the NCPDP DoseUnitOfMeasure Terminology rows from the

downloaded data.
DEASchedule Use the NCPDP DEASchedule Terminology rows from the downloaded
data.

Medication History EA Draft CG 3.0 Section 6: Application Certification Requirements
SECTION 6: APPLICATION CERTIFICATION

REQUIREMENTS
Numeric Representation
S.100: The decimal point is represented by a period and shall be used as follows:
l Only when there are significant digits to the right of the decimal
l When there is a digit before and after the decimal point
l Not with whole numbers
l Counts toward the length total of a data element
l User shall be able to enter up to three digits to the right of the decimal place without the system
rounding or truncating
For example, consider the following possible values:
Correct: 2.515 251.5 25.15 2515 0.2515 2.5
Incorrect: .2515 2515. 3.00
Message Format
S.101: Customer must create and send syntactically valid messages and shall be able to receive
syntactically valid maximum and minimum populated messages. Optional data elements (and values
therein) shall not cause message failure.
General Medication History Requirements

M.100: The application shall display a disclaimer regarding use of medication history retrieved via
Surescripts.
Sample Disclaimer: Certain information may not be available or accurate in this report, including items that
the patient asked not be disclosed due to patient privacy concerns, over the-counter medications, low cost
prescriptions, prescriptions paid for by the patient or nonparticipating sources, or errors in insurance claims
information. There may also be a potential for false positive match if the patient’s demographics sent in the
message have information similar to another patient in Master patient Index. The provider should verify the
patient’s demographics and medication history with the patient.
M.101: When a data element from the medication history response is displayed, the application shall have
the ability to display all data received for that data element.
M.103: Medication History - Ambulatory may only be pulled in conjunction with a patient interaction in which
a prescription could be written. In addition, prescribers must be activated for electronic prescription routing
messages on the Surescripts network and utilize a certified software solution in order to participate in
Medication History- Ambulatory.

Medication History EA Draft CG 3.0 Section 6: Application Certification Requirements
Definition of Patient Interaction:

“Patient interaction with the prescriber with the probability that a prescription will take place in the course of
that interaction. The interaction can take the form of a physical visit, phone call, telemedicine, or email from
the patient to the prescriber/prescriber to the patient. The medication history request occurs at the time of a
patient interaction.”
Examples of what is not considered a patient interaction for the purposes of pulling a medication history:
1. Activities associated with health care operations, including but not limited to:
a. Calls to schedule or check in appointments beyond 24hrs in advance
b. Opening a chart for:
i. Billing questions
ii. Reference purposes
iii. Post visit transcription
iv. Updating patient information
2. Clinical information activities not associated with a prescribing medication reconciliation or electronic
prior authorization process, including but not limited to:
a. Lab test results or follow up not affiliated with prescribing a medication
b. Post visit reviews
c. Coordination of care
M.104: Customers shall ensure that:
Medication history requests are sent only once within 3 calendar days/72 hours (unless an error is
encountered in the medication history retrieval process).
Definition: A calendar day runs from 12:00 a.m. to 11:59 p.m. Central Time, regardless of the location of the
patient encounter.
M.105: The Medication History for Ambulatory request for a patient shall be tied to the most recent eligibility
request for that patient. This is accomplished by using the ISA control number (ISA13) from the 270
Eligibility request in the RelatesToMessageID of the RxHistoryRequest.

Medication History EA Draft CG 3.0 Appendix A: Translation
APPENDIX A: TRANSLATION
For details on translation between different versions of the Surescripts implementation of the
NCPDP SCRIPT standard, see Medication History 3.0 Translation Matrix.

Medication History EA Draft CG 3.0 Appendix B: Document Change Log
APPENDIX B: DOCUMENT CHANGE LOG

The table below tracks significant changes made to the document since it was last published.
Change Log
Sec. # Sec. Title Change Description Reason

N/A - First release


Medication History Early Adopter Draft Companion Guide

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Medication History Early Adopter Draft Companion Guide

Uploaded by

Copyright:

Available Formats

Medication History Early Adopter Draft Companion

2800 CRYSTAL DRIVE

Copyright© 2018 by Surescripts, LLC.

All rights reserved. Proprietary and Confidential.

FOR SECTIONS OF THIS CUSTOMER GUIDE

P UBLISHED 10/01/2018 COPYRIGHT © 2018 BY S URESCRIPTS, LLC. P AGE 3

4.2 Message Header 24

P UBLISHED 10/01/2018 COPYRIGHT © 2018 BY S URESCRIPTS, LLC. P AGE 4

SECTION 1: PRODUCT OVERVIEW

1.1 ABOUT MEDICATION HISTORY

1.2 ABOUT THIS GUIDE

P UBLISHED 10/01/2018 COPYRIGHT © 2018 BY S URESCRIPTS, LLC. P AGE 5

1.3 EXAMPLES DISCLAIMER

1.4 GUIDE DISCLAIMER

1.5 DOCUMENT REFERENCES

Surescripts Provided Materials

Medication History 3.0 Translation Matrix

Surescripts Eligibility and Formulary: Eligibility Companion Guide

External materials to be obtained by the customer (available at www.NCPDP.org)

NCPDP SCRIPT Implementation Recommendations Version 1.45

NCPDP External Code List 201707 (NCPDP online tool)

P UBLISHED 10/01/2018 COPYRIGHT © 2018 BY S URESCRIPTS, LLC. P AGE 6

NCPDP is an American National Standards Institute (ANSI) accredited Standard Development

P UBLISHED 10/01/2018 COPYRIGHT © 2018 BY S URESCRIPTS, LLC. P AGE 7

SECTION 2: PRODUCT INTEGRATION &

2.1 INTEGRATION PROCESS

For requirements, consider the following:

P UBLISHED 10/01/2018 COPYRIGHT © 2018 BY S URESCRIPTS, LLC. P AGE 8

2.2 Terminology Usage

Term Term Usage

M.### Designates a Surescripts Medication History ACR.

S.### Designates an ACR that is shared with other Surescripts products.

2.3 TRANSITION TO PRODUCTION

2.4 COMMUNICATION RULES

2.5 SYNCHRONOUS PROCESSING

P UBLISHED 10/01/2018 COPYRIGHT © 2018 BY S URESCRIPTS, LLC. P AGE 9

2.6 UTC TIME FORMAT

2.7 CHARACTER SET

P UBLISHED 10/01/2018 COPYRIGHT © 2018 BY S URESCRIPTS, LLC. P AGE 10

P UBLISHED 10/01/2018 COPYRIGHT © 2018 BY S URESCRIPTS, LLC. P AGE 11

SECTION 3: MESSAGES OVERVIEW

3.1 MESSAGE DESCRIPTIONS

P UBLISHED COPYRIGHT © 2018 BY S URESCRIPTS, LLC. P AGE 12

3.2 MEDICATION HISTORY REQUEST/RESPONSE MESSAGE FLOW

P UBLISHED 10/01/2018 COPYRIGHT © 2018 BY S URESCRIPTS, LLC. P AGE 13

2. Provider vendor system sends an RxHistoryRequest message to Surescripts.

4. PBM/payer system receives an RxHistoryRequest message from Surescripts.

5. PBM/payer system sends a synchronous RxHistoryResponse message to Surescripts.

P UBLISHED 10/01/2018 COPYRIGHT © 2018 BY S URESCRIPTS, LLC. P AGE 14

3.2.1 EXAMPLE RESPONSE SCENARIOS FOR MULTIPLE SOURCES OF DATA

Valid RxHistoryRequest: Medications Medications No All Approved

No No Error No Approved Approved/ReasonCode = ‘DM’ AND Note = A

No No No No Approved Approved/ReasonCode = ‘DJ’ AND Note =

Error Error Error No Approved Approved/ReasonCode = ‘DM’ AND Note = A

P UBLISHED 10/01/2018 COPYRIGHT © 2018 BY S URESCRIPTS, LLC. P AGE 15

3.3 ACKNOWLEDGEMENT MESSAGES

3.3.2 STATUS BEST PRACTICE

P UBLISHED 10/01/2018 COPYRIGHT © 2018 BY S URESCRIPTS, LLC. P AGE 16

3.3.4 ACKNOWLEDGMENT MESSAGE TABLE

3.3.5 ERROR CODES

P UBLISHED 10/01/2018 COPYRIGHT © 2018 BY S URESCRIPTS, LLC. P AGE 17

3.3.6 ERROR TEXT TABLE

Code Error Description