Prescription Benefit IG 2016-12-12

Prescription Benefit Implementation Guide
December 12, 2016

PRESCRIPTION BENEFIT IMPLEMENTATION GUIDE
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© 2016 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 IMPLEMENTATION GUIDE

PERTAINING TO X12 STANDARDS:
Materials Reproduced with the Consent of X12.
FOR SECTIONS OF THIS CUSTOMER IMPLEMENTATION 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.
Prescription Benefit IG Table of Contents
TABLE OF CONTENTS
Section 1: Overview 11
1.1 About Surescripts 11
1.2 About This Guide 11
1.3 Document References 12
Section 2: Integration & Production 13
2.1 Integration Process 13
2.2 Terminology Usage 13
2.3 Transition to Production 14
2.4 Connectivity 14
2.5 Timeouts 14
2.5.1 Data Load Connectivity 14
2.5.1.1 Secure FTP 14
2.6 Security 15
2.7 Compliance 15
Section 3: Messages Overview 16
3.1 Prescription Benefit & Medication History Process Flow 16
3.2 Message Descriptions 16
3.3 General Interface Description 18
3.3.1 Dynamic Delimiters 18
3.3.2 Delimiter Examples 19
3.3.3 Representation 20
3.3.3.1 Numeric Representation 20
3.3.3.2 Character Set 21
3.3.3.3 Requirement Designation 21
3.4 Message Validation 22
3.5 Failure Mode/Response Approach 23
3.5.1 Error Processing for 270 and 271 23
Section 4: Eligibility 24
4.1 Introduction 24
4.2 Relationship to X12N 270/271 Standard 24
P UBLISHED 12/12/2016 COPYRIGHT © 2016 BY S URESCRIPTS, LLC. P AGE 3

A LL RIGHTS RESERVED . P ROPRIETARY AND CONFIDENTIAL
4.3 Eligibility Transaction Flow 25

4.4 Search Options 25
4.4.1 Insufficient Information 26
4.4.2 Multiple Matches 26
4.5 Patient Match Verification 26
4.6 270 Eligibility, Coverage, or Benefit Inquiry 28
4.7 271 Eligibility, Coverage, or Benefit Information 66
4.8 TA1 Interchange Acknowledgement 136
4.9 999 Implementation Acknowledgement for Health Care Insurance 144
4.10 270 and 271 Transaction Examples 165
Section 5: Eligibility Message Processing Summary 174
5.1 Surescripts Receives the 270 From the Requesting Party (Provider Vendor) 175
5.2 Surescripts Processes the 270 175
5.3 Surescripts Attempts to Connect with Source (PBM/payer) 178
5.4 PBM/payer Evaluates the Message 178
5.5 PBM/payer Processes the 270 180
5.6 PBM/payer Sends 271 Back to Surescripts 184
5.7 Summary of Errors is Sent to Provider Vendor 185
5.8 Summary of Translated Errors 186
Section 6: ID Load and Response Files 187
6.1 Introduction 187
6.2 ID Load Process Flow 187
6.3 Format to be Used 188
6.4 Member Directory Maintenance Flat File from PBM/payer 188
6.5 Member Directory Response Flat File to PBM/payer 191
6.6 Member Directory Maintenance Delimited File from PBM/payer 193
6.7 Member Directory Response Delimited File to PBM/payer 197
6.8 Member Directory Response Summary Delimited File to PBM/payer 199
6.9 Member Directory Codes 202
Section 7: Formulary and Benefit Data Load 204
7.1 Introduction 204
7.2 Formulary and Benefit Summary Information Model 205
7.3 Formulary and Benefit Data Overview 206
7.3.1 Formulary Status 206
7.3.2 Payer-Specified Alternatives 207

7.3.3 Coverage Information 207

7.3.4 Copay Information 208
7.3.5 Roll Up 208
7.4 Drug Identifiers 209
7.4.1 Representative NDC 209
7.4.2 RxNorm 209
7.5 High-Level Processing Examples (For Provider Vendors) 209
7.5.1 Flow One: Presenting Formulary & Coverage Information 209
7.5.2 Flow Two: Presenting Medication Copay 210
7.5.3 Flow Three: Presenting Formulary Alternatives 211
7.6 Formulary and Benefit Data Load Roles 211
7.7 Formulary and Benefit Data Load Process (For PBM/payers) 212
7.8 Formulary and Benefit Data Integration and Presentation to Prescribers (For Provider
Vendors) 213
7.9 Formulary and Benefit Publishing (For PBM/payers) 214
7.9.1 File Processing Options 214
7.9.2 Environment Setup 215
7.9.3 Formulary and Benefit File Naming and Structure 215
7.9.4 Formulary Distribution List Creation 217
7.10 Formulary Retrieval (For Provider Vendors) 218
7.10.1 WebDAV 218
7.10.2 Formulary and Benefit File Distribution 220
7.10.3 Formulary and Benefit File Processing 221
7.10.4 Retrieval Related Errors 221
7.11 General Structural Overview 222
7.11.1 File Level from the Sender to the Receiver 222
7.12 Formulary and Benefit Data Load Specification 223
7.12.1 File/Header Trailer Definition 223
7.12.2 Formulary and Benefit File Header 223
7.12.3 Formulary and Benefit File Trailer 224
7.13 Formulary Status List 224
7.13.1 Formulary Status Header 224
7.13.2 Formulary Status Detail 226
7.13.3 Formulary Status Trailer 229
7.14 Formulary Alternatives list 229

7.14.1 Formulary Alternatives Header 229

7.14.2 Formulary Alternatives Detail 230
7.14.3 Formulary Alternatives Trailer 233
7.15 Benefit Coverage List 234
7.15.1 Coverage Information Header 234
7.15.2 Coverage Information Detail – Coverage Text Message (TM) 234
7.15.3 Coverage Information Detail – Product Coverage Exclusion (DE), Prior Authorization
(PA), Step Therapy (ST) 236
7.15.4 Coverage Information Detail – Step Medications (SM) 238
7.15.5 Coverage Information Detail – Quantity Limits (QL) 241
7.15.6 Coverage Information Detail – Age Limits (AL) 243
7.15.7 Coverage Information Detail – Gender Limits (GL) 245
7.15.8 Coverage Information Detail – Resource Link – Drug Specific (RD) 247
7.15.9 Coverage Information Trailer 248
7.16 Benefit Copay List 249
7.16.1 Copay Header 249
7.16.2 Copay Information Detail – Summary Level (SL) 249
7.16.3 Copay Information Detail – Drug Specific (DS) 251
7.16.4 Copay Trailer 255
7.17 Formulary and Benefit File Validation (For PBM/payers) 255
7.17.1 Formulary and Benefit File Header and Trailer Validation 255
7.17.2 Formulary and Benefit Response File 255
7.17.3 Formulary and Benefit Response File Header 256
7.17.4 Reject Code Summary 258
7.18 Surescripts Translation From Version 1.0 to 3.0 and 3.0 to 1.0 260
7.19 NCPDP Changes from Version 1.0 to 3.0 264
7.20 Surescripts Changes from Version 1.0 to 3.0 266
7.21 Usage Examples 267
7.21.1 Formulary Status – Drug Listed in Payer’s Formulary 267
7.21.2 Formulary Status – Drug Not Listed by Payer 269
7.21.3 Formulary Status – Product Coverage Exclusion Applies 271
7.21.4 Formulary Status – Using Representative NDC 273
7.21.5 Formulary Alternative Lookup Using Payer Specified 275
7.21.6 Coverage – Quantity Limits and Gender Limits 277
7.21.7 Copay – Summary Level and Drug Specific 279

7.21.8 Copay – Combination Terms 282

7.21.9 Copay – Patient Out-of-Pocket Rules 284
7.21.10 Copay – Patient Out-of-Pocket / Medicare Example 287
7.21.11 Error Scenario – Formulary Status List (For PBM/payers) 291
7.21.12 Error Scenario – Age Limits 294
7.21.13 Error Scenario – Age Limits 296
Appendix A: Variances from Formulary 3.0 300
Appendix B: Secure File Transfer 301
Appendix C: Dynamic Delimiters 302

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

Throughout Removed Connect:Direct information as SFTP is Clarification
the method to be used.
Throughout Removed 030 – Audit or compare Change to

Requirements
1.3 Documentation Updated the NCPDP External Code List version Clarification
References from December 2010 to July 2016.
2.5 Timeouts Re-wrote section for clarification purposes and to Clarification

reflect the latest timeouts information.
2.8 Moving from Older Deleted section as it was no longer applicable. Clarification
Versions
3.3.1 Dynamic Delimiters Updates ISA segment example to reflect the Correction to
accurate number of characters and to be consistent Examples
with examples later in the guide.
3.5.2 Error Processing for Re-wrote section for clarification purposes. Clarification
270 and 271
4.5 Patient Match Updated the section for clarity and to reflect fields Change to
Verification that are now used for patient matching. Requirements
4.6 270 Eligibility, ISA08 – Added in Surescripts IDs. Clarification

Coverage, or Benefit
Inquiry
4.7 271 Eligibility, REF01 – Added HJ Identification Card Number Clarification

Coverage, or Benefit under Reference Identification Qualifier.
Information
REF (loop 2110C1) – Added Syntax Note to clarify Clarification

what Group Number refers to.
REF (loop 2110C1) – Corrected copy/paste error by Correction

adding back in the REF01 description and data
element number for the Reference Identification.
This was not a change to the process.
5.2 Surescripts Event Id 2.4 – Changed Subscriber Segment Loop Correction

Processes the 270 ID 2100C to Subscriber Segment Loop ID 2100A
7.3 Formulary and Updated note to remove information that was not Clarification
Benefit Data necessary for the process for clarification purposes.
Overview

7.8 Formulary and Clarified wording for step 1. Clarification
Benefit Data
Integration and
Presentation to
Prescribers (for
Provider Vendors)
7.9 Formulary and Update wording for the update and full replace Change to
Benefit Publishing processes to reflect the new process. Requirements
(for PBM/Payers)
7.9.3 Formulary and Updated the Directory Structure example to reflect Clarification
Benefit File Naming the file format.
and Structure
7.12 Formulary and Updated the wording from: “Where there are optional Clarification
Benefit Data Load fields at the end of the record, trailing delimiters are
Specification not required to be sent” to “Where there are optional
fields at the end of the record, it is recommended to
not send trailing delimiters”.
7.13 Formulary Status List Added detail to the ID(s) field to clarify where this Clarification
information is returned in the 271.
7.14 Formulary Added detail to the ID(s) field to clarify where this Clarification
Alternatives List information is returned in the 271.
7.15 Benefit Coverage List Added detail to the ID(s) field to clarify where this Clarification
7.16 Benefit Copay List Added detail to the ID(s) field to clarify where this Clarification
Updated notes for minimum and maximum copay to Change to

state that minimum and maximum should only be Requirements
sent if percent copay is populated.
7.17.1 Formulary and Remove Full Replace and Update Validation Clarification
Benefit File Header information as this is captured elsewhere in the
and Trailer Validation guide.
7.17.6 Reject Code Update section to detail the error and reject process. Change to
Summary Requirements
Added to detailed error message for code 1006: Field Clarification

[field name] is required when [field name 2] is
populated, or [field name 3] is empty
7.21 Usage Examples Remove list of example scenarios as this Clarification

information is captured in detail throughout the
section.

Added a step for locating the medication in the Clarification
examples.
Appendix Secure File Transfer Added the following note: “Compression should be Clarification
B used when possible while sending files to
Surescripts. The preferred file type is .gzip, but other
supported file types are .zip and .bzip.”

Prescription Benefit IG Section 1: Overview
SECTION 1: OVERVIEW
1.1 ABOUT SURESCRIPTS

Surescripts® operates a national clinical network that connects pharmacies, payers, pharmacy
benefit managers, physicians, hospitals, integrated delivery networks, health information
exchanges and health technology firms to enable the efficient and secure exchange of health
information. Guided by the principles of neutrality, transparency, physician and patient choice, open
standards, collaboration and privacy, Surescripts provides information for routine, recurring and
emergency care. Together with our network customers, Surescripts is committed to saving lives,
improving efficiency and reducing the cost of health care for all. For more information, go to
www.surescripts.com.
1.2 ABOUT THIS GUIDE

This Surescripts Prescription Benefit Implementation Guide was created to assist Pharmacy
Benefit Managers (PBMs)/Payers and Prescriber systems in developing and transferring
messages needed to provide PBM/payer member data (eligibility information, pharmacy benefit
coverage, and group-specific formulary information) to physicians in an ambulatory setting.
Note: The terms PBM/payer or processor, who acts on behalf of the PBM/payer, are referred
to as PBM/payer throughout this guide.
Note: The terms message and transaction are used interchangeably throughout this guide. The
term transaction will be used when referring to the X12 guide.
The audience for this document includes any customer responsible for developing a system
interface for these electronic prescribing messages. This guide describes the Surescripts
Prescription Benefit messages and provides other information needed for their implementation.

Prescription Benefit IG Section 1: Overview
1.3 DOCUMENT REFERENCES

The following documents were referenced in creating this Implementation Guide:
Document Title
ASC X12N/005010X279A1 Health Care Eligibility Benefit Inquiry and Response (270/271) – Referred to as the”
X12 Guide” in the rest of this guide.
ASC X12/N/005010X231A1 Implementation Acknowledgement for Health Care Insurance (999)
NCPDP’s Formulary And Benefit Standard Implementation Guide (Version 3, Release 0)
NCPDP’s Formulary and Benefit Implementation Recommendations Document
NCPDP’s External Code List (July 2016)
Surescripts Prescription Benefit Application Certification Requirements
Surescripts Connectivity and Authentication Implementation Guide
The Guide utilizes the ASC X12N/005010X279A1 and X12N/005010X231A1 implementation

guides as a baseline. In conjunction with this Surescripts Implementation Guide, customers must
have a copy of these documents readily available for use with the messages. Documentation can
be obtained through X12 at http://store.x12.org.
The Guide utilizes the NCPDP (National Council for Prescription Drug Programs) Formulary and
Benefit Standard Implementation Guide (Version 3, Release 0) as a baseline. In conjunction with
this Surescripts Implementation Guide, customers should have a copy of these documents readily
available for use with the messages. 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.
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
Some copyrighted materials in this guide are reproduced with the consent of the National Council
for Prescription Drug Programs, Inc.

Prescription Benefit IG Section 2: Integration & Production
SECTION 2: INTEGRATION & PRODUCTION
2.1 INTEGRATION PROCESS

The customer receives network guides/requirements documentation, product education and their
account is set up to access the Surescripts staging environment.
Note: The time frame of the project can vary depending on your resource allocation for the
project.
The integration process includes testing to ensure that the customer meets all Surescripts'
requirements. Surescripts provides a detailed plan outlining the necessary milestones for
integration and moving into production. Customers will be required to pass certification prior to
transitioning to production.
Certification focuses on message format, and when appropriate, application workflow and display
in accordance with Surescripts' implementation guides and the associated Application Certification
Requirements (ACR). By holding all customers accountable for meeting the ACRs, our customers
can send and receive the highest quality messages as e-prescribing and clinical messaging
continue to progress overall as an industry.
In addition, Surescripts Integration focuses on patient safety, efficiency of the electronic prescribing
process and ease of use by end-users.
2.2 TERMINOLOGY USAGE

Requirements that are enforced as part of the production code are denoted as “must” and will have
to be met to successfully complete certification. “Should” is used for guidance or best practices.
See the following chart for terminology usage in this implementation guide.
Term Term usage

must Requirements that are enforced as part of the production code.
should Used for guidance and best practices. Best practices can also be found in Best Practice sections.
Customers are encouraged, but not required, to meet best practices in order to be certified on the
Surescripts network.

2.3 TRANSITION TO PRODUCTION

Once certification is complete, and all Surescripts Identity Proofing Requirements have been
completed, 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
l Support hours
2.4 CONNECTIVITY
Please refer to the Surescripts Connectivity and Authentication Implementation Guide for
additional connectivity and authentic information. For the network to be reliable, there are
communication rules to which all customers must adhere.
2.5 TIMEOUTS
For timeouts, consider the following:
l When sending a message to Surescripts, the initiator should set the http timeout to no less
than 30 seconds.
l A receiving system must reply with a valid 271/999/TA1/NAK response within 10 seconds.
2.5.1 DATA LOAD CONNECTIVITY

Surescripts currently supports two data loads that require a customer to send large files to
Surescripts. The Master Patient Index (MPI) Data Load and the Formulary and Benefit Data Load
are created by the PBM/payer and sent to Surescripts for storage. The Formulary and Benefit File
is then ready for subsequent distribution. For these data loads, Surescripts supports Secure FTP
for file transfer between the PBM/payer and Surescripts.
2.5.1.1 SECURE FTP
Secure FTP is supported for the transfer of Master Patient Index (MPI) data loads and Formulary
and Benefit data uploads using FTP over SSL, SSH with FTP and HTTP/S. Surescripts supports
both Client-to-Server and Server-to-Server communications with compatible client software. A list
of compatible software should be requested from Surescripts. Surescripts processes do not have
file naming requirements. Security is enforced through data encryption during transfer and User
ID/Password. Customer files are isolated from other customer’s files.

Connectivity to Secure FTP can be established through an Internet route or through a Private
Virtual Circuit with Surescripts’ contracted MPLS service provider. If using the Private Virtual
Circuit, the customer must allow Surescripts to install and manage two routers in their data center
that connect to the customer’s extranet. The customer must have dual network connectivity for
redundancy.
2.6 SECURITY
Each customer must ensure that appropriate security measures are in place within its scope of
operations to the extent of its interface with Surescripts and Surescripts’ systems and data. These
security measures must be designed to protect against fraud and abuse and to maintain patient
confidentiality.
Each customer must provide a Surescripts Trading Partner ID (ISA06 for X12) and password
(ISA04 for X12) in all messages and a static network path (IP address). Surescripts will only allow
message connectivity from the customer specified network path. Provision of an otherwise-valid ID
and password from a network path not assigned to the customer will result in rejection of the
message, and will be logged as a potential security violation.
2.7 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,
l conducts scheduled and ad-hoc compliance checks of all customers transacting on the
network, 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.
The 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 including, but not limited to, local and state laws and regulations in which the
customer’s application is deployed.

Prescription Benefit IG Section 3: Messages Overview
SECTION 3: MESSAGES OVERVIEW
3.1 PRESCRIPTION BENEFIT & MEDICATION HISTORY PROCESS FLOW

The Surescripts Prescription Benefit & Medication History service provides physicians with the
electronic delivery of PBM/payer member data in an ambulatory setting. Through the Physician
System interface, the physician can request patient information such as eligibility and pharmacy
benefit coverage, formulary information, and medication history. The graphic below depicts the
process flow between customers in this process.
Figure 3 1 Surescripts Prescription Benefit & Medication History Process Flow Diagram
3.2 MESSAGE DESCRIPTIONS

Eligibility Request/Response
The X12 Health Care Eligibility, Coverage, or Benefit Inquiry (270) and Health Care Eligibility,
Coverage, or Benefit Information (271) message sets are used to request and respond to a patient
eligibility check. These messages enable prescribers to supply a patient’s name and demographic
information to Surescripts and get back the some or all of the following information from each
PBM/payer that covers the patient:

l Health Plan Number/Name

l Cardholder ID
l Relationship Code
l Person Code
l Group Number, Group Name
l Formulary ID
l Alternative List ID
l Coverage List ID
l Copay List ID
l BIN
l PCN
l Type of Prescription Benefit: Pharmacy and/or Mail Order
l Specialty Pharmacy
l Long Term Care (LTC)
Interchange Acknowledgment
This X12 specification, TA1, is utilized to acknowledge receipt/header errors for batch messages
and errors in real time messages. For the Surescripts message set, it only applies to the X12
specifications (270 & 271). None of the other specifications utilize this message.
Implementation Acknowledgement
The implementation acknowledgement, or 999, informs the submitter that the functional group
arrived at the destination and is required as a response to receipt of an X12 message in a batch
environment, and only for errors with real time messages. Surescripts only supports a real time
environment for the 270/271 messages, so the 999 will only be sent if there are errors. The 999
reports on errors generated due to data or segment issues that do not comply with the X12 guide.
ID Load/Update (Flat File)/Response
This message is used to load a PBM/payer’s patient directory into a directory at Surescripts. This
directory is an index Surescripts uses when looking up a patient’s prescription benefit. The Patient
Directory indicates which PBM/payer(s) can provide current coverage information. The elements
provided are limited to the demographic data needed for patient searches.
Formulary and Benefit Data Load
As requested or scheduled, the PBM/payer sends group-level formulary updates to provider

vendors using the Formulary and Benefit Data Load message. Once the file is retrieved, the
Physician System utilizes the file as a local repository for formulary checks.

Medication History Request/Response
After a patient’s eligibility has been determined, this message is used to retrieve a listing of
dispensed medications that were paid for by a patient’s PBM/payer. The message format is
NCPDP SCRIPT.
3.3 GENERAL INTERFACE DESCRIPTION

The message specifications have been defined to follow HIPAA standards where available and to
allow the most effective processing. Delimiters separate components, data elements, and
segments (see subsection Dynamic Delimiters below for clarification). For the X12 specifications,
the delimiters are defined in the ISA segment of the message. For NCPDP messages, the
delimiters are defined in the UNA Segment of the message. If a data element in the middle of a
segment is omitted, the separator acts as a “place holder”.
3.3.1 DYNAMIC DELIMITERS

X12 utilizes delimiters to separate component, segments, elements, etc. or as indicators (i.e., for
segment repetition.) These delimiters are defined within specified segments of the messages.
Customer's systems need to be able to dynamically set and handle these delimiters. Surescripts
recommends the use of unprintable characters as delimiters rather than the entire full character set
(Refer to Dynamic Delimiters on page 302 for a full list of acceptable characters).
For X12 messages, the delimiter set is defined within the ISA segment. The following is an
example:
ISA*00* *01*PWPHY12345*ZZ*POCID
*ZZ*S00000000000001*091217*0309*^*00501*000000001*1*P*>~
In the example above, the asterisk (*) is a delimiter based on its position immediately following ISA.
The segment delimiter is determined by calculating the last character of the fixed width row. The
row is 106 total bytes; therefore, the segment delimiter is the 106th character.
Choosing a Delimiter
Surescripts has published a list of allowed delimiters for the X12 messages (Refer to Dynamic
Delimiters on page 302 for a full list of acceptable characters). The customers may choose any
allowed delimiter desired for the messages they create. However, it is important that customers
communicate which delimiters they are using to ensure they will not cause issues with their trading
partners’ messages.
Surescripts recommends the following delimiters for X12 data:

l Data Element Separator – hex 1D, decimal 29
l Segment Terminator – hex 1E, decimal 30

l Component Element Separator (ISA 16) – hex 1C, decimal 28

l Repetition Character (ISA11) – hex 1F, decimal 31
Using Dynamic Delimiters
A Surescripts customer can expect to receive delimiters that are different than the set they define
for their messages. The customer needs to determine the delimiters dynamically when the
message is processed according to the rules listed in the above section. See Dynamic Delimiters
on page 302 for a complete list of acceptable characters.
3.3.2 DELIMITER EXAMPLES

The delimiters used in the examples below are the ~ for segment separation and the * for element
separation.
Example 1:
NM1*IL*1*SMITH*JOHN*L***34*444115555~
Elements 6 and 7 are not included; therefore, the asterisks (**) act as placeholders for the omitted
elements.
When data elements are omitted from the end of a segment, the data element delimiters do not
need to be used. The segment is ended with a segment terminator.
Example 2:
Elements 8 and 9 can be omitted in the same segment as Example 1. The new segment would
become:
NM1*IL*1*SMITH*JOHN*L~
And not:
NM1*IL*1*SMITH*JOHN*L****~
Example 3:
Surescripts does not publish segments that are HIPAA compliant but not utilized by Surescripts. If
a message contains these segments, it will still be valid and accepted; but the data within the
segment may not be utilized.
ABC*ABC01*ABC02*ABC03*ABC04*ABC05*ABC06~
If elements ABC02 and ABC03 are not used (not shown on the Surescripts EDI specifications)
then no value should be sent. However, the elements must be represented with a place holder
because there are used elements (ABC04, 05 and 06) after them.
This is the correct representation:

ABC*ABC01***ABC04*ABC05*ABC06~
ABC02 and ABC03 must be represented so that it is known that the next data value is ABC04.
This is the INCORRECT representation:
ABC*ABC01*ABC04*ABC05*ABC06~
If the placeholders for ABC02 and ABC03 are removed, ABC04 would be mistaken for ABC02.
Example 4:
ABC*ABC01*ABC02*ABC03*ABC04*ABC05*ABC06~
If elements ABC05 and ABC06 are not used (not shown on the Surescripts EDI specifications)
then no value should be sent. When elements 05 and 06 are located at the end of the segment
there is no need to represent them.
This is the correct representation:
ABC*ABC01*ABC02*ABC03*ABC04~
This is the INCORRECT representation:
ABC*ABC01*ABC02*ABC03*ABC04**~
3.3.3 REPRESENTATION
The following table lists the Field Type Notation used within the messages:
Type NCPDP Notation X12 Notation

Alphanumeric an AN
Date DT DT
Decimal R R
ID Number ID ID
Numeric n Nn
String AN AN
Time TM TM
Note: Each element, if sent, has a minimum and maximum length. For example:
AN 1/3 means an alphanumeric with range from one to three characters.
AN 3/3 means an alphanumeric with three characters.
3.3.3.1 NUMERIC REPRESENTATION
The decimal point is represented by a period and should 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
For example, consider the following possible values for a 5-digit field:
Correct: 2.515 251.5 25.15 2515 0.2515 2.5

Incorrect: .2515 2515. 3.00
3.3.3.2 CHARACTER SET
The following ASCII character sets are required by Surescripts:

l The ASCII character set between and including decimal 32 and decimal 126.
l All ID data types are case sensitive, including routing IDs in the header.
For Eligibility messages only:

l Unprintable characters are not used within the field elements but as delimiters between
segments, data elements, component elements and repeated elements or structures.
For ID File Load only:

l The decimal 94 ^ cannot be used in the ID Load process.
3.3.3.3 REQUIREMENT DESIGNATION
There are separate tables for X12 eligibility and NCPDP Formulary and Benefit since the base
standards use differing requirement designations.
X12
X12 Description
M Required/Mandatory - the segment must be used.
O Situational/Conditional - the segment must be used if conditions are met.

Segments that are not used have been removed from the message specifications.
X12 Description
M Required/Mandatory - the element must be used.
S or O Situational/Conditional - the element must be used if conditions are met.
X Usage of the element depends on the presence of another element.
NCPDP
Segment Attributes
Code Description
M Required/Mandatory – the segment must be used.
C Situational/Conditional – the segment must be used if conditions are met.
Element Attributes
Code Description
M Required/Mandatory – the element must be used.
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 for Prescription Benefit”, information will be passed on, but not used, by
Surescripts for processing.
D Dependent –the element is required or conditional based on the message type.
X Not used; will be rejected if sent.
Code Choice Attributes
Some codes have strikethrough indicating they are not to be used for that element for this
implementation.
Example: In this case in this position the only allowed code would be “A”.
Change Identifier Only the Add option is supported. AN 1/1 M A – Addition

C – Change
D – Delete
3.4 MESSAGE VALIDATION

Surescripts will certify that customers are in compliance with the message specifications outlined in
this Guide during implementation and will continue to validate once in production.
To validate a message, Surescripts:

l validates the sender identification and password.

l validates the recipient identification.
l verifies that the file is less than 1 MB.
l verifies that the sender and recipient are in agreement contractually to exchange
information.
l validates the syntax of the message including field lengths, data types and code values.
3.5 FAILURE MODE/RESPONSE APPROACH

Surescripts’ error processing approaches are defined below.
3.5.1 ERROR PROCESSING FOR 270 AND 271

When a network communication or system failure occurs between the originating customer and
Surescripts, an error message will not be returned to the customer. Customers should establish a
timeout parameter to allow their system to recover in the event that Surescripts does not respond.
Surescripts has defined four different levels of failure for exchanging errors with the customer.
NAK: In instances where Surescripts or a customer receives a message that is unrecognizable or
a system error occurs, the recipient will send back an XML formatted NAK.
The NAK is an XML formatted message. Error (NAK) <nak status=”n”>Text Message</nak>
Message Type Status Error Message

NAK 1 Invalid Syntax Transaction cannot be identified nor processed
NAK 3 Transaction Timeout Transaction Timeout
NAK 4 System Error System Error
An example of a nak: <nak status=”4”> System Error </nak>

TA1: The TA1 acknowledges the receipt of a message. It validates the syntax of the interchange
ISA and IEA segments. It notifies the sender that the receiver got the message, or it reports errors
so the sender is aware of interchange problems. Surescripts utilizes the TA1 to only report errors.
Surescripts only utilizes the TA1 to report errors when an error occurs within the header.
999: The 999 message reports functional problems to the sender. The sender will receive a 999
when a syntax error occurs in the body of the message or if the sender participant ID is invalid.
271: When a non-syntax error occurs during processing of a 270 message, AAA segments in the
271 will be used to report the errors.

Prescription Benefit IG Section 4: Eligibility
SECTION 4: ELIGIBILITY
4.1 INTRODUCTION
This section provides guidelines for the data messaging interfaces between the provider vendor
and PBM/payers. Standard segments will be required for commonly transmitted data such as basic
patient demographics and eligibility information.
The Patient and Eligibility Data will be transmitted between the Physician System, Surescripts, and
PBM/payer using the currently accepted X12 envelope segments. Message formats used include
the X12N 270 (Eligibility Benefit Inquiry) and the X12N 271 (Eligibility Benefit Response).
The requester is a Physician System, and the eligibility responder is a PBM/payer.
4.2 RELATIONSHIP TO X12N 270/271 STANDARD

All eligibility inquiries and responses sent to Surescripts by customers must comply with the X12N
standard for eligibility for a health plan mandated under HIPAA by the Department of Health and
Human Services (the "270/271 Implementation Guide"). The descriptions in this section of 270
transactions and the 271 transactions clarify the information that Surescripts expects to be included
in 270 transactions and 271 transactions exchanged with Surescripts. Nothing in these
Specifications are intended or shall be deemed to: (a) change the definition, data condition, or use
of a data element or segment in a HIPAA-mandated standard; (b) add any data elements or
segments to the maximum defined data set of a HIPAA-mandated standard; (c) use any code or
data elements that are either marked "not used" in the 270/271 Implementation Guide; or (d)
change the meaning or intent of the 270/271 Implementation Guide.
The guidelines for data messaging interfaces provided in this document are tailored to the needs of
Physician System and PBM/payer customers related to prescription drug benefits and are a subset
of the X12N 270/271 standard. The X12N 270/271 standard covers a great number of other
business scenarios that are not described in this section; however, Surescripts will support the
minimum requirements of the X12N 270/271 transaction. See Section 1.4.7 of the 270/271
Implementation Guide (“Implementation Compliant Use of the 270/271 Transaction Set”).
Note: Even though Surescripts has implemented a subset of the X12N 270/271 standard,
customers should be able to handle receiving all the segments, elements and related codes
contained in the HIPAA X12N 270/271 standard. Refer to the Document References on
page 12 for the exact reference guides needed.

If a provider vendor's customer submits an eligibility request that does not comply with the X12N
270/271 transaction standard, Surescripts will return a 999 response. If a Physician System
customer submits an eligibility request that complies with the X12N 270/271 transaction but
contains information that is unexpected by Surescripts, Surescripts will return a 271 response
based on the information received by Surescripts that was expected, but the response may include
AAA segments if insufficient information expected by Surescripts is submitted to generate a
meaningful response.
If a PBM/payer customer submits an eligibility response that does not comply with the X12N
270/271 transaction standard, Surescripts will return a 999 response to the PBM/payer. The
response to the PBM/payer should be responded to with an ACK. If a PBM/payer customer
submits an eligibility response that complies with the X12N 270/271 transaction but contains
information that is unexpected by Surescripts, Surescripts will pass the response to the requesting
prescriber system customer. However, PBM/payer customers should be aware that such
responses may not be understood or usable by the recipient prescriber system customer.
4.3 ELIGIBILITY TRANSACTION FLOW

The following steps depict the Eligibility transaction flow:
1. A requester sends an Eligibility request to Surescripts.
2. Surescripts validates the format of the transaction.
3. Surescripts locates the patient based on demographics information and uniquely identifies
the patient.
4. Surescripts determines to which PBM/payers the Eligibility request should be directed.
5. The PBM/payer verifies the patient, responds with a 271 transaction indicating the patient’s
eligibility status, and sends the 271 message back to Surescripts.
6. Surescripts validates the format of the incoming 271, consolidates all 271 responses and
sends the information back to the requester.
4.4 SEARCH OPTIONS

Unlike many other X12 transactions, the 270 transaction has the built-in flexibility of allowing a user
to enter whatever patient information they have on hand to identify them to an information source.
There are five key fields that are recommended to improve the chance of a match. They are first
name, last name, date of birth, gender and zip code.
By design, the 270 allows the requester to submit a patient as a subscriber or a dependent with a
subscriber. Surescripts will follow the following process to determine the unique ID for the patient to
retrieve eligibility.
If a patient is supplied in the subscriber loop and no dependent is listed:

Surescripts will search for this patient. If found, a PBM Unique Member ID will be placed in the

transaction and distributed to the PBM/payer. At this point, Surescripts does not know if this patient
is a subscriber or dependent.
4.4.1 INSUFFICIENT INFORMATION

In the event that insufficient identifying elements are sent to Surescripts to uniquely identify a
patient, Surescripts returns a 271 with an AAA segment identifying “Subscriber/Insured Not
Found” or “Patient Not Found” and sends recommendations for future searches, if appropriate.
4.4.2 MULTIPLE MATCHES

In the event that multiple matches are found, Surescripts returns a 271 with an AAA segment
identifying “Subscriber/Insured Not Found or Patient Not Found” and, if possible, lists the missing
data elements needed to help identify an exact patient match.
4.5 PATIENT MATCH VERIFICATION

The specific fields that are used to match the patient are listed below. Only valid patient data should
be entered. Invalid data or filler data may result in “patient not found” or an incorrect match.
• Last Name NM103
• First Name NM104 – Use formal name. Do not use nicknames.
• Middle Name NM105
• Suffix NM107 – If relevant, the name suffix should be included in this field.
• Street Address N301
• Street Address2 N303
• City N401
• State N402
• Zip N403
• DOB DMG02
• Gender DMG03
These fields could be in the subscriber loop, the dependent loop, or both; however, Surescripts
strongly suggests refraining from using the dependent loop because PBM/payers assign unique
IDs, thus according to the standard they are subscribers.
Different types of information sources identify patients in different manners depending upon how
their eligibility system is structured. There are two common approaches for the identification of
patients by an information source. One approach is to assign each member of the family (and plan)
a unique ID number. This number can be used to identify and access that individual's information
independent of whether he or she is a child, spouse, or the actual subscriber to the plan. In this
approach, the patient will be identified at the subscriber hierarchical level because a unique ID

number exists to access eligibility information for this individual. This is the approach that
PBM/payers use.
The second approach is where the primary subscriber and all dependents share one ID. Any
related spouse, children, or dependents are identified through the primary subscriber's
identification number and do not have a unique identification number of their own.
If any of the demographic fields listed above are different from what the provider vendor sent in, the
change flag must be set. If a field comes in blank and the PBM/payer sends back a value, this is
considered a change. However, if the provider vendor sends a value in a field and the PBM/payer is
unable to compare this field because they do not store this field in their patient data, the change flag
must not be set and the data from the request must not be returned. If both subscriber and
dependent information is sent, these rules apply to both.
The change flag is in the INS segment. INS03 = 001, INS04 = 25.
In the case of error conditions including patient not found - AAA error 75, contract /authorization
error - AAA error 41, and general system errors – AAA error 42, the same general rule should be
followed. Do not send back patient information from the 270 request. Therefore, in these error
conditions, no patient data should be sent back. The provider vendor should disregard any patient
information under these error scenarios.
Examples:
1. Here is an example where the PBM/payer should indicate that a change has been made and
set the change flag in the INS segment.
Provider vendor sends in: Joe M Doe, DOB 19550412, Gender Male, and Address 55
HIGH STREET, SEATTLE, WA 55111
PBM/payer returns: Joseph M Doe, DOB 19550412, Gender Male, and Address 55 HIGH
STREET, St. Paul, MN 55111
2. In this example, the PBM/payer does not need to set the change flag because they have not
changed any of the information returned, but the middle initial is blank due to the field not
being supported in the PBM/payer’s system:
HIGH STREET, St. Paul MN, 55111
PBM/payer returns: Joe Doe, DOB 19550412, Gender Male, and Address 55 HIGH
STREET, St. Paul MN, 55111
3. In this example, the PBM/payer looks up the information and finds a blank for the middle
name (which is a supported field in the PBM/payer’s system). This is considered a change so
the change flag needs to be set:
Provider vendor sends in: Joe M Doe, DOB 19550412, Gender Male,
PBM/payer returns: Joe Doe, DOB 19550412, Gender Male,

4. This is an example where the patient is not found, so none of the patient information is
returned.
HIGH STREET, St. Paul MN 55111
PBM/payer returns: No Patient Data and an AAA segment with error 75 –

Subscriber/Insured Not Found.
4.6 270 ELIGIBILITY, COVERAGE, OR BENEFIT INQUIRY

Functional Group ID= HS
Introduction
This Surescripts draft specification contains the format and establishes the data contents of the
Eligibility, Coverage or Benefit Inquiry Transaction Set (270) for use within the context of an
ePrescribing environment.
Note: For the complete set of segments and for more detail on items marked "Situational", refer
to the X12 guide.
Since PBM/payers uniquely identify each member, the subscriber level should be used
instead of the dependent level. However, receivers of the 270 should be able to handle
patients at the dependent level since the standard allows it. Because of this, the
dependent level sections of the guide are not displayed in this guide.

Heading:
Page # Seg Name Req Max Loop

ID Des Use Repeat
Header
ISA Interchange Control Header R 1
GS Functional Group Header R 1
ST Transaction Set Header R 1
BHT Beginning of Hierarchical Transaction R 1
Detail
LOOP ID – 2000A
HL Information Source Level(PBM/payer) R 1
LOOP ID – 2100A 1
NM1 Information Source Name R 1
LOOP ID – 2000B 1
HL Information Receiver Level(Physician) R 1
LOOP ID – 2100B 1
NM1 Information Receiver Name R 1
REF Information Receiver Additional Identification (Physician System S 9

Identification)
N3 Information Receiver Address S 1
N4 Information Receiver City/State/ZIP Code S 1
LOOP ID – 2000C 1
HL Subscriber Level R 1
TRN Subscriber Trace Number S 2
LOOP ID – 2100C 1
NM1 Subscriber Name R 1
REF Subscriber Additional Identification (SSN#, Person Code) S 9
N3 Subscriber Address S 1
N4 Subscriber City/State/ZIP Code S 1
DMG Subscriber Demographic Information S 1
DTP Subscriber Date S 2
LOOP ID - 2110C 99


ID Des Use Repeat
EQ Subscriber Eligibility or Benefit Inquiry Information (Health Benefit S 1
Plan Coverage)
Trailer
SE Transaction Set Trailer R 1
GE Functional Group Trailer R 1
IEA Interchange Control Trailer R 1
270 Segment: ISA Interchange Control Header

Loop:
Level: Heading
Usage: Mandatory
Max Use: 1
Purpose: To start and identify an interchange of zero or more functional groups and interchange-
related control segments
Syntax Notes:
Semantic Notes:
Comments:
Data Element Summary
Ref. Data Name Attributes

Des. Elements
M ISA01 I01 Authorization Information Qualifier ID 2/2
Code to identify the type of information in the Authorization Information
00 No Authorization Information Present (No Meaningful Information
in I02)
M ISA02 I02 Authorization Information AN 10/10
Information used for additional identification or authorization of the interchange
sender or the data in the interchange; the type of information is set by the
Authorization Information Qualifier (I01)
*Blank
M ISA03 I03 Security Information Qualifier ID 2/2
Code to identify the type of information in the Security Information
01 Password
M ISA04 I04 Security Information AN 10/10

This is used for identifying the security information about the interchange sender
or the data in the interchange; the type of information is set by the Security
Information Qualifier (I03)
*From the POC/PPMS, this is the Password assigned by Surescripts for the
POC/PPMS.
*From Surescripts, this is the password for Surescripts to get to the PBM/Payer.
M ISA05 I05 Interchange ID Qualifier ID 2/2
Qualifier to designate the system/method of code structure used to designate the
sender or receiver ID element being qualified
ZZ Mutually Defined
M ISA06 I06 Interchange Sender ID AN 15/15
Identification code published by the sender for other parties to use as the receiver
ID to route data to them; the sender always codes this value in the sender ID
element
*From the provider vendor system, this is the Participant ID as assigned by
Surescripts.
*From Surescripts to the PBM/payer, this is Surescripts’ ID.
Qualifier to designate the system/method of code structure used to designate the
sender or receiver ID element being qualified
ZZ Mutually Defined
M ISA08 I07 Interchange Receiver ID AN 15/15
Identification code published by the receiver of the data; When sending, it is used
by the sender as their sending ID, thus other parties sending to them will use this
as a receiving ID to route data to them
*From the provider vendor system, this is Surescripts’ ID (S00000000000001 for
Medication History for Ambulatory and S00000000000002 for Medication History
for Reconciliation) as assigned by Surescripts.
*From Surescripts to the PBM/payer, this is PBM/payer's Participant ID.
M ISA09 I08 Interchange Date DT 6/6
Date of the interchange
*Date format YYMMDD required.
M ISA10 I09 Interchange Time TM 4/4
Time of the interchange
*Time format HHMM required.
M ISA11 I65 Repetition Separator 1/1
Type is not applicable; the repetition separator is a delimiter and not a data
element; this field provides the delimiter used to separate repeated occurrences of
a simple data element or a composite data structure; this value must be different
than the data element separator, component element separator, and the segment
terminator.

*Surescripts recommends using Hex 1F.

M ISA12 I11 Interchange Control Version Number ID 5/5
This version number covers the interchange control segments
00501 Draft Standards for Trial Use Approved for Publication by X12
Procedures Review Board through October 2003
M ISA13 I12 Interchange Control Number N0 9/9
A control number assigned by the interchange sender
*From the provider vendor system, this is a unique ID assigned by the provider
vendor system for transaction tracking.
*From Surescripts, this is a unique ID assigned by Surescripts for transaction
tracking.
This ID will be returned on a TA1 if an error occurs. Providing a unique number will
assist in resolving errors and tracking messages.
M ISA14 I13 Acknowledgment Requested ID 1/1
Code sent by the sender to request an interchange acknowledgment (TA1)
The TA1 is returned only in the event of an error.
TA1 segments should not be returned for accepted transactions. If there are no
errors at the envelope level (ISA, GS, GE, IEA segments) then TA1 segments
should not be returned.
*Since these transactions are real time only, Surescripts does not use this field to
determine whether to create a TA1 acknowledgment.
0 No Acknowledgment Requested (Recommended by Surescripts)
1 Interchange Acknowledgment Requested
M ISA15 I14 Usage Indicator ID 1/1
Code to indicate whether data enclosed by this interchange envelope is test,
production or information
P Production Data
T Test Data
M ISA16 I15 Component Element Separator AN 1/1
Type is not applicable; the component element separator is a delimiter and not a
data element; this field provides the delimiter used to separate component data
elements within a composite data structure; this value must be different than the
data element separator and the segment terminator
*Surescripts recommends using Hex 1C.

270 Segment: GS Functional Group Header

Loop:
Level: Heading
Usage: Mandatory
Max Use: 1
Purpose: To indicate the beginning of a functional group and to provide control information
Syntax Notes:
Semantic Notes:
1 GS04 is the group date.
2 GS05 is the group time.
3 The data interchange control number GS06 in this header must be identical to the same
data element in the associated functional group trailer, GE02.
Comments:
1 A functional group of related transaction sets, within the scope of X12 standards,
consists of a collection of similar transaction sets enclosed by a functional group header
and a functional group trailer.

Des. Elements
M GS01 479 Functional Identifier Code ID 2/2
Code identifying a group of application related transaction sets
HS Eligibility, Coverage or Benefit Inquiry (270)
M GS02 142 Application Sender's Code AN 2/15
Code identifying party sending transmission; codes agreed to by trading partners
*From the provider vendor system, this is the Participant ID as assigned by
Surescripts.
*From Surescripts to PBM/payer, this is Surescripts’ ID.
M GS03 124 Application Receiver's Code AN 2/15
Code identifying party receiving transmission; codes agreed to by trading
partners
*From the provider vendor system, this is Surescripts’ ID as assigned by
Surescripts.
*From Surescripts to PBM/payer, this is PBM/payer's Participant ID.

M GS04 373 Date DT 8/8

Date expressed as CCYYMMDD
M GS05 337 Time TM 4/8
Time expressed in 24-hour clock time as follows: HHMM, or HHMMSS, or
HHMMSSD, or HHMMSSDD, where H = hours (00-23), M = minutes (00-59), S
= integer seconds (00-59) and DD = decimal seconds; decimal seconds are
expressed as follows: D = tenths (0-9) and DD = hundredths (00-99)
M GS06 28 Group Control Number N0 1/9
Assigned number originated and maintained by the sender
*The control number should be unique across all groups within this transaction
set. This ID will be returned on an AK102 of the 999 acknowledgment if an error
occurs. Providing unique numbers will assist in resolving errors and tracking
messages. Avoid using leading zeros in this field
M GS07 455 Responsible Agency Code ID 1/2
Code used in conjunction with Data Element 480 to identify the issuer of the
standard
X Accredited Standards Committee X12
M GS08 480 Version / Release / Industry Identifier Code AN 1/12
Code indicating the version, release, subrelease, and industry identifier of the
EDI standard being used, including the GS and GE segments; if code in DE455
in GS segment is X, then in DE 480 positions 1-3 are the version number;
positions 4-6 are the release and subrelease, level of the version; and positions
7-12 are the industry or trade association identifiers (optionally assigned by
user); if code in DE455 in GS segment is T, then other formats are allowed
005010X279A1
Draft Standards Approved for Publication by ASC X12
Procedures Review Board through October 2003, as
published in this implementation guide.

270 Segment: ST Transaction Set Header

Loop:
Level: Heading
Usage: Mandatory
Max Use: 1
Purpose: To indicate the start of a transaction set and to assign a control number
Syntax Notes:
Semantic Notes:
1 The transaction set identifier (ST01) is used by the translation routines of the
interchange partners to select the appropriate transaction set definition (e.g., 810 selects
the Invoice Transaction Set).
Comments:
Notes: Use this control segment to mark the start of a transaction set. One ST segment exists for every
transaction set that occurs within a functional group. As per the X12 guide, it is required that the
270 transaction contain only one patient request when using the transaction in a real time mode.
Example: ST*270*0001*005010X279A1~

Des. Elements
M ST01 143 Transaction Set Identifier Code ID 3/3
Code uniquely identifying a Transaction Set
Use this code to identify the transaction set ID for the transaction set that will
follow the ST segment. Each X12 standard has a transaction set identifier code
that is unique to that transaction set.
270 Eligibility, Coverage or Benefit Inquiry
M ST02 329 Transaction Set Control Number AN 4/9
Identifying control number that must be unique within the transaction set
functional group assigned by the originator for a transaction set

The transaction set control numbers in ST02 and SE02 must be identical. This
unique number also aids in error resolution research. Start with the number, for
example "0001", and increment from there. This number must be unique within
a specific group and interchange, but can repeat in other groups and
interchanges.
*1This ID will be returned on an AK202 of the 999 acknowledgment if an error
occurs. Providing a unique number will assist in resolving errors and tracking
messages.
M ST03 1705 Implementation Convention Reference AN 1/35
Reference assigned to identify Implementation Convention
The implementation convention reference (ST03) is used by the translation
routines of the interchange partners to select the appropriate implementation
convention to match the transaction set definition. When used, this
implementation convention reference takes precedence over the
implementation reference specified in the GS08. This element must be
populated with 005010X279A1.
This element contains the same value as GS08. Some translator products strip
off the ISA and GS segments prior to application (ST/SE) processing. Providing
the information from the GS08 at this level will ensure that the appropriate
application mapping is utilized at translation time.
270 Segment: BHT Beginning of Hierarchical Transaction

Loop:
Level: Heading
Usage: Mandatory
Max Use: 1
Purpose: To define the business hierarchical structure of the transaction set and identify the
business application purpose and reference data, i.e., number, date, and time.
Syntax Notes:
Semantic Notes:
1 BHT03 is the number assigned by the originator to identify the transaction within the
originator's business application system.
2 BHT04 is the date the transaction was created within the business application system.
3 BHT05 is the time the transaction was created within the business application system.
1 A gray shaded note that is preceded by an asterisk is a Surescripts’ specific note and is not from the X12 guide.

Comments:
Notes: Use this required segment to start the transaction set and indicate the sequence of the
hierarchical levels of information that will follow in Table 2.
Example: BHT*0022*13*199800114000001*19980101*1400~
Ref. Des. Data Name Attributes

Elements
M BHT01 1005 Hierarchical Structure Code ID 4/4
Code indicating the hierarchical application structure of a transaction set that
utilizes the HL segment to define the structure of the transaction set
Use this code to specify the sequence of hierarchical levels that may appear
in the transaction set. This code only indicates the sequence of the levels, not
the requirement that all levels be present. For example, if code "0022" is used,
the dependent level may or may not be present for each subscriber.
0022 Information Source, Information Receiver, Subscriber,
Dependent
M BHT02 353 Transaction Set Purpose Code ID 2/2
Code identifying purpose of transaction set
13 Request
* Surescripts customers utilize this option only; 01
(Cancellation) and 36 (Authority to Deduct) are not utilized.
M BHT03 127 Reference Identification AN 1/50
Reference information as defined for a particular Transaction Set or as
specified by the Reference Identification Qualifier
Required when the transaction is processed in Real Time. If not required by
this implementation guide, may be provided at the sender’s discretion, but
cannot be required by the receiver.
This element is to be used to trace the transaction from one point to the next
point, such as when the transaction is passed from one clearinghouse to
another clearinghouse. This identifier is to be returned in the corresponding
271 transaction's BHT03. This identifier will only be returned by the last
entity to handle the 270. This identifier will not be passed through the
complete life of the transaction. All recipients of 270 transactions are
required to return the Submitter Transaction Identifier in their 271 response if
one is submitted.
Submitter Transaction Identifier
*Because Surescripts only supports Real Time, this element is
required.
M BHT04 373 Date DT 8/8


Use this date for the date the transaction set was generated.
Format CCYYMMDD
M BHT05 337 Time TM 4/8
HHMMSSD, or HHMMSSDD, where H = hours (00-23), M = minutes (00-59),
S = integer seconds (00-59) and DD = decimal seconds; decimal seconds are
expressed as follows: D = tenths (0-9) and DD = hundredths (00-99)
Use this time for the time the transaction set was generated.

270 Segment: HL Information Source Level

Loop: 2000A
Level: Detail
Usage: Mandatory
Max Use: 1
Purpose: To identify dependencies among and the content of hierarchically related groups of data
segments
Syntax Notes:
Semantic Notes:
Comments:
1 The HL segment is used to identify levels of detail information using a hierarchical

structure, such as relating line-item data to shipment data, and packaging data to line-
item data.
The HL segment defines a top-down/left-right ordered structure.
2 HL01 shall contain a unique alphanumeric number for each occurrence of the HL
segment in the transaction set. For example, HL01 could be used to indicate the number
of occurrences of the HL segment, in which case the value of HL01 would be "1" for the
initial HL segment and would be incremented by one in each subsequent HL segment
within the transaction.
3 HL02 identifies the hierarchical ID number of the HL segment to which the current HL
segment is subordinate.
4 HL03 indicates the context of the series of segments following the current HL segment
up to the next occurrence of an HL segment in the transaction. For example, HL03 is
used to indicate that subsequent segments in the HL loop form a logical grouping of data
referring to shipment, order, or item-level information.
5 HL04 indicates whether or not there are subordinate (or child) HL segments related to
the current HL segment.

Notes: Segment to identify the hierarchical or entity level of information being conveyed. The HL
structure allows for the efficient nesting of related occurrences of information. The developers'
intent is to clearly identify the relationship of the patient to the subscriber and the subscriber to
the provider.
Additionally, multiple subscribers and/or dependents (i.e., the patient) can be grouped together
under the same provider or the information for multiple providers or information receivers can be
grouped together for the same payer or information source.
In a batch environment, only one Loop 2000A (Information Source) loop is to be created for each
unique information source in a transaction. Each Loop 2000B (Information Receiver) loop that is
subordinate to an information source is to be contained within only one Loop 2000A loop. There
has been a misuse of the HL structure creating multiple Loops 2000As for the same information
source. This is not the developer's intended use of the HL structure, and defeats the efficiencies
that are designed into the HL structure.
An example of the overall structure of the transaction set when used in batch mode is:
Information Source (Loop 2000A)
Information Receiver (Loop 2000B) Physician
Subscriber (Loop 2000C)
Dependent (Loop 2000D)
Eligibility or Benefit Inquiry
Example: HL*1**20*1~

Elements
M HL01 628 Hierarchical ID Number AN 1/12
A unique number assigned by the sender to identify a particular data
segment in a hierarchical structure
Use this sequentially assigned positive number to identify each specific
occurrence of an HL segment within a transaction set. The first HL segment
in the transaction must begin with the number 1 and be incremented by 1 for
each successive occurrence of the HL segment within that specific
transaction set (ST through SE).
An example of the use of the HL segment and this data element is:
HL*1**20*1~
NM1*2B*2*PBM NAME*****PI*87728~
M HL03 735 Hierarchical Level Code ID 1/2
Code defining the characteristic of a level in a hierarchical structure
All data that follows an HL segment is associated with the Information
Source identified by the level code. This association continues until the next
occurrence of an HL segment.

20 Information Source
Identifies the payer, maintainer, or source of the
information
M HL04 736 Hierarchical Child Code ID 1/1
Code indicating if there are hierarchical child data segments subordinate to
the level being described
Use this code to indicate whether there are subordinate (or child)
hierarchical levels to the hierarchical level being described.
Because of the hierarchical structure, and there will always be an
Information Receiver HL subordinate to this Information Source HL the code
value in the HL04 at the Loop 2000A level must always be "1".
1 Additional Subordinate HL Data Segment in This
Hierarchical Structure.

270 Segment: NM1 Information Source Name

Loop: 2100A
Level: Detail
Usage: Mandatory
Max Use: 1
Purpose: To supply the full name of an individual or organizational entity
Syntax Notes:
1 If either NM108 or NM109 is present, then the other is required.

Semantic Notes:
1 NM102 qualifies NM103.
Notes: Use this NM1 loop to identify an entity by name and/or identification number. This NM1 loop is
used to identify the eligibility or benefit information source.
Example: NM1*2B*2*SURESCRIPTS LLC*****PI*S00000000000001~

Elements
M NM101 98 Entity Identifier Code ID 2/3
Code identifying an organizational entity, a physical location, property or an
individual
2B Third-Party Administrator (Recommended by Surescripts)
M NM102 1065 Entity Type Qualifier ID 1/1
Code qualifying the type of entity
Use this code to indicate whether the entity is an individual person or an
organization.
1 Person
2 Non-Person Entity (Recommended by Surescripts)
M NM103 1035 Name Last or Organization Name AN 1/60
Individual last name or organizational name
*From the provider vendor system, the source is unknown so this would be
Surescripts.
*From Surescripts, Surescripts will place the source name here.
M NM108 66 Identification Code Qualifier ID 1/2
Code designating the system/method of code structure used for Identification
Code (67)

PI Payer Identification (Recommended by Surescripts)

M NM109 67 Identification Code AN 2/80
Code identifying a party or other code
Use this reference number as qualified by the preceding data element
(NM108).
*From the provider vendor system, the PBM/payer's ID is unknown so this
will be Surescripts’ ID. S00000000000001
*From Surescripts to PBM/payer, Surescripts will place the Participant ID of
the PBM/payer's here.

270 Segment: HL Information Receiver Level

Loop: 2000B
Level: Detail
Usage: Mandatory
Max Use: 1
segments
*Physician identification
Syntax Notes:
Semantic Notes:
Comments: Refer to X12 guide
Notes: Refer to X12 guide

Example: HL*2*1*21*1~

Elements
A unique number assigned by the sender to identify a particular data segment
in a hierarchical structure
M HL02 734 Hierarchical Parent ID Number AN 1/12
Identification number of the next higher hierarchical data segment that the
data segment being described is subordinate to
21 Information Receiver
1 Additional Subordinate HL Data Segment in This Hierarchical
Structure.

270 Segment: NM1 Information Receiver Name

Loop: 2100B
Level: Detail
Usage: Mandatory
Max Use: 1
Syntax Notes:

Semantic Notes:
Notes: Use this segment to identify an entity by name and/or identification number. This
NM1 loop is used to identify the eligibility/benefit information receiver.
Example: NM1*1P*1*JONES*TIM****XX*111223333~

Elements
individual
1P Provider (Recommended by Surescripts)
organization.
1 Person (Recommended by Surescripts)
2 Non-Person Entity
M NM103 1035 Name Last or Organization Name AN 1/60
* Physician Name
O NM104 1036 Name First AN 1/35
Individual first name
Required when 2100B NM102 is "1". If not required by this implementation
guide, do not send.
O NM105 1037 Name Middle AN 1/25

Individual middle name or initial

Use this name only when 2100B NM104 is present and Name Suffix in
2100B NM107 if sent are not sufficient to identify the information receiver. If
not required by this implementation guide and NM104 is present, may be
provided at sender’s discretion, but cannot be required by the receiver.
O NM107 1039 Name Suffix AN 1/10
Suffix to individual name
Use this for the suffix to an individual's name; e.g., Sr., Jr. or III.
Use this only if NM102 is "1".
Code designating the system/method of code structure used for
Identification Code (67)
Use this element to qualify the identification number submitted in NM109.
This is the number that the information source associates with the
information receiver.
XX Centers for Medicare and Medicaid Services National Provider
Identifier
Required value if the National Provider ID is mandated for use.
Otherwise, one of the other listed codes may be used.
***The NPI is mandated. Surescripts will reject if the NM108
and the NM109 are not populated.
Surescripts will not be validating the NPI, but some payers
may validate it.
(NM108).
*Shall be a valid 10 digit NPI.

270 Segment: REF Information Receiver Additional Identification (POC Identification)

Loop: 2100B
Level: Detail
Usage: Situational
Max Use: 9
Purpose: To specify identifying information
Syntax Notes:
1 At least one of REF02 or REF03 is required.

Comments:
Notes: Use this segment when needed to convey other or additional identification numbers for the
information receiver. The type of reference number is determined by the qualifier in REF01. Only
one occurrence of each REF01 code value may be used in the 2100B loop.
*Surescripts defined Participant ID for the provider vendor system. Required by Surescripts.
Example: REF*EO*477563928~
Ref. Des. Data Elements Name Attributes

M REF01 128 Reference Identification Qualifier ID 2/3
Code qualifying the Reference Identification
Use this code to specify or qualify the type of reference number that
is following in REF02, REF03, or both.
EO Submitter Identification Number
A unique number identifying the
submitter of the transaction set
* Surescripts defined Participant ID for
the provider vendor system.
M REF02 127 Reference Identification AN 1/50
Reference information as defined for a particular Transaction Set or
as specified by the Reference Identification Qualifier
(REF01).
O REF03 352 Description AN 1/80
A free-form description to clarify the related data elements and their
content
*Shall not be used for the EO qualifier.

`270 Segment: N3 Information Receiver Address

Loop: 2100B
Level: Detail
Usage: Situational
Max Use: 1
Purpose: To specify the location of the named party
Syntax Notes:
Semantic Notes:
Comments:
Notes: Required when the information receiver is a provider who has multiple locations and it is needed
to identify the location relative to the request. If not required by this implementation guide, may
be provided at sender’s discretion, but cannot be required by the receiver.
Example: N3*201 PARK AVENUE*SUITE 300~

Elements
M N301 166 Address Information AN 1/55
Address information
Use this information for the first line of the address information.
O N302 166 Address Information AN 1/55
Address information
Use this information for the second line of the address information.
Required if a second address line exists. If not required by this
implementation guide, do not send.

270 Segment: N4 Information Receiver City/State/ZIP Code

Loop: 2100B
Level: Detail
Usage: Situational
Max Use: 1
Purpose: To specify the geographic place of the named party
Syntax Notes: 1
Semantic Notes:
Comments:
1A combination of either N401 through N404, or N405 and N406 may be adequate to
specify a location.
2 *State (N402) and Postal (N403) are required if city name (N401) is in the U.S. or
Canada.
Notes: Required when the information receiver is a provider who has multiple locations and it is needed
to identify the location relative to the request. If not required by this implementation guide, may
be provided at sender’s discretion, but cannot be required by the receiver.
Example: N4*NEW YORK*NY*10003~

Elements
M N401 19 City Name AN 2/30
Free-form text for city name
Use this text for the city name of the information receiver's address.
O N402 156 State or Province Code ID 2/2
Code (Standard State/Province) as defined by appropriate government
agency
Required when the address is in the United States of America, including
its territories, or Canada. If not required by this implementation guide, do
not send.
O N403 116 Postal Code ID 3/15
Code defining international postal zone code excluding punctuation and
blanks (zip code for United States)
Required when the address is in the United States of America, including
its territories, or Canada, or when a postal code exists for the country in
N404. If not required by this implementation guide, do not send.

O N404 26 Country Code ID 2/3

Code identifying the country
Use this code to specify the country of the information receiver’s
address, if other than the United States of America. If not required by this
* Do not send the US Country Code.

270 Segment: HL Subscriber Level

Loop: 2000C
Level: Detail
Usage: Mandatory
Max Use: 1
segments
Syntax Notes:
Semantic Notes:
Comments:
Notes: Example: HL*3*2*22*0~

Elements
Identification number of the next higher hierarchical data segment
that the data segment being described is subordinate to
22 Subscriber
Code indicating if there are hierarchical child data segments
subordinate to the level being described
0 No Subordinate HL Segment in This Hierarchical
Structure.
1 Additional Subordinate HL Data Segment in This
Hierarchical Structure.

270 Segment: TRN Subscriber Trace Number

Loop: 2000C
Level: Detail
Usage: Situational
Max Use: 2
Purpose: To uniquely identify a transaction to an application
Syntax Notes:
Semantic Notes:
1 TRN02 provides unique identification for the transaction.
2 TRN03 identifies an organization.
3 TRN04 identifies a further subdivision within the organization.

Comments:
Notes: Required when information receiver or clearinghouse intends to use the TRN segment as a
tracing mechanism for the eligibility transaction and the subscriber is the patient. If not required by
this implementation guide, do not send.
Trace numbers assigned at the subscriber level are intended to allow tracing of an
eligibility/benefit transaction when the subscriber is the patient.
The information receiver may assign one TRN segment in this loop if the subscriber is the
patient. A clearinghouse may assign one TRN segment in this loop if the subscriber is the
patient. See Section 1.4.6 Information Linkage of the X12 HIPAA Implementation Guide.
Example: TRN*1*98175-012547*8877281234*RADIOLOGY~

Elements
M TRN01 481 Trace Type Code ID 1/2
Code identifying which transaction is being referenced
Current Transaction Trace Number
1 Current Transaction Trace Numbers
M TRN02 127 Reference Identification AN 1/50
Use this number for the trace or reference number assigned by the
information receiver or clearinghouse.
M TRN03 509 Originating Company Identifier AN 10/10

A unique identifier designating the company initiating the funds transfer

instructions, business transaction or assigning tracking reference
identification.
Use this number for the identification number of the company that
assigned the trace or reference number specified in the previous data
element (TRN02).
The first position must be either a "1" if an EIN is used, a "3" if a DUNS is
used or a "9" if a user assigned identifier is used.
* In the 5010A1 Errata version the above requirement has been removed,
however is recommended to follow this rule for backwards compatibility.
O TRN04 127 Reference Identification AN 1/50
Use this information if necessary to further identify a specific component
of the company identified in the previous data element (TRN03). This
information allows the originating company to further identify a specific
division or group within that organization that was responsible for
assigning the trace or reference number.

270 Segment: NM1 Subscriber Name

Loop: 2100C
Level: Detail
Usage: Mandatory
Max Use: 1
Syntax Notes:

Semantic Notes:
Notes: Use this segment to identify an entity by name and/or identification number. Use this NM1 loop
to identify the insured or subscriber.
Example: NM1*IL*1*SMITH*JOHN*L***MI*444115555~

Elements
individual
IL Insured or Subscriber
organization.
1 Person
O NM103 1035 Name Last or Organization Name AN 1/60
Use this name for the subscriber's last name.
Use this name if the subscriber is the patient and if utilizing the HIPAA
search option. See Section 1.4.8 Search Options of the X12
Implementation Guide for more information.

Use this name for the subscriber’s first name.

Use this name if the subscriber is the patient and if utilizing the HIPAA
search option. See Section 1.4.8 Search Options of the X12
Implementation Guide for more information.
Use this for the suffix to an individual's name; e.g., Sr., Jr. or III. Use if
information is known and will assist in identification of the person named,
particularly when not utilizing the HIPAA search option.
O NM108 66 Identification Code Qualifier ID 1/2
This is the primary number that the information source associates with the
subscriber.
Use this element if utilizing the HIPAA search option. See Section 1.4.8
Search Options) of the X12 Implementation Guide for more information.
*From the provider vendor system this is blank. Surescripts will put the
PBM Unique Member ID into this field.
M Member Identification Number
This code may only be used prior to the mandated use of code "II".
This is the unique number the payer or information source uses to
identify the insured (e.g., Health Insurance Claim Number, Medicaid
Recipient ID Number, HMO Member ID, etc.).
O NM109 67 Identification Code AN 2/80
Subscriber Identification Code if available
(NM108).
*From the provider vendor system this is blank. Surescripts will put the
PBM Unique Member ID into this field.

270 Segment: REF Subscriber Additional Identification

Loop: 2100C
Level: Detail
Usage: Situational
Max Use: 9
Syntax Notes:
Notes: Example: REF*EJ*660415~

Elements
Use this code to specify or qualify the type of reference number that is
following in REF02, REF03, or both. See X12 guide for additional
qualifiers.
SY Social Security Number
The social security number may not be used for any Federally
administered programs such as Medicare.
EJ Patient Account Number

270 Segment: N3 Subscriber Address

Loop: 2100C
Level: Detail
Usage: Situational
Max Use: 1
Syntax Notes:
Semantic Notes:
Comments:
Notes: Use this segment when needed to convey the address information for the subscriber. Use if
information is known and will assist in identification of the person named, particularly when not
utilizing the HIPAA search option. See the X12 guide.
Example: N3*15197 BROADWAY AVENUE*APT 215~

Elements
Address information
Address information

270 Segment: N4 Subscriber City/State/ZIP Code

Loop: 2100C
Level: Detail
Usage: Situational
Max Use: 1
Syntax Notes: 1
Semantic Notes:
Comments:
1 A combination of either N401 through N404, or N405 and N406 may be adequate to
specify a location.
2 State (N402) and Postal (N403) are required if city name (N401) is in the U.S. or
Canada.
Notes: Use this segment when needed to convey the city, state, and ZIP code for the subscriber. Use if
information is known and will assist in identification of the person named, particularly when not
utilizing the HIPAA search option.

Des. Elements
Use this text for the city name of the subscriber's address.
agency
Required when the address is in the United States of America, including its
territories, or Canada. If not required by this implementation guide, do not
send.
territories, or Canada, or when a postal code exists for the country in N404.
If not required by this implementation guide, do not send.


Use this code to specify the country of the subscriber's address, if other
than the United States.
* Do not send the US Country Code

270 Segment: DMG Subscriber Demographic Information

Loop: 2100C
Level: Detail
Usage: Situational
Max Use: 1
Purpose: To supply demographic information
Syntax Notes:
1 If either DMG01 or DMG02 is present, then the other is required.

Semantic Notes:
1 DMG02 is the date of birth.
2 DMG07 is the country of citizenship.
3 DMG09 is the age in years.

Comments:
Notes: Example: DMG*D8*19430917*M~

Elements
O DMG01 1250 Date Time Period Format Qualifier ID 2/3
Code indicating the date format, time format, or date and time format
Use this code to indicate the format of the date of birth that follows in
DMG02.
D8 Date Expressed in Format CCYYMMDD
O DMG02 1251 Date Time Period AN 1/35
Expression of a date, a time, or range of dates, times or dates and times
Use this date for the date of birth of the individual.
O DMG03 1068 Gender Code ID 1/1
Code indicating the sex of the individual
Use this code to indicate the subscriber's gender.
F Female
M Male

270 Segment: DTP Subscriber Date

Loop: 2100C
Level: Detail
Usage: Situational
Max Use: 2
Purpose: To specify any or all of a date, a time, or a time period.
*Use this segment only if subscriber is patient.
Syntax Notes:
Semantic Notes:
1 DTP02 is the date or time or period format that will appear in DTP03.
Comments:
Notes: Absence of a Plan date indicates the request is for the date the transaction is processed and the
information source is to process the transaction in the same manner as if the processing date was
sent.
Example: DTP*291*D8*20151015~

Elements
M DTP01 374 Date/Time Qualifier ID 3/3
Code specifying type of date or time, or both date and time
291 Plan
Begin and end dates of the service being rendered
M DTP02 1250 Date Time Period Format Qualifier ID 2/3
RD8 Date Range expressed in Format CCYYMMDD-CCYYMMDD
M DTP03 1251 Date Time Period AN 1/35
Use this date for the date(s) as qualified by the preceding data elements.

270 Segment: EQ Subscriber Eligibility or Benefit Inquiry Information (Pharmacy)

Loop:2110C
Notes: The loop can repeat up to 99 times.
Level: Detail
Usage: Situational
Max Use: 1
Purpose: To specify inquired eligibility or benefit information
Syntax Notes:
1 At least one of EQ01 or EQ02 is required.

Semantic Notes:
Comments:
Notes: Required when the subscriber is the patient whose eligibility or benefits are being verified. Since
dependent level is not used in this implementation, this is required.
Example: EQ*30~

Elements
O EQ01 1365 Service Type Code ID 1/2
Code identifying the classification of service
30 Health Benefit Plan Coverage. Recommended by Surescripts.
* Instead of specifying a specific service type code, this code allows the
information source to respond with all the relevant service types. If other
service types are sent, the responder will only respond to pharmacy-related
coverages.
An information source may support the use of Service Type Codes other
than “30" (Health Benefit Plan Coverage) in EQ01 at their discretion.

270 Segment: SE Transaction Set Trailer

Loop:
Level: Summary
Usage: Mandatory
Max Use: 1
Purpose: To indicate the end of the transaction set and provide the count of the transmitted
segments (including the beginning (ST) and ending (SE) segments)
Syntax Notes:
Semantic Notes:
Comments:
1 SE is the last segment of each transaction set.
Notes: Use this segment to mark the end of a transaction set and provide control information on the
total number of segments included in the transaction set.
Example: SE*41*0001~

Elements
M SE01 96 Number of Included Segments N0 1/10
Total number of segments included in a transaction set including ST
and SE segments
Use this number to indicate the total number of segments included in
the transaction set inclusive of the ST and SE segments.
M SE02 329 Transaction Set Control Number AN 4/9
Identifying control number that must be unique within the transaction
set functional group assigned by the originator for a transaction set
The transaction set control numbers in ST02 and SE02 must be
identical. This unique number also aids in error resolution research.
Start with a number, for example “0001”, and increment from there. This
number must be unique within a specific functional group (segments GS
through GE) and interchange, but can repeat in other groups and
interchanges.

270 Segment: GE Functional Group Trailer

Loop:
Level: Summary
Usage: Mandatory
Max Use: 1
Purpose: To indicate the end of a functional group and to provide control information.
Syntax Notes:
Semantic Notes:
1 The data interchange control number GE02 in this trailer must be identical to the same
data element in the associated functional group header, GS06.
Comments:
1 The use of identical data interchange control numbers in the associated functional
group header and trailer is designed to maximize functional group integrity. The control
number is the same as that used in the corresponding header.

Elements
M GE01 97 Number of Transaction Sets Included N0 1/6
Total number of transaction sets included in the functional group or
interchange (transmission) group terminated by the trailer containing this
data element
M GE02 28 Group Control Number N0 1/9
Same control number as GS06.

270 Segment: IEA Interchange Control Trailer

Loop:
Level: Summary
Usage: Mandatory
Max Use: 1
Purpose: To define the end of an interchange of zero or more functional groups and interchange-
Syntax Notes:
Semantic Notes:
Comments:

Elements
M IEA01 I16 Number of Included Functional Groups N0 1/5
A count of the number of functional groups included in an interchange
M IEA02 I12 Interchange Control Number N0 9/9
*Same control number as ISA13.

4.7 271 ELIGIBILITY, COVERAGE, OR BENEFIT INFORMATION

Functional Group ID= HB
This Surescripts draft specification contains the format and establishes the data contents of the
Eligibility, Coverage or Benefit Information Transaction Set (271) for use within the context of an
ePrescribing environment. For the complete set of segments, refer to the X12 guide.
The X12 guide defines loops 2110C/D and 2120C/D. This guide has numbered occurrences of
these loops as C1 through C4 to help clarify what should go in each occurrence of the loop.
PBM/payer's uniquely identify each patient, thus the subscriber level should be used instead of the
dependent level. However, receivers of the 270 should be able to handle patients at the dependent
level since the standard allows it. Also, when the patient is submitted in the dependent loop (in 270)
they must be moved to subscriber loop (in 271). This is due to the fact that PBM/payer's assign
unique identifiers to all members thus they are deemed to be subscribers according to the
standard.
Note: For the complete set of segments and for more detail on items marked "Situational", refer
to the X12 guide.
Heading:

ID Des Use Repeat
Header
ISA Interchange Control Header R 1
GS Functional Group Header R 1
ST Transaction Set Header R 1
BHT Beginning of Hierarchical Transaction R 1
Detail
LOOP ID – 2000A Information Source Level
HL Information Source Level(PBM/payer) R 1
AAA Request Validation S 9
LOOP ID – 2100A 1
NM1 Information Source Name R 1
AAA Request Validation S 9
LOOP ID – 2000B Information Receiver Level 1
HL Information Receiver Level(Physician) S 1


ID Des Use Repeat
LOOP ID – 2100B 1
NM1 Information Receiver Name R 1
REF Information Receiver Additional Identification (Physician System S 1

Identification)
AAA Information Receiver Request Validation S 9
LOOP ID – 2000C Subscriber Level 1
HL Subscriber Level S 1
TRN Subscriber Trace Number S 3
LOOP ID – 2100C 1
NM1 Subscriber Name R 1
REF Subscriber Additional Identification (Person Code, Cardholder ID, SSN, S 9

Patient Account Number)
N3 Subscriber Address S 1
N4 Subscriber City/State/ZIP Code S 1
AAA Subscriber Request Validation S 9
DMG Subscriber Demographic Information S 1
INS Subscriber Relationship S 1
DTP Subscriber Date S 9
LOOP ID – 2110C1 1
EB Subscriber Eligibility or Benefit Information S 1
REF Subscriber Additional Identification (Plan ID, Group ID/Name, Formulary S 9

ID, Alternative ID, Coverage List ID, BIN/PCN, and Copay ID)
DTP Subscriber Eligibility/Benefit Date S 20
MSG Message Text S 10
LS Loop Header2110C1 S 1
LOOP ID – 2120C1 23
NM1 Subscriber Benefit Related Entity Name 2120C1 S 1 1
LE Loop Trailer 2110C1 S 1
LOOP ID – 2110C2-5 (One loop for retail, one for mail order, and 23
optionally, one for specialty pharmacy, and/ or LTC)


ID Des Use Repeat
EB Subscriber Eligibility or Benefit Information S 1
DTP Subscriber Eligibility/Benefit Date S 20
MSG Message Text S 10
LS Loop Header 2110C2-5 S 1
LOOP ID – 2120C2-5 23
NM1 Subscriber Benefit Related Entity Name 2120C2-5 S 1 1
LE Loop Trailer 2110C2-5 S 1
Trailer
SE Transaction Set Trailer R 1
GE Functional Group Trailer R 1
IEA Interchange Control Trailer R 1


Loop:
Level: Heading
Usage: Mandatory
Max Use: 1

Des. Elements
00 No Authorization Information Present (No Meaningful
Information in I02)
M ISA02 I02 Authorization Information AN
10/10
Information used for additional identification or authorization of the
interchange sender or the data in the interchange; the type of information is
set by the Authorization Information Qualifier (I01)
*Blank
01 Password
M ISA04 I04 Security Information AN
10/10
This is used for identifying the security information about the interchange
Security Information Qualifier (I03)
*From the PBM/payer to Surescripts, this is the Surescripts system
assigned password to the PBM/payer.
*From Surescripts to the Physician System, this is Surescripts’ defined
password that is used to access the Physician System.
Qualifier to designate the system/method of code structure used to
designate the sender or receiver ID element being qualified
ZZ Mutually Defined
M ISA06 I06 Interchange Sender ID AN
15/15

Identification code published by the sender for other parties to use as the
receiver ID to route data to them; the sender always codes this value in the
sender ID element
*From the PBM/payer to Surescripts, this is the PBM/payer's Participant
ID.
*From Surescripts to the provider vendor system, this is Surescripts’ ID.
ZZ Mutually Defined
M ISA08 I07 Interchange Receiver ID AN
15/15
Identification code published by the receiver of the data; When sending, it
is used by the sender as their sending ID, thus other parties sending to
them will use this as a receiving ID to route data to them
*From the PBM/payer, this is Surescripts’ ID.
*From Surescripts to the provider vendor system, this is the provider
vendor’s Participant ID.
*Time format HHDD required.
element; this field provides the delimiter used to separate repeated
occurrences of a simple data element or a composite data structure; this
value must be different than the data element separator, component element
separator, and the segment terminator
00501 Standards Approved for Publication by X12 Procedures Review
Board through October 2003

*From the PBM/payer, this is the PBM/payer's unique identification of this

transaction.
*From Surescripts, this is Surescripts’ unique identification of this
transaction.
*This number is returned on a TA1 if an error occurs. Providing a unique
number will assist in resolving errors and tracking messages.
The TA1 segment will only be transmitted in the event of a header or trailer
ERROR.
TA1 segments should not be returned for accepted transactions. If there
are no errors at the envelope level (ISA, GS, GE, IEA segments) then TA1
segments should not be returned.
*Since these transactions are real time only, Surescripts does not use this
field to determine whether to create a TA1 acknowledgment.
0 No Acknowledgment Requested
1 Interchange Acknowledgment Requested (TA1)
M ISA15 I14 Interchange Usage Indicator ID 1/1
Code to indicate whether data enclosed by this interchange envelope is
test, production or information
P Production Data
T Test Data
Type is not applicable; the component element separator is a delimiter and
not a data element; this field provides the delimiter used to separate
component data elements within a composite data structure; this value
must be different than the data element separator and the segment
terminator.


Loop:
Level: Heading
Usage: Mandatory
Max Use: 1
Syntax Notes:
Semantic Notes:
Comments:
Notes: When sending a TA1, the GS segment is not required.

Des. Elements
HB Eligibility, Coverage or Benefit Information (271)
M GS02 142 Application Sender’s Code AN 2/15
Code identifying party sending transmission; codes agreed to by trading
partners
*From the PBM/payer to Surescripts, this is the PBM/payer's Participant ID.
M GS02 142 Application Sender’s Code AN 2/15
partners

*From the PBM/payer to Surescripts, this is the PBM/payer's Participant

ID.
Date expressed as CCYYMMDD where CC represents the first two digits
of the calendar year
HHMMSSD, or HHMMSSDD, where H = hours (00-23), M = minutes (00-
59), S = integer seconds (00-59) and DD = decimal seconds; decimal
seconds are expressed as follows: D = tenths (0-9) and DD = hundredths
(00-99)
The control number should be unique across all functional groups within
this transaction set.
*This number is returned on an AK102 of the 999 acknowledgment if an
error occurs. Providing a unique number will assist in resolving errors and
tracking messages.
standard
Code indicating the version, release, subrelease, and industry identifier of
the EDI standard being used, including the GS and GE segments; if code in
DE455 in GS segment is X, then in DE 480 positions 1-3 are the version
number; positions 4-6 are the release and subrelease, level of the version;
and positions 7-12 are the industry or trade association identifiers
(optionally assigned by user); if code in DE455 in GS segment is T, then
other formats are allowed.
005010X279A1
Draft Standards Approved for Publication by X12


Loop:
Level: Heading
Usage: Mandatory
Max Use: 9
Syntax Notes:
Semantic Notes:
Comments:
Notes: Use this control segment to mark the start of a transaction set. One ST segment exists for every
transaction set that occurs within a functional group.
Example: ST*271*0001*005010X279A1~

Elements
Use this code to identify the transaction set ID for the transaction set that
will follow the ST segment. Each X12 standard has a transaction set
identifier code that is unique to that transaction set.
271 Eligibility, Coverage or Benefit Information
The transaction set control numbers in ST02 and SE02 must be identical.
This unique number also aids in error resolution research. Start with a
number, for example “0001”, and increment from there. This number must
be unique within a specific group and interchange, but can repeat in other
groups and interchanges.
*This number is returned on an AK202 of the 999 acknowledgment if an
error occurs. Providing a unique number will assist in resolving errors and
tracking messages.


implementation reference specified in the GS08 This element must be
This element contains the same value as GS08. Some translator products
strip off the ISA and GS segments prior to application (ST/SE) processing.
Providing the information from the GS08 at this level will ensure that the
appropriate application mapping is utilized at translation time.

271 Segment: BHT Beginning of Hierarchical Transaction

Loop:
Level: Heading
Usage: Mandatory
Max Use: 1
Purpose: To define the business hierarchical structure of the transaction set and identify the
business application purpose and reference data, i.e., number, date, and time
Syntax Notes:
Semantic Notes:
1 BHT03 is the number assigned by the originator to identify the transaction within the
originator’s business application system.
2 BHT04 is the date the transaction was created within the business application system.
3 BHT05 is the time the transaction was created within the business application system.
Comments:
Notes: Use this required segment to start the transaction set and indicate the sequence of the
hierarchical levels of information that will follow in Table 2.
Example: BHT*0022*11*199800114000001*19980101*1401~

Elements
M BHT01 1005 Hierarchical Structure Code ID 4/4
Code indicating the hierarchical application structure of a transaction set
that utilizes the HL segment to define the structure of the transaction set
Use this code to specify the sequence of hierarchical levels that may
appear in the transaction set. This code only indicates the sequence of the
levels, not the requirement that all levels be present. For example, if code
“0022” is used, the dependent level may or may not be present for each
subscriber.
0022 Information Source, Information Receiver, Subscriber,
Dependent
M BHT02 353 Transaction Set Purpose Code ID 2/2
Code identifying purpose of transaction set
11 Response
M BHT03 127 Reference Identification AN 1/50


*Because this Implementation is Real Time, this number from the 270 is to
be returned in this field.
M BHT04 373 Date DT 8/8
Use this date for the date the transaction set was generated.
M BHT05 337 Time TM 4/8
(00-99)
Use this time for the time the transaction set was generated.

271 Segment: HL Information Source Level (PBM/Payer)

Loop: 2000A
Level: Detail
Usage: Mandatory
Max Use: 1
segments
Comments:
Notes: Example: HL*1**20*1~

Des. Elements
20 Information Source
Identifies the payer, maintainer, or source of the information
Structure.

271 Segment: AAA Request Validation

Position: 025
Loop: 2000A
Level: Detail
Usage: Situational
Max Use: 9
Purpose: To specify the validity of the request and indicate follow-up action authorized
Syntax Notes:
Semantic Notes:
1 AAA01 designates whether the request is valid or invalid. Code “Y” indicates that the
code is valid; code “N” indicates that the code is invalid.
Comments:
1 If AAA02 is used, AAA03 contains a code from an industry code list.
Notes: Use this segment when a request could not be processed at a system or
application level and to indicate what action the originator of the request
transaction should take.
Use of this segment at this location in the HL is to identify reasons why a request
cannot be processed based on the entities identified in ISA06, ISA08, GS02 or
GS03.
Example: AAA*Y**42*Y~

Elements
M AAA01 1073 Yes/No Condition or Response Code ID 1/1
Code indicating a Yes or No condition or response
N No
Use this code to indicate that the request or an element in the
request is not valid. The transaction has been rejected as
identified by the code in AAA03.
Y Yes
Use this code to indicate that the request is valid, however the
transaction has been rejected as identified by the code in
AAA03.
M AAA03 901 Reject Reason Code ID 2/2
Code assigned by issuer to identify reason for rejection

Use this code to indicate the reason why the transaction was unable to be
processed successfully by the entity identified in either ISA08 or GS03.
04 Authorized Quantity Exceeded
Use this code to indicate that the transaction exceeds the
number of patient requests allowed by the entity identified in
either ISA08 or GS03. See the X12 Implementation Guide
(Section 1.4.3 Batch and Real Time) for more information
regarding the number of patient requests allowed in a
transaction. This is not to be used to indicate that the number of
patient requests exceeds the number allowed by the Information
Source identified in Loop 2100A.
41 Authorization/Access Restrictions
Use this code to indicate that the entity identified in GS02 is not
authorized to submit 270 transactions to the entity identified in
either ISA08 or GS03. This is not to be used to indicate
Authorization/Access Restrictions as related to the Information
Source Identified in Loop 2100A.
42 Unable to Respond at Current Time
Use this code to indicate that the entity identified in either ISA08
or GS03 is unable to process the transaction at the current time.
This indicates that there is a problem within the systems of the
entity identified in either ISA08 or GS03 and is not related to any
problem with the Information Source Identified in Loop 2100A.
*Note: Surescripts could not process the transaction.
79 Invalid Participant Identification
Use this code to indicate that the value in either GS02 or GS03
is invalid.
M AAA04 889 Follow-up Action Code ID 1/1
Code identifying follow-up actions allowed
Use this code to instruct the recipient of the 271 about what action needs
to be taken, if any, based on the validity code and the reject reason code (if
applicable).
C Please Correct and Resubmit
N Resubmission Not Allowed
P Please Resubmit Original Transaction
R Resubmission Allowed
S Do Not Resubmit; Inquiry Initiated to a Third Party
Y Do Not Resubmit; We Will Hold Your Request and Respond
Again Shortly

271 Segment: NM1 Information Source Name

Loop: 2100A
Level: Detail
Usage: Mandatory
Max Use: 1
Syntax Notes:

Semantic Notes:
Notes: Use this segment to identify an entity by name and/or identification number.
This NM1 loop is used to identify the eligibility or benefit information source
(e.g., insurance company, HMO, IPA, employer).
Example: NM1*2B*2*PBM NAME*****PI*87728~

Elements
individual
2B Third-Party
Administrator
(Recommended by
Surescripts)
organization.
1 Person
2 Non-Person Entity
(Recommended by
Surescripts)
M NM103 1035 Organization Name AN 1/60

* This will contain the actual source of the information (The PBM). It does
not include Surescripts at any point.
* Surescripts will utilize PI to identify the Payer (The PBM).
PI Payer Identification
(Recommended by
Surescripts)
Use this code for the reference number as qualified by the preceding data
element (NM108).
* This is the PBM’s Participant ID.

271 Segment: AAA Request Validation

Position: 085
Loop: 2100A
Level: Detail
Usage: Situational
Max Use: 9
Syntax Notes:
Semantic Notes:
Comments:
Notes: Use this segment when a request could not be processed at a system or application level and to
indicate what action the originator of the request transaction should take.
Use this segment to indicate problems in processing the transaction specifically related to the
information source data contained in the original 270 transaction’s information source name loop
(Loop 2100A) or to indicate that the information source itself is experiencing system problems.
Example: AAA*Y**42*Y~

Elements
N No
Y Yes
Use this code to indicate that the request is valid, however
the transaction has been rejected as identified by the code in
AAA03.

Use this code for the reason why the transaction was unable to be
processed successfully. This may indicate problems with the system, the
application, or the data content.
04 Authorized Quantity Exceeded
Use this code to indicate that the transaction exceeds the
number of patient requests allowed by the Information Source
identified in Loop 2100A. See the X12 Implementation Guide
(Section 1.4.3 Batch and Real Time) for more information
regarding the number of patient requests allowed in a
transaction.
Use this code to indicate that the entity identified in ISA06 or
GS02 is not authorized to submit 270 transactions to the
Information Source Identified in Loop 2100A.
*For the Physician System (from Surescripts), 41 would
indicate that the Physician System cannot request
transactions for the identified PBM.
*For Surescripts (from the PBM), 41 would indicate that
Surescripts cannot request eligibility from this PBM.
Use this code to indicate that Information Source Identified in
Loop 2100A is unable to process the transaction at the current
time. This indicates that there is a problem within the
Information Source’s system.
*PBM cannot process at current time.
* The PBM will use this code to indicate that Information
Source Identified in Loop 2100A is invalid.
80 No Response received – Transaction Terminated
Use this code only if the transaction is processed by a
clearing house, VAN, etc. Use this code to indicate that the
transaction was sent to the Information Source Identified in
Loop 2100A however no response was received in the
expected time frame.
This code must not be used by the Information source
identified in Loop 2100A.
T4 Payer Name or Identifier Missing
Use this code to indicate that either the name or identifier for
Information Source Identified in Loop 2100A is missing.

to be taken, if any, based on the validity code and the reject reason code
(if applicable).
P Please Resubmit Original Transaction
W Please Wait 30 Days and Resubmit
X Please Wait 10 Days and Resubmit
Again Shortly

271 Segment: HL Information Receiver Level (Physician)

Loop: 2000B
Level: Detail
Usage: Mandatory
Max Use: 1
segments.
Comments:
Notes: Example: HL*2*1*21*1~

Elements
Identification number of the next higher hierarchical data segment that
the data segment being described is subordinate to
21 Information Receiver
Identifies the provider or party(ies) who are the recipient(s) of
the information
Code indicating if there are hierarchical child data segments subordinate
to the level being described
Structure.

271 Segment: NM1 Information Receiver Name

Loop: 2100B
Level: Detail
Usage: Mandatory
Max Use: 1
Syntax Notes:

Semantic Notes:
Notes: Use this segment to identify an entity by name and/or identification number. This NM1 loop is
used to identify the eligibility/benefit information receiver (e.g., provider, medical group, IPA, or
hospital).
Example: NM1*1P*1*JONES*TIM****XX*111223333~

Elements
Code identifying an organizational entity, a physical location, property or
an individual
1P Provider (Recommended by Surescripts)
organization.
1 Person (Recommended by Surescripts)
2 Non-Person Entity
Use this name for the organization name if the entity type qualifier is a
non-person entity. Otherwise, this will be the individual’s last name.
Use this name if used in the search and NM102 is “1”.


Use this name only if available and NM102 is “1”.
Use name suffix only if available and NM102 is “1”; e.g., Sr., Jr., or III.
This is the number that the information source associates with the
information receiver.
XX Centers for Medicare and Medicaid Services National
Provider Identifier.
***The NPI is now mandated. Surescripts will only reject
if the NM108 and the NM109 are not populated.
Surescripts will not be validating the NPI, but some
payers may validate it.
element (NM108).

271 Segment: REF Information Receiver Additional Identification (Physician System

Identification)
Loop: 2100B
Level: Detail
Usage: Situational
Max Use: 9
Syntax Notes:
Comments:
Notes: *Surescripts defined Participant ID for the provider vendor.

Example: REF*EO*477563928~

Elements
following in REF02, REF03, or both.
EO Submitter Identification Number
*A unique number identifying the submitter of the transaction
set
*Qualifier to define this is a Physician System Participant ID.
Use this information for the reference number as qualified by the
preceding data element (REF01).
content
*Not Used for the EO qualifier.

271 Segment: AAA Information Receiver Request Validation

Loop: 2100B
Level: Detail
Usage: Situational
Max Use: 9
Syntax Notes:
Semantic Notes:
Comments:
information receiver data contained in the original 270 transaction’s information receiver name
loop (Loop 2100B).
Example: AAA*N**43*C~

Elements
N No
Use this code to indicate that the request or an element in
the request is not valid. The transaction has been rejected as
Y Yes
Use this code to indicate that the request is valid, however
the transaction has been rejected as identified by the code in
AAA03.

15 Required application data missing

Use this code only when the information receiver’s additional
identification is missing.
*Not enough information given to identify the Physician
System.
*A contract does not exist between this Physician System
and the PBM to exchange eligibility information.
43 Invalid/Missing Provider Identification (Surescripts
recommends this for NPI error.)
44 Invalid/Missing Provider Name
45 Invalid/Missing Provider Specialty
46 Invalid/Missing Provider Phone Number
47 Invalid/Missing Provider State
48 Invalid/Missing Referring Provider Identification Number
50 Provider Ineligible for Inquiries
51 Provider Not on File
Use this code only when the information receiver is not a
provider or payer.
*Surescripts cannot validate the receiver.
97 Invalid or Missing Provider Address
T4 Payer Name or Identifier Missing
Use this code only when the information receiver is a payer.
to be taken, if any, based on the validity code and the reject reason code
(if applicable).
Again Shortly

271 Segment: HL Subscriber Level

Loop: 2000C
Level: Detail
Usage: Situational
Max Use: 1
segments
Comments:
Notes: This segment is required if this loop is used.

Example: HL*3*2*22*0~

Des. Elements
Identification number of the next higher hierarchical data segment that the
data segment being described is subordinate to
22 Subscriber
Identifies the employee or group member who is covered for
insurance and to whom, or on behalf of whom, the insurer
agrees to pay benefits
Use the subscriber level to identify the insured or subscriber of
the health care coverage. This entity may or may not be the
actual patient.
Because of the hierarchical structure, the code value in the HL04 at the
Loop 2000C level should be “1” if a Loop 2000D level (dependent) is
associated with this subscriber. If no Loop 2000D level exists for this
subscriber, then the code value for HL04 should be “0” (zero).
0 No Subordinate HL Segment in This Hierarchical Structure.
Structure.

271 Segment: TRN Subscriber Trace Number

Loop: 2000C
Level: Detail
Usage: Situational
Max Use: 3
Purpose: To uniquely identify a transaction to an application
Syntax Notes:
Semantic Notes:
1 TRN02 provides unique identification for the transaction.
2 TRN03 identifies an organization.
3 TRN04 identifies a further subdivision within the organization.

Comments:
Notes: Required when the 270 request contained one or two TRN segments and the subscriber is the
patient. One TRN segment for each TRN submitted in the 270 must be returned.

Elements
M TRN01 481 Trace Type Code ID 1/2
Code identifying which transaction is being referenced
1 Current Transaction Trace Numbers
The term “Current Transaction Trace Numbers” refers to trace or
reference numbers assigned by the creator of the 271
transaction (the information source).
If a clearinghouse has assigned a TRN segment and intends on
returning their TRN segment in the 271 response to the
information receiver, they must convert the value in TRN01 to
“1” (since it will be returned by the information source as a “2”).
M TRN02 127 Reference Identification AN 1/50
M TRN03 509 Originating Company Identifier AN
10/10

A unique identifier designating the company initiating the funds transfer

instructions. The first character is one-digit ANSI identification code
designation (ICD) followed by the nine-digit identification number which
may be an IRS employer identification number (EIN), data universal
numbering system (DUNS), or a user assigned number; the ICD for an
EIN is 1, DUNS is 3, user assigned number is 9
If TRN01 is “2”, this is the value received in the original 270 transaction.
If TRN01 is “1”, use this information to identify the organization that
assigned this trace number.
The first position must be either a “1” if an EIN is used, a “3” if a DUNS is
used or a “9” if a user assigned identifier is used.
* In the 5010A1 Errata version the above requirement has been removed,
however is recommended to follow this rule for backwards compatibility.
O TRN04 127 Reference Identification AN 1/50
If TRN01 is “2”, this is the value received in the original 270 transaction.
If TRN01 is “1”, use this information if necessary to further identify a
specific component, such as a specific division or group of the entity
identified in the previous data element (TRN03).

271 Segment: NM1 Subscriber Name

Loop: 2100C
Level: Detail
Usage: Mandatory
Max Use: 1
Syntax Notes:

Semantic Notes:
used to identify the insured or subscriber.
* See the Patient Match Verification for more details.
Example: NM1*IL*1*SMITH*ROBERT*B***MI*33399999~

Elements
Code identifying an organizational entity, a physical location, property or
an individual
IL Insured or Subscriber
1 Person
Use this name for the subscriber’s last name.
Required unless a rejection response is generated and this element was
not valued in the request.
*This data is to be returned from the PBM/payer system.

Use this name for the subscriber’s first name.

Required when NM102 = 1 (Person) and the person has a first name
unless a rejection response is generated and this element was not valued
in the request. *This data is to be returned from the PBM/payer system.
Use this name for the subscriber’s middle name or initial. Required when
NM102 is “1" and the Last Name in NM103 and First Name in NM104 are
not sufficient to identify the individual. If not required by this
implementation guide, may be provided at sender’s discretion, but cannot
be required by the receiver.
Use this for the suffix to an individual’s name; e.g., Sr., Jr., or III.
Use if available.
This is the primary number that the information source associates with
the subscriber.
MI Member Identification Number
This code may only be used prior to the mandated use of code
“II”. This is the unique number the payer or information source
uses to identify the insured (e.g., Health Insurance Claim
Number, Medicaid Recipient ID Number, HMO Member ID,
etc.).
element (NM108).
*Subscriber PBM Unique Member ID.


Loop: 2100C
Level: Detail
Usage: Situational
Max Use: 9
Syntax Notes:
Notes: Required when the 270 request contained a REF segment with a Patient Account Number in Loop
2100C/REF02 with REF01 equal EJ;
OR
Required when the 270 request contained a REF segment and the information provided in that
REF segment was used to locate the individual in the information source’s system (See Section
1.4.7).
Example: REF*SY*SOCSEC126329818~
REF*HJ*CARDID23111 ~
REF*49*01~

Elements
49 Family Unit Member
(*Person Code)
SY Social Security Number
The social security number may not be used for any Federally
administered programs such as Medicare.
EJ Patient Account Number
HJ HJ Identity Card Number
Use this code when the Identity Card Number is
different than the Member Identification Number.
This is particularly prevalent in the Medicaid
environment. HJ is for the cardholder ID.


Use this information for the reference number as qualified by the preceding
data element (REF01).
content

271 Segment: N3 Subscriber Address

Loop: 2100C
Level: Detail
Usage: Situational
Max Use: 1
Syntax Notes:
Semantic Notes:
Comments:
Notes: Required when the Subscriber is the patient or when the Information Source requires this
information to identify the Subscriber for subsequent EDI transactions, but not required if a
rejection response is generated and this segment was not sent in the request. If not required by
this implementation guide, may be provided at sender’s discretion but cannot be required by the
receiver.
Example: N3*15197 BROADWAY AVENUE*APT 215~

Des. Elements
Address information
*This data is to be returned from the PBM payer system.
Address information
Required if a second address line exists.

271 Segment: N4 Subscriber City/State/ZIP Code

Loop: 2100C
Level: Detail
Usage: Situational
Max Use: 1
Syntax Notes:
Semantic Notes:
Comments:
1 A combination of N401 through N404 may be adequate to specify a location.
2 State (N402) and Postal (N403) are required if city name (N401) is in the U.S. or
Canada.
Notes: Required when the Subscriber is the patient or when the Information Source requires this
information to identify the Subscriber for subsequent EDI transactions, but not required if a
rejection response is generated and this segment was not sent in the request. If not required by
this implementation guide, may be provided at sender’s discretion but cannot be required by the
receiver.

Elements
Use this text for the city name of the subscriber’s address.
agency
territories, or Canada, or when a postal code exists for the country in N404.


territories, or Canada. If not required by this implementation guide, do not
send.
Use this code to specify the country of the subscriber’s address, if other
than the United States.
* Do not send the US Country Code

271 Segment: AAA Subscriber Request Validation

Loop: 2100C
Level: Detail
Usage: Situational
Max Use: 9
Syntax Notes:
Semantic Notes:
Comments:
data contained in the original 270 transaction’s subscriber name loop (Loop 2100C).

Elements
N No
request is not valid. The transaction has been rejected as identified
by the code in AAA03.
Y Yes
transaction has been rejected as identified by the code in AAA03.


*At Surescripts – Not enough information for Surescripts to identify
patient.
*At PBM –wants more info than what was supplied.
35 Out of Network
Use this code in a batch environment where an information source
returns all requests from the 270 in the 271 and identifies “Unable
to Respond at Current Time” for each individual request
(subscriber or dependent) within the transaction that they were
unable to process for reasons other than data content (such as
their system is down or timed out when generating a response).
43 Invalid/Missing Provider Identification
45 Invalid/Missing Provider Specialty
47 Invalid/Missing Provider State
48 Invalid/Missing Referring Provider Identification
Number
49 Provider is Not Primary Care Physician
51 Provider Not on File
52 Service Dates Not Within Provider Plan Enrollment
56 Inappropriate Date
57 Invalid/Missing Date(s) of Service
58 Invalid/Missing Date-of-Birth
60 Date of Birth Follows Date(s) of Service
61 Date of Death Precedes Date(s) of Service
62 Date of Service Not Within Allowable Inquiry Period
63 Date of Service in Future
71 Patient Birth Date Does Not Match That for the Patient
on the Database
72 Invalid/Missing Subscriber/Insured ID
73 Invalid/Missing Subscriber/Insured Name
74 Invalid/Missing Subscriber/Insured Gender Code
75 Subscriber/Insured Not Found
76 Duplicate Subscriber/Insured ID Number
78 Subscriber/Insured Not in Group/Plan Identified

applicable).
Use only when AAA03 is “42”.
Y Do Not Resubmit; We Will Hold Your Request and
Respond Again Shortly
Use only when AAA03 is “42”.

271 Segment: DMG Subscriber Demographic Information

Loop: 2100C
Level: Detail
Usage: Situational
Max Use: 1
Purpose: To supply demographic information
Syntax Notes:
1 If either DMG01 or DMG02 is present, then the other is required.

Semantic Notes:
1 DMG02 is the date of birth.

Comments:
Notes: Use this segment to convey the birth date or gender demographic information for the subscriber.
Use this segment only if the subscriber is the patient and if this information is available from the
Information Source’s database unless a rejection response is generated and the elements were
*See the Patient Match Verification for more details.
Example: DMG*D8*19430917*M~

Elements
O DMG01 1250 Date Time Period Format Qualifier ID 2/3
Use this code to indicate the format of the date of birth that follows in
DMG02.
O DMG02 1251 Date Time Period AN 1/35
Use this date for the date of birth of the individual.
Required if this is available from the Information Source’s database unless
a rejection response is generated and this element was not valued in the
request.
O DMG03 1068 Gender Code ID 1/1

Code indicating the sex of the individual

Required if this is available from the Information Source’s database unless
a rejection response is generated and this element was not valued in the
request.
F Female
M Male
U Unknown

271 Segment: INS Subscriber Relationship

Loop: 2100C
Level: Detail
Usage: Situational
Max Use: 1
Purpose: To provide benefit information on insured entities
Syntax Notes:
Semantic Notes:
1 INS01 indicates status of the insured. A “Y” value indicates the insured is a subscriber:
an “N” value indicates the insured is a dependent.
Comments:
Notes: Required when acknowledging a change in the identifying elements for the subscriber from
those submitted in the 270 or the Birth Sequence Number submitted in INS17 of the 270 was
used to locate the Subscriber.
Example: INS*Y*18*001*25~
*Surescripts only uses this segment to indicate if any of the identifying elements for the
subscriber have been changed from those submitted in the 270.
If the INS segment student status and handicap status are used it will be rejected.

Elements
M INS01 1073 Yes/No Condition or Response Code ID 1/1
* For the Physician System, this will always be Yes (if supplied).
Y Yes ID 2/2
M INS02 1069 Individual Relationship Code
Code indicating the relationship between two individuals or entities
* For the Physician System, this will always be Self (18).
18 Self
O INS03 875 Maintenance Type Code ID 3/3
Code identifying the reason for the maintenance change

Use this element (and code “001” in INS03) if any of the identifying
elements for the subscriber have been changed from those submitted in the
270.
001 Change
O INS04 1203 Maintenance Reason Code ID 2/3
Code identifying the reason for the maintenance change
Use this element (and code “001” in INS03) if any of the identifying
elements for the subscriber have been changed from those submitted in the
270.
25 Change in Identifying Data Elements
Use this code to indicate that a change has been made to the
primary elements that identify a specific person. Such elements
are first name, last name, date of birth, identification numbers, and
address.


Loop: 2100C
Level: Detail
Usage: Situational
Max Use: 9
Purpose: To specify any or all of a date, a time, or a time period
Syntax Notes:
Semantic Notes:
Comments:
Notes: Use this segment to convey any relevant dates. The dates represented may be in the past, the
current date, or a future date. The dates may also be a single date or a span of dates. Which
date(s) to use is determined by the format qualifier in DTP02.
When using code “291” (Plan) at this level, it is implied that these dates apply to all of the
Eligibility or Benefit Information (EB) loops that follow.
Example: DTP*291*D8*19950818~

Elements
291 Plan
Use this code to specify the format of the date(s)/time(s) that follow in the
next data element.
*Surescripts is recommending D8
RD8 Range of Dates express in Format CCYYMMDD-
CCYYMMDD

271 Segment: EB Subscriber Eligibility or Benefit Information

Loop: 2110C1
Level: Detail
Usage: Situational
Max Use: 1
Purpose: To supply eligibility or benefit information
Syntax Notes:
1 If either EB09 or EB10 is present, then the other is required.

Semantic Notes:
Comments:
Notes: Required when the subscriber is the person whose eligibility or benefits are being described and
the transaction is not rejected or if the transaction needs to be rejected in this loop. If not
required by this implementation guide, do not send.
Use this segment to begin the eligibility/benefit information looping structure. The EB segment
is used to convey the specific eligibility or benefit information for the entity identified.
If the transaction is rejected, and the MESSAGE field is utilized in the EB segment, then the
segment will exist with a V- Cannot process, and the associated message.
Example: EB*1**30**HEALTH PLAN NAME~

Elements
M EB01 1390 Eligibility or Benefit Information ID 1/2
Code identifying eligibility or benefit information
1 Active Coverage
6 Inactive
*If the member is inactive, then no other EB loops are
required to be sent.
V Cannot Process
O EB03 1365 Service Type Code ID 1/2
30 Health Plan Benefit Coverage
O EB04 1336 Insurance Type Code ID 1/3

Code identifying the type of insurance policy within a specific insurance
program

Use if available.
* See X12 guide for additional qualifiers.
47 Medicare Secondary, Other Liability Insurance is
Primary
CP Medicare Conditionally Primary
MC Medicaid
MP Medicare Primary
OT Other (Used for Medicare Part D)
O EB05 1204 Plan Coverage Description AN 1/50
A description or number that identifies the plan or coverage
This element is to be used only to convey the specific product name or
special program name for an insurance plan. For example, if a plan has a
brand name, such as “Gold 1-2-3", the name may be placed in this element.
This element must not be used to give benefit details of a plan.
Required when a specific Plan Name exists for the plan which the individual
has coverage in conjunction with the 2110C loop with EB01 Status = 1, 2, 3,
4, 5, 6, 7 or 8 and EB03 Service Type Code = 30 (See Section 1.4.7 in the
X12 Guide).
*The health plan name for patients that are eligible should be sent at this
level.
*Surescripts requires applications display this if sent.
O EB07 782 Monetary Amount R 1/18
Monetary amount
INDUSTRY: Benefit Amount
Use this monetary amount as qualified by EB01.
Use if eligibility or benefit must be qualified by a monetary amount;
e.g., deductible, copayment.
* Surescripts is utilizing this field for Out of Pocket Accumulator. EB01 set
to G.


Loop: 2110C1
Level: Detail
Usage: Situational
Max Use: 9
Syntax Notes:
2 Group number (6P) refers to the prescription benefit coverage Group ID (which is
typically 15 charters or less), not the Member Plan Group ID Number that refers to
Medical, Dental, etc. coverage.
Comments:
Notes: Example:
REF*18*PLAN ID~
REF*6P*GROUP NUMBER*GROUP NAME~
REF*ALS*ALTERNATIVE ID~
REF*CLI*COVERAGEID~
REF*FO*FORMULARYID~
REF*IG*COPAYID~
REF*N6*BIN*PCN~

Elements
M REF01 128 Code qualifying the Reference Identification
18 Plan ID
6P Group Number
ALS Alternate List ID
CLI Coverage List ID
FO Drug Formulary Number ID
IG Insurance Policy Number (*Copay ID)-
N6 Plan Network ID (*BIN/PCN)
*Strongly recommended by Surescripts.


Use this information for the reference number as qualified by the preceding
data element (REF01).
A free-form description to clarify the related data elements and their content
*This element should only be used for Group Name and/or PCN number.
REF01=6P, This is the group name.
REF01=N6, This is the PCN Number
271 Segment: DTP Subscriber Eligibility/Benefit Date

Loop: 2110C1
Level: Detail
Usage: Situational
Max Use: 20

Syntax Notes:
Semantic Notes:
Comments:
Notes: *Surescripts recommends sending back the date range of the health plan benefit for this patient’s
coverage.
When using the DTP segment in the 2110C loop this date applies only to the 2110C Eligibility or
Benefit Information (EB) loop in which it is located.
If a DTP segment with the same DTP01 value is present in the 2100C loop, the date is overridden
for only this 2110C Eligibility or Benefit Information (EB) loop.
Example: DTP*291*RD8*20100101-20101231~


Elements
291 Plan
next data element.
CCYYMMDD
*Surescripts is recommending RD8


Loop: 2110C1
Level: Detail
Usage: Situational
Max Use: 9
Syntax Notes:
Semantic Notes:
1 AAA01 designates whether the request is valid or invalid. Code "Y" indicates that the
code is valid; code "N" indicates that the code is invalid.
Comments:
Use this segment to indicate problems in processing the transaction specifically related to
specific eligibility/benefit inquiry data contained in the original 270 transaction's subscriber
eligibility/benefit inquiry information loop (Loop 2110C).

Elements
N No
request is not valid. The transaction has been rejected as identified
by the code in AAA03.
Y Yes
transaction has been rejected as identified by the code in AAA03.


33 Input Errors
Use this code only when data is present in this transaction and no
other Reject Reason Code is valid for describing the error. Detail of
the error must be supplied in the MSG segment of the 2110C loop
containing this Reject Reason Code.
53 Inquired Benefit Inconsistent with Provider Type
54 Inappropriate Product/Service ID Qualifier
55 Inappropriate Product/Service ID
69 Inconsistent with Patient's Age
70 Inconsistent with Patient's Gender
See X12 guide for additional codes.
applicable).

271 Segment: MSG Message Text

Loop: 2110C1
Level: Detail
Usage: Situational
Max Use: 10
Purpose: To provide a free-form format that allows the transmission of text information
Syntax Notes:
1 If MSG03 is present, then MSG02 is required.

Semantic Notes:
1 MSG03 is the number of lines to advance before printing.

Comments:
1 MSG02 is not related to the specific characteristics of a printer, but identifies top of
page, advance a line, etc.
2 If MSG02 is "AA - Advance the specified number of lines before print" then MSG03 is
required.
Notes: *This free text field will be populated by Surescripts as a hint to the requester on what fields
would assist in identifying the patient. This is sent if patient is not found and one or more of the
following fields are missing; first name, last name, zip code or date of birth.
Under no circumstances can an information source use the MSG segment to relay information
that can be sent using codified information in existing data elements (including combinations of
multiple data elements and segments).
Example: MSG*Unable to find patient in Surescripts system. Supplying some of these fields will
help find a match: patient zip code~

Elements
M MSG01 933 Free-Form Message Text AN
1/264
Free-form message text

271 Segment: LS Loop Header

Loop: 2110C1
Level: Detail
Usage: Situational
Max Use: 1
Purpose: To indicate that the next segment begins a loop.
Notes: Use this segment to identify the beginning of the Subscriber Benefit Related Entity Name loop.
Because both the subscriber’s name loop and this loop begin with NM1 segments, the LS and
LE segments are used to differentiate these two loops. Required if Loop 2120C is used.
Example: LS*2120~

Elements
M LS01 447 Loop Identifier Code AN 1/4
The loop ID number given on the transaction set diagram is the value for
this data element in segments LS and LE
This data element must have the value of “2120".

271 Segment: NM1 Subscriber Benefit Related Entity Name

Loop: 2120C1
Level: Detail
Usage: Situational
Max Use: 1
Syntax Notes:

Semantic Notes:
used to identify a provider (such as the primary care provider), an individual, another payer, or
another information source when applicable to the eligibility response.
Example: NM1*SEP*2*SECONDARY PAYER NAME*****PI*PAYERPARTID~

Elements
individual
PRP Primary Payer
SEP Secondary Payer
TTP Tertiary Payer
1 Person
2 Non-Person Entity
*Surescripts recommends using 2
Use this name for the organization name if the entity type qualifier is a non-
person entity. Otherwise, this will be the individual’s last name.

Required when NM102 is “1" and NM103 is used. If not required by this
Use this name only if available and NM102 is "1".
Use name suffix only if available and NM102 is "1"; e.g., Sr., Jr., or III.
element (NM108).

271 Segment: LE Loop Trailer

Loop: 2110C1
Level: Detail
Usage: Situational
Max Use: 1
Purpose: To indicate that the loop immediately preceding this segment is complete.
Syntax Notes:
Semantic Notes:
Comments:
Notes: Use this segment to identify the end of the Subscriber Benefit Related Entity Name loop.
See X12 guide.
Example: LE*2120~

Elements
M LE01 447 Loop Identifier Code AN 1/4
Example: LE*2120~

271 Segment: EB Subscriber Eligibility or Benefit Information

Loop: 2110C2-5
Level: Detail
Usage: Situational
Max Use: 1 (Loop Repeats >0
Purpose: To supply eligibility or benefit information
Syntax Notes:
1 If either EB09 or EB10 is present, then the other is required.

Semantic Notes:
1 EB01 qualifies EB06 through EB10.
Notes: Required when the subscriber is the person whose eligibility or benefits are being described and
the transaction is not rejected or if the transaction needs to be rejected in this loop. If not
required by this implementation guide, do not send.
See X12 Guide. Use this segment to begin the eligibility/benefit information looping structure.
The EB segment is used to convey the specific eligibility or benefit information for the entity
identified.
*If the previous EB loop – EB 30 was set to 6 for not active, then no other EB loops are required.
Example:
EB*1**88**RETAIL HEALTH PLAN NAME ~
EB*1**90**MAIL ORDER HEALTH PLAN NAME ~
EB*1****SPECIALTY HEALTH PLAN NAME ~
MSG*SPECIALTY PHARMACY~
EB*1****LTC HEALTH PLAN NAME ~
MSG*LTC~

Elements
M EB01 1390 Eligibility or Benefit Information
Code identifying eligibility or benefit information
Use this code to identify the eligibility or benefit information. This may be
the eligibility status of the individual or the benefit related category that is
being further described in the following data elements. This data element
also qualifies the data in elements EB06 through EB10.
* Surescripts is utilizing 1, G, I.
1 Active Coverage
*Covered

G Out of Pocket (Stop Loss)

I Non-Covered
O EB03 1365 Service Type Code ID 1/2
Code identifying the classification of service
88 Pharmacy (*Retail Benefit)
90 Mail Order Prescription Drug
Empty/Null Specialty Pharmacy or LTC (See MSG
segment)
EB03 is a repeating data element that may be repeated up to 99 times. If
all of the information that will be used in the 2110C loop is the same with
the exception of the Service Type Code used in EB03, it is more efficient
to use the repetition function of EB03 to send each of the Service Type
Codes needed. If an Information Source supports responses with multiple
Service Type Codes, the repetition use of EB03 must be supported if all
other elements in the 2110C loop are identical.
O EB04 1336 Insurance Type Code ID 1/3
Code identifying the type of insurance policy within a specific insurance
program
Use if available.
* See X12 guide for additional qualifiers.
47 Medicare Secondary, Other Liability Insurance
is Primary
CP Medicare Conditionally Primary
MC Medicaid
MP Medicare Primary
OT Other (Used for Medicare Part D)
O EB05 1204 Plan Coverage Description AN 1/50
A description or number that identifies the plan or coverage
See X12 guide. This element is to be used only to convey the specific
product name or special program name for an insurance plan. For
example, if a plan has a brand name, such as “Gold 1-2-3", the name may
be placed in this element. This element must not be used to give benefit
details of a plan.
O EB07 782 Monetary Amount R 1/18
Monetary amount
INDUSTRY: Benefit Amount
Use this monetary amount as qualified by EB01.
Use if eligibility or benefit must be qualified by a monetary amount;
e.g., deductible, copayment.
* Surescripts is utilizing this field for Out of Pocket Accumulator. EB01
set to G.


Loop: 2110C2-5
Level: Detail
Usage: Situational
Max Use: 20

Syntax Notes:
Semantic Notes:
Comments:
Notes: *Surescripts recommends sending back the date range of the health plan benefit for this patient’s
coverage.
When using the DTP segment in the 2110C loop this date applies only to the 2110C Eligibility or
Benefit Information (EB) loop in which it is located.
If a DTP segment with the same DTP01 value is present in the 2100C loop, the date is overridden
for only this 2110C Eligibility or Benefit Information (EB) loop.
See X12 guide.

Example: DTP*291*RD8*20100101-20101231~

Elements
291 Plan
next data element.


CCYYMMDD
*Surescripts is recommending RD8


Loop: 2110C2-5
Level: Detail
Usage: Situational
Max Use: 9
Syntax Notes:
Semantic Notes:
1 AAA01 designates whether the request is valid or invalid. Code "Y" indicates that the
code is valid; code "N" indicates that the code is invalid.
Comments:
Use this segment to indicate problems in processing the transaction specifically related to
specific eligibility/benefit inquiry data contained in the original 270 transaction's subscriber
eligibility/benefit inquiry information loop (Loop 2110C).

Elements
N No
Y Yes
Use this code to indicate that the request is valid; however, the
transaction has been rejected as identified by the code in
AAA03.

33 Input Errors
Use this code only when data is present in this transaction and no
other Reject Reason Code is valid for describing the error. Detail
of the error must be supplied in the MSG segment of the 2110C
loop containing this Reject Reason Code.
53 Inquired Benefit Inconsistent with Provider Type
54 Inappropriate Product/Service ID Qualifier
55 Inappropriate Product/Service ID
69 Inconsistent with Patient's Age
70 Inconsistent with Patient's Gender
See X12 guide for additional codes.
applicable).

271 Segment: MSG Message Text

Loop: 2110C2-5
Level: Detail
Usage: Situational
Max Use: 10
Purpose: To provide a free-form format that allows the transmission of text information
Syntax Notes:
1 If MSG03 is present, then MSG02 is required.

Semantic Notes:
1 MSG03 is the number of lines to advance before printing.

Comments:
1 MSG02 is not related to the specific characteristics of a printer, but identifies top of
page, advance a line, etc.
2 If MSG02 is "AA - Advance the specified number of lines before print" then MSG03 is
required.
Notes: *This free text is used for Specialty Pharmacy and LTC since there is not a service type code
available to use. The text SPECIALTY PHARMACY will indicate this EB loop is for Specialty
Pharmacy and the text LTC will indicate this is for Long Term Care.
Under no circumstances can an information source use the MSG segment to relay information
that can be sent using codified information in existing data elements.
See X12 guide.
Example: MSG*SPECIALTY PHARMACY~
MSG*LTC~

Elements
M MSG01 933 Free-Form Message Text AN
1/264
Free-form message text

271 Segment: LS Loop Header

Loop: 2110C2-5
Level: Detail
Usage: Situational
Max Use: 1
Purpose: To indicate that the next segment begins a loop.
Notes: Use this segment to identify the beginning of the Subscriber Benefit Related Entity Name loop.
See X12 guide.
Example: LS*2120~

Des. Elements
M LS01 447 Loop Identifier Code AN 1/4

271 Segment: NM1 Subscriber Benefit Related Entity Name

Loop: 2120C2-5
Level: Detail
Usage: Situational
Max Use: 1
Syntax Notes:

Semantic Notes:
used to identify a provider (such as the primary care provider), an individual, another payer, or
another information source when applicable to the eligibility response.
See X12 guide.
Example: NM1*SEP*2*SECONDARY PAYER NAME*****PI*PAYERPARTID~
Example: NM1*13*2*PHARMACY ABC*****SV*NCPDPID~

Elements
Code identifying an organizational entity, a physical location,
property or an individual
13 Contracted Service Provider
* Use for Mail Only Benefit. Used to further clarify
benefits, including Mail Only, Specialty and Long Term
Care.
PRP Primary Payer
SEP Secondary Payer
TTP Tertiary Payer
1 Person
2 Non-Person Entity
*Surescripts recommends using 2


Use this name for the organization name if the entity type qualifier is a non-
person entity. Otherwise, this will be the individual’s last name.
Required when NM102 is “1" and NM103 is used. If not required by this
Use this name only if available and NM102 is "1".
Use name suffix only if available and NM102 is "1"; e.g., Sr., Jr., or III.
SV Service Provider Number (Recommended by Surescripts)
Use this code for the identification number assigned by the
information source.
element (NM108).

271 Segment: LE Loop Trailer

Loop: 2110C2-5
Level: Detail
Usage: Situational
Max Use: 1
Purpose: To indicate that the loop immediately preceding this segment is complete.
Syntax Notes:
Semantic Notes:
Comments:
See X12 guide.
Example: LE*2120~

Des. Elements
M LE01 447 Loop Identifier Code
The loop ID number given on the transaction set diagram is the value for this
data element in segments LS and LE
Example: LE*2120~


Loop:
Level: Summary
Usage: Mandatory
Max Use: 1
Syntax Notes:
Semantic Notes:
Comments:
Notes: Use this segment to mark the end of a transaction set and provide control information on the
total number of segments included in the transaction set.
Example: SE*52*0001~

Elements
Total number of segments included in a transaction set including ST and SE
segments
number, for example "0001", and increment from there. This number must
be unique within a specific functional group (segments GS through GE) and
interchange, but can repeat in other groups and interchanges.


Loop:
Level: Summary
Usage: Mandatory
Max Use: 1
Purpose: To indicate the end of a functional group and to provide control information
Syntax Notes:
Semantic Notes:
Comments:

Elements
data element


Loop:
Level: Summary
Usage: Mandatory
Max Use: 1
Syntax Notes:
Semantic Notes:
Comments:

Elements
Same control number as ISA13.

4.8 TA1 INTERCHANGE ACKNOWLEDGEMENT

ICS Interchange Control Structures
Introduction
The purpose of this standard is to define the control structures for the electronic interchange of one
or more encoded business transactions including the EDI (Electronic Data Interchange) encoded
transactions of Accredited Standards Committee X12. This standard provides the interchange
envelope of a header and trailer for the electronic interchange through a data transmission, and it
provides a structure to acknowledge the receipt and processing of this envelope.
Page Seg Name Req Max Loop

# ID Des Use Repeat
ISA Interchange Control Header M 1
TA1 Interchange Acknowledgment O 1
IEA Interchange Control Trailer M 1

Segment: ISA Interchange Control Header

Loop:
Level:
Usage: Mandatory
Max Use: 1
Syntax Notes:
Semantic Notes:
Comments:

Des. Elements
00 No Authorization Information Present (No Meaningful
Information in I02)
10/10
*Empty/Null
01 Password
10/10
*Password utilized by the sender to access the receiver system.
ZZ Mutually Defined
15/15

sender ID element
*The Sender Participant ID. Participant ID is the Surescripts system
Participant ID.
ZZ Mutually Defined
15/15
Identification code published by the receiver of the data; When sending, it is
used by the sender as their sending ID, thus other parties sending to them
will use this as a receiving ID to route data to them
*The Receiver Participant ID. Participant ID is assigned by Surescripts.
*Time format HHMM required.
occurrences of a simple data element or a composite data structure; this value
must be different than the data element separator, component element
separator, and the segment terminator
00501 Draft Standards for Trial Use Approved for Publication by X12
Procedures Review Board through October 2003
*A unique number assigned by the sender. Used to communicate from the
receiver back to the sender to identify this transaction.
* No TA1s are returned for TA1s


Code to indicate whether data enclosed by this interchange envelope is test,
production or information
P Production Data
T Test Data
component data elements within a composite data structure; this value must
be different than the data element separator and the segment terminator.

Segment: TA1 Interchange Acknowledgment

Loop:
Level:
Usage: Situational
Max Use: 1
Purpose: To report the status of processing a received interchange header and trailer or the non-
delivery by a network provider
Syntax Notes:
Semantic Notes:
Comments:
Notes: *Surescripts only supports the TA1 for errors. It is not sent as an acknowledgement for
successful messages.
All fields must contain data.
This segment acknowledges the reception of an X12 interchange header and trailer from a
previous interchange. If the header/trailer pair was received correctly, the TA1 reflects a valid
interchange, regardless of the validity of the contents of the data included inside the
header/trailer envelope.
Example: TA1*000000905*940101*0100*A*000~

Elements
M TA101 I12 Interchange Control Number N0 9/9
This number uniquely identifies the interchange data to the sender. It is
assigned by the sender. Together with the sender ID it uniquely identifies
the interchange data to the receiver. It is suggested that the sender,
receiver, and all third parties be able to maintain an audit trail of
interchanges using this number.
In the TA1, this should be the interchange control number of the original
interchange that this TA1 is acknowledging.
M TA102 I08 Interchange Date DT 6/6
This is the date of the original interchange being acknowledged. (YYMMDD)
M TA103 I09 Interchange Time TM 4/4
This is the time of the original interchange being acknowledged. (HHMM)

M TA104 I17 Interchange Acknowledgment Code ID 1/1

This indicates the status of the receipt of the interchange control structure
A The Transmitted Interchange Control Structure Header and
Trailer Have Been Received and Have No Errors.
E The Transmitted Interchange Control Structure Header and
Trailer Have Been Received and Are Accepted But Errors Are
Noted. This Means the Sender Must Not Resend This Data.
R The Transmitted Interchange Control Structure Header and
Trailer are Rejected Because of Errors.
M TA105 I18 Interchange Note Code ID 3/3
This numeric code indicates the error found processing the interchange
control structure
000 No error
001 The Interchange Control Number in the Header and
Trailer Do Not Match. The Value From the Header is
Used in the Acknowledgment.
002 This Standard as Noted in the Control Standards
Identifier is Not Supported.
003 This Version of the Controls is Not Supported
004 The Segment Terminator is Invalid
005 Invalid Interchange ID Qualifier for Sender
006 Invalid Interchange Sender ID
007 Invalid Interchange ID Qualifier for Receiver
008 Invalid Interchange Receiver ID
009 Unknown Interchange Receiver ID
010 Invalid Authorization Information Qualifier Value
011 Invalid Authorization Information Value
012 Invalid Security Information Qualifier Value
013 Invalid Security Information Value
014 Invalid Interchange Date Value
015 Invalid Interchange Time Value
016 Invalid Interchange Standards Identifier Value
017 Invalid Interchange Version ID Value
018 Invalid Interchange Control Number Value
019 Invalid Acknowledgment Requested Value
020 Invalid Test Indicator Value
021 Invalid Number of Included Groups Value
022 Invalid Control Structure
023 Improper (Premature) End-of-File (Transmission)

024 Invalid Interchange Content (e.g., Invalid GS

Segment)
025 Duplicate Interchange Control Number
026 Invalid Data Element Separator
027 Invalid Component Element Separator
028 Invalid Delivery Date in Deferred Delivery Request
029 Invalid Delivery Time in Deferred Delivery Request
030 Invalid Delivery Time Code in Deferred Delivery
Request
031 Invalid Grade of Service Code

Segment: IEA Interchange Control Trailer

Loop:
Level:
Usage: Mandatory
Max Use: 1
Syntax Notes:
Semantic Notes:
Comments:

Elements
A count of the number of functional groups included in an
interchange
Same control number as ISA13.

4.9 999 IMPLEMENTATION ACKNOWLEDGEMENT FOR HEALTH CARE

INSURANCE
Functional Group ID= FA
Introduction
Refer to the 005010X231A1 guide for purpose and scope of this transaction.
Heading:
Page Seg Name M/C Max Loop

# ID Use Repeat
Header
ISA Interchange Control Header M 1
GS Functional Group Header M 1
ST Transaction Set Header M 1
Detail
AK1 Functional Group Response Header M 1
LOOP ID - 2000 - AK2 TRANSACTION SET RESPONSE >1

HEADER
AK2 Transaction Set Response Header C 1
LOOP ID - 2100 - AK2/IK3 ERROR IDENTIFICATION >1

IK3 Error Identification C 1
IK4 Implementation Data Element Note C >1
IK5 Transaction Set Response Trailer M 1
AK9 Functional Group Response Trailer M 1
Trailer
SE Transaction Set Trailer M 1
GE Functional Group Trailer M 1
IEA Interchange Control Trailer M 1
Transaction Set Notes From the Standard
The 999 Acknowledgment shall not be acknowledged, thereby preventing an endless cycle of
acknowledgments of acknowledgments. Nor shall an Implementation Acknowledgment be sent to
report errors in a previous Implementation Acknowledgment.

There is only one Implementation Acknowledgment Transaction Set per acknowledged functional
group.
Only one acknowledgement should be generated for a functional group unless mutually agreed
upon.
AK1 is used to respond to the functional group header and to start the acknowledgment for a
functional group. There shall be one AK1 segment for the functional group that is being
acknowledged.
The Implementation Acknowledgement is generated at the point of translation, intended for the
originator (not any intermediate parties).
The Functional Group Header Segment (GS) is used to start the envelope for the Implementation
Acknowledgment Transaction Sets. In preparing the functional group of acknowledgments, the
application sender’s code and the application receiver’s code, taken from the functional group
being acknowledged, are exchanged; therefore, one acknowledgment functional group responds
to only those functional groups from one application receiver’s code to one application sender’s
code.
AK2 is used to start the acknowledgment of a transaction set within the received functional group.
The AK2 segments shall appear in the same order as the transaction sets in the functional group
that has been received and is being acknowledged.
The data segments of this standard are used to report the results of the syntactical analysis of the
functional groups of transaction sets; they report the extent to which the syntax complies with the
standards or proper subsets of transaction sets and functional groups as expressed in compliant
implementation guides. They do not report on the semantic meaning of the transaction sets (for
example, on the ability of the receiver to comply with the request of the sender).
The CTX Segment shall be used to disambiguate a reported error that is dependent on context.
If any implementation guide errors have been reported in IK3 or IK4, then code I5 shall be reported
in the IK5 Segment.


Loop:
Level:
Usage: Mandatory
Max Use: 1
Syntax Notes:
Semantic Notes:
Comments:

Des. Elements
00 No Authorization Information Present (No
Meaningful Information in I02)
10/10
01 Password
10/10
*Password used by the sender to access the receiver system. Password
assigned by Surescripts.
ZZ Mutually Defined


15/15
sender ID element
*From Surescripts to the PBM/payer, this is Surescripts’ ID.
ZZ Mutually Defined
15/15
Identification code published by the receiver of the data. When sending, it is
used by the sender as their sending ID, thus other parties sending to them
will use this as a receiving ID to route data to them
*Time format HHDD required.
occurrences of a simple data element or a composite data structure; this
value must be different than the data element separator, component element
separator, and the segment terminator.
00501 Draft Standards for Trial Use Approved for
Publication by X12 Procedures Review Board
through October 2003
*The sender’s unique identification of this transaction.
*No TA1s are returned for 999s

Code to indicate whether data enclosed by this interchange envelope is
test, production or information
P Production Data
T Test Data
component data elements within a composite data structure; this value
must be different than the data element separator and the segment
terminator.


Loop:
Level:
Usage: Mandatory
Max Use: 1
Syntax Notes:
Semantic Notes:
Comments:
Notes:

Des. Elements
FA Implementation Acknowledgment (999)
M GS02 142 Application Sender's Code AN 2/15
partners
*The Sender Participant ID. Participant ID is assigned by Surescripts.
M GS03 124 Application Receiver's Code AN 2/15
Code identifying party receiving transmission; codes agreed to by trading
partners


(00-99)
Use this time for the creation time. The recommended format is HHMM.
The control number should be unique across all functional groups within this
transaction set.
standard
Code indicating the version, release, subrelease, and industry identifier of
and positions 7-12 are the industry or trade association identifiers (optionally
assigned by user); if code in DE455 in GS segment is T, then other formats
are allowed
005010X231A1
Draft Standards Approved for Publication by ASC X12


Loop:
Level:
Usage: Mandatory
Max Use: 1
Syntax Notes:
Semantic Notes:
Comments:

Des. Elements
999 Implementation Acknowledgment
This unique number also aids in error resolution research. Start with the
number, for example "0001", and increment from there. This number must be
unique within a specific group and interchange, but can repeat in other
implementation reference specified in the GS08 This element must be
This element contains the same value as GS08. Some translator products
strip off the ISA and GS segments prior to application (ST/SE) processing.
Providing the information from the GS08 at this level will ensure that the
appropriate application mapping is utilized at translation time.

999 Segment: AK1 Functional Group Response Header

Loop:
Level:
Usage: Mandatory
Max Use: 1
Purpose: To start acknowledgment of a functional group
Syntax Notes:
Semantic Notes:
1 AK101 is the functional ID found in the GS segment (GS01) in the functional group
being acknowledged.
2 AK102 is the functional group control number found in the GS segment in the functional
group being acknowledged.
Comments:

Elements
M AK101 479 Functional Identifier Code ID 2/2
HB Eligibility, Coverage or Benefit Information (271)
HS Eligibility, Coverage or Benefit Inquiry (270)
M AK102 28 Group Control Number N0 1/9
Use the value in GS06 from the functional group to which this 999
transaction set is responding.
M AK103 480 Version / Release / Industry Identifier Code AN 1/12
A Code indicating the version, release, subrelease, and industry identifier of
and positions 7-12 are the industry or trade association identifiers (optionally
assigned by user); if code in DE455 in GS segment is T, then other formats
are allowed
Use the value in GS08 from the functional group to which this 999
transaction set is responding.

Segment: AK2 Transaction Set Response Header

Loop: AK2
Level:
Usage: Situational
Max Use: 1
Purpose: To start acknowledgment of a single transaction set
Syntax Notes:
Semantic Notes:
1 AK201 is the transaction set ID found in the ST segment (ST01) in the transaction set
being acknowledged.
2 AK202 is the transaction set control number found in the ST segment in the transaction
set being acknowledged.
Notes: Required when an error is present in a transaction set contained in the functional group to which
this 999 transaction set is responding.
Comments:

Elements
M AK201 143 Transaction Set Identifier Code ID 3/3
270 Eligibility, Coverage or Benefit Inquiry
271 Eligibility, Coverage or Benefit Information
M AK202 329 Transaction Set Control Number AN 4/9
O AK203 329 Implementation Convention Reference AN 1/35
Required when the ST03 value is available in the transaction set to which
this 999 transaction set is responding.
*Since ST03 is required the AK203 must be present.

999 Segment: IK3 Error Identification

Loop: IK3
Level:
Usage: Situational
Max Use: 1
Purpose: To report errors in a data segment and identify the location of the data segment
Notes: Required when an error is present in the transaction set identified in this AK2
loop and the location of the data segment containing the error can be identified
by the submitter of this 999.

Elements
M IK301 721 Segment ID Code ID 2/3
Code defining the segment ID of the data segment in error (
M IK302 719 Segment Position in Transaction Set N0 1/10
The numerical count position of this data segment from the start of the
transaction set: the transaction set header is count position 1
O IK303 447 Loop Identifier Code AN 1/4
M IK304 620 Segment Syntax Error Code ID 1/3
Code indicating error found based on the syntax editing of a segment
1 Unrecognized segment ID
2 Unexpected segment
3 Mandatory segment missing
4 Loop Occurs Over Maximum Times
5 Segment Exceeds Maximum Use
6 Segment Not in Defined Transaction Set
7 Segment Not in Proper Sequence
8 Segment Has Data Element Errors

999 Segment: IK4 Implementation Data Element Note

Loop: IK3
Level:
Usage: Situational
Max Use: >1
Purpose: To report errors in a data element or composite data structure and identify the location of
the data element
Syntax Notes:
Semantic Notes:
1 In no case shall a value be used for AK404 that would generate a syntax error, e.g., an
invalid character.
Notes: Required when the error in the segment described in the IK3 segment applies to a
data element and the location of the data element containing the error can be
identified by the submitter of the 999.
Comments:

Elements
M IK401 C030 Position in Segment
Code indicating the relative position of a simple data element, or the
relative position of a composite data structure combined with the relative
position of the component data element within the composite data
structure, in error; the count starts with 1 for the simple data element or
composite data structure immediately following the segment ID.
M C03001 722 Element Position in Segment N0 1/2
This is used to indicate the relative position of a simple data element, or
the relative position of a composite data structure with the relative position
of the component within the composite data structure, in error; in the data
segment the count starts with 1 for the simple data element or composite
data structure immediately following the segment ID.
O C03002 1528 Component Data Element Position in Composite N0 1/2
To identify the component data element position within the composite that
is in error.
O IK402 725 Data Element Reference Number N0 1/4
Reference number used to locate the data element in the Data Element
Dictionary.
M IK403 621 Implementation Data Element Syntax Error Code ID 1/3

1 Mandatory data element missing

2 Conditional required data element missing.
3 Too many data elements.
4 Data element too short.
5 Data element too long.
6 Invalid character in data element.
7 Invalid code value.
8 Invalid Date
9 Invalid Time
10 Exclusion Condition Violated
O IK404 724 Copy of Bad Data Element AN 1/99
This is a copy of the data element in error

999 Segment: IK5 Implementation Transaction Set Response Trailer

Loop: AK2
Level:
Usage: Mandatory
Max Use: 1
Purpose: To acknowledge acceptance or rejection and report errors in a transaction set

Des. Elements
M IK501 717 Transaction Set Acknowledgment Code ID 1/1
A Accepted
E Accepted But Errors Were Noted
M Rejected, Message Authentication Code (MAC)
Failed
R Rejected
* Surescripts recommends R.
W Rejected, Assurance Failed Validity Tests
X Rejected, Content After Decryption Could Not Be
Analyzed
O IK502 618 Transaction Set Syntax Error Code ID 1/3
Code indicating error found based on the syntax editing of a transaction set
Required when IK501 = E or R. If not required by this implementation guide,
do not send.
1 Transaction Set Not Supported
2 Transaction Set Trailer Missing
3 Transaction Set Control Number in Header and
Trailer Do Not Match
4 Number of Included Segments Does Not Match
Actual Count
5 One or More Segments in Error
6 Missing or Invalid Transaction Set Identifier
7 Missing or Invalid Transaction Set Control Number
8 Authentication Key Name Unknown
9 Encryption Key Name Unknown
10 Requested Service (Authentication or Encrypted)
Not Available

11 Unknown Security Recipient

12 Incorrect Message Length (Encryption Only)
13 Message Authentication Code Failed
15 Unknown Security Originator
16 Syntax Error in Decrypted Text
17 Security Not Supported
19 S1E Security End Segment Missing for S1S
Security Start Segment
20 S1S Security Start Segment Missing for S1E
Security End Segment
23 Transaction Set Control Number Not Unique within
the Functional Group
I5 Implementation One or More Segments in Error
I6 Implementation Convention Not Supported
Same Codes as IK502
Same Codes as IK502
Same Codes as IK502
Same Codes as IK502

999 Segment: AK9 Functional Group Response Trailer

Loop:
Level:
Usage: Mandatory
Max Use: 1
Purpose: To acknowledge acceptance or rejection of a functional group and report the number of
included transaction sets from the original trailer, the accepted sets, and the received sets in this
functional group
Syntax Notes:
Semantic Notes:
Comments:
1 If AK901 contains the value "A" or "E", then the transmitted functional group is
accepted.

Elements
M AK901 715 Functional Group Acknowledge Code ID 1/1
A Accepted
E Accepted, But Errors Were Noted.
M Rejected, Message Authentication Code (MAC)
Failed
P Partially Accepted, At Least One Transaction Set
Was Rejected
R Rejected
*Surescripts recommends use of R.
W Rejected, Assurance Failed Validity Tests
X Rejected, Content After Decryption Could Not Be
Analyzed
M AK902 97 Number of Transaction Sets Included N0 1/6
data element
M AK903 123 Number of Received Transaction Sets N0 1/6
Number of Transaction Sets received
M AK904 2 Number of Accepted Transaction Sets N0 1/6
Number of accepted Transaction Sets in a Functional Group

O AK905 716 Functional Group Syntax Error Code ID 1/3

Code indicating error found based on the syntax editing of the functional
group header and/or trailer
1 Functional Group Not Supported
2 Functional Group Version Not Supported
3 Functional Group Trailer Missing
4 Group Control Number in the Functional Group
Header and Trailer Do Not Agree
5 Number of Included Transaction Sets Does Not
Match Actual Count
6 Group Control Number Violates Syntax
10 Authentication Key Name Unknown
11 Encryption Key Name Unknown
12 Requested Service (Authentication or Encryption)
Not Available
13 Unknown Security Recipient
14 Unknown Security Originator
15 Syntax Error in Decrypted Text
16 Security Not Supported
17 Incorrect Message Length (Encryption Only)
18 Message Authentication Code Failed
20 S1S Security Start Segment Missing for S1E End
Segment
24 S3S Security Start Segment Missing for S3E End
Segment
group header and/or trailer (Same codes as AK905)




Loop:
Level:
Usage: Mandatory
Max Use: 1
Syntax Notes:
Semantic Notes:
Comments:

Elements
Total number of segments included in a transaction set including ST and
SE segments
number, for example "0001", and increment from there. This number must
be unique within a specific group and interchange, but can repeat in other


Loop:
Level:
Usage: Mandatory
Max Use: 1
Purpose: To indicate the end of a functional group and to provide control information
Syntax Notes:
Semantic Notes:
Comments:

Elements
data element


Loop:
Level:
Usage: Mandatory
Max Use: 1
Syntax Notes:
Semantic Notes:
Comments:

Elements
Same control number as ISA13

4.10 270 AND 271 TRANSACTION EXAMPLES

This is an example of a prescriber/clinic checking a patient’s benefit plan. The lifecycle consists of:
l Prescriber System creates the 270 and sends to Surescripts.
l Surescripts identifies the patient and sends a 270 to the PBM/payer.
l The PBM/payer processes the 270 and returns a 271 to Surescripts.
l Surescripts returns the 271 to the Prescriber System.
Note: In the examples, line breaks are used at the end of the segments for display purposes –
live transactions should not contain line breaks.
Eligibility Request (from Prescriber System to Surescripts)

ISA*00* *01*PWPHY12345*ZZ*POCID
*ZZ*S00000000000001*091217*0309*^*00501*000000001*1*P*>~
GS*HS*POCID*S00000000000001*20091217*16150000*1*X*005010X279A1~
ST*270*0001*005010X279A1~
BHT*0022*13*3920394930203*20091217*16150000~
HL*1**20*1~
NM1*2B*2*SURESCRIPTS LLC*****PI*S00000000000001~
HL*2*1*21*1~
NM1*1P*1*JONSON*TIM*T**M.D.*XX*3334444555~
REF*EO*POCID~
N3*55 HIGH STREET~
N4*SEATTLE*WA*98123~
HL*3*2*22*0~
NM1*IL*1*CROSS*DAVID*M~
N3*6785 LAUGHALOT LANE~
N4*TRENTON*NJ*08608~
DMG*D8*19720910*M~
DTP*291*D8*20150206~
EQ*30~
SE*17*0001~
GE*1*1~
IEA*1*000000001~

Segment Value Note

ISA PWPHY12345 The Password needed to correspond with the Surescripts’ system.
ISA POCID The Physician System’s Participant ID.
ISA S00000000000001 Participant ID for Surescripts.
BHT 3920394930203 The Transaction reference number that ties the request to the response.
HL1:NM1 SURESCRIPTS LLC Source does not know PBM/payer so they put in Surescripts.
HL2:NM1 TIM JONSON Dr.’s Name.
HL2:NM1 3334444555 Dr. Jonson NPI Number 3334444555.
HL3:NM1 DAVID CROSS David Cross is the patient.
EQ 30 Health Plan Benefit Coverage

Eligibility Request (from Surescripts to PBM/payer)
Note: Surescripts has located the patient and populated the PBM Unique Member ID.
ISA*00* *01*PW12345PBM*ZZ*S00000000000001*ZZ*PBM123
*011217*0309*^*00501*000000001*1*P*>~
GS*HS*S00000000000001*PBM123*20011217*16150000*1*X*005010X279A1~
ST*270*0001*005010X279A1~
BHT*0022*13*3920394930203*20091217*16150000~
HL*1**20*1~
NM1*2B*2*PBM COMPANY*****PI*PBM123~
HL*2*1*21*1~
REF*EO*POCID~
N3*55 HIGH STREET~
N4*SEATTLE*WA*98123~
HL*3*2*22*0~
NM1*IL*1*CROSS*DAVID*M***MI*DD145645645601~
DMG*D8*19720910*M~
DTP*291*D8*20150206~
EQ*30~
SE*17*0001~
GE*1*1~
IEA*1*000000001~
Segment Value Note

ISA PW12345PBM The Password needed to correspond with the PBM/payer’s
system.
ISA S00000000000001 Surescripts’ ID.
ISA PBM123 The PBM/payer's Participant ID.
BHT 3920394930203 The Transaction reference number that ties the request to the
response.
HL1:NM1 PBM COMPANY Name of the Source (PBM/payer Name).
HL2:NM1 TIM JONSON Name of the Physician.

Segment Value Note

HL2:NM1 3334444555 Dr. Jonson NPI number 3334444555.
HL2:REF POCID Participant ID for the provider vendor.
HL3:NM1 DAVID CROSS David Cross with PBM Unique Member ID DD145645645601
DD145645645601
EQ 30 Health Plan Benefit Coverage.

Eligibility Response (from PBM/payer to Surescripts)

ISA*00* *01*PWPBM12345*ZZ*PBM123
*ZZ*S00000000000001*091217*0345*^*00501*000000001*1*P*>~
GS*HB*PBM123*S00000000000001*20091217*16150000*1*X*005010X279A1~
ST*271*0001*005010X279A1~
BHT*0022*11*3920394930203*20091217*16150000~
HL*1**20*1~
HL*2*1*21*1~
REF*EO*POCID~
HL*3*2*22*0~
REF*49*01~
N3*6785 LAUGHALOT LANE
N4*TRENTON*NJ*08608
DMG*D8*19720910*M
INS*Y*18~
DTP*291*D8*20091222~
EB*1**30**PLANA
REF*18*1234
REF*6P*DD1
REF*FO*201
REF*CLI*201
REF*N6*234876*AV
REF*IG*201
REF*ALS*142345~
DTP*291*RD8*20100801-20991231~
EB*1**88~
EB*1**90~
SE*27*0001~
GE*1*1~
IEA*1*000000001~

Segment Value Note

ISA PWPBM12345 The Password needed to correspond with the Surescripts’
system.
ISA PBM123 The PBM/payer’s Participant ID.
response.
HL2:NM1 TIM JONSON: 3334444555 Dr. Jonson with NPI number 3334444555.
HL2:REF POCID Participant ID for the Physician System.
HL3:NM1 DAVID CROSS: David Cross with PBM Unique Member ID DD145645645601.
DD145645645601
HL3:REF 49 Family Unit Number
EB 1:30 1 This patient has coverage.
HL3:REF 18 Plan Number
HL3:REF 6P Group Number and Group Name
HL3:REF FO Formulary ID
HL3:REF CLI Coverage List ID
HL3:REF N6 Bin = 234876: Processor Control Number = AV
HL3:REF IG Copay ID
HL3:REF ALS Alternative List ID
EB1:88 1 Eligible for Retail Pharmacy Benefits
EB1:90 1 Eligible for Mail Order Pharmacy Benefits.
Eligibility Response (from Surescripts to Physician System)

ISA*00* *01*PW12345PHY*ZZ*S00000000000001*ZZ*POCID
*011217*0345*^*00501*000000001*1*P*>~
GS*HB*S00000000000001*POCID*20091217*16150000*1*X*005010X279A1~
The rest of this message is the same as the prior message Eligibility Response (from PBM/payer to
Surescripts).
Segment Value Note

ISA PW12345PHY The Password needed to correspond with the Physician System’s system.
ISA POCID The Physician System’s Participant ID.

Eligibility Response (Not Active)

*ZZ*S00000000000001*091217*0345*^*00501*000000001*1*P*>~
GS*HB*PBM123*S00000000000001*20091217*16150000*1*X*005010X279A1~
ST*271*0001*005010X279A1~
BHT*0022*11*3920394930203*20091217*16150000~
HL*1**20*1~
HL*2*1*21*1~
REF*EO*POCID~
HL*3*2*22*0~
DMG*D8*19720910*M~
INS*Y*18~
DTP*291*RD8*20100801-20111231~
EB*6**30**PLANA~
SE*16*0001~
GE*1*1~
IEA*1*000000001~

Eligibility Response (for Specialty and Long Term Care)

*ZZ*S00000000000001*091217*0345*^*00501*000000001*1*P*>~
GS*HB*PBM123*S00000000000001*20091217*16150000*1*X*005010X279A1~
ST*271*0001*005010X279A1~
BHT*0022*11*3920394930203*20091217*16150000~
HL*1**20*1~
HL*2*1*21*1~
REF*EO*POCID~
HL*3*2*22*0~
REF*49*01~
DMG*D8*19720910*M~
INS*Y*18~
DTP*291*RD8*20100801-20991231~
EB*1**30**PLANA~
REF*18*1234~
REF*6P*DD1~
REF*FO*201~
REF*CLI*201~
REF*N6*234876*AV~
REF*IG*201~
REF*ALS*142345~
EB*1**88~
EB*1**90~
EB*1~
MSG*SPECIALTY PHARMACY~
EB*1~
MSG*LTC~
SE*30*0001~
GE*1*1~

IEA*1*000000001~
Segment Value Note

ISA PWPBM12345 The Password needed to correspond with the Surescripts’
system.
ISA PBM123 The PBM/payer’s Participant ID.
response.
HL2:NM1 Tim Jonson : 3334444555 Dr. Jonson with NPI number 3334444555.
HL2:REF POCID Participant ID for the Physician System.
HL3:NM1 DAVID CROSS: David Cross with PBM Unique Member ID DD145645645601
DD145645645601
HL3:REF 49 Family Unit Number
EB 1:30 1 This patient has coverage.
HL3:REF 18 Plan Number
HL3:REF 6P Group Number and Group Name
HL3:REF FO Formulary ID
HL3:REF CLI Coverage List ID
HL3:REF N6 Bin = 234876: Processor Control Number = AV
HL3:REF IG Copay ID
HL3:REF ALS Alternative List ID
EB1:88 1 Eligible for Retail Pharmacy Benefits
EB1:90 1 Eligible for Mail Order Pharmacy Benefits.
EB1 1 Eligible for benefit specified in the MSG segment.
MSG SPECIALTY PHARMACY Eligible for Specialty Pharmacy Benefits.
EB1 1 Eligible for benefit specified in the MSG segment.
MSG LTC Eligible for Long Term Care Pharmacy Benefits.

Prescription Benefit IG Section 5: Eligibility Message Processing Summary
SECTION 5: ELIGIBILITY MESSAGE PROCESSING SUMMARY

Depending on the connectivity between customers, the error processing may differ slightly. This section lays out the error processing for
the supported connection types. It also contains the error processing that happens within the 270/271 message that will be consistent
regardless of connectivity type.
The system (Surescripts) will store the request until the receiver responds to the message or until the specified time has elapsed. If the
timeout elapses before the message is processed, an error message will be returned to the sender as the reply (explained below). If the
sender has timed out, the message is discarded.
The Eligibility (270/271) message is a message where Surescripts is a defined customer in the process and adds processing value in the
middle. For that reason, additional error processing needs to be handled. The following section outlines the life of the Eligibility message
with the expected responses to different flows of events. It is broken down into the following stages:
l Surescripts receives the 270 from the requesting party.
l Surescripts processes the 270, identifying the coverage(s).
l Surescripts passes the 270 on to the defined source. (If multiple coverages are found, multiple 270’s are sent.)
l The source processes the request(s) and returns a 271 response.
l Surescripts combines the response(s) into one envelope.
l Surescripts passes the response back to the original requester.
P UBLISHED COPYRIGHT © 2016 BY S URESCRIPTS, LLC. P AGE 174

12/12/2016 A LL RIGHTS RESERVED . P ROPRIETARY AND CONFIDENTIAL
5.1 SURESCRIPTS RECEIVES THE 270 FROM THE REQUESTING PARTY (PROVIDER VENDOR)
Event Location Event Surescripts Error Description Requestor Follow-
Id Response Up
1.0 Connectivity Cannot get response from Surescripts None None Investigate and
Error contact Surescripts
production support
1.1 Translation Surescripts cannot identify the NAK A Negative Acknowledgement (NAK) with a message Investigate and
message or does not have enough info that says: “TRANSACTION CANNOT BE IDENTIFIED contact Surescripts
to create a TA1 NOR PROCESSED” production support
1.2 Translation Translator cannot identify the file (bad TA1 Refer to X12 005010 Data Element Dictionary for Investigate and
ISA or IEA segments) but can produce acceptable codes contact Surescripts
a TA1 response production support
1.3 Translation EDI Format has Fatal errors - 999 Refer to the 999 spec for a complete list of errors Investigate and
At any Level: contact Surescripts
Data Segment production support
Data Element
Transaction Set
Functional Group
5.2 SURESCRIPTS PROCESSES THE 270

Event Location Event Surescripts Error Description Requestor
Id Response Follow-up
2.0 Source Wrong platform Participant ID and/or password. 271 Loop ID 2000A C – Please correct
Segment AAA – Error 42 Unable to and resubmit
Loop ID – Respond a current time
2000A


2.1 Source Responder system goes down at any time in the process 271 Loop ID 2000A P – Please
Segment (Surescripts). AAA – Error 42 Unable to resubmit
Loop ID – Respond a current time
2000A
2.2 Source Requester puts bad data in the source segment. This should be 271 Loop ID 2000A C – Please correct
Segment Surescripts’ Participant ID. AAA – Error 79 and resubmit
Loop ID – Invalid participant
2000A identification
2.3 Source Requester is not set up to send eligibility message to Surescripts. 271 Loop ID 2000A N – Resubmission
Segment AAA – Error 41 not allowed
Loop ID – Authorization/Access
2000A Restrictions
2.4 Source Requester does not have a contract set up with the PBM/payer that 271 Subscriber Segment Loop N – Resubmission
Name was determined through patient lookup or the receiver is not ID 2100A not allowed
Segment authorized to receive an eligibility request. AAA – Error 75 -
Loop ID – Subscriber/Insured Not
2100A Found
2.5 Subscriber Surescripts cannot find the desired patient 271 Subscriber Segment Loop N – Resubmission
Name ID 2100C not allowed
Segment AAA – Error 75 -
Loop ID Subscriber/Insured Not
2100C Found
2.5a Subscriber Surescripts cannot find the desired patient 271 Subscriber Segment Loop C – Please correct
Name One of the demographic fields is missing ID 2100C and resubmit (Hint
Segment AAA – Error 75 – is sent back)
Loop ID Subscriber/Insured Not
2100C Found. Hint is in MSG
segment.


2.5b Subscriber Version translation fails for outgoing 270 271 Subscriber Segment Loop C – Please correct
Request ID 2110C and resubmit
Validation AAA – Error 15 - Required
Segment application data missing
Loop ID MSG – Details of Error
2110C
2.6 Dependent Surescripts cannot find the desired patient 271 Dependent Segment Loop N – Resubmission
Name ID 2100D not allowed
Segment AAA – Error 67 - Patient Not
Loop ID Found
2100D
2.6a Dependent Surescripts cannot find the desired patient 271 Dependent Segment Loop C – Please correct
Name One of the demographic fields is missing ID 2100D and resubmit (Hint
Segment AAA – Error 67 - Patient Not is sent back)
Loop ID Found
2100D
2.7 Dependent Version translation fails for outgoing 270 271 Dependent Segment Loop C – Please correct
Request ID 2110D and resubmit
Validation AAA – Error 15 - Required
Segment application data missing
Loop ID MSG – Details of Error
2110D

5.3 SURESCRIPTS ATTEMPTS TO CONNECT WITH SOURCE (PBM/PAYER)

Event Location Event PBM/payer PBM/payer Surescripts Provider Vendor Error Requestor Follow
Id Response Error Follow up Up
Description
3.0 Surescripts to Time Out – PBM/payer failed None None Investigate and Source Segment P – Please Resubmit
PBM/payer to reply to Surescripts in the create AAA error Loop 2100A Original Transaction
Connector specified time for requestor
AAA – Error 80
No Response received -
Transaction Terminated
New in 5010A1
3.1 PBM/payer Some failure at PBM/payer NAK Text Error Investigate and Source Segment S – Do not resubmit;
Internal where they cannot produce a Message create AAA error Loop 2000A Inquiry initiated to a
TA1 or 999 for requestor third party.
AAA – Error 42
Unable to respond at
current time
5.4 PBM/PAYER EVALUATES THE MESSAGE

Event Location Event PBM/payer PBM/payer Error Description Surescripts Follow Provider Requestor Follow Up
Id Response up Vendor Error
4.0 Translation Fatal Error TA1 Refer to X12 005010 Data Investigate and create Source S – Do not resubmit;
Initiation with the ISA, Element Dictionary for acceptable AAA error for Segment Inquiry initiated to a third
GS codes requestor Loop 2000A party.
AAA – Error 42
Unable to
respond at
current time

Event Location Event PBM/payer PBM/payer Error Description Surescripts Follow Provider Requestor Follow Up
Id Response up Vendor Error
4.1 Translation EDI Format 999 Refer to the 999 spec to Investigate and create Source S – Do not resubmit;
Initiation has Fatal determine AK level and AAA error for Segment Inquiry initiated to a third
errors - appropriate error requestor Loop 2000A party.
At any Level:
Data AAA – Error 42
Segment Unable to
Data respond at
Element current time
Transaction
Set
Functional
Group

5.5 PBM/PAYER PROCESSES THE 270

Note: Errors that occur during any mapping/translation exercise would result in an AAA segment within the 2000A Source Segment.
The error would be a 42 – Unable to respond at current time.
Generic Error messages for the following messages would result in a 42 within the segment where the error occurred.
Event Location Event PBM/payer PBM/payer PBM/payer Surescripts Provider Vendor Requestor
Id Response Error Follow up Follow up Error Follow Up
Description
5.0 Source Any issue that caused the process to 271 Source Investigate None Source Segment P – Please
Segment halt during processing Segment and contact Loop 2100A Resubmit
Loop ID Loop 2100A Surescripts Original
production AAA – Error 42 Transaction
2100A AAA – Error 42 support if
(Note: Unable to respond
Information Unable to additional at current time
Source is respond at information
the current time or
PBM/payer clarification
info that is needed.
was
supplied by
Surescripts)

Description
5.1 Source PBM/payer validates the Source 271 Source Investigate Investigate Source Segment S – Do not
Segment Identifier to make sure it’s their own. Segment and contact and Loop 2100A resubmit;
Loop ID Surescripts puts in wrong identifier Loop 2100A Surescripts translate to Inquiry
production AAA system AAA – Error 79 initiated to a
2100A AAA – Error 79 support
(Note: error for Invalid participant third party
Information Invalid requestor Identification
Source is participant
the Identification
PBM/payer
info that
was
supplied by
Surescripts)
5.2 Source PBM/payer validates the source 271 Source Investigate Investigate Source Segment S – Do not
Name contact information. Surescripts puts Segment and contact and Loop 2100A resubmit;
Segment in wrong PBM/payer contact name, Loop 2100A Surescripts translate to Inquiry
Loop ID etc. production AAA system AAA – Error 79 initiated to a
2100A AAA – Error 79 support error for Invalid participant third party
(Note: Invalid requestor Identification
Information participant
Source is Identification
the
PBM/payer
info that
was
supplied by
Surescripts)

Description
5.3 Receiver PBM/payer validates the receiver. 271 Receiver None None Receiver Segment C – Please
Segment PBM/payer wants more fields Segment Loop Loop ID 2100B correct and
Loop ID populated than what is required by ID 2100B AAA – Error 15 resubmit
2100B Surescripts; i.e. – the POC is not AAA – Error 15 Surescripts
(This loop identified. Required
Required application data recommends
contains this value,
the application missing
data missing however a
physician PBM/Payer
info and the might send a
Physician different value
System
info)
5.4 Receiver PBM/payer validates receiver. 271 Receiver None None Receiver Segment N–
Segment PBM/payer cannot return eligibility Segment Loop Loop ID 2100B Resubmission
Loop ID for this patient because of the ID 2100B AAA – Error 41 – not allowed
2100B patients group or plan. AAA – Error 41 Authorization/ Surescripts
(This loop – recommends
contains Access restrictions
Authorization/ this value,
the however a
physician Access
restrictions PBM/Payer
info and the might send a
Physician different
System value
info)

Description
5.5 Receiver PBM/payer validates the physician 271 Receiver None None Receiver Name C – Correct
Name Identifier Name Segment Loop ID and Resubmit
Segment Segment Loop – 2100B Surescripts
Loop ID – ID – 2100B Physician Loop recommends
2100B AAA – Error 43 this value,
AAA – Error 43
Invalid/Missing however a
Invalid/Missing PBM/Payer
Provider Provider
Identification might send a
Identification different value
5.8 Subscriber Patient found at Surescripts, but not 271 AAA – Error 75 None None AAA – Error 75 - S – Do not
Name Loop in the PBM/payer’s system (could be – Subscriber / Subscriber/Insured resubmit;
ID 2100C caused by a difference between Insured Not Not Found Inquiry
Surescripts and the PBM/payer’s Found initiated to a
patient databases or caused by the third party
patient demographic mismatch
between requestor and PBM/payer).
5.11 Dependant Patient found at Surescripts, but not 271 Dependant None None Dependant Name S – Do not
Name Loop in the PBM’s system (could be Name Segment Loop ID resubmit;
ID 2100D caused by a difference between Segment Loop 2100D AAA – Inquiry
Surescripts and the PBM’s patient ID 2100D AAA Error 67 – Patient initiated to a
databases or caused by the patient – Error 67 – not found third party
demographic mismatch between Patient not
requestor and PBM). found

5.6 PBM/PAYER SENDS 271 BACK TO SURESCRIPTS

Surescripts evaluates the message.
Event Location Event Surescripts Surescripts PBM/payer Surescripts Provider Requestor

Id Response Error Follow up Follow up Vendor Follow Up
Description Error
6.0 Translation Fatal Error TA1 Refer to NCPDP Investigate Investigate and Source S - Do not
of 271 from with ISA or Data Element and contact translate to Segment resubmit;
PBM/payer GS segments Dictionary for Surescripts AAA system Loop Inquiry
acceptable production error for 2100A initiated to a
codes support requestor third party
AAA –
Error 42
Unable
to
respond
at
current
time
6.1 Translation EDI Format 999 Refer to the 999 Investigate Investigate and Source S - Do not
of 271 from has Fatal spec to and contact translate to Segment resubmit;
PBM/payer errors - determine AK Surescripts AAA system Loop Inquiry
At any Level: level and production error for 2100A initiated to a
Data appropriate error support requestor third party
Segment AAA –
Data Error 42
Element Unable
Transaction to
Set respond
Functional at
Group current
time

Event Location Event Surescripts Surescripts PBM/payer Surescripts Provider Requestor

Id Response Error Follow up Follow up Vendor Follow Up
Description Error
6.2 Any Level Error in Log Error Cannot Translate Investigate Investigate and Loop N–
in the 271 translating to Version and contact translate to 2000A Resubmission
between Surescripts AAA system AAA – Not Allowed
4010/5010A1 production error for Error 42
support requestor
Unable
to
respond
at
current
time
5.7 SUMMARY OF ERRORS IS SENT TO PROVIDER VENDOR

The following is a summary of some of the errors a provider vendor can expect to see.
Error Description
Source Segment Generic error message for all errors that occurred that were not caused by the Physician System.
Loop 2000A
AAA – Error 42
Receiver Segment If the provider vendor fails to give enough information in the message to identify themselves or the physician to the
Loop ID- 2100B PBM/payer.
AAA – Error 15
Source Segment The sending customer is not set up to send an eligibility message.
Loop ID- 2000A
AAA – Error 41

Error Description
Subscriber Name Surescripts determines that there is no contract between the provider vendor and the PBM/payer. Coordinate with Event
Segment Loop ID 2100C ID 2.4 above.
AAA – Error 75
Receiver Segment If the PBM/payer determines that they cannot return information for this patient based off of the plan or group.
Loop ID- 2100B
AAA – Error 41
Receiver Segment If the PBM/payer requires a DEA or state license number for the prescribing office but the provider vendor does not
Loop ID- 2100B provide it.
AAA – Error 43
Subscriber Name Segment Loop Surescripts cannot find the patient in the MPI.
ID
AAA – Error 75
5.8 SUMMARY OF TRANSLATED ERRORS

Segment Error Translation for Provider Vendor
Connectivity Type All (Timeouts, NAKs, 999) Source Segment
Loop 2000A
AAA – Error 42

Prescription Benefit IG Section 6: ID Load and Response Files
SECTION 6: ID LOAD AND RESPONSE FILES
6.1 INTRODUCTION
PBM/payers use the ID Load message to provide Surescripts with their member roster to populate
the Surescripts Master Patient Index (MPI). Surescripts uses these files from the PBM/payers to
establish uniqueness for individuals across PBM/payers. Surescripts’ search process uses
demographics to identify a patient and then uses the PBM/payer's unique member ID to
communicate with the PBM/payers.
Surescripts responds to PBM/payer ID Loads with a Member Directory Response File indicating
the status of each load, including details at both the file and detail level. Information provided by
Surescripts indicates if a file loaded successfully, loaded with errors or was not loaded at all.
Affected records are detailed in the response file which indicates the specific reason each line had
an error or warning.
Surescripts will also provide statistical data about the processing for a given Delimited File received
from a PBM/payer (not provided for those that submit flat files). The Member Directory Response
Summary File will allow PBM/payers new insight into the processing of MPI files, and will allow
them to better determine whether all of the records sent to Surescripts were loaded as expected.
6.2 ID LOAD PROCESS FLOW

The following steps depict the flow of the ID load:
1. The PBM/payer creates a directory of patients, assigning each occurrence a unique member
ID.
2. The PBM/payer submits the initial load to Surescripts.
3. Surescripts populates the MPI internal directory with the initial file load.
4. Surescripts sends a response to the PBM/payer indicating the process success and failure
details.
Note: All date/times within response files are in UTC.
5. The PBM/payer creates an update file to keep the Surescripts MPI internal directory up-to-
date.

Note: Updates should only be sent if there is a change in the members’ demographic
data that Surescripts has defined in the file layout. If other member information not
contained in the file layout changes, no update should be sent.
6. Surescripts processes the updates.

7. Surescripts sends a response to the PBM/payer indicating the process success and failure
details.
6.3 FORMAT TO BE USED

Surescripts has implemented a custom specification that contains demographic and PBM/payer
specific information. There are two formats supported; one is a flat fixed width file. The other is a
delimited field format. Use the same character set as referenced in Character Set on page 21
except for the “^” character – decimal 94 which cannot be used in the ID Load Process.
Note: For flat fixed width files with more than 10 million lives, customers should notify
Surescripts to ensure the file can be processed.
6.4 MEMBER DIRECTORY MAINTENANCE FLAT FILE FROM

PBM/PAYER
Alpha-numeric data should be left justified and space filled. Numeric data should be right justified
and zero filled. Each line is separated by a new line (Hex 0A) character.
Header Info
Field Description Type Start End Required

Section Identifies the Header Section - Value = 1 N 1/1 1 1 Yes
Identifier
Participant ID as assigned by Surescripts identifying the PBM/payer AN 2 31 Yes

ID 3/30
Participant Password for this customer as assigned by Surescripts AN 32 41 Yes

Password 10/10
Transaction Unique identifier defined by the sender AN 42 51 Yes

Number 1/10
Transaction Date File was created (D8 - CCYYMMDD) DT 52 59 Yes

Date 8/8
Transaction Time File was created (HHMMSSDD) where H = hours (00-23), TM 60 67 Yes
Time M = minutes (00-59), S = integer seconds (00-59) and DD = 8/8
decimal seconds (00-99)


Usage Test or Production (T/P) ID 68 68 Yes
Indicator 1/1
Version Version of Member Directory File Format (1.0) AN 69 73 No

Number 1/5
Filler Filler field to extend row AN 74 796 Yes

723
Detail Info
Field Description Type Start End Required Notes

Section Identifies the Detail Section - N 1 1 Yes
Identifier Value = 2 1/1
Record Number for this detail row in the AN 2 11 Yes Number that will be
Sequence message 1/10 utilized in the response
Number document.
PBM Unique Unique ID as identified by the AN 12 71 Yes Unique identification

Member ID PBM/payer for the member 1/60 number for this member.
PBM Unique ID Unique ID as identified by the AN 72 131 No

for Subscriber PBM/payer for the subscriber of 1/60
the member
Health Plan Health Plan Unique Member AN 132 161 No

Member identification number 1/30
Number Number on the Health Plan card
identifying the patient (Either a
subscriber or a dependent)
Health Plan Health Plan Unique Subscriber AN 162 191 No

Subscriber identification number - Number 1/30
Number on the Health Plan card
identifying the subscriber
Policy Number Health Plan policy or group AN 192 221 No

number 1/30
Member Date that the member is no DT 222 229 No If multiple dates are
Expiration Date longer eligible (D8) 8/8 available (i.e. Term Date,
Expired Date, End Date),
use the earliest date of
the three.
Last Name Last Name of the Member AN 230 264 Yes

1/35
First Name First Name of the Member AN 265 289 Yes

1/25
Middle Name Middle Name of the Member AN 290 314 No

1/25
Prefix Member Prefix AN 315 324 No

1/10


Suffix Member Suffix AN 325 334 No
1/10
Social Security Member SSN - No dashes N 335 343 No

Number 9/9
Address Line 1 First Line of the Address (No C/O AN 344 398 No
type info) 1/55
Address Line 2 Second Line of the Address (No AN 399 453 No

C/O type info) 1/55
City Name Member City Name AN 454 483 No

2/30
State or Member State Code AN 484 485 No

Province Code 2/2
Postal Code Member zip code AN 486 500 No

3/15
Country Code Member Country Code AN 501 503 No

2/3
Comm Number 1st Comm. Number Type AN 504 505 No EM = Email

1 Type 2/2 EX = Telephone
Extension
FX = Facsimile
HP = Home Phone
TE = Telephone
WP = Work Phone
Communication 1st Communication Number AN 506 585 No

Number 1 1/80
Communication 2nd Communication Number AN 586 587 No EM = Email

Number 2 Type Type 2/2 EX = Telephone
Extension
FX = Facsimile
HP = Home Phone
TE = Telephone
WP = Work Phone
Communication 2nd Communication Number AN 588 667 No

Number 2 1/80


Communication 3rd Communication Number AN 668 669 No EM = Email
Number 3 Type Type 2/2 EX = Telephone
Extension
FX = Facsimile
HP = Home Phone
TE = Telephone
WP = Work Phone
Communication 3rd Communication Number AN 670 749 No

Number 3 1/80
Date of Birth Member DOB (CCYYMMDD) DT 750 757 No

8/8
Gender Member Gender (M,F,U, Blank) AN 758 758 No If gender not given, a
1/1 blank space will be used.
Employer Employer Name AN 759 793 No

Name 1/35
Transaction Type of Action needed AN 794 796 Yes 001 – Change

Type 3/3 021 – Addition
024 - Cancellation or
Termination
025 – Reinstatement
Trailer Info

Section Identifier Value = 3 (End of File) N 1/1 1 1 Yes
Total Records Total Records Processed N 1/10 2 11 Yes
Filler Filler Field to extend row AN 785 12 796 Yes
6.5 MEMBER DIRECTORY RESPONSE FLAT FILE TO PBM/PAYER

Header Info
Field Description Type Start End Notes

Section Identifier Identifies the Header Section - Value = N 1 1
1 1/1
Participant ID ID as assigned by Surescripts AN 2 31 Participant ID of Original File

identifying the PBM/payer 3/30 Sender
Sender ID ID of Surescripts An 32 61
3/30


Transaction Unique identifier that was assigned to AN 62 71
Number the incoming message 1/10
Incoming Date Original Incoming File was DT 72 79 Echoes the date from the
Transaction Date created (D8 - CCYYMMDD) 8/8 incoming file.
Incoming Time Original Incoming File was TM 80 87 Echoes the time from the
Transaction created (HHMMSSDD) 8/8 incoming file.
Time
Transaction Date Date Response was created (D8 - DT 88 95 The date that Surescripts
CCYYMMDD) 8/8 processed the file in GMT.
Transaction Time Response was created TM 96 103 The time that Surescripts
Time (HHMMSSDD) 8/8 processed the file in GMT.
Transaction Code Explaining the status of the load AN 104 105 01-17
Response 2/2 See Member Directory Codes
on page 202
Records Loaded Number of total records loaded N 106 115

1/10
Records Failed Number of total records failed N 116 125

1/10
Detail Info

Section Identifies the Detail N 1/1 1 1
Identifier Section - Value = 2
Record Number that AN 2 11

Sequence identified the row 1/10
Number in the incoming
message
PBM Unique ID as AN 12 71
Unique ID identified by the 1/60
for the PBM/payer for the
member member
Error Describes error for AN 72 74 See Member Directory Codes on page 202

Code this row 3/3
Filler Filler Field to AN 75 125

extend row 51

Trailer Info

Section Value = 3 (End of N 1/1 1 1
Identifier File
Filler Fill to make the row AN 2 125

125 124
6.6 MEMBER DIRECTORY MAINTENANCE DELIMITED FILE FROM

PBM/PAYER
Each field is delimited by the pipe character (|). Each line is separated by a new line (Hex 0A)
character. The tilde character (~) is used as a repetition character – currently only supported in the
postal code field.
Header Info
Field Field Name Type Required Comments Example

#
1 Record Type AN Yes Identifies record type Value = HDR
3/5
2 Version/Release AN Yes Version Number of this specification 2.1

Number 3/5
3 Sender ID AN Yes ID as assigned by Surescripts P11111111111111

3/30 identifying customer sending the file.
4 Sender Participant AN Yes Password for this customer identified in ABCDE12345

Password 10/10 field 3 (Sender ID).
5 Receiver ID AN Yes ID identifying the receiver of the file. RXHUB

1/30
6 Source Name AN Not Used Future use

1/35
7 Transmission AN Yes Unique identifier defined by the sender 0000001000

Control Number 1/10
8 Transmission Date DT Yes Date message was created (D8 - 20060701

8/8 CCYYMMDD)
9 Transmission Time TM Yes Time message was created 12200101

8/8 (HHMMSSDD)
10 Transmission File AN Yes Identifier telling the type of message MPI

Type 1/3 MPI=ID load


#
11 Transmission Action AN No U=Update U
1/1 F=Full file
If blank, default to U=Update
12 Extract Date DT Yes Date File was created (D8 - 20060630

8/8 CCYYMMDD)
13 File Type AN Yes Test or Production - T=Test, P

1/1 P=Production
Detail Info

#
1 Record Type AN Yes Identifies record type Value = MEM
3/3
2 Record Sequence AN Yes Number for this detail row in the

Number 1/10 message
3 PBM Unique Member AN Yes Unique ID as identified by the

ID 1/60 PBM/payer for the member
4 PBM Unique ID for AN No Unique ID as identified by the

Subscriber 1/60 PBM/payer for the subscriber of the
member
5 Health Plan Member AN No Health Plan Unique Member

Number 1/30 identification number on the Health
Plan card identifying the patient
(Either a subscriber or a dependent)
6 Health Plan AN No Health Plan Unique Subscriber

Subscriber Number 1/30 identification number - Number on the
Health Plan card identifying the
subscriber
7 Policy Number AN No Health Plan policy or group number

1/30
8 Member Expiration DT No Date that the member is no longer If multiple dates

Date 8/8 eligible (D8) are available (i.e.
Term Date,
Expired Date, End
Date), use the
earliest date of
the three.
9 Last Name AN Yes Last Name of the Member

1/35
10 First Name AN Yes First Name of the Member

1/25


#
11 Middle Name AN No Middle Name of the Member
1/25
12 Prefix AN No Member Prefix

1/10
13 Suffix AN No Member Suffix

1/10
14 Social Security N 9/9 No Member SSN - No dashes

Number
15 Address Line 1 AN No First Line of the Address (No C/O type

1/55 info)
16 Address Line 2 AN No Second Line of the Address (No C/O

1/55 type info)
17 City Name AN No Member City Name

2/30
18 State or Province AN No Member State Code

Code 2/2
19 Postal Code AN No Member zip code 5 or 9 numeric no 55123~55102

3/15 punctuation.
Can Use the tilde character (~) to send
repeat multiple zip codes.
up to
five
times.
20 Country Code AN No Member Country Code

2/3
21 Comm Number 1 Type AN No 1st Comm. Number Type EM = Email

2/2 EX = Telephone
Extension
FX = Facsimile
HP = Home
Phone
TE = Telephone
WP = Work Phone
22 Communication AN No 1st Communication Number

Number 1 1/80


#
23 Communication AN No 2nd Communication Number Type EM = Email
Number 2 Type 2/2 EX = Telephone
Extension
FX = Facsimile
HP = Home
Phone
TE = Telephone
WP = Work Phone
24 Communication AN No 2nd Communication Number

Number 2 1/80
25 Communication AN No 3rd Communication Number Type EM = Email

Number 3 Type 2/2 EX = Telephone
Extension
FX = Facsimile
HP = Home
Phone
TE = Telephone
WP = Work Phone
26 Communication AN No 3rd Communication Number

Number 3 1/80
27 Date of Birth DT No Member DOB (CCYYMMDD)

8/8
28 Gender AN No Member Gender (M,F,U, blank) If gender not

1/1 given, a blank
space will be
used.
29 Employer Name AN No Employer Name

1/35
30 Transaction Type AN Yes Type of Action needed 001 – Change

3/3 021 – Addition
024 -
Cancellation or
Termination
025 –
Reinstatement

Trailer Info

#
1 Record Type AN Yes Identifies record type Value = TRL
3/3
2 Total Records N Yes Total Records Processed

1/10
6.7 MEMBER DIRECTORY RESPONSE DELIMITED FILE TO PBM/PAYER

The file name reflects the file name from the PBM/payer with a .rsp file extension.
Example: NewPatient_TestingPBMC_MPI.1450188243095.rsp
Note: If the source file had an extension, the extension remains and the .rsp is added after it.
For example: NewPatient_TestingPBMC_MPI.1450188243095.txt.rsp
Header
Field Description Type Required Notes

Record Type Identifies record type AN Yes Value = SHD
3/3
Version/Release Version Number of this AN Yes 2.0

Number specification 1/2
Recipient ID ID assigned by AN Yes P11111111111111

Surescripts for the 3/30 Note: If the inbound MPI file included an
recipient of the response invalid Sender ID, Sender Participant
file (original sender of Password, Transmission Date, or
the ID load file) Transmission time, this field in the response
file will be populated with: “INV_HEADER”.
Sender ID ID as assigned by AN Yes RXHUB

Surescripts identifying 3/30
Surescripts
Recipient Password assigned by AN Yes Note: If the inbound MPI file included an
Participant Surescripts for accessing 10/10 invalid Sender ID, Sender Participant
Password the PBM/payer system. Password, Transmission Date, or
Transmission time, this field in the response
file will be populated with: “INV_HEADER”.
Transaction Unique identifier defined AN Yes

Control Number by the sender 1/10
Transaction Date message was DT Yes CCYYMMDD

Date created 8/8


Transaction Time message was TM Yes HHMMSSDD
Time created 8/8
Transaction File Identifier telling receiver AN Yes MPR

Type the type of file. 1/3
Transaction Number of the original AN Yes

Number - report message 1/10
Originating
Transaction Date Original Incoming DT Yes CCYYMMDD

Date- File was created (D8) 8/8 Note: If the inbound MPI file included an
Originating invalid Sender ID, Sender Participant
Password, Transmission Date, and/or
file will be populated with: “20000101”.
Transaction Time Original Incoming TM Yes HHMMSSDD

Time- File was created 8/8 Note: If the inbound MPI file included an
Originating invalid Sender ID, Sender Participant
Password, Transmission Date, and/or
file will be populated with: “00000000”.
File Type Test or Production (T/P) AN Yes T=Test

1/1 P=Production
Load Status Code Explaining the AN Yes See Member Directory Codes on page 202
status of the load. 2/2

Detail Info

Record Type Identifies record type N Yes Value=SDT
1/1
Record Sequence Number that identified the row in the AN Yes

Number incoming message 1/10
PBM Unique ID for Unique ID as identified by the AN No

the member PBM/payer for the member 1/60
Error Code Describes error for this row AN Yes See Member Directory
3/3 Codes on page 202
W - Signifies a Warning
E - Signifies a Error
Trailer Info

Record Type Identifies record type. AN 3/3 Yes Value = STR
Total Rows in Error N 1/10 Yes
6.8 MEMBER DIRECTORY RESPONSE SUMMARY DELIMITED FILE TO

PBM/PAYER
Note: This will only be returned to customers that send the Member Directory Maintenance
Delimited File. See Member Directory Maintenance Delimited File from PBM/payer on
page 193 for more information.
File Naming Convention:

l A human readable file (on Admin Console) will have a .smt file extension. Example: erx_
RXHUB_member_directory_02082015_201919.1423456259313.smt
l A pipe delimited file (on FTP) will have a .smd file extension.
Note: The PBM/payer needs to request an opt-in from Surescripts in order to receive this .smd
file.
Example: erx_RXHUB_member_directory_02082015_
201919.1423456259313.smd

Field Field Description Type Required Example

#
1 File Load Date Date the MPI file was processed by DT Yes 12/05/2014
Surescripts. 10/10
UTC Date in MM/DD/CCYY format.
2 Transmission Unique identifier defined by the sender from AN Yes 0000001000

Control inbound MPI file. 1/10
Number
3 Participant ID Surescripts ID assigned to the PBM/payer. AN Yes P111111111111111

3/30
4 Sender ID The Sender ID is Surescripts. AN Yes Value = Surescripts

3/30
5 Incoming File Date time that Surescripts received the AN 12/05/2014 04:34:02
Received inbound file. 24 hour time used - UTC 19/19
Datetime in MM/DD/YYYY HH:MM:SS
format.
6 Total Number Number of active lives in the MPI before N Yes 10000
of Active Lives processing. 1/12
in MPI Before Note: Number of active lives reflects the
Processing customer's requested lag days. For
example, if the customer's lag day value is
7, all members in their MPI file are
considered active for 7 days beyond the
Member Expiration date provided by the
customer in the MPI file.
Incoming File Record Count
7 Total Records Number of patient records in the MPI file. N Yes 1000
in File 1/12
8 Number of Number of records in the inbound MPI file N Yes 200

Adds where Transaction Type == 021. 1/12

Terms where Transaction Type == 024. 1/12

Changes where Transaction Type == 001. 1/12

Reinstatements where Transaction Type == 025. 1/12
Results of Processing the File
12 Requested Number of records with Transaction Type N Yes 300

Number of == 021 that were added. 1/12
Records Added


#
Number of == 001 that were changed. 1/12
Records
Changed

Number of == 024 that were terminated. 1/12
Records
Termed

Number of == 025 that were reinstated. 1/12
Reinstatements
16 Number of Number of errors generated. N Yes 50

Errors 1/12
17 Number of Number of cases on update file loads where N Yes 75

Adds That a record in the inbound file had Transaction 1/12
Already Existed Type == 021, but the patient already existed
in the Surescripts system.

Changed that a record in the inbound file had Transaction 1/12
Did Not Exist Type == 001, but the patient record did not
exist in the Surescripts system.

Terms that Did a record in the inbound file had Transaction 1/12
Not Exist Type == 024, but the patient record did not
exist in the Surescripts system.

Reinstatements a record in the inbound file had Transaction 1/12
that Did Not Type == 025, but the patient record did not
Exist exist in the Surescripts system (patient was
not found in either an active or inactive
state).
21 Total Number Number of active lives in the MPI after N Yes 10300
of Active Lives processing. 1/12
in MPI After After processing the new file, the number of
Processing records where the Member Expiration Date
is >= to today's date in the Surescripts
system.
22 Processing Date time the new MPI file began AN Yes 12/05/2014 05:04:00
Start Time processing in 24 hour clock - UTC Datetime 19/19
in MM/DD/YYYY HH:MM:SS format
23 Processing Date time the new MPI file began AN Yes 12/05/2014 07:16:02
End Time processing in 24 hour clock - UTC Datetime 19/19
in MM/DD/YYYY HH:MM:SS format


#
24 Processing Time it took to process the file in DT Yes 002:12:02
Time for File HHH:MM:SS format. 9/9
25 Member Version ID of the Member Directory AN Yes 1.0

Directory Response Summary. 3/3
Response
Summary
Version ID
6.9 MEMBER DIRECTORY CODES

Note: These codes apply to the Member Directory Maintenance Flat File from PBM/Payer and
the Member Directory Response Delimited File to PBM/Payer. See Member Directory
Response Flat File to PBM/payer on page 191 and Member Directory Response Delimited File
to PBM/payer on page 197 for more information.
Header Response Codes
Code Description
01 File loaded correctly.
02 File loaded with errors.
03 Invalid file format - File Not loaded.
04 System error - Please resend.
05 Invalid header section ID - File not loaded (Not Used).
06 Invalid header Participant ID or password - File not loaded.
07 Invalid header transaction number format - File not loaded.
08 Invalid header transaction datetime format - File not loaded.
09 Invalid header usage indicator - File not loaded.
10 Invalid header filler - File not loaded.
11 Invalid header new line character - File not loaded.
12 Invalid trailer section ID – Trailer not validated - File not loaded.
13 Invalid trailer filler - Trailer not validated. - File not loaded.
14 Invalid reported number of records - File not loaded.
15 Contract does not exist - File not loaded.
17 Invalid header version number - File not loaded (Not Used).

Detail Error Codes
Code Description
E01 Missing PBM Unique Member ID, record not loaded.
E02 Missing required fields, record not loaded.
E03 Invalid characters in row, record not loaded.
E04 Invalid record length, record not loaded.
E05 Invalid record type, record not loaded.
E07 Invalid transaction type, record not loaded.
E09 Missing Term Date, record not loaded.
E10 Maximum repetitions exceeded.
W04 Change Record not found, record added.
W05 Record to Add exists, record updated.
W06 Record to Term does not exist, record added.
W07 Record to Reinstate not found, record added.
W08 Duplicate PBM Unique Member ID found in update file, record not loaded. This warning will only occur
for the membership update process. If a duplicate PBM Unique Member ID is found in the initial
membership load, no records are loaded and the entire file is rejected.

Prescription Benefit IG Section 7: Formulary and Benefit Data Load
SECTION 7: FORMULARY AND BENEFIT DATA

LOAD
7.1 INTRODUCTION
During the prescribing process, provider vendor systems typically use the information retrieved
through the Formulary and Benefit Data Load service to inform prescribers of the following:
l Drugs that the patient’s benefit plan considers to be “on formulary” (Formulary Status), and
alternative medications for those which are not preferred (Alternatives);
l Limitations that may impact whether the patient’s benefit will cover a drug being considered
(Coverage);
l The copay for one drug option versus another.
Note: Provider vendors should refrain from displaying unnecessary information to prescribers,
(e.g. NDC numbers, Formulary IDs, Coverage IDs, PBM Unique Member IDs etc.).
This section provides an overview of the information that can be communicated using the
Formulary and Benefit Data Load service.
Note: The prior authorization function that is part of the standard is not explained in this guide.
The PA lists are not complete in this version and NCPDP has adopted specific messages to
handle prior authorization work flow.
Note: The cross reference function that is part of the standard is not explained in this guide
because it is not supported in Surescripts’ business model, since eligibility check is always
performed prior to the formulary and benefit check.

7.2 FORMULARY AND BENEFIT SUMMARY INFORMATION MODEL

7.3 FORMULARY AND BENEFIT DATA OVERVIEW

Formulary and benefit data can consist of the following types: Formulary Status, Payer-specified
Alternatives, Coverage Information, and Copay Information. If Payer-specified Alternatives,
Coverage Information, and/or Copay Information are provided, there must be an associated
Formulary Status List.
A drug formulary is a list of prescription drugs published by a health plan, pharmacy benefit
manager, payer, or provider. Each drug within a formulary is assigned a "formulary status", which is
an indicator of a formulary publisher’s preference for the drugs on the formulary relative to other
drugs in the same or a related therapeutic class. Formulary publishers periodically publish revisions
to their drug formularies as new clinical and cost issues influence their preferences.
Note: Payers determine a drug’s formulary status by considering its efficacy and value
compared to other drugs in the same therapeutic class (a grouping of medications known to be
effective for a particular diagnosis). Those drugs with a higher rating obtain a higher formulary
status.
If a therapeutic class contains multiple drugs, those drugs with a higher formulary status are
commonly referred to as being "preferred" to those with lower ratings.
7.3.1 FORMULARY STATUS

Formulary status is defined by using a simple, low-to-high scale. Drugs with a lower formulary
status are considered less preferable by the payer; those with a higher status are more preferable.
Formulary Status:
U = Unknown Status
1 = Non-Formulary
2 = On Formulary/Non-Preferred
3 - 99 = On Formulary/Preferred (higher number means “more preferred”)
If formulary status 2 or less is sent, the provider vendor will need to check alternatives (whether
from the alternatives file or from the therapeutic alternatives as defined by the drug database).
Payers can flag drugs that the benefit simply does not cover at any level. These drugs are referred
to as “non-reimbursable,” meaning that the patient bears full responsibility for their cost.
0 = Non-Reimbursable
If a drug is not listed in the file, a Formulary Status can be specified by using the Non-Listed
Formulary Status fields in the header (e.g. Non-listed Prescription Brand Formulary Status, Non-
Listed Prescription Generic Formulary Status, Non-Listed Brand Over The Counter Formulary
Status etc.).

It is possible for drugs within the same therapeutic class to have a different formulary status. For
example, there may be several non-reimbursable drugs as well as five formulary drugs; three of
which are a preferred level ‘3’ and two designated as a preferred level ‘4’. Note that the “most
preferred” products in this example are the two level ‘4’ products.
Note: Payer formulary data, including copay and specific coverage factors, is at the plan level –
not a real-time check at the patient level. Specific nuances such as remaining deductibles or a
Prior Authorization requirement may still apply for a patient at time of prescription filling.
7.3.2 PAYER-SPECIFIED ALTERNATIVES

As discussed above, drugs with a higher formulary status than others of the same therapeutic class
are considered to be “preferred alternatives” to those with lower ratings. Therefore, provider
vendor systems can identify preferred alternatives by comparing the status of drugs within a
therapeutic class.
Payers can explicitly state alternatives for specific drugs. These payer-specified alternatives are
communicated in Alternatives lists, which contain the following information:
l Source drug: the off-formulary drug
l Alternative drug: the preferred alternative
l Alternative drug preference level: if there are multiple preferred alternatives, the payer’s
order of preference (higher number equals greater preference)
7.3.3 COVERAGE INFORMATION

Coverage information qualifies the conditions under which the patient’s pharmacy benefit covers a
medication. For instance, a drug may be covered only for patients under a certain age, or of a
certain gender. Other drugs may be covered up to a certain quantity. Payers can communicate the
following coverage factors to provider vendor systems using the file load:
l Prior authorization requirements
l Step therapy requirements
l Step medications
l Age limits
l Gender limits
l Quantity limits
l Product coverage exclusions
l Resource links
l Text messages
A payer may send multiple quantity limits, step medications, text messages and resource links for
the same drug.

7.3.4 COPAY INFORMATION

Copay information describes the “cost to the patient” - the extent to which the patient is responsible
for the cost of a prescription. The specification supports multiple ways to state this cost, including
flat dollar amounts, percentages, and tier levels. Payers may use one, or a combination of these
options.
For instance, a flat $10 patient copay may apply to one drug, and a 15% copay may apply to
another. One payer may state copay exclusively in terms of copay tiers, where lower tiers mean a
lower patient copay. The publisher determines what is appropriate to send, based on their benefit
design.
Payers can communicate the following copay terms to provider vendor systems using the file load:
l Flat copay (dollar amount)
l Percentage copay
l Combination flat / percentage
l Copay tier (tier of given drug versus the number of tiers)
l Minimum and maximum copay
l Days supply per stated copay
l Copay differences by type of pharmacy
l Copay specific text message (via the text message Coverage list type)
Summary-level copay. Often, a class of medications will receive the same copay (generics, for
example). Payers can state a summary-level copay rule, based on a drug’s Formulary Status and
its type (Branded, Generic, Over The Counter, Supply, or Compound). Any drug with the
characteristics stated in the summary-level rule receives the copay defined in the rule.
Drug-specific copay. Exceptions to these summary-level rules will also frequently exist. To
accommodate these exceptions, Payers can provide drug-level copays. These copays apply to
specific drugs, as identified with one of the supported drug identifiers or a representative 11-digit
NDC ID.
7.3.5 ROLL UP
Formulary information is provided to Surescripts by all PBM/payers customers. This data identifies
formulary status, coverage, and copay data for the payer’s active members. Today, most
PBM/payers are providing formulary files at the NDC-11 packaged drug level. All provider vendors
prescribe at a dispensable drug level (drug name, form, and strength). In order to display formulary
correctly the data must be rolled up to a dispensable drug level. This process involves Surescripts
performing this roll-up feature before the data is supplied to the clinical vendor. Surescripts will
select a representative NDC from the drug database vendor and roll all formulary information to
this level.
During the roll-up process, Surescripts will identify any discrepancies in the files provided. Reports
will be generated and sent back to the PBM/Payer that will indicate conflicts in formulary status,

coverage factors, and copay details. The reports will be made available to the PBM/payer for
periodic download and review.
This may not be done in all cases (PBM/payer has to opt in, and the drug database vendor needs to
support Roll Up.)
Note: See Formulary Roll-Up Supplement for more information.
7.4 DRUG IDENTIFIERS
7.4.1 REPRESENTATIVE NDC

Since prescribing systems typically operate at a label name level of specificity, it is not always
necessary to supply all NDCs that tie to a given label name. In order to reduce the size of the
formulary and benefit files, it is possible to use one or a subset of representative NDCs to define a
category of medication. A representative NDC is an 11-digit NDC code that depicts a category of
medication regardless of package size and manufacturer/labeler. In order to maximize the
opportunity that the selected NDC exists among the various drug files, a representative NDC
should not be a repackaged NDC, obsolete NDC, private label NDC or unit dose NDC unless it is
the only NDC available identifying that category of medication.
7.4.2 RXNORM
RxNorm provides standard names for clinical drugs (active ingredient + strength + dose form) and
for dose forms as administered to a patient. It provides links from clinical drugs, both branded and
generic, to their active ingredients, drug components (active ingredient + strength), NDC codes
and related brand names. RxNorm links its names to many of the drug vocabularies commonly
used in pharmacy management and drug interaction software. By providing links between these
vocabularies, RxNorm can mediate messages between systems not using the same software and
vocabulary.
7.5 HIGH-LEVEL PROCESSING EXAMPLES (FOR PROVIDER VENDORS)

The following examples show processing flows for:
l Presenting Formulary and Coverage Information
l Presenting Medication Copay
l Presenting Formulary Alternatives
7.5.1 FLOW ONE: PRESENTING FORMULARY & COVERAGE INFORMATION

For each medication presented to the prescriber:

1. Note the medication’s NDC(s) (“drug ID(s)” hereafter).

2. Determine the patient’s Formulary ID and Coverage ID using the Eligibility 271 message.
3. Determine the medication’s formulary status:
a. Search the Coverage Information Detail - Product Coverage Exclusion list for this
drug ID and Coverage ID. If an exclusion is found, present “Not Reimbursable” as the
formulary status.
b. If no Product Coverage Exclusion is associated with this medication, search the
Formulary Status List and present the highest Formulary Status reflected there.
c. If the payer has not included this drug ID in the Formulary Status List, use the
appropriate non-listed default status specified in the Formulary Status Header (if
provided by the payer):
l Non-Listed Prescription Brand Formulary Status
l Non-Listed Prescription Generic Formulary Status
l Non-Listed Brand Over The Counter Formulary Status
l Non-Listed Generic Over The Counter Formulary Status
l Non-Listed Supplies Formulary Status
4. Present coverage information:
l Search the various coverage lists for this Drug ID and Coverage ID.
l Display each overage rule found.
7.5.2 FLOW TWO: PRESENTING MEDICATION COPAY

For each medication presented to the prescriber:
1. Note the medication’s NDC(s) (“drug ID” hereafter).
2. Determine the patient’s Formulary ID and Copay ID using the Eligibility 271 message).
3. Determine the medication’s formulary status
l See step 3 in the previous example, “Flow One: Presenting Formulary And Coverage
Information”
4. If the formulary status from the previous step is Not Reimbursable, finish (do not display
copay terms), otherwise proceed to step 5.
5. Reference the Benefit Copay List/Copay Information Detail - Drug Specific to determine
whether a drug-specific copay override applies to this medication. If so, present the drug-
specific copay.
6. If no drug-specific copay is found for this medication, look up the copay based on the drug’s
characteristics.
l Search the Benefit Copay List/Copay Information Detail - Summary Level for the
record that matches this medication’s characteristics (below) and present the copay
terms for each type of pharmacy specified by the payer:

l Formulary Status
l Product Type
7.5.3 FLOW THREE: PRESENTING FORMULARY ALTERNATIVES

To present preferred alternatives for Not Reimbursable, Non Formulary, and On Formulary (Not
Preferred) medications, use the following methods.
Method One: Use payer-specified formulary alternatives

1. Note the Not Reimbursable, Non Formulary, or On Formulary (Not Preferred) medication’s
NDC(s) identifier (“drug ID” hereafter).
2. Using the Eligibility 271 message, determine the patient’s Alternatives ID.
3. Search the corresponding Formulary Alternatives List’s “source drug” field as appropriate for
the Not Reimbursable, Non Formulary, or On Formulary (Not Preferred) medication’s drug
ID.
Note: This search may yield multiple record matches, indicating there are multiple preferred
alternatives for the drug.
Method Two: Use a third-party drug classification system to determine formulary alternatives
1. Note the Not Reimbursable, Non Formulary, or On Formulary (Not Preferred) medication’s
NDC(s) (“drug ID”).
2. Reference a third-party drug classification scheme to locate medications within the same
drug class. Within these medications, reference the patient’s Formulary Status List to identify
preferred alternatives.
Note: The third party classification system mentioned above is a Surescripts approved drug
database.
7.6 FORMULARY AND BENEFIT DATA LOAD ROLES

Surescripts, Formulary Publishers (pharmacy benefit payers, such as PBM/payers and health
plans), and Formulary Retrievers (Provider Vendors) have the following roles within the Formulary
and Benefit Data Load process.
Formulary Publishers
Within the Formulary and Benefit Data Load process, Formulary Publishers:
l Load and maintain updated formulary information (formulary drugs, status, and alternatives)
at Surescripts.
l Maintain a formulary distribution list at Surescripts that indicates which provider vendors
have access to which plan/group formulary and benefit lists.

Formulary Retrievers
Formulary Retrievers download the formulary information from the Surescripts WebDAV server
and integrate it into their point-of-care application. With this information, prescribers can check a
prescription drug against a patient’s formulary, view coverage/copay limitations, and consider
alternative medications.
Surescripts
Surescripts’ role in the Formulary and Benefit Data Load process is to:
l Facilitate the distribution of formulary and benefit lists between the Formulary Publishers and
Retrievers.
l Document and communicate the Formulary and Benefit Data Load specification, process,
and usage guidelines.
l Validate the formulary and benefit files against the current Surescripts specification.
l Certify the provider vendor's retrieval of the formulary and benefit lists.
7.7 FORMULARY AND BENEFIT DATA LOAD PROCESS (FOR

PBM/PAYERS)
The Formulary and Benefit Data Load consists of two processes: Formulary Publishing (data setup
and loading) and Formulary Retrieval (data integration and presentation to prescribers).
Formulary and Benefit Data Setup and Loading
1. The Formulary Publisher develops their formulary and benefit file layout according to
Surescripts’ standard Formulary and Benefit Data Load specification.
2. The Formulary Publisher sends Surescripts a formulary and benefit file on a defined
schedule that contains one or more of the formulary and benefit list types (e.g. formulary
status and/or alternatives). The Formulary and Benefit Data is electronically transmitted to
Surescripts via the selected file transfer method as a single physical file.
3. Surescripts performs a physical validation of the file.

4. Surescripts sends the Formulary Response File back to the Publisher indicating the
Formulary and Benefit Data load status. The Response file indicates any errors encountered
in the load process.
5. The Formulary Publisher provides Surescripts with a Formulary Distribution List. The
Formulary Distribution List indicates which customers have access to which formulary and
benefit lists.
6. Surescripts separates the file into individual formulary and benefit lists, processing each with
its own list identifier. If there are no errors the lists are loaded into the database.
7.8 FORMULARY AND BENEFIT DATA INTEGRATION AND

PRESENTATION TO PRESCRIBERS (FOR PROVIDER VENDORS)
1. Based on customer-to-customer contract relationships and the permissions granted by the

Formulary Publisher on the Distribution List, Surescripts makes the appropriate subset of
formulary and benefit lists available on the WebDAV server for Formulary Retrievers to
download.
2. The Formulary Retriever checks the WebDAV server on a scheduled basis to determine if
there are new or updated formulary and benefit lists available.
3. The Retriever downloads the formulary and benefit lists to their system and makes them
available to prescribers via their point-of-care (POC) application.
4. During or before a patient’s office visit, a prescriber sends an Eligibility Request (270) to
verify the patient’s health plan information, prescription benefit, and formulary information.
The Request is routed through the system application to Surescripts’ Master Patient Index
(MPI) for processing, and then on to respective PBM/payer(s) for processing. Refer to the
Eligibility section for more information on this process flow.
5. The patient’s Formulary ID, Alternatives ID, Coverage ID, and Copay ID are contained
within the Eligibility response (271) sent back from the PBM/payer(s). The POC application
links these IDs from the patient’s Eligibility response with the corresponding lists.

6. During the prescribing process, the physician views patient formulary and benefit information
within the POC application to verify that a particular medication is on the patient’s formulary
and covered under the patient’s plan. If not, the prescriber can view “preferred” alternative
drugs within that medication’s therapeutic class.
7.9 FORMULARY AND BENEFIT PUBLISHING (FOR PBM/PAYERS)

The following sections described how Formulary Publishers develop, set up, and load their
formulary and benefit files for processing at Surescripts.
7.9.1 FILE PROCESSING OPTIONS

Formulary Publishers specify within the formulary and benefit file header and each file list header
how that data should be processed. The options for the formulary and benefit file are “U” (Updates)
or “F” (Full formulary replace). The options for lists are “F” (Full list replace) or “D” (Delete the list).
Update Process:
After receiving the formulary and benefit files from the Formulary Publisher, Surescripts checks
each section of the file to validate that the data is formatted correctly. If any of the lists were
previously loaded in the database, the new lists replace the existing ones, thereby updating the
information. Any new information not previously loaded in the database is added. Updates will be
processed even if the file contains validation errors. This process is outlined in the Reject Code
Summary on page 258.
When a Formulary Publisher would like to notify its partners of the discontinuation of a list, they
send an action code of “D” (Delete) within the list header and include no detail rows in the list. The
Formulary Retriever responds by removing the previously loaded list with that ID.
Note: If the Formulary Publisher wants the Formulary Retriever to be notified of the delete, they
cannot remove access to the deleted list within the distribution list.

Full Replace Process:
With the Full Replace process, the new formulary and benefit file overwrites all the previously
loaded lists from that Formulary Publisher. Full loads will be processed even if the file contains
validation errors. This process is outlined in the Reject Code Summary below.
l Full replace option should only be used when all list types can be sent to Surescripts in one
physical file.
l Any formulary and benefit list previously loaded in the database that is not included in the
new file is purged from the system. There will be a delay removing these lists as the lists will
be removed when the next full load is successful. Removal of a list is always one full load
behind.
7.9.2 ENVIRONMENT SETUP

Before sending formulary and benefit files to Surescripts, Formulary Publishers need to set up a
network connection to Surescripts and implement the selected file transfer method within their
environment. The network connection is set up and configured as part of the regular integration
process with Surescripts. For more information, refer to the Secure File Transfer on page 301.
7.9.3 FORMULARY AND BENEFIT FILE NAMING AND STRUCTURE

The Formulary Publisher’s data load can be made up of several list types. Surescripts stores these
individually, as separate lists, to give the Formulary Retriever the ability to select the formulary
status, alternative, coverage or copay list applicable to a specific patient. The structure of these lists
as they appear to the Formulary Retriever is described below. The file naming and WebDAV
directory structure for the formulary and benefit lists is described in the following sections.
File Naming
The individual formulary and benefit lists are named according to the value specified within the
formulary and benefit list file header (the “Formulary ID” field). The field is a text field; it can only
contain the following characters (A-Z, a-z, Numeral 0-9, period “.”, and a dash “-“). This also
applies to Alternative ID, Coverage ID, Copay ID, and Classification ID as these fields are also
used to create file names. The Formulary ID can be up to 10 characters long. The list names are
tied to each Participant’s ID; therefore, if two Formulary Publishers use the same file name, the
Participant ID is what distinguishes them within the system.
Note: Underscores are not allowed in the List ID portion of the file name.
List Type Key Field (with Participant ID)

Formulary Status List Formulary ID
Alternative List Alternative ID
Coverage List Coverage ID
Copay List Copay ID

Each list is available to Formulary Retrievers on the WebDAV server in a directory respective to the
list’s type. The file name contains the date the list was extracted from the Publisher’s system. The
date the list was made available through Surescripts is displayed as date modified. For coverage
and copay lists the first two characters of the file name are the type of coverage list.
File Name Structure Example

Formulary Status List
/FSL/Formulary id_effective date_extract date /FSL/123451_20120301_20120318
Alternative File List
/ALT/Alternative id_effective date_extract date /ALT/214312_20120301_2020318
Coverage List
/COV/List id_effective date_extract date /COV/ALFFT_20120301_20120318
Copay List
/COP/List id_effective date_extract date /COP/SLCDE_20120301_20120318
Directory Structure
The WebDAV environment contains a directory structure similar to the examples below. The actual
appearance may vary slightly due to the different WebDAV client interfaces that Formulary
Retrievers may use. The three examples in this section use the following customer names:
l ABC - ABC Corporation (Health Plan)
l BMI - Benefit Management, Inc. (PBM/payer)
Note: This structure assumes that the Formulary Retriever has access to files from the
following Formulary Publishers: “ABC Corporation”, and “Benefit Management, Inc.”.
Filename Size Last Modified
ABC
ALT
HEALTHA_20130301_20130318 30KB 4/12/2013
HEALTHB_20130301_20130318 24KB 4/12/2013
HEALTHC_20130301_20130318 100KB 4/12/2013
FSL
HEALTHA_20130301_20130317 630KB 4/12/2013
HEALTHB_20130301_20130317 362KB 4/12/2013
HEALTHC_20130301_20130317 424KB 4/12/2013
COP
DSABCD_20130301_20130317 2230KB 4/12/2013
DSDFFG_20130301_20130317 242KB 4/12/2013

SLAAON_20130301_20130317 19KB 4/12/2013
COV
ALABCD_20130301_20130317 877KB 4/12/2013
PATTHI_20130301_20130317 188KB 4/12/2013
QLFFVG_20130301_20130317 3900KB 4/12/2013
BMI
FSL
HEALTHD_20130301_20130316 630KB 4/11/2013
HEALTHE_20130301_20130316 362KB 4/11/2013
HEALTHG_20130301_20130316 424KB 4/11/2013
COV
QL1234_20130301_20130301 843KB 4/11/2013
QL11DE_20130301_20130301 128KB 4/11/2013
RL44DE_20130301_20130301 500KB 4/11/2013
7.9.4 FORMULARY DISTRIBUTION LIST CREATION

Before distributing its formulary and benefit files, the Formulary Publisher creates or updates a
formulary distribution list spreadsheet at Surescripts. The list indicates which Technology Providers
(Formulary Retrievers) have access to which formulary and benefit lists. An example distribution
list follows:
Source Participant: Participant ID: List Date File Type:

PBMB T0000000000xxxx 10/13/2003 DIS
Receiving Customer List Type Coverage List Type List ID

Name Participant ID
select from list select from list select from list enter
if List Type = COV
POC System, Inc. P0000001 FSL 1111
POC_A Company P0000002 ALT 4444
Access rights are tracked at the individual list level. For example, a particular Formulary Retriever
may be given access to Formulary Status Lists 1111, 2222, and 3333, while another Formulary
Retriever is given access for Alternative List 4444.

Publishers can use an “All customers” wildcard in the distribution list instead of a particular
Technology Provider Participant ID to indicate that all Technology Providers that have a formulary
contract relationship with the Formulary Publisher can access a particular list. In the same way, an
“All lists” wildcard may also be used to indicate that the named customer has access to all lists for
that Publisher. Wildcards take precedence over all other entries in the distribution list.
Surescripts updates its system according to the information provided by the Publisher in the
distribution list and validates that all Technology Providers included in the list have Formulary
Contract Relationships with the Publisher. The Surescripts system also determines what has
changed since the last distribution and identifies the specific access changes (adds and deletes)
that are reflected in the list.
When an update has been made to the list, Surescripts re-runs the distribution process, treating the
Publisher’s complete, current set of formulary information as a new load. If a particular Technology
Provider has gained access to a file due to the Publisher’s new access rules, Surescripts distributes
the most recent version of the list to them. If a Technology Provider loses access to a file in the new
rules, Surescripts removes the files from the customer’s folder. Surescripts also records distribution
lists that have references to lists that do not exist (for example, in cases where lists have been
deleted). For more information, refer to File Processing Options on page 214.
7.10 FORMULARY RETRIEVAL (FOR PROVIDER VENDORS)

Formulary Retrievers download Formulary Publisher information from Surescripts via WebDAV
(Web-based Distributed Authoring and Versioning). WebDAV is a series of extensions to HTTPS
that allow users to manage files on remote servers. Within the WebDAV context, a Formulary
Publisher is the customer providing the data files. The Formulary Retriever is the customer that is
accessing for review and retrieval purposes.
The Formulary Retriever downloads formulary and benefit data from WebDAV by an automated or
manual process on a periodic basis. Retrieval of the formulary and benefit lists can be done by
utilizing the WebDAV clients creating a script that periodically checks for updates to formulary and
benefit data, or by using both a WebDAV client and a script. (For more information please refer to
http://www.webdav.org/).
The frequency of updates to the formulary and benefit data depends on the Formulary Publisher,
but generally changes are made on a monthly or quarterly basis. After the Formulary Retriever
downloads the updated formulary and benefit data, it is stored in the Retriever’s database and then
displayed to physicians based on the Retriever’s system presentation rules.
7.10.1 WEBDAV
WebDAV can be used with the following specifications:
l Username and password are communicated during implementation.
l Each customer is configured with a unique secure directory. The customer will have access

to all contracted formulary and benefit related files.

l It is recommended to not have more than 100 concurrent connections per provider vendor.
Supported Network Connections for WebDaV
Customers may use one of the following network connectivity methods with WebDAV:
l Internet:
l Address filtering will be done in the Surescripts firewall.
l Surescripts will work with customers to review their current connection speed and
bandwidth to ensure they are adequate for anticipated message volumes.
l Frame Relay:
l 128 kbps minimum bandwidth over a frame relay circuit between Surescripts and the
customer.
l The line must be encrypted with 3DES.
l The customer must allow Surescripts to install and manage two routers in their data
center that connect to their extranet environment.
l The customer must have dual network connections through two different
telecommunication providers.
Selecting WebDaV Clients and Configuration
Implementation and support for WebDAV clients is the responsibility of the provider vendor. Some
WebDAV clients and configurations are known to provide a faster, more consistent formulary
retrieval experience. Surescripts expects that full formulary retrieval will take less than a day with
the appropriate client and configuration.
The following principles should be followed when choosing or building a WebDAV Client:
1. Concurrency is expected when downloading from WebDav. Choose a client that can
request multiple files concurrently. Surescripts recommends that the level of concurrency be
between 10 and 50 threads.
l If more than 50 simultaneous connections are used, Surescripts reserves the right to
block the vendor from downloading until they limit concurrency to an acceptable level.
2. Only new or modified files should be downloaded. The last modified date field should be
utilized to determine if a file has been modified.
3. Surescripts WebDAV servers can use GZip compression to speed up downloads if HTTP
compression is accepted by the client software.
l Client software that allows compression will advertise that in the HTTP header
information sent: Accept-Encoding: gzip
l The WebDAV server’s response will indicate that it has compressed the payload in the
response header: Content-Encoding: gzip

Note: Although supported, compression may not always occur as it is only beneficial for larger
files.
CyberDuck
Cyberduck is a cross platform downloader that supports WebDAV as well as other protocols. It is
available for Mac, Linux, and Windows. CyberDuck offers both a command line interface version as
well as a graphical version.
Sample Configuration:
Once installed, a command similar to the following could be used. Items in red should be replaced
with your credentials. Items in green should be the absolute path of the local folder files will be
saved to.
$ duck --parallel 20 --preserve -d davs://files.rxhub.net/webdav/Formulary/ /data02/Formulary/ -u

P000000000XXXXX -p PASSWORD -e compare
DAVIX
Davix is a set of command line tools to work with DAV file systems over the web. Davix is available
on most Linux distributions and may also work on other platforms.
Sample Configuration:
Once installed, a command similar to the following could be used. Items in red should be replaced
with your credentials. Items in green should be the absolute path of the local folder files will be
saved to.
$ davix-get -r 20 davs://files.rxhub.net/webdav/Formulary/ /data02/Formulary/ --userlogin

P000000000XXXXX --userpass PASSWORD
WebDAV Client and Configuration to Avoid:
Rsync
Rsync over a remotely mounted davfs file system should not be used. This configuration has been
known to take over 1 week to do a single sync. Rsync is not multi-threaded.
7.10.2 FORMULARY AND BENEFIT FILE DISTRIBUTION

WebDAV is the Surescripts-supported technology for the distribution of formulary information.
Retrievers utilize their same Surescripts Participant ID and password on the WebDAV server as
they use for all of the other Surescripts supported messages. The secure WebDAV connection
allows the Retriever access to their Surescripts established directory. Within the root directory, the
Retriever sees individual directories of the Formulary Publishers with which they have a formulary
contract relationship. Once connected, the Retriever has READ ONLY access to the files within
their directory.

Surescripts presents each formulary and benefit list as a separate physical file, enabling the
Formulary Retriever to download lists individually. Formulary Retrievers distinguish each formulary
and benefit list by its unique list identifier and by the file’s header and trailer information, which is
wrapped around each individual list.
The distribution of formulary information to customers is based on the following:

1. The Formulary Publisher having a contract to share formulary and benefit data with the
Formulary Retriever or otherwise having provided permission to the Formulary Retriever to
download the formulary and benefit data.
2. The Formulary Publisher identifying which lists the Formulary Retriever has access to within
the formulary distribution list.
7.10.3 FORMULARY AND BENEFIT FILE PROCESSING

Formulary Retrievers follow the steps below to process formulary and benefit lists:
1. Log into WebDAV.
2. View Formulary Publishers’ folders for which they have access (as defined in the Formulary
Distribution List created by the Formulary Publisher).
3. Compare the WebDAV directories to look for changes in the formulary and benefit lists.
a. Download the updated formulary and benefit lists to their database. At the list header
level there is an action code of “F” or “D” (delete).
b. For list with an “F” in the list header, the Retriever should do a full replace of all the
records in that list. Full Replaces occur at the list level, not at the individual record
level. All previous records will be replaced in this list.
c. A delete action specifies the Retriever should remove that list from their formulary and
benefit database.
7.10.4 RETRIEVAL RELATED ERRORS

If Formulary Retrievers encounter any of the following types of errors during the data utilization and
presentation process, they should contact the following groups:
l For problems related to the WebDAV client/user interface, contact that product’s
manufacturer.
l For problems related to WebDAV security, access, and/or no formulary and benefit lists
being present on the WebDAV server, contact Surescripts’ Production Support team.
l If a Formulary Retriever receives a Formulary ID within an Eligibility 271 message that they
cannot access on WebDAV, they should contact the corresponding Formulary Publisher.
This error type can occur if a formulary and benefit list has not been loaded at Surescripts, or
if the Formulary Retriever has not been given distribution permission for that formulary and
benefit list ID by the Formulary Publisher.

7.11 GENERAL STRUCTURAL OVERVIEW
7.11.1 FILE LEVEL FROM THE SENDER TO THE RECEIVER

File/Transmission - The highest level of data transfer is the file. The file contains information that
is global to the entire data set. This includes routing information, identification, and information
which determine the parsing of the lists within. A file may contain multiple message types. List /
Transaction – Transactions occur within transmissions. Messages are comprised of data
segments of related data elements.

7.12 FORMULARY AND BENEFIT DATA LOAD SPECIFICATION

The formulary and benefit data load is represented as a flat variable length file. The pipe character
(hex 7c) will be used to delimit fields and the new line (hex 0a) character will delimit records. Where
there are optional fields at the end of the record, it is recommended to not send trailing delimiters.
This format promotes a bulk load type message.
7.12.1 FILE/HEADER TRAILER DEFINITION

A formulary and benefit file is made up of formulary, alternatives, benefit coverage and benefit
copay list types. The file header and trailer information, as defined below, should be consistent
across all lists within the file.
7.12.2 FORMULARY AND BENEFIT FILE HEADER

Field Description Type M/C Notes
Record Type Identifies record AN M Value = HDR
type. 3/3
Version/Release Version Number of AN M 30

Number this specification 1/2
Sender ID ID as assigned by AN M The sender represents the entity that is providing the data
Surescripts 3/30 and creating the file.
identifying the
sending customer
(Formulary
Publisher)
Sender Password for this AN M Only populated when publisher is sending file to
Participant customer as 10/10 Surescripts.
Password assigned by
Surescripts
Receiver ID S00000000000001 AN M Only populated when publisher is sending file to

3/30 Surescripts.
Source Name Name of Source AN M

supplying the 1/35
formulary -
Formulary
Publisher
Transmission Unique identifier AN M

Control Number defined by the 1/10
sender
Transmission Date message was DT M CCYYMMDD

Date created (D8 - 8/8
CCYYMMDD)


Transmission Time message was TM M HHMMSSDD
Time created 8/8
(HHMMSSDD)
Transmission Identifier telling the AN M FRM = Formulary And Benefit Load

File Type type of message 1/3
Transmission Action for the entire AN M For formulary publishers this action tells Surescripts if this
Action message. 1/1 file replaces all previously loaded lists from this Source
(F = Full Replace), or if it is an update file,
(U = Update) - contains updated lists only.
An “F” (Full Replace) action indicates to the receiver to
remove ALL previously loaded lists from this source from
the database. The new file is then loaded in their place. A
“U” (Update) contains lists that need to be deleted and/or
added on an individual basis to the formulary database.
Extract Date Date the file was DT M CCYYMMDD

extracted from the 8/8
internal Publisher’s
system
File Type Test or Production AN M T=Test

1/1 P=Production
7.12.3 FORMULARY AND BENEFIT FILE TRAILER

Record Identifies AN M Value = TRL
Type record type. 3/3
Total Total records N M Do not include the Formulary And Benefit File Header and Trailer in this
Records processed 1/10 count. Include any subordinate header, detail, and trailer records in this
total. Total records in file minus 2.
7.13 FORMULARY STATUS LIST
7.13.1 FORMULARY STATUS HEADER

Record Identifies record AN M Value = FHD
Type type. 3/3


Formulary Identification for AN M This is the formulary ID that was returned in the Eligibility 271
ID the formulary 1/10 message (located in loop 2110C1, REF segment, qualifier = ‘FO’).
Must be unique across all lists of this type.
Valid characters are (A-Z, a-z, Numeral 0-9, period “.”, and a dash
“-“)
Formulary Name given to AN C

Name the formulary 1/35
Non-Listed Tells the AN M U - Unknown

Prescription receiver how to 1/2 0 – Not Reimbursable
Brand treat non-listed
Formulary prescription 1 – Non Formulary
Status branded drugs. 2 – On Formulary (Not Preferred)
The higher the 3 – On Formulary Preferred Level 1
number for the 4 – On Formulary Preferred Level 2
preferred level,
the more 5 – On Formulary Preferred Level 3
preferred the Up to 99.
drug is.
Non-listed Tells the AN M U - Unknown

Prescription receiver how to 1/2 0 – Not Reimbursable
Generic treat non-listed
Formulary prescription 1 – Non Formulary
Status generic drugs. 2 – On Formulary (Not Preferred)
The higher the 3 – On Formulary Preferred Level 1
preferred level,
drug is.

Brand Over receiver how to 1/2 0 – Not Reimbursable
The treat non-listed
Counter brand over the 1 – Non Formulary
Formulary counter drugs. 2 – On Formulary (Not Preferred)
Status The higher the 3 – On Formulary Preferred Level 1
preferred level,
drug is.


Generic receiver how to 1/2 0 – Not Reimbursable
Over The treat non-listed
Counter generic over the 1 – Non Formulary
Formulary counter drugs. 2 – On Formulary (Not Preferred)
Status The higher the 3 – On Formulary Preferred Level 1
preferred level,
drug is.

Supplies receiver how to 1/2 0 – Not Reimbursable
Formulary treat non-listed
Status supplies. 1 – Non Formulary
The higher the 2 – On Formulary (Not Preferred)

preferred level, 4 – On Formulary Preferred Level 2
the more
preferred the 5 – On Formulary Preferred Level 3
supply is. Up to 99.
Relative Number of N M Note, if relative value is not used in the detail, this value is 0
Cost Limit levels used 1/2 (zero).
within the
Relative value
indicator.
List Action Tells the AN M F = Full List Replacement (If exists, replace, if not, add)
receiver that this 1/1 U = UPDATE LIST
is a Full list
replacement (Or D = Delete List
Add) or a delete Note: The detail records list the drugs within the formulary. Detail
list. records may not exist if the non-listed formulary statuses from the
header record are used exclusively to convey the drugs’ formulary
statuses. If the list action in the formulary status header is a “D”
(Delete), the detail records should be ignored (if present) by the
retriever.
Variance from Formulary and Benefit 3.0: The update option is
not currently supported.
List Date the list DT M CCYYMMDD

Effective goes into effect. 8/8
Date
7.13.2 FORMULARY STATUS DETAIL

Record Type Identifies record type. AN M Value = FDT
3/3


Change Only the Add option is AN M A – Addition
Identifier supported. 1/1 C – Change
D – Delete
Product/Service Drug ID (NDC) AN M Mandatory because Class ID is no longer used.

ID - Source 1/19 Variance from Formulary and Benefit 3.0:
Surescripts requires N 11/11.
Qualified by Product/Service ID Qualifier. Used if
Drug Reference Number or RxNorm Code is not
specified.
If either Product/Service ID or Product/Service ID
qualifier is sent, then both are required
Product/Service Drug ID qualifier AN M 01 = Universal Product Code (UPC)

ID Qualifier 2/2 02 = Health Related Item (HRI)
03 = National Drug Code (NDC) -
09 = Health Care Financing Administration Common
Procedural Coding System (HCPCS)
28 = Universal Product Number (UPN)
36 = Representative National Drug Code (NDC)
Variance from Formulary and Benefit 3.0: Only
NDC is supported by Surescripts.
Drug Identifier for the drug AN C Qualified by Drug Reference Qualifier.

Reference from proprietary code 1/35 Used if Product/Service ID or RxNorm Code is not
Number sources. specified.
If either drug reference number or drug reference
qualifier is sent, then both are required.


Drug Code value that AN C Code value that identifies the source and type for the
Reference identifies the source and 1/3 Drug Reference Number.
Qualifier type for the Drug AF = American Hospital Formulary Service (AHFS)
Reference Number.
E = Medical Economic GFC
FD = First DataBank Routed Dosage Form ID (FDB
Routed Dosage Form Med ID)
FG = First Databank GCN Seq#
FM = First DataBank Medication ID (FDB MedID)
FN = First DataBank Medication Name ID (FDB Med
Name ID)
FR = First DataBank Routed Medication ID (FDB
Routed Med ID)
FS = First Databank Smartkey
G = Medical Economic GM
GS = Gold Standard Product Item Collection
MC = Multum Drug ID
MD = Medispan DDID
MG = Medispan GPI
MM = Multum MMDC
US = U.S. Pharmacopoeia (USP)
If either drug reference number or drug reference
RxNorm Code ID From RxNorm AN C Qualified by RxNorm Qualifier.

database. 1/15 Used if Product/Service ID or Drug Reference
Number is not specified or unable to match.
If either drug RxNorm code or RxNorm Qualifier is
sent, then both are required.
RxNorm Code qualifying the AN C Values:

Qualifier RxNorm code submitted. 1/3 This field is constrained to the following values:
SCD = Semantic Clinical Drug
SBD = Semantic Branded Drug
GPK = Generic Package
BPK = Branded Package
If either drug RxNorm code or RxNorm Qualifier is


Formulary Status of the drug within AN M U - Unknown
Status the formulary. 1/2 0 – Not Reimbursable
The higher the number 1 – Non Formulary
for the preferred level,
the more preferred the 2 – On Formulary (Not Preferred)
drug is. 3 – Preferred Level 1
4 – Preferred Level 2
Up to 99.
Relative Cost The relative value of this N C Represents the cost of the drug to the health plan. If
drug within its 1/2 used, the relative value limit in the header must be
classification. greater than 0 and this value must be less than or
equal to the header value.
7.13.3 FORMULARY STATUS TRAILER

Record Identifies record type. AN M Value = FTR
Type 3/3
Total Total Records sent for this N M Do not include the Header and Trailer records in this
Records formulary ID. 1/10 count. Total of Detail records.
7.14 FORMULARY ALTERNATIVES LIST

Alternative drugs for a specified product.
7.14.1 FORMULARY ALTERNATIVES HEADER

Record Identifies record type. AN M Value = AHD
Type 3/3
Alternative The identification number for AN M The ID for the alternative list that may have been
ID this alternative list. 1/10 returned in the Eligibility 271 message (located in
loop 2110C1, REF segment, qualifier = ‘ALS’).
Must be unique across all lists of this type.
Valid characters are (A-Z, a-z, Numeral 0-9, period “.”,
and a dash “-“)


List Action Tells the receiver that this is a AN M F = Full List Replacement (If exists, replace, if not,
Full list replacement (Or Add) 1/1 add)
or a delete list. U = Update File
The update option is not D = Delete List
currently supported.
Note: If the Header Transaction Action is a Delete, the
detail records should be ignored (if present) by the
Retriever.
List Date the list goes into effect. DT M CCYYMMDD

Effective 8/8
Date
7.14.2 FORMULARY ALTERNATIVES DETAIL

Record Type Identifies record type. AN M Value = ADT
3/3
Change Only the Add option is supported. AN M A – Addition

Identifier 1/1 C – Change
D – Delete
Product/Service Drug ID (NDC) AN M Variance from Formulary

ID - Source 1/19 and Benefit 3.0: Mandatory
because Class ID is no longer
used.
Variance from Formulary
and Benefit 3.0: Surescripts
requires N 11/11.
If either Product/Service ID or
Product/Service ID qualifier is


Product/Service Drug ID qualifier AN M 01 = Universal Product Code
ID Qualifier 2/2 (UPC)
02 = Health Related Item
(HRI)
03 = National Drug Code
(NDC) - This can be the
representative NDC Number.
and Benefit 3.0: Only NDC is
supported by Surescripts.
09 = Health Care Financing
Administration Common
Procedural Coding System
(HCPCS)
28 = Universal Product
Number (UPN)
36 = Representative National
Drug Code (NDC)
Drug Identifier for the drug from proprietary code AN C Qualified by Drug Reference
Reference sources. 1/35 Qualifier
Number - Used if Product/Service ID or
Source RxNorm Code is not specified.
If either Drug Reference
Number or Drug Reference
Qualifier is sent, then both are
required.
Drug Code value that identifies the source and type AN C See Formulary Status Detail
Reference for the Drug Reference Number. 1/3 on page 226 for values.
Qualifier - If either Drug Reference
Source Number or Drug Reference
required.
RxNorm Code - ID From RxNorm database. AN C Qualified by RxNorm Qualifier.

Source 1/15 Used if Product/Service ID or
Drug Reference Number is not
specified or unable to match.
If either Drug RxNorm code or
RxNorm Qualifier is sent, then
both are required.


RxNorm Code qualifying the RxNorm code submitted. AN C Values:
Qualifier - 1/3 This field is constrained to the
Source following values:
SBD = Semantic Branded
Drug
both are required.
Product/Service Drug ID (NDC) AN M Mandatory because Class ID

ID - Alternative 1/19 is no longer used.
and Benefit 3.0: Surescripts
requires N 11/11.
sent, then both are required
Product/Service Drug ID qualifier AN M 01 = Universal Product Code

ID Qualifier 2/2 (UPC)
(HRI)
representative NDC
Number.
Variance from
Formulary and Benefit
3.0: Only NDC is
Administration Common
Procedural Coding System
(HCPCS)
Number (UPN)
36 = Representative National
Drug Code (NDC)
sent, then both are required


Drug Identifier for the drug from proprietary code AN C Qualified by Drug Reference
Reference sources. 1/35 Qualifier
Number - Used if Product/Service ID or
Alternative RxNorm Code is not specified.
Number or Drug Reference
required.
Drug Code value that identifies the source and type AN C See Formulary Status Detail
Reference for the Drug Reference Number. 1/3 on page 226 for values
Qualifier - If either Drug Reference
Alternative Number or Drug Reference
required.
RxNorm Code - ID From RxNorm database. AN C Qualified by RxNorm Qualifier.

Alternative 1/15 Used if Product/Service ID or
Drug Reference Number is not
specified or unable to match.
both are required.
RxNorm Code qualifying the RxNorm code submitted. AN C Values:

Qualifier - 1/3 This field is constrained to the
Alternative following values:
Drug
both are required.
Preference If there are multiple alternatives for a given N M 1-99 Higher = more preferred
Level Source NDC, this is the payer’s order of 1/2
preference (a higher number equals greater
preference).
7.14.3 FORMULARY ALTERNATIVES TRAILER

Record Identifies record type. AN M Value = ATR
Type 3/3
Total Total Records Processed for N1/10 M Do not include Header and Trailer records in this
Records this alternative list count. Total of Detail records.

7.15 BENEFIT COVERAGE LIST
7.15.1 COVERAGE INFORMATION HEADER

Record Identifies record type. AN M Value = GHD
Type 3/3
Coverage ID for the list AN M Must be unique across all lists of this type.
List ID 1/10 Valid characters are (A-Z, a-z, Numeral 0-9, period
“.”, and a dash “-“)
Coverage Code identifying the type of AN M Each Coverage List ID will have only one List
List Type coverage factor being conveyed 1/2 Type - Coverage associated within it.
AL = Age Limits
DE = Product Coverage Exclusion
GL = Gender Limits
MN = Medical Necessity
PA = Prior Authorization
QL = Quantity Limits
RD = Resource Link – Drug-Specific Level
RS = Resource Link – Summary Level
SM = Step Medication
ST = Step Therapy
TM = Coverage Text Message
List Tells the receiver that this is a Full AN M F = Full list replacement (If list with this List Type /
Action list replacement (Or Add) or a 1/1 List ID exists, replace; if not, add)
delete list. U = Update File
D = Delete List
Note: If the Header Transaction Action is a Delete,
the detail records should be ignored (if present) by
the Retriever.
Variance from Formulary and Benefit 3.0: The
update option is not currently supported.

Effective 8/8
Date
7.15.2 COVERAGE INFORMATION DETAIL – COVERAGE TEXT MESSAGE (TM)

Record Type Identifies record type. AN M Value = TDT
3/3


Change AN M A – Addition
D – Delete
the Add option is accepted.
Coverage ID The membership AN M Relates to the Coverage ID returned in the

population to which the 1/40 Surescripts Eligibility response (located in loop
coverage rule applies. 2110C1, REF segment, qualifier = ‘CLI’).


03 = National Drug Code (NDC) - This can be the
representative NDC Number.
09 = Health Care Financing Administration
Common Procedural Coding System (HCPCS)
Drug Identifier for the drug from AN C Qualified by Drug Reference Qualifier
Reference proprietary code sources. 1/35 Used if Product/Service ID or RxNorm Code is not
Number specified.
If either Drug Reference Number or Drug
Reference Qualifier is sent, then both are required.
Drug Code value that identifies AN C See Formulary Status Detail on page 226 for
Reference the source and type for the 1/3 values
Qualifier Drug Reference Number. If either Drug Reference Number or Drug
Reference Qualifier is sent, then both are required.
RxNorm Code ID from RxNorm database. AN C Qualified by RxNorm Qualifier.

1/15 Used if Product/Service ID or Drug Reference
If either Drug RxNorm code or RxNorm Qualifier is


Qualifier RxNorm code submitted. 1/3 This field is constrained to the following values:
If either Drug RxNorm code or RxNorm Qualifier is
Message – A text message to be AN M A text message to be presented to the prescriber.

Short presented to the 1/100 Variance from Formulary and Benefit 3.0: This is
prescriber. mandatory for this implementation.
The short text message is an abbreviated version
of the long text message and should be used
when display space in limited like a handheld or
smart phone.
Message - A text message to be AN C A text message to be presented to the prescriber.

Long presented to the 1/200 Optional long text message.
prescriber. The long text message is the full version of the
short text message and should be used on
systems that use larger screens than handheld
devices.
Text Message Identifies the type of AN M Values:

Type coverage information 2/2 AL = Age Limits
contained in the message.
CP = Copay
DE = Product Coverage Exclusion
FM – Formulary
GI = General Information
GL = Gender Limits
PA = Prior Authorization
QL = Quantity Limits
ST = Step Therapy
7.15.3 COVERAGE INFORMATION DETAIL – PRODUCT COVERAGE EXCLUSION (DE),

PRIOR AUTHORIZATION (PA), STEP THERAPY (ST)
Record Type Identifies record type. AN M Value = DDT
3/3

Identifier accepted. 1/1 C – Change
D – Delete


Coverage ID The membership population to AN M Relates to the Coverage ID returned in the
which the coverage rule 1/40 Surescripts Eligibility response (located in loop
applies. 2110C1, REF segment, qualifier = ‘CLI’).

If either Product/Service ID or Product/Service
ID qualifier is sent, then both are required

03 = National Drug Code (NDC) - This can be
the representative NDC Number.
Variance from Formulary and Benefit 3.0:
Only NDC is supported by Surescripts.
ID qualifier is sent, then both are required
Reference proprietary code sources. 1/35 If either Drug Reference Number or Drug
Number Reference Qualifier is sent, then both are
required.
Drug Code value that identifies the AN C See Formulary Status Detail on page 226 for
Reference source and type for the Drug 1/3 values.
Qualifier Reference Number. If either Drug Reference Number or Drug
Reference Qualifier is sent, then both are
required.

If either Drug RxNorm code or RxNorm Qualifier
is sent, then both are required.
RxNorm Code qualifying the RxNorm AN C Values:

Qualifier code submitted. 1/3 This field is constrained to the following values:

7.15.4 COVERAGE INFORMATION DETAIL – STEP MEDICATIONS (SM)

Record Type Identifies record type. AN M Value = MDT
3/3
Change Only the Add option is accepted. AN M A – Addition

D – Delete
Coverage ID The membership population to AN M Relates to the Coverage ID returned in the

which the coverage rule applies. 1/40 Surescripts Eligibility response (located in
loop 2110C1, REF segment, qualifier =
‘CLI’).
Product/Service Drug ID (NDC) AN M Mandatory because Class ID is no longer

ID - Source 1/19 used.
Variance from Formulary and Benefit
3.0: Surescripts requires N 11/11.
Product/Service ID qualifier is sent, then
both are required

ID Qualifier - 2/2 02 = Health Related Item (HRI)
Source
03 = National Drug Code (NDC) - This can
be the representative NDC Number.
3.0: Only NDC is supported by
Surescripts.
Administration Common Procedural
Coding System (HCPCS)
36 = Representative National Drug Code
(NDC)
both are required
Reference proprietary code sources. 1/35 Used if Product/Service ID or RxNorm
Number -– Code is not specified.
Source
required.
Drug Code value that identifies the AN C See Formulary Status Detail on page 226
Reference source and type for the Drug 1/3 for values
Qualifier - Reference Number. If either Drug Reference Number or Drug
Source Reference Qualifier is sent, then both are
required.


RxNorm Code - ID from RxNorm database. AN C Qualified by RxNorm Qualifier.
Source 1/15 Used if Product/Service ID or Drug
Reference Number is not specified or
unable to match.
If either Drug RxNorm code or RxNorm
Qualifier is sent, then both are required.
RxNorm Code qualifying the RxNorm code AN C Values:

Qualifier - submitted. 1/3 This field is constrained to the following
Source values:
Product/Service Drug ID (NDC) AN M Variance: from Formulary and Benefit

ID – Step Drug 1/19 3.0: Only NDC is supported by
Surescripts.
both are required
Product/Service Drug ID qualifier AN M Variance from Formulary and Benefit

ID Qualifier – 2/2 3.0: NDC required thus qualifier is
Step Drug required.
01 = Universal Product Code (UPC)
02 = Health Related Item (HRI)
3.0: Only NDC is supported by
Surescripts.
(NDC)
both are required


Number – Step Code is not specified.
Drug
required.
Drug Code value that identifies the AN C See Formulary Status Detail on page 226
Reference source and type for the Drug 1/3 for values
Qualifier – Step Reference Number. If either Drug Reference Number or Drug
Drug Reference Qualifier is sent, then both are
required.

– Step Drug 1/15 Used if Product/Service ID or Drug
unable to match.

Qualifier – Step submitted. 1/3 This field is constrained to the following
Drug values:
Drug Qualifier - Indicates whether the AN C This would only be used when a
Step Drug Product/Service ID represents a 2/2 Product/Service ID - Step Drug is
specific medication versus a specified.
pharmacological class Values:
SM = Specific Medication
PC = Pharmacological Class no longer
relevant because Class ID and Subclass
ID are no longer used
Class ID - Step ID for the proprietary designated N C Not used because classification list has
drug class that the product falls within ID 1/5 been removed from the standard.
for the proprietary
Subclass ID - ID for the designated sub-class that N C Not used because classification list has
Step Drug the product falls within 1/5 been removed from the standard.
Number of The number of drugs to try. N C Note: This field may only be present if
Drugs to Try 1/2 Drug Qualifier – Step Drug is “SM".


Step Order The suggested order in which the AN M 1 = First to be tried
step medication is to be tried 1/1 2 = second to be tried etc.
Diagnosis Code identifying the diagnosis of AN C

Code the patient. 1/15
Diagnosis Code qualifying the Diagnosis AN C 00 - Not Specified

Code Qualifier Code. 2/2 01 - International Classification of
Diseases (ICD9) - the 9th edition
02 - International Classification of
Diseases (ICD10) - the 10th edition
03 - National Criteria Care Institute (NCCI)
04 - The Systematized Nomenclature of
Human and Veterinary Medicine
(SNOMED)
05 - Common Dental Terminology (CDT)
06 - First DataBank MDDB Product Line
07 - American Psychiatric Association
Diagnostic Statistical Manual of Mental
Disorders (DSM IV)
99 – Other
7.15.5 COVERAGE INFORMATION DETAIL – QUANTITY LIMITS (QL)

Record Type Identifies record AN M Value = QDT
type. 3/3
Change Only the Add AN M A – Addition

Identifier option is 1/1 C – Change
accepted. D – Delete
Coverage ID The membership AN M Relates to the Coverage ID returned in

population to 1/40 the Surescripts Eligibility response
which the (located in loop 2110C1, REF segment,
coverage rule qualifier = ‘CLI’).
applies.
Product/Service Drug ID (NDC) AN M Mandatory because Class ID is no

ID - Source 1/19 longer used.
Product/Service ID qualifier is sent,
then both are required.


03 = National Drug Code (NDC) - This
can be the representative NDC
Number. 09 = Health Care Financing
36 = Representative National Drug
Code (NDC)
Product/Service ID qualifier is sent,
then both are required.
Variance from Formulary and
Benefit 3.0: Only NDC is supported
by Surescripts.
Drug Identifier for the AN C Qualified by Drug Reference Qualifier

Reference drug from 1/35 Used if Product/Service ID or RxNorm
Number proprietary code Code is not specified.
sources.
If either Drug Reference Number or
Drug Reference Qualifier is sent, then
both are required.
Drug Code value that AN C See Formulary Status Detail on

Reference identifies the 1/3 page 226 for values.
Qualifier source and type If either Drug Reference Number or
for the Drug Drug Reference Qualifier is sent, then
Reference both are required.
Number.
RxNorm Code ID from RxNorm AN C Qualified by RxNorm Qualifier.

database. 1/15 Used if Product/Service ID or Drug
unable to match.
RxNorm Code qualifying AN C Values:

Qualifier the RxNorm code 1/3 This field is constrained to the following
submitted. values:


Maximum Maximum amount R C – required if Maximum If dollar amount, No dollar sign.
Amount qualified by 1/10 Amount Qualifier is Decimal required if value includes
Amount Qualifier present. cents. Currency: USD
The length includes the decimal point.
If Max Quantity then quantity is stated in
this NDC unit of measure
Maximum This field qualifies AN C –required if Maximum Valid values are:

Amount the amount in the 2/2 Amount is present. DL=“Dollar Amount”
Qualifier Maximum
Amount. DS=”Days Supply”
FL = “Fills”
QY=”Quantity”
Maximum Type of time AN C – required if Maximum Valid values are:

Amount Time period associated 2/2 Amount Qualifier = “DL”, CM=”Calendar Month”
Period with the overall “FL” or “QY” Optional if
Maximum Amount Maximum Amount CQ =”Calendar Quarter”
Qualifier. Qualifier is “DS”. CY=”Calendar Year”
DY= “Days”
LT=“Lifetime”
PD=”Per Dispensing”
SP=”Specific Date Range”
Maximum Starting date of DT C – required if Time CCYYMMDD

Amount Time Specific Date 8/8 Period = "SP”, otherwise
Period Start Range not populated.
Date
Maximum Ending date of DT C – required if Time CCYYMMDD

Amount Time Specific Date 8/8 Period = ”SP””,
Period End Range otherwise not
Date populated.
Maximum Number of units N C – required if Maximum

Amount Time associated with 1/4 Amount Time Period =
Period Units the overall Time “DY”, “CQ” “CY” or “CM”
Period otherwise not
populated.
7.15.6 COVERAGE INFORMATION DETAIL – AGE LIMITS (AL)

Record Type Identifies record type. AN M Value = GDA
3/3

D – Delete


Coverage ID The membership AN M Relates to the Coverage ID returned in the
population to which the 1/40 Surescripts Eligibility response (located in
coverage rule applies. loop 2110C1, REF segment, qualifier =
‘CLI’).
Product/Service Drug ID (NDC) AN M Mandatory because Class ID is no longer

ID - Source 1/19 used.
both are required.

Common Procedural Coding System
(HCPCS)
(NDC)
both are required.
3.0: Only NDC is supported by Surescripts.
Number Code is not specified.
required.
Drug Code value that identifies AN C See Formulary Status Detail on page 226
Reference the source and type for the 1/3 for values.
Qualifier Drug Reference Number. If either Drug Reference Number or Drug
required.

1/15 Used if Product/Service ID or Drug
unable to match.


Qualifier RxNorm code submitted. 1/3 This field is constrained to the following
values:
Minimum Age Minimum age at which the N C, if If minimum does not apply, leave blank
drug is covered (inclusive) 1/3 Minimum
Age
Qualifier is
populated
Minimum Age Qualifier for the Minimum AN C, if D = Days

Qualifier Age field: Years or Days 1/1 Minimum Y = Years
Age is
populated
Maximum Age Maximum age at which N C, if If maximum does not apply, leave blank
the drug is covered 1/3 Maximum
(inclusive) Age
Qualifier is
populated
Maximum Age Qualifier for the Maximum AN C, if D = Days

Qualifier Age field: Years or Days 1/1 Maximum Y = Years
Age is
populated
7.15.7 COVERAGE INFORMATION DETAIL – GENDER LIMITS (GL)

Record Type Identifies record type. AN M Value = GDT
3/3

D – Delete
Coverage ID The membership population AN M Relates to the Coverage ID returned in the

to which the coverage rule 1/40 Surescripts Eligibility response (located in loop



03 = National Drug Code (NDC) - This can be
the representative NDC Number
(NDC)
Reference proprietary code sources. 1/35 Used if Product/Service ID or RxNorm Code is
Number not specified.
required.
required.


Gender Gender for which the drug is AN M 1 = Male

covered 1/1 2 = Female

7.15.8 COVERAGE INFORMATION DETAIL – RESOURCE LINK – DRUG SPECIFIC

(RD)
Record Type Identifies record type. AN M Value = RRT
3/3

D – Delete
Coverage ID The membership population AN M Relates to the Coverage ID returned in the

to which the coverage rule 1/40 Surescripts Eligibility response (located in loop

ID 1/19 Variance from Formulary and Benefit 3.0:
ID qualifier is sent, then both are required.

03 = National Drug Code (NDC) - This
can be the representative NDC
Number.
(NDC)
ID qualifier is sent, then both are required.
Variance from Formulary and Benefit 3.0:
Only NDC is supported by Surescripts.
Reference proprietary code sources. 1/35 Used if Product/Service ID or RxNorm Code is
Number not specified.
required.
required.



Resource Link Identifies the type of coverage AN M AL - Age Limits

Type information contained at the 2/2 CP - Copay
URL listed below.
DE - Product Coverage Exclusion
FM – Formulary
GI - General Info
GL - Gender Limits
PA - Prior Authorization
QL - Quantity Limits
ST - Step Therapy
URL The web page address. AN M Only one URL may be associated with each
1/255 coverage id / resource type combination.
7.15.9 COVERAGE INFORMATION TRAILER

Record Identifies record AN M Value = GTR
Type type. 3/3
Record Total Records N M Do not include the Coverage Information Header and Trailer records
Count included in this 1/10 in this count. Total of Coverage Information Detail records.
list

7.16 BENEFIT COPAY LIST
7.16.1 COPAY HEADER

Record Identifies record type. AN M Value = CHD
Type 3/3
Copay ID for the list. AN M Must be unique across all lists of this type. Provides
List ID 1/10 the linkage for managing the processing of detail
data over time.
Valid characters are (A-Z, a-z, Numeral 0-9, period
“.”, and a dash “-“)
Copay Code identifying the type of Copay AN M SL – Summary Level

List being conveyed 1/2 DS – Drug Specific
Type
Note: When selecting SL copay type the CDT detail
type must be used.
When selecting DS copay type the CRT detail must
be used,
List Tells the receiver that this is a Full AN M F = Full list replacement (If list with this List Type /
Action list replacement (Or Add) or a 1/1 List ID exists, replace; if not, add)
delete list. U = Update File
D = Delete List
The update option is not currently Note: If the Header Transaction Action is a Delete,
supported. the detail records should be ignored (if present) by
the Retriever.

Effective 8/8
Date
7.16.2 COPAY INFORMATION DETAIL – SUMMARY LEVEL (SL)

Record Identifies record type. AN M Value = CDT
Type 3/3

D – Delete
Copay ID The membership population to AN M Relates to the Copay ID

which the Copay rule applies. 1/40 returned in the Surescripts
Eligibility response (located
in loop 2110C1, REF
segment, qualifier = ‘IG’).


Formulary Status of drug in formulary AN M 1 – Non-Formulary
Status 1/2 2 – On Formulary (Not
Preferred)
3 - Preferred Level 1
Up to 99
Note: 0 (Non-
Reimbursable) is not
allowed
A = Any
Product Type of drug: Branded, Multi-Source AN M 0 = Not Specified

Type Branded, Generic 1/1 1 = Single source brand
2 = Branded generic
3 = Generic
4 = O.T.C. (over the
counter)
5 = Compound
6 = Supply
A = Any
Pharmacy Dispensing pharmacy type. AN M R = Retail

Type 1/1 M = Mail Order
S = Specialty
L = Long-term Care
A = Any
Out of If the copay varies according to the R C No dollar sign. Decimal

Pocket patient’s out of pocket, this is the 1/10 required if value includes
Range lower range value. cents. Currency: USD
Start The length includes the
decimal point.
Out of If the copay varies according to the R C No dollar sign. Decimal

Pocket patient’s out of pocket, this is the 1/10 required if value includes
Range upper range value. cents. Currency: USD
End The length includes the
decimal point.
Field not populated
indicates no upper limit to
range.
Flat Fixed Copay amount R C at least one of the No dollar sign. Decimal
Copay 1/10 following fields must be required if value includes
Amount populated: Flat Copay cents.
Amount, Percent Copay The length includes the
Rate, or Copay Tier decimal point.
Currency: USD


Percent Percentage Copay rate R C - at least one of the Percentage expressed as a
Copay 1/10 following fields must be decimal (e.g., 0.0 through
Rate populated: Flat Copay 1.0 represents 0% through
Amount, Percent Copay 100%).
Rate, or Copay Tier The length includes the
decimal point.
First First Copay term (flat Copay amount AN C – This is required if F = Flat Copay
Copay or percent Copay) to be considered 1/1 both Flat Copay and P = Percent Copay
Term Percent Copay are
populated.
Minimum Minimum total Copay to be paid by R C – This can only be No dollar sign. Decimal
Copay the patient 1/10 sent if Percent Copay required if value includes
Rate is populated. cents. Currency: USD
Do not use if Percent The length includes the
Copay Rate is not decimal point.
populated. Min/Max: Should only be
sent if Percent Copay is
populated.
Maximum Maximum total Copay to be paid by R C -This can only be sent No dollar sign. Decimal
Copay the patient 1/10 if Percent Copay Rate is required if value includes
populated. cents. Currency: USD
populated. Min/Max: Should only be
sent if Percent Copay is
populated.
Days The days’ supply associated with N C

Supply the stated Copay terms 1/3
per
Copay
Copay This medication’s Tier; an indication N C - at least one of the The Copay Tier value may
Tier of the cost to the patient. Lower 1/2 following fields must be not be greater than the
values represent lower cost to the populated: Flat Copay Maximum Copay Tier value
patient (e.g., Tier 1 is less costly to Amount, Percent Copay
the patient than Tier 2) Rate, or Copay Tier
Maximum Provides the range within which the N C – if Copay Tier is

Copay Copay Tier is stated. The highest 1/2 populated
Tier Copay tier within that range.
7.16.3 COPAY INFORMATION DETAIL – DRUG SPECIFIC (DS)

Record Type Identifies record type. AN M Value = CRT
3/3


D – Delete
Copay ID The membership population to AN M Relates to the Copay ID

which the Copay rule applies. 1/40 returned in the
Surescripts Eligibility
response (located in loop
2110C1, REF segment,
qualifier = ‘IG’).
Product/Service Drug ID (NDC) AN M Mandatory because Class

ID - Source 1/19 ID is no longer used.
Variance from
3.0: Surescripts requires
N 11/11.
If either Product/Service
ID or Product/Service ID
Qualifier is sent, then both
are required.
Product/Service Drug ID qualifier AN M 01 = Universal Product

ID Qualifier 2/2 Code (UPC)
(HRI)
representative NDC
Number.
09 = Health Care
Financing Administration
Common Procedural
Number (UPN)
36 = Representative
National Drug Code
(NDC)
Variance from
3.0: Only NDC is
If either Product/Service
ID or Product/Service ID
qualifier is sent, then both
are required.


Drug Identifier for the drug from AN C Qualified by Drug
Reference proprietary code sources. 1/35 Reference Qualifier
Number Used if Product/Service ID
or RxNorm Code is not
specified.
Number or Drug
Reference Qualifier is
sent, then both are
required.
Drug Code value that identifies the AN C See Formulary Status

Reference source and type for the Drug 1/3 Detail on page 226 for
Qualifier Reference Number. values.
Number or Drug
Reference Qualifier is
sent, then both are
required.
RxNorm Code ID from RxNorm database. AN C Qualified by RxNorm

1/15 Qualifier.
Used if Product/Service ID
or Drug Reference
Number is not specified or
unable to match.
If either Drug RxNorm
code or RxNorm Qualifier
is sent, then both are
required.

Qualifier submitted. 1/3 This field is constrained to
the following values:
SCD = Semantic
Clinical Drug
Drug
If either Drug RxNorm
code or RxNorm Qualifier
is sent, then both are
required.
Pharmacy Type Dispensing pharmacy type AN C R = Retail

1/1 M = Mail Order
S = Specialty
L = Long-term Care
A = Any


Flat Copay Fixed Copay amount R C - At least one of the No dollar sign. Decimal
Amount 1/10 following fields must required if value includes
be populated: Flat cents.
Copay Amount, The length includes the
Percent Copay Rate, decimal point.
or Copay Tier
Currency: USD
Percent Copay Percentage Copay rate R C - At least one of the Percentage expressed as
Rate 1/10 following fields must a decimal (e.g., 0.0
be populated: Flat through 1.0 represents
Copay Amount, 0% through 100%)
Percent Copay Rate, The length includes the
or Copay Tier decimal point.
First Copay First Copay term (flat Copay AN C – This is required if F = Flat Copay
Term amount or percent Copay) to be 1/1 both Flat Copay and P = Percent Copay
considered Percent Copay are
populated
Minimum Minimum total Copay to be paid R C – Can only be sent if No dollar sign. Decimal
Copay by the patient 1/10 Percent Copay Rate is required if value includes
populated. If there is no
minimum/maximum
copay, do not send this
field.
Maximum Maximum total Copay to be paid R C -Can only be sent if No dollar sign. Decimal
Copay by the patient 1/10 Percent Copay Rate is required if value includes
populated. If there is no
minimum/maximum
copay, do not send this
field.
Days Supply The days’ supply associated with N C

per Copay the stated Copay terms 1/3
Copay Tier This medication’s Tier; an N C - at least one of the The Copay Tier value
indication of the cost to the 1/2 following fields must may not be greater than
patient. Lower values represent be populated: Flat the Maximum Copay Tier
lower cost to the patient (e.g., Tier Copay Amount, value
1 is less costly to the patient than Percent Copay Rate,
Tier 2) or Copay Tier
Maximum Provides the range within which N C – if Copay Tier is

Copay Tier the Copay Tier is stated. The 1/2 populated
highest Copay tier within that
range.

7.16.4 COPAY TRAILER

Record Identifies record type. AN M Value = CTR
Type 3/3
Record Total Records Processed N M Do not include the Copay Header and Trailer records in this
Count for this Copay List 1/10 count. Total of Copay Information Detail records.
7.17 FORMULARY AND BENEFIT FILE VALIDATION (FOR

PBM/PAYERS)
A formulary and benefit file coming from a Formulary Publisher goes through a series of validations
at Surescripts before it is loaded. These validations are described in the following sections. For
more information on the possible error codes returned, refer to the Reject Code Summary on
page 258.
7.17.1 FORMULARY AND BENEFIT FILE HEADER AND TRAILER VALIDATION

The formulary and benefit file header and trailer is the wrapper for the entire file. Surescripts
performs the following validations for the file header and trailer:
1. Validate the proper physical format of the header (required fields are present and contain
valid values as defined in Surescripts’ specification).
2. Validate the sender (source) Participant ID and password.
3. Validate that the File Type (Usage Indicator) is valid for the system the file is sent to (i.e. T for
Test, P for Production).
4. Validate the version number.
5. Validate the record length and termination of the header and trailer.
Upon failure of the validations performed in steps 1-5, Surescripts submits a Response File to the
Formulary Publisher with the appropriate error code. Processing stops when a header level error is
encountered.
7.17.2 FORMULARY AND BENEFIT RESPONSE FILE

A Response File is posted for the formulary provider to retrieve after it has been loaded or
attempted to load. It contains information related to any errors, encountered by recipient while
attempting to load the file.
For more detailed information on the error codes sent within the Response File, refer to the Reject
Code Summary on page 258.

7.17.3 FORMULARY AND BENEFIT RESPONSE FILE HEADER

Header Info

Record Type Identifies record type. AN M Value = SHD
3/3
Version/Release Version Number of this AN M 30

Number specification 1/2
Sender ID ID as assigned by Surescripts AN M S00000000000001

identifying Surescripts 3/30
Recipient ID ID assigned by Surescripts for AN M

the recipient or Formulary 3/30
Publisher (original sender of
the Formulary and Benefit
Data Load.)
Sender Password assigned by AN M

Participant Surescripts for accessing the 10/10
Password PBM/payer system.
Transaction Unique identifier defined by AN M

Control Number the sender 1/10
Transaction Date message was created DT M CCYYMMDD

Date 8/8
Transaction Time message was created TM M HHMMSSDD

Time 8/8
Transaction File Identifier telling receiver the AN M FRE – Formulary Transaction Response
Type type of file. 1/3
Transaction Number of the original AN M

Number - formulary message 1/10
Originating
Transaction Date Original Incoming File DT M CCYYMMDD

Date- was created (D8 -) 8/8
Originating
Transaction Time Original Incoming File TM C HHMMSSDD

Time- was created 8/8
Originating
File Type Test or Production (T/P) AN C T=Test

(Usage 1/1 P=Production
Indicator)


Load Status Code Explaining the status of AN C 01 File loaded correctly.
the load. 2/2 The entire formulary and benefit data load file
has loaded without any errors. No detail row
errors exist.
02 File loaded with errors
The file was partially loaded due to row level
errors. For row error information, refer to the
Reject Codes section.
03 File contains errors - File Not loaded
The entire file was unable to load because of
errors. This error code is only used for Full
Replace processes or with Update processes
where all lists contain an error and none of
the lists are loaded.
04 System Error – An error has occurred
during processing not related to the structure
of the file. Contact Surescripts and then
resend the same file.

Detail Info

Record Type Identifies record type. AN M Value = SDT
3/3
Absolute The absolute row or line N M If the row number is 1 then the error is for the file
Row number in the file that 1/10 header.
Number contains the error.
Section Column number that contains N 1/2 M Column number of error in row. The first field -
Column in the error Record Type is considered column 0, the next field
Error is considered column 1.
Reject Code Describes error for this AN M See Reject Code Summary below
column 4/4
Note: If an error occurred, the
entire list that the error was in
did not load.
Additional Free text description of the AN C

Message error 1/100
Information
Data in Error Copy of the bad data AN C If the data in error is longer than 100 characters it
1/100 will be truncated. If a pipe character is in the data it
will be represented as [PIPE]
Trailer Info

Record Type Identifies record type. AN 3/3 M Value = STR
Total Rows in Error N 1/10 M
Total Errors N 1/10 M
7.17.4 REJECT CODE SUMMARY

For any validation error, an error message is sent including the reject code value and a detailed
description.
When the Formulary and Benefit File Header Load Status contains “02 – File loaded with errors” or
“03 – File contains errors – File not loaded”, the following reject code values may be reported:
l If a file header or a file trailer contains an error, the processing of the entire file is stopped and
the entire file is rejected. Response file contains load status “03”.
l If a list header or list trailer contains an error, that list will be rejected, but any other valid lists
in the file will be processed. Response file has load status “02”.
l If a detail row contains an error, the row containing the error is rejected, but the rest of the list
and file will be processed. Response file has load status “02”.
Example of an error message:

SDT|22|5|1007|Required length: 1 - 35|1782^Acetaminophen-Propoxyphene

Hydrochloride
Note: The process that Surescripts is using to process the formulary files is an enhancement to
what is in the standard. This enhanced process is needed to provide clearer error details and
less rejections of the entire file.
Code Surescripts Detailed Error Message Description

1001 No Valid Detail 1.0
1002 Required list missing
1003 Unknown Segment - there is an extra blank line in the file
1004 Unexpected Segment - header can only be on first line
Unexpected Segment - list detail with no list header
Unexpected Segment - wrong detail type for header
Unexpected Segment - non valid record identifier
Unexpected Segment – missing list trailer
Unexpected segment - list header type does not match list trailer type
Unexpected segment - missing list header
1006 Required field missing
All fields or no fields must be populated: drug-reference-number drug-reference-qualifier
Field [field name 1] is greater than [field name 2] and should be <= [value of field name 2]
Field [field name] is required when [field name] = [specific value]
Field [field name] must be empty when [field name] = [specific value]
Fields [list of fields] require [field name]
Field [field name] must be <= [field name]
At least [number] fields must be populated: [list of fields]
Field [field name] is required when [field name 2] is populated, or [field name 3] is empty
1007 Required length: 1 - 35
Not in range [1-99]

Code Surescripts Detailed Error Message Description

1009 Disallowed characters found
Not one of allowed values
This value must be numeric
Invalid Date Format expect: yyyyMMdd
Not matching pattern: [A-Za-z0-9 .-]+
Invalid Date: yyyyMMdd
Invalid Time Format expect: HHmmssdd
Invalid Transmission Action
Invalid Usage Indicator
Invalid Extract Date Format: yyyyMMdd
1010 Extra Data Found After Segment - max fields: 12
1012 List Trailer count: 3 expected 2
1013 Invalid Participant ID or Password
Invalid Receiver Id
1014 Duplicate detail record
9000 Contract does not exist
9000 System Exception
7.18 SURESCRIPTS TRANSLATION FROM VERSION 1.0 TO 3.0 AND

3.0 TO 1.0
1.0 Field 3.0 Field Gap 1.0 to 3.0 3.0 to 1.0 Translation
Translation
Step N/A Not in standard Receivers of 3.0 Receivers of 1.0 will not receive
Medication will not receive Class ID due to translation to 1.0
Class ID Class ID due to
translation to 3.0
Step
Medication
Sub Class ID
Product Type Product 7 - Multi Source Map to 0 = Not Receivers of 1.0 will not receive
Brand Not in Specified product type code 7-Multi-Source
standard Brand due to translation to 1.0.

Translation
Multiple Lists Multiple Lists New Value of N/A Product/Service ID Qualifier of “36”
Product/ Product/Service “36” is allowed in will be changed to “03”
Service ID ID Qualifier v3.0 and not in
Qualifier v1.0.
This will affect
the following
lists and sub-
types:
*Formulary
Status Detail
*Copay - Drug
Specific
*Coverage
Benefit
Coverage
Benefit Type:
Text
Message
Prior
Authorization
Step
Therapy
Step
Medication
Quantity
Limits
Resource
Link - Drug
Specific
Age Limits
Gender
Limits

Translation
RxNorm and Fields in v3.0 Not sent so not Not supported in v1.0.
RxNorm supported with a mapped.
Qualifier limited number of
values.
Added fields and
qualifiers to v3.0 In v1.0 these
from v1.0 fields were not
used.
This will affect
the following
lists and sub-
types:
*Formulary
Status Detail
*Copay - Drug
Specific
*Coverage
Benefit
Coverage
Benefit Type:
Text
Message
Product
Coverage
Exclusion (Drug
Exclusion)
Prior
Authorization
Step Therapy
Step
Medication
Quantity
Limits
Resource
Link - Drug
Specific
Age Limits
Gender
Limits
Copay List Copay List v1.0 allows for A Product Type

Product Type Product Type use of a value = Code with a value N/A since value of 7 is not allowed
Code Code “7”; of “7” will be in v3.0.
v3.0 does not translated to a
allow this value. code of “0”,
Unspecified List

Translation
Copay List Copay List This is a If the v1.0 field is N/A
Type of Type of Mandatory field empty, Surescripts
Pharmacy Pharmacy in v3.0; in v1.0 it will translate the
is Conditional data to v3.0 by
adding “A” (all) in
the Pharmacy
Type field
Coverage Coverage List v1.0 allows use List Type Codes of N/A
List List Type Field of codes MN and MN and RS codes
List Type RS for the List will be dropped.
Field Type field.
v3.0 will NOT
accept codes MN
and RS for the
List Type field.
Coverage Medical v1.0 allows use Translation v1.0 to N/A

List – Necessity List is of a Medical v3.0 Medical
Medical eliminated in Necessity List; Necessity List will
Necessity v3.0 v3.0 does not be dropped when
include a Medical translating from
Necessity List. v1.0 to v3.0 – no
Medical Necessity
List will display in
v3.0
Coverage Resource v1.0 allows use Translation v1.0 to N/A

List – Summary List is of a Resource v3.0 Resource
Resource eliminated in Summary List; Summary list will
Summary v3.0 v3.0 does not be dropped when
include a translating from
Resource v1.0 to v3.0 – no
Summary List. Resource
Summary List will
display in v3.0
N/A Coverage List- Mandatory V3.0 Surescripts will eliminate the Message Type code
Text message: Text Message systematically data that was included in Text
Message Type Type; does not populate a Message
Field exist in v1.0 Message Type
field with a value of
"GI" (General
Information).

Translation
Coverage Coverage List- v1.0 contains If data is contained If sent will drop and not translate to
List-Step Step fields for data in the inbound v1.0 v1.0
Medications Medications relative to the list, it will be
Use of Classification ID dropped
Classification and the Sub-
and Sub- Classification ID;
Classification they will not be
IDs is used in v3.0
eliminated.
Alternative Alternative Drug TWO N/A Translations from v3.0 to v1.0 will
Drug Detail Detail List OCCURRENCES Fields are not used drop this data and will not be
List RxNorm and of RxNorm Code in v1.0 available in the translation v1.0
& the Qualifier
RxNorm are in this list,
Qualifier
one associated
with Product ID-
SOURCE and
one with the
Product ID-
ALTERNATIVE
Classification N/A The If a Classification N/A

List Classification list List is included in
is allowed in v1.0 v1.0, the data will
but is not be dropped and
available in v3.0 not translated to a
v3.0 list.
The definition of the value “03” in

Product/Service ID Qualifier (436-
E1) was changed to National Drug
Code (NDC) to match the July 2007
External Code List (ECL). A new
Product/Service ID Qualifier (436-
E1) “36” (Representative National
Drug Code (NDC)) was added
7.19 NCPDP CHANGES FROM VERSION 1.0 TO 3.0

The definition of the value “03” in Product/Service ID Qualifier was changed to National Drug Code
(NDC) to match the July 2007 External Code List (ECL). A new Product/Service ID Qualifier “36”
(Representative National Drug Code (NDC)) was added.
External Code List values were removed from the data elements with a note to see the NCPDP
External Code List. Values remained where the field was constrained in the implementation guide.

To provide a dependable base of information for Formulary and Benefit transmissions, the
Formulary Status List is now required (section “Formulary Data Overview”). Additionally, the
Formulary Status List Header provides fields that allow the sender to specify a default formulary
status for non-listed drugs. In some cases, this is all the information that is necessary to describe
the formulary. Verbiage was added to allow omission of Formulary Status Detail records when the
non-listed formulary policies are used exclusively to convey the drugs’ formulary statuses in section
“General Structural Overview” and “Formulary Status List”. Minor clarifications were made in
sections “High-Level Processing Examples” and “File Processing Options”.
The Classification List and references to it (such as Drug Classification Information) has been
removed due to lack of use. The Classification ID has been removed from the Cross Reference
Detail.
Coverage Information Detail – Medical Necessity (MN) was also removed. Coverage Information
Detail – Resource Link – Summary Level (RS) has been removed.
Formulary Status value 2 was clarified to On Formulary/Non-Preferred. Value 3-99 was clarified to
On Formulary/Preferred. The statement “If 2 or less is sent – the provider vendor will need to check
therapeutic alternatives (whether from the alternatives file or created on the fly)” was added.
Section “Coverage Information” added Text message support. The following has been clarified
from “The file load also enables payers to specify a single coverage-related text message for each
drug” to “A payer may send multiple quantity limits, step medications, text messages and resource
links for the same drug.”
Section “Copay Information” added a bullet about Copay specific text message.
The following fields now reference RxNorm:

l Product/Service ID (407-D7)
l Drug Reference Number (915-B6)
l Product/Service ID – Source (962-HY)
l Drug Reference Number – Source (919-CS)
l Product/Service ID – Alternative (958-HU)
l Drug Reference Number – Alternative (917-B8)
l Product/Service ID – Step Drug (960-HW)
l Drug Reference Number – Step Drug (921-CU)
RxNorm Code and Qualifier are no longer designated for future use.
Coverage Information Detail – Coverage Text Message –

l The field Message – Short (942-GP) and Message – Long (941-GN) comments have been
modified.
l The field Text Message Type (A46-1S) has been added.

7.20 SURESCRIPTS CHANGES FROM VERSION 1.0 TO 3.0

Version/Release Number changes from 10 to 30 in the Formulary and Benefit File Header and the
Formulary and Benefit Response File Header.
Text Message – Short field is mandatory for the PBM/payer in the Surescripts implementation.
Formulary Header Information: Receiver ID was RXHUB in Formulary 1.0 and S00000000000001
in Formulary 3.0.

7.21 USAGE EXAMPLES

Below are examples that illustrate how the formulary and benefits information is accessed and interpreted in a variety of situations. Note
that only the detail pertinent to each example is included in the Content sections; for instance, file headers and trailers are excluded.
7.21.1 FORMULARY STATUS – DRUG LISTED IN PAYER’S FORMULARY

In this scenario, the payer administering the patient’s pharmacy benefit has provided a formulary status (in the Formulary Status List) for
the specific drug being considered.
Note: The payer in this example does not employ the Product Coverage Exclusion list. See a later example for an illustration of its use.
Retrieving the formulary status is a straightforward lookup process, using the patient’s Formulary ID and a drug ID.
Medication: Paroxetine HCL 12.5 mg Tablet, NDC# 00029-3206-13
Step one: Retrieve the patient’s PBM/payer’s Participant ID (P00010) and Formulary ID (100) from the Eligibility 271 message.
Step two: Locate the medication in the Formulary Status List 100, and note the Formulary Status (2 = On-Formulary).
The following shows example content.
Formulary Status List Header (Received from Payer P00010)

Record Formulary Formulary Non-Listed Non-Listed Non- Non-Listed Generic Non- Relative File List
Type ID Name Prescription Prescription Listed Over The Counter Listed Cost Action Effective
Brand Generic Brand Formulary Status Supplies Limit Date
Formulary Formulary Over The Formulary
Status Status Counter Status
Formulary
Status
FHD 100 HealthOne U U U U U 0 F 20150101
National
Formulary

Formulary Status Detail
Record Change Product / Product / Service Drug Drug Reference RxNorm RxNorm Formulary Relative
Type Identifier Service ID ID Qualifier Reference Qualifier Code Qualifier Status Cost
Number
…
FDT A 00029320613 36 2
Formulary Status Trailer
Record Type Record Count

FTR …
Raw Data:
FHD|100|HealthOne National Formulary|U|U|U|U|U|0|F|20150101
FDT….
FDT|A|0029320613|36|||||2
FDT….
FTR|3
7.21.2 FORMULARY STATUS – DRUG NOT LISTED BY PAYER

In this scenario, the payer administering the patient’s pharmacy benefit did not include an entry in their Formulary Status List for the
specific drug being considered.
Note: The payer in this example does not employ the Product Coverage Exclusion list. See a later example for an illustration of its use.

The process has simple formulary status lookup as in the previous example. However, when the Formulary Status List search fails, an
additional step is taken to reference the Non-Listed Prescription Brand Formulary Status value in the Formulary Status List Header.
Medication: Paxil CR 12.5 mg Tablet, NDC# 00029-3206-13
Step one: Retrieve the patient’s PBM/payer’s Participant ID (P00010), and Formulary ID (100) from the Eligibility 271 message.
Step two: Search Formulary Status List 100 for the medication, looking for the product’s NDC in the Product/Service ID field. The
medication’s NDC cannot be found.
Step three: Refer to the Non-Listed Prescription Brand Formulary Status field in the Formulary Status List Header record. That value
applies to this medication: 2 – On Formulary.
Formulary
Status
FHD 100 HealthOne 2 3 1 2 0 0 F 20150101

National
Formulary

Number
FDT …

FTR …
Raw Data:
FHD|100| HealthOne National Formulary|2|3|1|2|0|0|F|20150101
FDT….
FDT…
FTR|..
7.21.3 FORMULARY STATUS – PRODUCT COVERAGE EXCLUSION APPLIES

Formulary Status – Product Coverage Exclusion Applies
In this scenario, the payer administering the patient’s pharmacy benefit uses the Product Coverage Exclusion list to communicate specific
medications that are not covered by certain membership groups.
When a payer utilizes the Product Coverage Exclusion list, an additional pre-step is added to the formulary lookup process. Before
consulting the Formulary Status List, the user searches the Product Coverage Exclusion list for the patient’s Coverage ID and the
medication being considered.
Medication: Paroxetine HCL 12.5 mg Tablet, NDC# 00029-3206-13

Step one: Retrieve the patient’s PBM/payer’s Participant ID (P00010), Formulary ID (100), and Coverage ID (2222) from the Eligibility
271 message.
Step two: Confirm there’s no product coverage exclusion for medication being considered, by searching the Product Coverage Exclusion
list for the Coverage ID 2222 and the medication’s ID.
If the Coverage ID/Drug ID combination is present, the process stops. The patient’s membership group does not cover the medication,
and the Formulary Status is equal to 0 – Not Reimbursable.
Product Coverage Exclusion List
Coverage Information Header – Product Coverage Exclusion (Received from Payer P00010)
Record Type Coverage List ID Coverage List Type File Action List Effective Date
GHD HEALTHONE DE F 20150101
Coverage Information Detail - Product Coverage Exclusion
Record Change Coverage Product / Service Product / Service ID Drug Reference Drug Reference
Type Identifier ID ID Qualifier Number Qualifier
…
GDT A 2222 00029320613 36
Coverage Information Trailer - Product Coverage Exclusion

GTR …
Raw Data:

GHD|HEALTHONE|DE|F|20150101
GDT|A|2222|000293320613|36
GTR|…..
7.21.4 FORMULARY STATUS – USING REPRESENTATIVE NDC

In this scenario, the payer provides formulary status using 11-digit representative NDCs, rather than supplying NDCs for all of a
medication’s packaging variations. On its Formulary Status List, the payer includes one NDC for each “label name” medication—
representing that drug name/strength/dosage form combination.
In the example below, the payer has included just one NDC11 to represent Zyprexa 10 mg Tablet, though there are multiple package
variations for the medication (a 60 count bottle, a 1,000 count bottle, and a unit dose pack, along with other variations offered by
repackagers). Following the guidelines set out elsewhere in this guide, the payer included an NDC which is (a) not repackaged, (b) not
obsolete, and (c) not a unit dose pack.
Note: The payer in this example does not employ the Product Coverage Exclusion list. See a separate example in this section for an
illustration of its use.
Below is a conceptual process for locating a medication within a Formulary Status List containing representative NDCs. Note that
different system implementations of this “logical” process are possible.
Step one: Retrieve the patient’s PBM/payer’s Participant ID (P00010), and Formulary ID (100) from the Eligibility 271 message.
Step two: Reference a third-party or proprietary drug database to gather all NDCs associated with the prescription-level medication
being considered:
l 00002-4117-04 (1,000 count bottle)
l 00002-4117-33 (100 count blister pack)
l 00002-4117-60 (60 count bottle)
Step three: Search Formulary Status List 100 for each NDC gathered in the preceding step. Once a match is made, note the Formulary
Status.

In this example, the third NDC was listed by the payer: 00002-4117-60, with a Formulary Status value of 2.
Therefore, the formulary status for the label name drug, Zyprexa 10 mg Tablet, is 2 – On-Formulary.
Formulary
Status
FHD 100 HealthOne U U U U U 0 F 20150101

National
Formulary
Record Change Product / Product / Service Drug Drug RxNorm RxNorm Formulary Relative
Type Identifier Service ID ID Qualifier Reference Reference Code Qualifier Status Cost
Number Qualifier
FDT A 00002411760 36 2

FTR …
Raw Data:
FHD|100|HealthOne National Formulary|U|U|U|U|U|0|F|20150101
FDT….
FDT|A|00002411760|36|||||2
FDT…
FTR|..
7.21.5 FORMULARY ALTERNATIVE LOOKUP USING PAYER SPECIFIED

Formulary alternative lookup using payer specified formulary alternatives
Medication: Cardene SR 30 mg Oral CpSR, NDC# 00004-0180-91
Step one: Note the off-formulary medication’s.
Step two: Retrieve the patient’s PBM/payer’s Participant ID (P00010), and Alternatives ID (100) from the Eligibility 271 message.
Step three: Search the corresponding Formulary Alternatives List’s NDCs of the off-formulary medication’s drug ID.
Note: This search may yield multiple record matches, indicating there are multiple preferred alternatives for the off-formulary drug.
Step four: Present the matched alternative medications' NDC field, in the order indicated by the Preference Level field (higher-numbered
medications are “more preferred”)
l 00093-0822-01 Nifedipine ER
l 00069-1520-68 Norvasc

Formulary Alternatives List
Formulary Alternatives List (Received from Payer P00010)
Record Type Alternative List ID List Action List Effective Date

AHD 100 F 20150506
Alternative Detail
Record Type Change Identifier Source NDC … Alternative NDC … Preference Level
…
ADT A 00004018091 00093082201 4
ADT A 00004018091 00069152068 3
Record Type Total Records Minus Header and Trailer

ATR …
Raw Data:
AHD|100|F|20150506
ADT|….
ADT|A|00004018091|00093082201|4
ADT|A|00004018091|00069152068|3
ADT|….
ATR|4

7.21.6 COVERAGE – QUANTITY LIMITS AND GENDER LIMITS

This scenario demonstrates how to associate coverage rules with a medication.
The drug in this illustration is covered for women only (a female hormone replacement therapy), within a stated quantity limit.
The steps below locate these coverage rules.
Medication: FemHRT 1/5 5 mcg-1 mg Tablet, NDC# 54868-4679-00
Step one: Retrieve the patient’s PBM/payer’s Participant ID (P00010), Formulary ID (100) and Coverage ID (2222) from the Eligibility
271 message.
Step three: Search the various Coverage Lists for the Coverage ID 2222 and the medication’s ID.
Two matches are made:

l Gender Limit: F = Female
l Quantity Limit: Maximum Amount = 30, Maximum Amount Qualifier = Days Supply
l (30 Days Supply)
Gender Limits List
Coverage Information Header – Gender Limits (Received from Payer P00010)
GHD HEALTHONE GL F 20150101
Coverage Information Detail - Gender Limits

Record Change Coverage Product / Product / Service ID Drug Reference Drug Reference Gender
Type Identifier ID Service ID Qualifier Number Qualifier Code
…
GDT A 2222 54868467900 36 2
Coverage Information Trailer - Gender Limits

GTR …
Raw Data:
GHD|HEALTHONE|GL|F|20150101
GDT…
GDT|A|2222|54868467900|36|||2
GDT…
GTR|…
Quantity Limits List
Coverage Information Header – Quantity Limits (Received from Payer P00010)
GHD HEALTHONE QL F 20150101
Coverage Information Detail - Quantity Limits

Record Change Coverage Product / Product / Drug Drug Maximum Maximum Maximum …
Type Identifier ID Service ID Service ID Reference Reference Amount Amount Amount Time
Qualifier Number Qualifier Qualifier Period
…
GDT A 2222 54868467900 36 30 DS
Coverage Information Trailer - Quantity Limits

GTR …
Raw Data:
GHD|HEALTHONE|QL|F|20150101
GDT…
GDT|A|2222|54868467900|36|||30|DS
GDT…
GTR|…
7.21.7 COPAY – SUMMARY LEVEL AND DRUG SPECIFIC

In this example, the payer provides general copay rules using the Copay Information Detail - Summary Level list. Using that list, it states
the copay terms that generally apply to different types of products (e.g., single-source branded medications, generics, compounds, etc.).
The payer also utilizes the Copay Information Detail - Drug-Specific list to communicate exceptions to those general copay rules. For
instance, a patient may ordinarily have a copay of $20 for single-source branded medications, but for certain branded drugs the copay is
lower.

The scenario below illustrates such a case. The general copay for single-source branded prescription drugs is $20, but for the specific
drug, Risperdal, for which there is no generic alternative, the copay is $10.
The steps below locate the copay information.
Medication: Risperdal 2mg Tablet, NDC# 50458-0320-06
Step one: Retrieve the patient’s PBM/payer’s Participant ID (P00010), Formulary ID (100) and Copay List ID (COP300) from the
Eligibility 271 message.
Step three: Search the Copay Information Detail – Drug-Specific list to determine whether a drug-specific copay was provided by the
payer. Use the following search criteria:
l Copay ID = COP300
l NDC# = 50458-0320-06 (Risperdal 2 mg Tablet)
l One match is made, specifying the copay that applies when dispensed at any type of pharmacy.
l For illustration, the example content below also contains the summary-level copay that represented the general rule (which was
overridden in this scenario):
l Copay List ID = COP300
l Formulary Status = A (Any)
l Product Type = 1 (Single Source Brand)
l Pharmacy Type = A (Any)
l Flat Copay Amount = 20 ($20)
Drug-Specific Copay List
Copay Header (Received from Payer P00010)

Record Type Copay List ID Copay List Type File Action List Effective Date
CHD HEALTHONE DS F 20150101
Copay Information Detail - Drug Specific
Record Change Copay Source Product / Service Product / Service ID … Pharmacy Flat Copay …
Type Identifier ID ID Qualifier Type Amount
CRT A COP300 50458032006 36 A 10
Copay Trailer
CTR …
Raw Data:
CHD|HEALTHONE|DS|F|20150101
CRT…
CRT|A|COP300|50458032006|36||A|10
CRT..
CTR|…
Summary-Level Copay List

CHD HEALTHONE SL F 20150101
Copay Information Detail - Summary-Level
Record Type Change Identifier Copay ID Formulary Status Product Type Pharmacy Type Flat Copay Amount …
…
CDT A COP300 A 1 A 20
Copay Trailer

CTR …
Raw Data:
CHD|HEALTHONE|SL|F|20150101
CDT…
CDT|A|COP300|A|1|A|20
CDT..
CTR|…
7.21.8 COPAY – COMBINATION TERMS

In this example, the patient’s health plan employs copays that are a combination of percentage rates and flat dollar amounts.
The illustration below shows a general copay rule for single-source branded medications where the member pays the first $10 of the
drug’s cost, plus 15% of the remaining cost, not to exceed $30.

The steps below locate the copay information. The example assumes the user is considering a single-source branded prescription
medication.
Step one: Retrieve the patient’s PBM/payer’s Participant ID (P00010), Formulary ID (100) and Copay List ID (COP300).
Step three: Search the Copay Information Detail – Drug-Specific list to determine whether a drug-specific copay was provided by the
payer. In this example, no drug-specific rule was supplied.
Step four: Search the Copay Information Detail – Summary Level list to find the general rule for branded medications.
In the matching entry in the Copay Information Detail – Summary Level list, the rule described above is represented as
l Product Type = 1 (Single source brand)
l Percent Copay Rate = 0.15 (15%)
l First Copay Term = F (Flat copay is applied first)
l Minimum Copay Amount = 10 ($10)
l Maximum Copay Amount = 30 ($30)
Copay Information Detail - Summary Level

Record Change Copay Formulary Product Pharmacy … Flat Copay Percent First Minimum Maximum …
Type Identifier ID Status Type Type Amount Copay Rate Copay Copay Copay
Term
…
CDT A COP300 A 1 A 10 0.15 F 10 30
Copay Trailer

CTR …
Raw Data:
CDT…
CDT|A|COP300|A|1|A| … |10|0.15|F|10|30
CDT..
CTR|…
7.21.9 COPAY – PATIENT OUT-OF-POCKET RULES

In this example, the patient’s health plan varies the patient copay based on their current “out-of-pocket balance” – the amount that the
patient has contributed, to-date, to the cost of their medications.
The illustration below presents a copay plan with different patient copays for the three conditions below:
l If the patient has contributed less than $100 to-date, their copay is $30
l If the patient’s out-of-pocket balance is between $100 and $1,000, their copay is $20
l Lastly, if the patient’s out-of-pocket balance is greater than $1,000, their copay is $10

The steps below locate those copay rules.
Step three: Search the Copay Information Detail - Drug-Specific list to determine whether a drug-specific copay was provided by the
payer. In this example, no drug-specific rule was supplied.
Step four: Search the Copay Information Detail - Summary Level list to find the general rule.
The three matching entries in the Copay Information Detail - Summary Level list codify the rule described above...
First record
l Product Type = A (Any)
l Out-of-pocket Range Start = 0
l Out-of-pocket Range End = 100
l (Patient out-of-pocket balance is between zero and $100)
Second record
l Out-of-pocket Range Start = 100.01
l (Patient out-of-pocket balance is between $100.01 and $1,000)

Third record
l Out-of-pocket Range Start = 1,000.01
l Out-of-pocket Range End = not populated
l (Patient out-of-pocket balance is more than $1,000.01)
Record Change Copay Formulary Product Pharmacy Out-of-pocket Range Out-of-pocket Flat Copay …
Type Identifier ID Status Type Type Start Range End Amount
…
CDT A COP300 A A A 0 100 30
CDT A COP300 A A A 100.01 1000 20
CDT A COP300 A A A 1000.01 10
Copay Trailer


CTR …
Raw Data:
CDT…
CDT|A|COP300|A|A|A|0|100|30
CDT|A|COP300|A|A|A|100.01|1000|20
CDT|A|COP300|A|A|A|1000.01||10
CDT..
CTR|…
7.21.10 COPAY – PATIENT OUT-OF-POCKET / MEDICARE EXAMPLE

This example describes how the new Medicare prescription drug benefit’s out-of-pocket rules would be represented in the Benefit Copay
Lists. The patient’s copay varies from 100% down to 5% based on their current “out-of-pocket balance” – the amount that the patient has
contributed, year-to-date, to the cost of their medications.
The figure below illustrates how a patient’s out-of-pocket balance accumulates according to drug purchases:

Below are the associated copay rules:

l If the patient has contributed less than $250 to-date, their copay is 100% of the cost of the drug.
l If the patient’s out-of-pocket balance is between $250 and $750, their copay is 25% of the cost of the drug.
l If the patient’s out-of-pocket balance is between $750 and $3,600, their copay goes back up to 100% of the cost of the drug.
l Lastly, once the patient’s out-of-pocket balance exceeds $3,600, their copay goes down to 5% of the cost of the medication.
The steps below locate those copay rules. Note: In this example, HealthOne MN is administering the patient’s Medicare benefit.
Step three: Search the Copay Information Detail - Drug-Specific list to determine whether a drug-specific copay was provided by the
payer. In this example, no drug-specific rule was supplied
Step four: Search the Copay Information Detail - Summary Level list to find the general rule.
The four matching entries in the Copay Information Detail - Summary Level list codify the rule described above.
First record

l Out-of-pocket Range Start = 0

l (Patient out-of-pocket balance is between zero and $250)
Second record
l (Patient out-of-pocket balance is between $250.01 and $750)
Third record
l (Patient out-of-pocket balance is between $750 and $3,600)
Fourth record
l Out-of-pocket Range Start = 3,600.01
l Out-of-pocket Range End = not populated
l (Patient out-of-pocket balance is more than $3,600)

Record Change Copay Formulary Product Pharmacy Out-of-pocket Out-of-pocket Percent Copay …
Type Identifier ID Status Type Type Range Start Range End Rate
…
CDT A COP300 A A A 0 250 1.0
CDT A COP300 A A A 250.01 750 0.25
CDT A COP300 A A A 750.01 3600 1.0
CDT A COP300 A A A 3600.01 0.05
Copay Trailer

CTR …
Raw Data:
CDT…
CDT|A|COP300|A|A|A|0|250|1.0
CDT|A|COP300|A|A|A|250.01|750|0.25

CDT|A|COP300|A|A|A|750.01|3600|1.0
CDT|A|COP300|A|A|A|3600.01||0. 05
CDT..
CTR|…
7.21.11 ERROR SCENARIO – FORMULARY STATUS LIST (FOR PBM/PAYERS)

This scenario contains a formulary status header record with an invalid file action of “X”. The error returned in the response file is 1008
“Field value not found in validation table”.
Formulary and Benefit File Header
Reco Versio Send Sender Receiv Receive Sourc Transmiss Transmiss Transmiss Transmiss Transmiss Extract File
rd n er ID Particip er ID r e ion ion Date ion Time ion File ion Action Date Ty
Type /Relea ant Particip Name Control Type pe
se Passwo ant Number
Numb rd Passwo
er rd
HDR 30 ABC PASS XYZ PASS Publis 30011 20150101 12053001 FRM F 201501 T
her 01
Formulary Status List Header
Record Formulary Formulary Non-Listed Non-Listed Non-Listed Non-Listed Non- Relative File List
Type ID Name Prescription Brand Prescription Brand Over Generic Listed Cost Action Effective
Formulary Status Generic The Over The Supplies Limit Date
Formulary Counter Counter Formulary
Status Formulary Formulary Status
Status Status
FHD 100 HealthOne U U U U U 0 X 20150101
National
Formulary

Number
…
FDT A 54868467900 03 2

FTR …

Formulary and Benefit File Trailer
Record Type Total Records

TRL …
Raw Data:
HDR|30|ABC|PASS|XYZ|PASS|Publisher|30011|20150101|12053001|FRM|F|20150101|T
FHD|100|HealthOne National Formulary|||||| 0|X|20150101
FDT….
FDT|A|54868467900|03|||||2
FDT….
FTR|3
TRL|…
Formulary and Benefit Response File Header
Reco Versio Send Receiv Receiver Transmissi Transmissi Transmissi Transmissi Transmissi Transmissi Transmissi File Load
rd n er ID er ID Particip on Control on Date on Time on File on Number on Date - on Time - Typ Stat
Type /Relea ant Number Type - Originating Originating e us
se Passwor Originating
Numb d
er
SHD 30 XYZ ABC PASS 445534 20150101 15053001 FRE 30011 20150101 12053001 T 03
Formulary and Benefit Response File Detail
Record Type Absolute Row Number Section Column In Error Reject Code Additional Message Information Data In Error
SDT 2 10 1008 Field value not found in validation table X

Formulary and Benefit Response Trailer
Record Type Total Rows In Error Total Errors

STR 1 1
Raw Data:
SHD|30|XYZ|ABC|PASS|445534|20150101|15053001|FRE|30011|20150101|15053001|T|03
SDT|2|10|1008|Field value not found in validation table |X
STR|1|1
7.21.12 ERROR SCENARIO – AGE LIMITS

This scenario contains a Coverage Information Detail – Age Limits record. The record contains the maximum age of 18, but not the
qualifier of Y for years. The error returned in the response file is 1006 “Required Field Missing”.
Numb rd Passwo
er rd
her 01
Coverage Information Header – Quantity Limits
GHD HEALTHONE AL F 20150101

Coverage Information Detail – Quantity Limits
Record Change Coverage Product / Product / Service ID … Minimum Minimum Age Maximum Maximum Age
Type Identifier ID Service ID Qualifier Age Qualifier Age Qualifier
…
GDA A 2222 54868467900 36 18
Coverage Information Trailer – Quantity Limits

GTR …
Formulary and Benefit File Trailer

TRL …
Raw Data:
GHD|HEALTHONE|AL|F|20150101
GDA…
GDA|A|2222|54868467900|36||||18
GDA…
GTR|…
TRL|…

Reco Versi Send Recei Receive Transmis Transmis Transmis Transmis Transmis Transmis Transmis Fil Loa
rd on er ID ver ID r sion sion Date sion Time sion File sion sion Date sion Time e d
Type /Relea Particip Control Type Number - - - Ty Stat
se ant Number Originatin Originatin Originatin pe us
Numb Passwo g g g
er rd
SDT 4 13 1006 Required Field Missing
Formulary and Benefit File Response Trailer

STR 1 1
Raw Data:
SDT|4|13|1006|Required Field Missing
STR|1|1
7.21.13 ERROR SCENARIO – AGE LIMITS

This scenario contains a Coverage Information Detail – Age Limits record. The Coverage Information Header record is missing. The error
returned in the response file is 1004 “Unexpected Segment”.

Numb rd Passwo
er rd
her 01
Coverage Information Header – Quantity Limits (MISSING)
Coverage Information Detail – Quantity Limits
Record Change Coverage Product / Product / Service ID … Minimum Minimum Age Maximum Maximum Age
Type Identifier ID Service ID Qualifier Age Qualifier Age Qualifier
…
GDA A 2222 54868467900 36 18
Coverage Information Trailer – Quantity Limits

GTR …
Formulary and Benefit File Transfer

TRL …

Raw Data:
(MISSING)
GDA…
GDA|A|2222|54868467900|36||||18
GDA…
GTR|…
TRL|…
Reco Versio Send Receiv Receiver Transmissi Transmissi Transmissi Transmissi Transmissi Transmissi Transmissi File Load
n er ID er ID on Time - Typ Stat
rd Participa on Control on Date on Time on File on - on Date -
/Relea Number Type Number Originating Originating e us
Type nt
se Originating
Passwor
Numb
er d
SDT 2 1 1004 Unexpected Segment
Formulary and Benefit File Response Trailer

STR 1 1
Raw Data:

SDT|2|1|1004|Unexpected Segment
STR|1|1

Prescription Benefit IG Appendix A: Variances from Formulary 3.0
APPENDIX A: VARIANCES FROM FORMULARY

3.0
Field Field Description Variance Reason for Variance
Product/Service Drug ID qualifier Only NDC is To date NDC is the only universally
ID Qualifier supported. accepted product identifier.
Product/Service Drug ID Surescripts NDCs are numeric and 11 digits in

ID Source requires N 11/11. length.
Mandatory Since no class ID this is the only way to
because Class ID identify the product.
is no longer used.
List Action Tells the receiver that this is a The update Senders have only implemented full file
Full list replacement (Or Add) option is not replacement.
or a delete list. currently
supported
Change Change Only the Add Senders have only implemented add
Identifier option is option.
accepted.
Message Short Text message presented to Mandatory for this Standard is in error indicating this is
prescriber. implementation. optional. If sending a text message
record you need the message.
Product/Service Drug ID qualifier. Required. Since no class ID this is the only way to
ID Qualifier – identify the product.
Step Drug
Drug Code value that identifies the Only support a Surescripts will not be supporting other
Reference source and type for the Drug limited set of code drug databases.
Qualifier Reference Number. values.

Prescription Benefit IG Appendix B: Secure File Transfer
APPENDIX B: SECURE FILE TRANSFER

Surescripts supports the Secure FTP method for file transfer.
File Processing Guidelines

The files received by Surescripts must be in an ASCII line-feed terminated format. Typically, the file
transfer methods will inherently perform character set and record termination translation.
The maximum file size a customer should send to Surescripts is 1 GB. If a customer needs to send
a file larger than 1 GB, they should notify Surescripts to ensure we will be able to process the file.
Note: Compression should be used when possible while sending files to Surescripts. The
preferred file type is .gzip, but other supported file types are .zip and .bzip.
Secure FTP
The Surescripts Response File naming convention will closely match the file name as transfer to
Surescripts, with the addition of a timestamp value appended. Response files can be pulled by the
customer using client software that is compatible with the Surescripts Secure FTP Server. If the
customer has a compatible Secure FTP server, Surescripts can optionally push Response files to
the customer's Secure FTP Server. Contact your Integration Project Manager for more information
on the Secure FTP process.

Prescription Benefit IG Appendix C: Dynamic Delimiters
APPENDIX C: DYNAMIC DELIMITERS

This section contains a full list of characters that are acceptable to use as delimiters.
Note: This applies to X12 270/271 Eligibility messages only.
Char Dec Oct Hex

(bel) 7 0007 0x07
(ht) 9 0011 0x09
(nl) 10 0012 0x0a
(vt) 11 0013 0x0b
(cr) 13 0015 0x0d
(np) 12 0014 0x0c
(fs) 28 0034 0x1c
(gs) 29 0035 0x1d
(rs) 30 0036 0x1e
(us) 31 0037 0x1f
! 33 0041 0x21
" 34 0042 0x22
% 37 0045 0x25
& 38 0046 0x26
' 39 0047 0x27
( 40 0050 0x28
) 41 0051 0x29
* 42 0052 0x2a
+ 43 0053 0x2b
, 44 0054 0x2c
- 45 0055 0x2d
. 46 0056 0x2e

Prescription Benefit IG Appendix C: Dynamic Delimiters
Char Dec Oct Hex

/ 47 0057 0x2f
: 58 0072 0x3a
Ã‚ ; 59 0073 0x3b
< 60 0074 0x3c
= 61 0075 0x3d
> 62 0076 0x3e
? 63 0077 0x3f
@ 64 0100 0x40
[ 91 0133 0x5b
\ 92 0134 0x5c
] 93 0135 0x5d
^ 94 0136 0x5e
_ 95 0137 0x5f
` 96 0140 0x60
{ 123 0173 0x7b
| 124 0174 0x7c
} 125 0175 0x7d
~ 126 0176 0x7e


Prescription Benefit IG 2016-12-12

Uploaded by

Document Information

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

Prescription Benefit IG 2016-12-12

Uploaded by

Copyright:

Available Formats

Prescription Benefit Implementation Guide

December 12, 2016

2800 CRYSTAL DRIVE

Copyright© 2016 by Surescripts, LLC.

All rights reserved. Proprietary and Confidential.

FOR SECTIONS OF THIS IMPLEMENTATION GUIDE

FOR SECTIONS OF THIS CUSTOMER IMPLEMENTATION GUIDE

P UBLISHED 12/12/2016 COPYRIGHT © 2016 BY S URESCRIPTS, LLC. P AGE 3

4.3 Eligibility Transaction Flow 25

P UBLISHED 12/12/2016 COPYRIGHT © 2016 BY S URESCRIPTS, LLC. P AGE 4

7.3.3 Coverage Information 207

P UBLISHED 12/12/2016 COPYRIGHT © 2016 BY S URESCRIPTS, LLC. P AGE 5

7.14.1 Formulary Alternatives Header 229

P UBLISHED 12/12/2016 COPYRIGHT © 2016 BY S URESCRIPTS, LLC. P AGE 6

7.21.8 Copay – Combination Terms 282

P UBLISHED 12/12/2016 COPYRIGHT © 2016 BY S URESCRIPTS, LLC. P AGE 7

Section Section Title Change Description Reason

Throughout Removed 030 – Audit or compare Change to

2.5 Timeouts Re-wrote section for clarification purposes and to Clarification

4.6 270 Eligibility, ISA08 – Added in Surescripts IDs. Clarification

4.7 271 Eligibility, REF01 – Added HJ Identification Card Number Clarification

REF (loop 2110C1) – Added Syntax Note to clarify Clarification

REF (loop 2110C1) – Corrected copy/paste error by Correction

5.2 Surescripts Event Id 2.4 – Changed Subscriber Segment Loop Correction

P UBLISHED 12/12/2016 COPYRIGHT © 2016 BY S URESCRIPTS, LLC. P AGE 8

Updated notes for minimum and maximum copay to Change to

Added to detailed error message for code 1006: Field Clarification

7.21 Usage Examples Remove list of example scenarios as this Clarification

P UBLISHED 12/12/2016 COPYRIGHT © 2016 BY S URESCRIPTS, LLC. P AGE 9

P UBLISHED 12/12/2016 COPYRIGHT © 2016 BY S URESCRIPTS, LLC. P AGE 10

1.1 ABOUT SURESCRIPTS

1.2 ABOUT THIS GUIDE

P UBLISHED 12/12/2016 COPYRIGHT © 2016 BY S URESCRIPTS, LLC. P AGE 11

1.3 DOCUMENT REFERENCES

ASC X12/N/005010X231A1 Implementation Acknowledgement for Health Care Insurance (999)

NCPDP’s Formulary And Benefit Standard Implementation Guide (Version 3, Release 0)

NCPDP’s Formulary and Benefit Implementation Recommendations Document

NCPDP’s External Code List (July 2016)

Surescripts Prescription Benefit Application Certification Requirements

Surescripts Connectivity and Authentication Implementation Guide

The Guide utilizes the ASC X12N/005010X279A1 and X12N/005010X231A1 implementation

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

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

SECTION 2: INTEGRATION & PRODUCTION

2.1 INTEGRATION PROCESS

2.2 TERMINOLOGY USAGE

Term Term usage

P UBLISHED 12/12/2016 COPYRIGHT © 2016 BY S URESCRIPTS, LLC. P AGE 13

2.3 TRANSITION TO PRODUCTION

2.5.1 DATA LOAD CONNECTIVITY

2.5.1.1 SECURE FTP

P UBLISHED 12/12/2016 COPYRIGHT © 2016 BY S URESCRIPTS, LLC. P AGE 14

P UBLISHED 12/12/2016 COPYRIGHT © 2016 BY S URESCRIPTS, LLC. P AGE 15

SECTION 3: MESSAGES OVERVIEW

3.1 PRESCRIPTION BENEFIT & MEDICATION HISTORY PROCESS FLOW

3.2 MESSAGE DESCRIPTIONS

P UBLISHED 12/12/2016 COPYRIGHT © 2016 BY S URESCRIPTS, LLC. P AGE 16

l Health Plan Number/Name

ID Load/Update (Flat File)/Response

Formulary and Benefit Data Load

As requested or scheduled, the PBM/payer sends group-level formulary updates to provider

P UBLISHED 12/12/2016 COPYRIGHT © 2016 BY S URESCRIPTS, LLC. P AGE 17

Medication History Request/Response

3.3 GENERAL INTERFACE DESCRIPTION