Prescription Benefit IG 2011-04-15

Prescription Benefit Implementation Guide
Eligibility Sections are based on the ASC X12N/005010X279 Guide
DATE: APRIL 15, 2011
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 2011 Surescripts, LLC. All rights reserved.
Information in this document is subject to change without notice. This document is the property of Surescripts,
LLC, and contains information that is proprietary and confidential. Surescripts is a registered trademark of
Surescripts, LLC. The Surescripts logo is a trademark of Surescripts, LLC. All other trademarks are the property
of their respective owners.
This document and all other documents, materials, or other information of any kind transmitted or orally
communicated by Surescripts (or its members) in the course of the parties dealings constitute and are hereby
designated as confidential and proprietary information of Surescripts for purposes of the Confidentiality
Agreement entered into by Surescripts and the recipient and are intended by Surescripts to be, and shall be
deemed to be, Proprietary Information under such Confidentiality Agreement.
FOR SECTIONS OF THIS IMPLEMENTATION GUIDE

PERTAINING TO ASC X12 STANDARDS:
Materials Reproduced With the Consent of
Copyright I 2009, Data Interchange Standards Association on behalf of ASC X12. Format I 2009 Washington
Publishing Company. All Rights Reserved. Users of this guide must purchase their own copy of the ASC
X12N/005010X279 and X12N/005010X231 as this guide only includes a subset of those guides. Go
to http://store.x12.org/ to obtain your copy.
FOR SECTIONS OF THIS PARTICIPANT 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 Councils standards documents and their predecessors include
proprietary material protected under the U.S. Copyright Law and that all rights remain with NCPDP.
DOCUMENT CHANGE LOG

The table below tracks significant changes to the document made in the last few months.
Please review these changes as they may pertain to valid or invalid file exchanges.
Publication
Date
Section
Title
Change
Reason
2010/12/07
4.13
Differences Between
4010 and 5010
Added #21 Loop 2120 increased

from 1 repetition to 23.
Clarified #9 Subscriber/Dependent
REF Segment
Correction.
2010/12/16
2.2
Connectivity
Removed URL encoding requirement

and parameter name.
Correction.
2011/01/09
4.8
Eligibility
Change N402 and N403 to optional
Correction.
4.13
Differences Between
4010 and 5010
Clarified which differences are for 270,

271 or both.
Clarification.
4.13
Differences Between
4010 and 5010
Added Country Code and 2100B

REF03 participant name as changes.
Clarification.
4.8
Eligibility
Removed note on 2100B REF03 for

participant name.
Clarification.
Implementation
Overview
Removed VPN
No longer
supported.
2011/01/31
Appendix
A
WebDav Clients
Changed the secure URL for

connecting to the WebDav Directory.
Correction.
2011/02/03
Formulary & Benefit

Data Load
Changed the section number for all

references to the Drug Classification
Detail from Section 8.15.2 to Section
7.15.2.
Correction.
2011/03/11
Eligibility
Replaced RXHUB with

S00000000000001
Change to use
number instead
of name for
participant id.
Eligibility
Added extra EB loop for test cases

that included mail, retails, specialty,
and LTC.
Clarification.
Eligibility
Added note to N404 Country Code

Do not send US Country Code
Added note to REF03 at the 2100B
receiver level.
Clarification.
Appendix
A
WebDAV
Adding trailing slash to URL.
Correction.
Formulary & Benefit
Replaced RXHUB with

S00000000000001
Change to use
number instead
of name for
participant id
2011/01/12
SURESCRIPTS CONFIDENTIAL AND PROPRIETARY

NOT TO BE COPIED OR DISTRIBUTED
Publication
Date
Section
Title
Change
Reason
ID Load
Changed S00000000000001 back to

RXHUB.
This was
changed in
error only the
Eligibility and
Formulary &
Benefit sections
were changed
to use new ID.
4.5
Search Options
Corrected the key fields for search.
Correction.
Eligibility
Changed 270 2100B NM103 Receiver

Name to mandatory to match the X12
guide. Added to changes from 4010
section and translation section.
Correction.
Eligibility
Receiver N4 Segment State and

Postal Code changed from
mandatory to optional to match the
X12 guide.
Correction.
Eligibility
Added situational rule to all N4

segments for State and Postal Code
required for US addresses.
Correction.
2011/03/18
2011/04/15
SURESCRIPTS CONFIDENTIAL AND PROPRIETARY

Surescripts Prescription Benefit Implementation Guide
Table of Contents
TABLE OF CONTENTS
SECTION 1 Introduction .................................................................................................11
1.1
Document Purpose ....................................................................................11
1.1.1 Other related Surescripts Guides ............................................................11
1.2
Surescripts Overview .................................................................................13
1.3
Surescripts Service Overview ....................................................................13
1.4
Document References ...............................................................................14
SECTION 2 Implementation Overview ............................................................................15
2.1
Implementation, Certification, and Production ............................................15
2.1.1 Implementation Process .........................................................................15
2.1.2 Certification Process ...............................................................................15
2.1.3 Transition to Production ..........................................................................15
2.2
Connectivity ...............................................................................................15
2.2.1 CAQH CORE Phase II Connectivity Rule................................................16
2.2.2 HTTPS POST .........................................................................................16
2.2.2.1
2.2.2.2
2.2.2.3
2.2.2.4
2.2.2.5
HTTP-Level Authentication ............................................................................. 16

POST Method Snippets .................................................................................. 17
SSL Information .............................................................................................. 19
Server Certificates........................................................................................... 19
Supported Network Connections for HTTPS ................................................... 19
2.3
Transaction Timeouts ................................................................................20
2.3.1 Data Load Connectivity ...........................................................................20
2.3.1.1
2.3.1.2
2.3.1.3
2.3.1.4
2.4
2.5
Connect:Direct ................................................................................................ 20
Secure FTP ..................................................................................................... 21
Data Distribution Connectivity ......................................................................... 21
WebDAV ......................................................................................................... 21
Security .....................................................................................................22
Compliance................................................................................................22
SECTION 3 Transactions Overview ................................................................................24

3.1
Prescription Benefit & Prescription History Transaction Flow .....................24
3.2
Transaction Descriptions ...........................................................................25
3.3
General Interface Description ....................................................................26
3.3.1 Dynamic Delimiters .................................................................................26
3.3.1.1
3.3.1.2
3.3.2
3.3.3
Delimiter Examples .................................................................................27

Representation .......................................................................................28
3.3.3.1
3.3.3.2
3.3.3.3
3.4
Choosing a Delimiter ....................................................................................... 26

Using Dynamic Delimiters ............................................................................... 27
Numeric Representation ................................................................................. 28

Character Set .................................................................................................. 28
Requirement Designation ................................................................................ 29
Transaction Validation ...............................................................................29
SURESCRIPTS CONFIDENTIAL AND PROPRIETARY,

PAGE 5
Table of Contents
3.5
Failure Mode/Response Approach ............................................................ 30
3.5.1 X12 Error Processing.............................................................................. 30
3.6
Connectivity ............................................................................................... 30
SECTION 4 Eligibility ...................................................................................................... 32
4.1
Introduction ............................................................................................... 32
4.2
Relationship to X12N 270/271 Standard .................................................... 32
4.3
Eligibility Message Flow ............................................................................ 33
4.4
Subscriber/Dependent defined .................................................................. 33
4.5
Search Options.......................................................................................... 34
4.5.1 Insufficient information ............................................................................ 34
4.5.2 Multiple Matches..................................................................................... 34
4.6
Patient Match Verification .......................................................................... 34
4.7
Related Transactions................................................................................. 36
4.8
270 Eligibility, Coverage, or Benefit Inquiry ............................................... 36
4.9
271 Eligibility, Coverage, or Benefit Information ........................................ 81
4.10
TA1 Interchange Acknowledgement ........................................................ 182
4.11
999 Implementation Acknowledgement For Health Care Insurance......... 188
4.12
270 and 271 Transaction Examples ........................................................ 208
4.13
Differences Between 4010 and 5010 ....................................................... 217
4.14
Translation .............................................................................................. 219
SECTION 5
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
Eligibility Transaction Processing Summary .............................................. 220

Surescripts Receives the 270 from the Requesting Party (Tech Vendor). 221
Surescripts Processes the 270 ................................................................ 221
Surescripts Attempts to Connect with Source (PBM) ............................... 223
PBM Evaluates the Transaction............................................................... 223
PBM Processes the 270 .......................................................................... 224
PBM Sends 271 Back to Surescripts ....................................................... 227
Summary of Errors Sent to Tech Vendor ................................................. 227
Summary of Translated Errors ................................................................. 228
SECTION 6
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
ID Load ..................................................................................................... 230

Introduction ............................................................................................. 230
ID Load Process Flow ............................................................................. 230
Format to be Used ................................................................................... 230
Member Directory Maintenance Flat File From PBM ............................... 230
Member Directory Response Flat File to PBM ......................................... 233
Member Directory Maintenance Delimited File From PBM....................... 235
Member Directory Response Delimited File to PBM ................................ 238
Member Directory Codes ......................................................................... 239
SECTION 7
7.1
Formulary and Benefit Data Load ............................................................. 242

Introduction ............................................................................................. 242

PAGE 6
Table of Contents
7.2
Formulary and Benefit Summary Information Model ................................243
7.3
Formulary and Benefit Data Overview .....................................................244
7.3.1 Formulary Status ..................................................................................244
7.3.2 Payer-Specified Alternatives .................................................................245
7.3.3 Coverage Information ...........................................................................245
7.3.4 Copay Information ................................................................................246
7.3.5 Drug Classification Information .............................................................246
7.3.6 Cross-Reference Information ................................................................247
7.4
11-Digit Representative NDC ...................................................................247
7.5
High-Level Processing Examples ............................................................248
7.5.1 Flow One: Presenting Formulary & Coverage Information ...................248
7.5.2 Flow Two: Presenting Medication Copay .............................................248
7.5.3 Flow Three: Presenting Formulary Alternatives....................................249
7.6
Formulary and Benefit Data Load Roles ..................................................250
7.7
Formulary and Benefit Data Load Process ..............................................250
7.8
Formulary and Benefit Publishing ............................................................252
7.8.1 File Processing Options ........................................................................252
7.8.2 Environment Setup ...............................................................................253
7.8.3 Formulary and Benefit File Naming and Structure.................................253
7.8.3.1
7.8.3.2
File Naming ................................................................................................... 254

Directory Structure ........................................................................................ 255
7.8.4 Formulary Distribution List Creation ......................................................256

7.9
Formulary Retrieval .................................................................................257
7.9.1 Formulary and Benefit File Distribution .................................................257
7.9.2 Formulary and Benefit File Processing .................................................257
7.9.3 Retrieval Related Errors........................................................................258
7.10
General structural overview .....................................................................259
7.10.1 File Level From The Sender To The Receiver ......................................259
7.11
Formulary and Benefit Data Load Specification .......................................261
7.11.1 File Header/Trailer Definition ................................................................261
7.11.2 Formulary And Benefit File Header .......................................................261
7.11.3 Formulary And Benefit File Trailer.........................................................262
7.12
Formulary Status List ...............................................................................262
7.12.1 Formulary Status Header ......................................................................262
7.12.2 Formulary Status Detail ........................................................................263
7.12.3 Formulary Status Trailer .......................................................................264
7.13
Cross Reference List ...............................................................................264
7.13.1 Cross Reference List Header ................................................................264
7.13.2 Cross Reference Detail .........................................................................265
7.13.3 Cross Reference Trailer ........................................................................265
7.14
Formulary Alternatives List ......................................................................265

PAGE 7
Table of Contents
7.14.1 Formulary Alternatives Header ............................................................. 265

7.14.2 Formulary Alternatives Detail ................................................................ 266
7.14.3 Formulary Alternatives Trailer ............................................................... 267
7.15
Drug Classification List ............................................................................ 267
7.15.1 Drug Classification Header ................................................................... 267
7.15.2 Drug Classification Detail ...................................................................... 268
7.15.3 Drug Classification Trailer ..................................................................... 269
7.16
Benefit Coverage List .............................................................................. 269
7.16.1 Coverage Information Header............................................................... 269
7.16.1.1
7.16.1.2
7.16.1.3
7.16.1.4
7.16.1.5
7.16.1.6
7.16.1.7
7.16.1.8
Coverage Information Detail - Coverage Text Message (TM ) ...................... 270

Coverage Information Detail Product Coverage Exclusion (DE), Prior
Authorization (PA), Medical Necessity (MN), Step Therapy (ST) .................. 271
Coverage Information Detail Step Medications (SM).................................. 271
Coverage Information Detail Quantity Limits (QL) ...................................... 273
Coverage Information Detail Age Limits (AL) ............................................. 275
Coverage Information Detail Gender Limits (GL) ....................................... 276
Coverage Information Detail Resource Link - Summary Level (RS)........... 277
Coverage Information Detail Resource Link - Drug Specific (RD) .............. 277
7.16.2 Coverage Information Trailer ................................................................ 278

7.17
Benefit Copay List ................................................................................... 278
7.17.1 Copay Header ...................................................................................... 279
7.17.1.1
7.17.1.2
Copay Information Detail Summary Level (SL) .......................................... 279

Copay Information Detail Drug-Specific (DS) ............................................. 281
7.17.2 Copay Trailer ........................................................................................ 283

7.18
Formulary and Benefit File Validation ...................................................... 283
7.18.1 Formulary and Benefit File Header and Trailer Validation ..................... 283
7.18.2 Formulary And Benefit List Header and Trailer Validation ..................... 284
7.18.3 Formulary And Benefit Detail Validation ............................................... 284
7.19
Formulary And Benefit Response File ..................................................... 284
7.19.1 Formulary And Benefit Response File Header ...................................... 285
7.19.2 Reject Code Summary.......................................................................... 287
7.20
Usage Examples ..................................................................................... 288
7.20.1 Formulary Status Drug Listed In Payers Formulary ........................... 288
7.20.1.1
Formulary Status List .................................................................................... 289
7.20.2 Formulary Status Drug Not Listed By Payer ...................................... 289

7.20.2.1
7.20.3 Formulary Status Product Coverage Exclusion Applies ..................... 290

7.20.3.1
Product Coverage Exclusion List................................................................... 291
7.20.4 Formulary Status Using Representative NDC .................................... 291

7.20.4.1
7.20.5 Formulary alternative lookup using payer specified .............................. 293

7.20.5.1
Formulary Alternatives List ............................................................................ 293
7.20.6 Coverage Quantity Limits And Gender Limits .................................... 295

7.20.6.1
Gender Limits List ......................................................................................... 295

PAGE 8

7.20.6.2
Table of Contents
Quantity Limits List ........................................................................................ 296
7.20.7 Coverage - Step Medications In Terms Of Drug Class ..........................296

7.20.7.1
7.20.7.2
Step Medications List .................................................................................... 297

Drug Classification List.................................................................................. 298
7.20.8 Copay Summary Level And Drug Specific .........................................298

7.20.8.1
7.20.8.2
Drug-Specific Copay List ............................................................................... 299

Summary-Level Copay List ........................................................................... 300
7.20.9 Copay Combination Terms ................................................................300

7.20.9.1
7.20.10 Copay - Patient Out-Of-Pocket Rules.................................................302

7.20.10.1
7.20.11 Copay - Patient Out-Of-Pocket / Medicare Example ..........................304

7.20.11.1
7.20.12 Error Scenario - Formulary Status List ...............................................307

7.20.13 Error Scenario Age Limits ...............................................................309
7.20.14 Error Scenario Age Limits ...............................................................310
Appendix A: WebDAV Clients .......................................................................................314
1.1.
WebDAV Compression ............................................................................314
1.2.
WebDAV Commands...............................................................................315
1.3.
Microsoft Web Folders .............................................................................315
1.3.1. Supported Platforms .............................................................................315
1.3.2. Installation ............................................................................................315
1.3.3. Connecting to a WebDAV directory.......................................................315
1.4.
Cadaver ...................................................................................................317
1.4.2. Installation ............................................................................................318
1.5.
WebDrive .................................................................................................319
1.5.2. Installation ............................................................................................319
1.6.
CAQH ......................................................................................................322
1.7.
SSL Information .......................................................................................323
1.8.
Server Certificates ...................................................................................323
Appendix B: Secure File Transfer ..................................................................................324
1.1.
File Processing Guidelines ......................................................................324
1.2.
Connect:Direct .........................................................................................324
1.2.1. Connect:Direct Process Setup .................................................................324
1.3.
Connect:Direct Process Configuration .....................................................326
1.4.
Secure FTP .............................................................................................327

PAGE 9
Table of Contents
This page intentionally left blank.

PAGE 10
INTRODUCTION
SECTION 1
1.1
Implementation Overview
DOCUMENT PURPOSE
Prescription Benefit Implementation Guide (This Guide)
This Surescripts Prescription Benefit Implementation Guide was created to assist
Pharmacy Benefit Managers (PBMs) and Physician Systems in developing and
transferring messages needed to provide PBM member data (eligibility information,
pharmacy benefit coverage, group-specific formulary information, and medication
history) to physicians in an ambulatory setting.
The audience for this document includes any Participant responsible for developing a
system interface for these electronic prescribing transactions. This guide describes
the Surescripts Prescription Benefit transaction sets and provides other information
needed for their implementation.
1.1.1
OTHER RELATED SURESCRIPTS GUIDES

Directories Implementation Guide
The Surescripts Directories Guide was created to assist Pharmacies and Physician
Systems in developing and transferring messages needed to send pharmacy and
prescriber data to Surescripts and receive pharmacy and prescriber data from
Surescripts. Complete and accurate directories are essential for prescription
routing. The audience for this document includes any trading partner responsible
for developing a system interface for these directory messages. This guide
describes the directory message sets and provides other information needed for
their implementation.
Prescription History Implementation Guide
This Surescripts Prescription History Implementation Guide was created to assist
Pharmacy Benefit Managers (PBMs) and Physician Systems in developing and
transferring messages needed to provide medication history to physicians in an
ambulatory setting.
The audience for this document includes any Participant responsible for developing
a system interface for these electronic prescribing transactions. This guide
describes the Surescripts Prescription History transaction sets and provides other
information needed for their implementation.
Prescription History Acute Implementation Guide
The Prescription History Acute guide was created to:
Assist hospitals in developing and transferring messages needed to

provide physicians treating hospitalized patients access to outpatient
medication history.
Assist Pharmaceutical Benefits Management (PBM) companies as a
claims source in responding to a medication request and developing a
medication response.
LAST PUBLISHED 4/15/11

PAGE 11
a system interface for these transactions. This guide describes the Surescripts
Prescription History Acute transaction sets and provides other information
Prescription Routing Implementation Guide
This Surescripts Routing Implementation Guide was created to assist Pharmacies
and Prescriber Systems in developing and transferring messages needed to
provide direct conveyance of new prescriptions from physician to pharmacy, and of
refills and change requests from pharmacy to physician.
This document represents XML and EDIFACT implementations. The audience for
this document includes any Participant responsible for developing a system
interface for these electronic prescribing transactions.
Participant Implementation Guide for Eligibility 5010
This Surescripts Eligibility Implementation Guide was created to assist Medicaid
Management Information System (MMIS) vendors that process Medicaid and
Pharmacies in developing and transferring messages needed to provide PBM
member data (eligibility information, pharmacy benefit coverage, group-specific
formulary information, and medication history) to physicians and pharmacies in an
ambulatory setting.
a system interface for these electronic prescribing transactions. This guide
describes the Surescripts Eligibility transaction sets and provides other information

PAGE 12
1.2
SURESCRIPTS OVERVIEW
Surescripts operates the nations largest e-prescription network and supports a
rapidly expanding ecosystem of health care organizations nationwide. Surescripts
was founded on the principles of neutrality, transparency, interoperability, efficiency,
collaboration and quality. Surescripts connects prescribers in all 50 states through
their choice of e-prescribing software to the nations leading payers, chain
pharmacies and independent pharmacies. Available during emergencies or routine
care, the Nations E-Prescription network gives health care providers secure, lowcost, electronic access to prescription and health information that can save their
patients lives, improve efficiency and reduce the cost of health care for all. For more
information, go to www.surescripts.com.
1.3
SURESCRIPTS SERVICE OVERVIEW

An electronic connection between payers, prescribers, and pharmacists is essential
to reducing costs and improving the safety and efficiency of the prescribing process.
Patients can feel confident knowing their prescribers are empowered to make the
most clinically appropriate and cost effective treatment decision at the point of care.
Surescripts certifies software used by prescribers, pharmacies, and payers/PBMs for
access to the three core services Prescription Benefit, Prescription History, and
Prescription Routing Services.
Prescription Benefit
Surescripts is working with the nation's pharmacy benefit managers (PBMs) and
payers to offer prescribers access to their patient's Prescription Benefit information in
real time during an office visit. The Prescription Benefit service puts eligibility,
benefits and formulary information at a prescribers fingertips at the time of
prescribing. This enables prescribers to select medications that are on formulary and
are covered by the patients drug benefit. It also informs them of lower cost
alternatives such as generic drugs and ultimately ensures that the staff in the
pharmacy receives a clean script. Unnecessary phone calls from pharmacy staff to
physician practices related to drug coverage are reduced. Prescribers access
prescription benefit information through software from a vendor that is certified for
these services.
Prescription History
Surescripts delivers prescription history information across providers during a
patient's office visit through electronic prescribing and electronic health record
systems that are certified for the Prescription History service. The service is made
possible by Surescripts ability to securely access and aggregate patient prescription
history data from community pharmacies and patient medication claims history from
payers and pharmacy benefit managers.
Prescribers who can access critically important information on their patient's current
and past prescriptions are better informed about potential medication issues with
their patients and can use this information to improve safety and quality. Prescription
History can also be used for reconciliation support for patients being treated in an
inpatient setting (click here to read more about Surescripts Prescription History for
Hospitals service. This service is also called Prescription History Acute.).
Prescription Routing

PAGE 13
By eliminating paper, phone and fax, electronic Prescription Routing makes getting
patients the medications they need a safer and more efficient process. Prescription
Routing replaces old, error-prone approaches to sending new prescriptions e.g.
handwritten prescriptions, computer-printed prescriptions and hand or computerfaxed prescriptions with the secure computer-to-computer exchange of
prescriptions between prescribers and pharmacies. Routing new prescriptions
electronically reduces the risk of medication errors associated with poor handwriting,
illegible faxes and manual data entry.
Using Prescription Routing to process prescription renewals saves health care
professionals time and money by dramatically reducing the number of phone calls
and faxes typically associated with the prescription renewal authorization process.
MGMA studies have estimated that the value of the time spent just on prescription
renewal authorization phone calls costs practices $10,000 a year per physician. With
electronic prescription renewals, prescribers can receive electronic authorization
requests directly and securely to practice computers as an alternative to time
consuming phone calls and faxes. Physicians or authorized staff can then return
approvals or denials with a few mouse clicks at their convenience, in seconds, which
could translate into more time with patients for physicians and more efficient use of
staff.
1.4
DOCUMENT REFERENCES
The following documents were referenced in creating this Implementation Guide:
Document Title
ANSI ASC X12 Standards for Implementation
ASC X12N/005010X279 Health Care Eligibility Benefit Inquiry and Response (270/271) Referred to as
the X12 Guide in the rest of this guide.
ASC X12/N/005010X231 Implementation Acknowledgement for Health Care Insurance (999)
NCPDPs Formulary And Benefit Standard Implementation Guide (Version 1, Release 0)
In conjunction with this Surescripts Prescription Benefit Implementation Guide,

Participants should have a copy of these documents readily available for use with the
transactions.

PAGE 14
IMPLEMENTATION OVERVIEW
SECTION 2
2.1
2.1.1
IMPLEMENTATION, CERTIFICATION, AND PRODUCTION

IMPLEMENTATION PROCESS
The typical timeframe of the Implementation Phase is 3 - 6 months, depending on
your resource allocation for the project. During this time you will be invited to the
Surescripts Education Series, receive Surescripts Network guides / requirement
documentation and your account will be set up to access the Surescripts
staging/certification environment.
2.1.2
CERTIFICATION PROCESS
This phase includes more detailed testing of the transactions and the user interface
to ensure that all Surescripts requirements are met. You will be assigned a
Certification Project Manager who will work with you through the completion of
certification testing. Surescripts will provide more detail surrounding the milestones
that are necessary to certify and move into production. Once a participant passes
certification, services are turned on in production.
2.1.3
TRANSITION TO PRODUCTION
Once Certification is complete, the Participant is ready to move into production.
Surescripts will schedule a hand-off meeting for the business and technical staff of
both Surescripts and the Participant to discuss the following:
2.2
Production Support Contacts (Surescripts and Participants)

Support Process
Support Hours
The Surescripts Network Operations Guide (NOG) will be reviewed as
part of the transition to production.
CONNECTIVITY
To transmit transactions between participants, Surescripts supports the HTTPS
method for connectivity. With HTTPS, Participants act as the client and send
transactions to the server on the Surescripts system. With certain transactions,
Surescripts also acts as the client by sending HTTPS requests to servers on
Participants systems.
The preferred connectivity method is HTTPS with the following specifications:
TCP/IP is the communication protocol utilized between the Participant

and Surescripts.
HTTPS (Version 3) is the preferred application protocol.
A static, registered IP address is required of the Participant.
Participants use the standard HTTPS post method to connect and send
transactions to Surescripts.

PAGE 15
Surescripts uses the standard HTTPS post method to connect and send
transactions to Participants.
The URLs are supplied at the point of integration.
Server certificates with 128-bit encryption are utilized at Surescripts. The
Participant is responsible for providing its own 128-bit (server) digital
certificate.
Separate test and production instances are created for Surescripts and
the Participants systems.
A Participant receiving Point-to-Point messages via SSL from Surescripts
will need to identify the Certificate Authority associated with the
Participants certificate. Surescripts needs to check for the Participants
certificate from that Certificate Authority. If the Participant is using a selfsigned certificate, Surescripts will need the Participants Certificate
Authority certificate.
Outbound HTTP Basic Authentication is an option for Participants, if
needed.
Surescripts supports two methods for inbound connection: CAQH CORE Phase II
Connectivity Rule and HTTP POST. CAQH is a nonprofit alliance of health plans and
trade associations. CAQH launched the Committee on Operating Rules for
Information Exchange (CORE).
2.2.1
CAQH CORE PHASE II CONNECTIVITY RULE

Surescripts follows the CAQH CORE Phase II Connectivity Rule. Refer to the
CAQH web site for details: http://www.caqh.org/pdf/270.pdf. Although the CORE
documentation references 270 transaction, Surescripts will accept all transactions
using the Phase II Connectivity Rule. Specific details regarding field usage will be
coming soon.
2.2.2
HTTPS POST
This section contains supplemental information on the usage of HTTPS
connectivity. The flow of a HTTPS transaction requires the following generic steps:
1. Format the transaction (sending transaction in body)
a. Setting the HTTP content-type to text/xml if xml, or text/plain if not
xml.
b. Write the transaction to the body
2. Send the transaction using the POST method
2.2.2.1 HTTP-Level Authentication

If a Participant's infrastructure requires that incoming HTTP communication must
be authenticated using basic HTTP authentication before being passed along to a
business system for processing, Surescripts will format the Authorization property
in the HTTP header. Participants that are in need of this feature must notify their
Surescripts Implementation Manager during the implementation process.
An example of the HTTP Authorization header formatted by Surescripts for
authentication on the participants system follows:

PAGE 16
Authorization: Basic U1VSRVNDUklQVFM6Tk9QQVNT

where U1VSRVNDUklQVFM6Tk9QQVNT is the result of base64 encoding
SURESCRIPTS:NOPASS (NOPASS was Surescripts password for the receiving
participant system in this example)
2.2.2.2 POST Method Snippets

The following Java Code gives an example of how to POST to Surescipts:
/**
* Send a transaction to the Surescripts Network.
* @param urlString
- The url to use.
* @param transaction - The transaction.

* @param isXML
* @return
- Set to true if this is an XML transaction.

- The response from Surescripts Network.
* @throws Exception On any unhandled error.

*/
public static String sendTransaction(String urlString, String transaction, boolean isXML)
throws Exception
{
OutputStream out;
BufferedReader in;
HttpURLConnection con;
String response = "";
int BUFFER_SIZE = 500;
URL url = new URL(urlString);
con = (HttpURLConnection) url.openConnection();

con.setDoOutput(true);
con.setDoInput(true);
con.setRequestMethod("POST");
con.setRequestProperty("Content-length", String.valueOf(transaction.length()));
con.setRequestProperty("Content-type: ", isXML ? "text/xml" : "text/plain");
out = con.getOutputStream();
// Send the transaction

out.write(transaction.getBytes());
out.flush();

PAGE 17
// The InputStreamReader cannot be created until after the write and

// flush have occurred. If it is, the write fails.
in = new BufferedReader(new InputStreamReader(con.getInputStream()));
char[] cbuf = new char[BUFFER_SIZE + 1];
// Read the response

while (true) {
//String line = in.readLine();
int numCharRead = in.read(cbuf, 0, BUFFER_SIZE);
// If -1, it is the end of the file/stream
if (numCharRead == -1) {
break;
}
// Null terminate the final position of the string read into cbuf
String line = new String(cbuf, 0, numCharRead);
response += line;
}
//close the streams

in.close();
out.close();
con.disconnect();
return response;
The following .NET Code gives an example of how to POST to Surescipts:
/**
* Sends a transaction to the Surescripts Network.
* Parameters:
*
urlString -- The URL to send to.
transaction -- The transaction to submit.
*
* Returns the response from the Surescripts Network.
*

PAGE 18
* Throws System.Net.WebException if it doesn't get a good response.

*/
public static string sendTransaction(string urlString, string transaction) {
ASCIIEncoding encoding=new ASCIIEncoding();
byte[] data = encoding.GetBytes(transaction);
HttpWebRequest req = (HttpWebRequest)WebRequest.Create(urlString);

req.Method = "POST";
req.ContentLength = data.Length;
Stream newStream=req.GetRequestStream();
newStream.Write(data,0,data.Length);
newStream.Close();
HttpWebResponse res = (HttpWebResponse)req.GetResponse();

Stream receiveStream = res.GetResponseStream ();
// Pipes the stream to a higher level stream reader with the

// required encoding format.
StreamReader readStream = new StreamReader (receiveStream, Encoding.UTF8);
string response = readStream.ReadToEnd();

res.Close ();
readStream.Close ();
return response;
}
2.2.2.3 SSL Information

Surescripts expects SSL (HTTPS) traffic on the standard SSL port, 443.
2.2.2.4 Server Certificates

When setting up a Web server to accept SSL, it is necessary to use a digital
certificate. The certificate that is used in the production environment must be
signed by an established certificate authority, such as VeriSign. In the certification
environment, the certificate can be self-signed. In the case of a self-signed cert, it
will be necessary to send a copy of the cert to Surescripts so it can be recognized
as a valid certificate when Surescripts connects to the site.
2.2.2.5 Supported Network Connections for HTTPS


PAGE 19
Participants may use one of the following network connectivity methods with
HTTPS.
2.3
Internet:
o Address filtering will be done in the Surescripts firewall.
o Surescripts will work with Participants to review their current
connection speed and bandwidth to ensure they are adequate for
anticipated transaction volumes.
Frame Relay:
o 128 kbps minimum bandwidth over a frame relay circuit between
Surescripts and the Participant.
o The line must be encrypted with 3DES.
o The Participant must allow Surescripts to install and manage two
routers in their data center that connect to their extranet
environment.
o The Participant must have a dual network connection through two
different telecommunication providers.
TRANSACTION TIMEOUTS
Each transaction that Surescripts submits to a Participant has a time-out parameter.
If Surescripts does not get a response from the Participant within the specified time
period, the transaction times out. Surescripts will then respond to the original sender
in the appropriate manner. The Surescripts default time-out period is 10 seconds.
For round-trip transactions, the initiator of a transaction can expect Surescripts to
time out after 30 seconds of attempting to respond to the request. Therefore, the
initiator should set their time-out to a value at least two seconds greater, or 32
seconds.
For a transaction being sent from Surescripts to a Participant, Surescripts utilizes the
Participant specific time-out to determine when the transactions will time out. For
instance, if a Participant has set their Surescripts specific time-out to 10 seconds,
Surescripts will time out after waiting for an acknowledgment for 10 seconds.
Therefore, the recipient should set their time-out to two seconds less than the set 10
seconds.
2.3.1
DATA LOAD CONNECTIVITY

Surescripts currently supports two data loads that require a participant to send
large flat text files to Surescripts. The Master Patient Index (MPI) Data Load and
the Formulary and Benefit Data Load are created by the PBM and sent to
Surescripts for storage. The Formulary and Benefit File is then ready for
subsequent distribution. For these data loads, Surescripts supports Connect:Direct
and Secure FTP for file transfer between the PBM and Surescripts
2.3.1.1 Connect:Direct
Connect:Direct (formerly known as NDM) is supported for the transfer of Master
Patient Index (MPI) data loads, Formulary and Benefit data loads, and ePrescribing
Activity Reports data loads. Surescripts requires TCP/IP protocol and Server-toServer communications. Connect:Direct compression is optional and highly

PAGE 20
encouraged. Surescripts processes do not have file naming requirements. Security

is enforced by firewall rules and User ID/Password. Participant files are isolated
from other participants files.
Connectivity to Connect:Direct can be established through an encrypted Internet
configuration or through a Private Virtual Circuit with Surescripts contracted MPLS
service provider. If using the Private Virtual Circuit, the participant must allow
Surescripts to install and manage two routers in their data center that connect to
the participants extranet. The participant must have dual network connectivity for
redundancy.
2.3.1.2 Secure FTP

Secure FTP is supported for the transfer of Master Patient Index (MPI) data loads,
Formulary and Benefit data loads, and ePrescribing Activity Report data loads
using FTP over SSL, SSH with FTP and HTTP/S. Surescripts supports both Clientto-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. Participant files are isolated from
other participants 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 participant must allow Surescripts to install and
manage two routers in their data center that connect to the participants extranet.
The participant must have dual network connectivity for redundancy.
2.3.1.3 Data Distribution Connectivity

Surescripts supports WebDAV for handling the distribution of formulary and benefit
files to Physician System technology vendors. WebDAV stands for "Web-based
Distributed Authoring and Versioning". It is a set of extensions to the HTTP protocol
which allows users to collaboratively edit and manage files on remote web servers.
(Refer to Appendix A: WebDAV Clients for more information.)
2.3.1.4 WebDAV
WebDAV can be used with the following specifications:
Username and password are communicated at the point of integration.

Each Participant is configured with a unique secure directory. The participant
will have access to all contracted formulary and benefit related files.
Surescripts has tested the following WebDAV clients:
o Windows Webfolders, a WebDAV client. Integrated with and
included in the cost of Windows 2000.
o Cadaver (0.19.1), a command-line WebDAV client for Unix. Open
Source.
Supported Network Connections for WebDAV
Participants may use one of the following network connectivity methods with
WebDAV:
Internet:

PAGE 21
Address filtering will be done in the Surescripts firewall.

Surescripts will work with Participants to review their current
connection speed and bandwidth to ensure they are adequate for
anticipated transaction volumes.
Frame Relay:
o 128 kbps minimum bandwidth over a frame relay circuit between
Surescripts and the Participant.
o The line must be encrypted with 3DES.
o The Participant must allow Surescripts to install and manage two
routers in their data center that connect to their extranet
environment.
o The Participant must have a dual network connection through two
different telecommunication providers.
o
o
2.4
SECURITY
Each Participant 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 Participant must provide a Surescripts Trading Partner ID (ISA06 for X12) and
password (ISA04 for X12) in all transactions and a static network path (IP address).
Surescripts will only allow transaction connectivity from the Participant specified
network path. Provision of an otherwise-valid ID and password from a network path
not assigned to the Participant will result in rejection of the transaction, and will be
logged as a potential security violation.
2.5
COMPLIANCE
Prior to using Surescripts for transmissions of electronic prescriptions, each
Participant must verify that such transmissions are legal in the states it services.
Each Participant must also use the Surescripts System in compliance with applicable
restrictions on steering in order that patients retain control over the choice of
pharmacy. A prescriber Participant must not steer a patient to have prescriptions
filled at one pharmacy over another.
Participant pharmacy and prescriber systems must also be protected from fraud and
unauthorized access to the generation of prescriptions and refills. Appropriate
system security should be present to allow only specific authorized persons access
to these activities.
While implementing Prescription Routing according to the NCPDP SCRIPT version
10.6 standard, the participant must comply with the Participant Responsibilities
itemized in the then current Surescripts Network Operations Guide (NOG). These
responsibilities are in the areas of certification requirements, production operations
requirements, directory management, training, and support. Every participant must
have a signed NOG Acknowledgement form on file. The NOG is available to all
network participants and can be obtained as a supplemental file to this document by
sending a request to: support@surescripts.com.

PAGE 22

PAGE 23
SECTION 3
3.1
TRANSACTIONS OVERVIEW
PRESCRIPTION BENEFIT & PRESCRIPTION HISTORY TRANSACTION FLOW

The Surescripts Prescription Benefit & Prescription History service provides
physicians with the electronic delivery of PBM 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 transaction flow between
participants in this process.
ID Load
Eligibility Request
Eligibility Request
Eligibility Response
Eligibility Response
Medication History Request
Distribution
List
Lookup
Medication History Request
Medication History Response
Medication History Response
Formulary and Benefit Data
Formulary and Benefit Data Load
PBM
Tech Vendor
Load Response
Patient
Lookup
Surescripts
Figure 3-1 Surescripts Prescription Benefit & Prescription History Transaction Flow
Diagram

PAGE 24
3.2
TRANSACTION DESCRIPTIONS
Eligibility Request/Response
The ANSI X12 Health Care Eligibility, Coverage, or Benefit Inquiry (270) and Health
Care Eligibility, Coverage, or Benefit Information (271) transaction sets are used to
request and respond to a patient eligibility check. These transactions enable
prescribers to supply a patients name and demographic information to Surescripts
and get back the following information from each PBM that covers the patient:
Health Plan Number/Name

Cardholder ID
Cardholder Last Name, First Name
Relationship Code
Person Code
Group Number, Group Name
Formulary ID, Alternative List ID
Coverage List ID
Copay List ID
BIN
PCN
Type of Prescription Benefit: Pharmacy and/or Mail Order
Interchange Acknowledgment
This X12 specification, TA1, is utilized to acknowledge receipt/header errors for
batch transactions and errors in real time transactions. For the Surescripts
transaction set, it only applies to the X12 specifications (270 & 271). None of the
other specifications utilize this transaction.
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 transaction in a batch environment, and only errors with real time
transactions. Surescripts only supports a real time environment for the 270/271
transactions 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 transaction is used to load a PBMs patient directory into a directory at
Surescripts. This directory is an index Surescripts uses when looking up a patients
prescription benefit. The Patient Directory indicates which PBM(s) can provide
current coverage information. The elements provided are limited to the demographic
data needed for patient searches.
As requested or scheduled, the PBM sends group-level formulary updates to
Physician System vendors using the Formulary and Benefit Data Load transaction.

PAGE 25
Once the file is retrieved, the Physician System utilizes the file as a local repository
for formulary checks.
Medication History Request/Response
After a patients eligibility has been determined, this transaction is used to retrieve a
listing of dispensed medications that were paid for by a patients PBM. The
transaction format is NCPDP SCRIPT.
3.3
GENERAL INTERFACE DESCRIPTION

The transaction 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 for
clarification). For the X12 specifications, the delimiters are defined in the ISA
segment of the message. For NCPDP transactions, the delimiters are defined in the
UNA Segment of the transaction. 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 utilize delimiters to separate component, segments, elements, etc. or as
indicators (i.e., for segment repetition.) These delimiters are defined within
specified segments of the transactions. Participants 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 set of character set
(Refer to Appendix C: Dynamic Delimiters for a full list of acceptable characters).
For X12 transactions, the delimiter set is defined within the ISA segment. The
following is an example:
ISA*00*
*01*PWPOCOUT *ZZ*PCO123
**ZZ*S00000000000001~
In the example above, the asterisk (*) is a delimiter based on its position of
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.
3.3.1.1 Choosing a Delimiter

Surescripts has published a list of allowed delimiters for the X12 transactions (to
Appendix C: Dynamic Delimiters for a full list of acceptable characters). The
Participants may choose any allowed delimiter desired for the transactions that they
create. However, it is important that Participants communicate which delimiters
they are using to ensure they will not cause issues with their trading partners
transactions.
Surescripts recommends the following delimiters for X12 data:
Data Element Separator hex 1D, decimal 29
Segment Terminator hex 1E, decimal 30
Component Element Separator (ISA 16) hex 1C, decimal 28
Repetition Character (ISA11) hex 1F, decimal 30

PAGE 26
3.3.1.2 Using Dynamic Delimiters

A Surescripts Participant can expect to receive delimiters that are different than the
set they define for their transactions. The Participant needs to determine the
delimiters dynamically when the transaction is processed according to the rules
listed in the above section. See Appendix C: Dynamic Delimiters 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 transaction 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.

PAGE 27
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 element 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 transactions:
Type
NCPDP Notation
X12 Notation
Alphanumeric
Date
Decimal
ID Number
Numeric
String
Time
an
DT
R
ID
n
AN
TM
AN
DT
R
ID
Nn
AN
TM
Note: Two periods .. after the Field Type Notation are used to indicate a range. If
no periods are present, the number following the Field Type Notation signifies a
mandatory length. For example,
an..3 means an alphanumeric with range from zero to three characters.
an3 means an alphanumeric with three characters required.
3.3.3.1 Numeric Representation

The decimal point is represented by a period and should be used as follows:
only when there are significant digits to the right of the decimal
when there is a digit before and after the decimal point
not with whole numbers
For example, consider the following possible values for a 5-digit field:
Correct:
2.515
251.5
25.15
Incorrect:
.2515
2515.
3.00
2515
0.2515
2.5
3.3.3.2 Character Set

The following character set is recommended by Surescripts, unless trading partners
determine a different set:
Alpha characters are the subset of upper case letters (A-Z). Lower case
letters are not recommended.
Numeric characters are the subset of numbers (0-9).
Printable characters include, but are not limited to # ! $ % & _ -.

PAGE 28
Alphanumeric characters are the set of alpha, numeric, and printable

characters.
Unprintable characters are not used within the field sets but as delimiters
within field sets.
All ID data types are case sensitive, including routing IDs in the header.
The ASCII representation of valid characters is as follows:
between and including decimal 32 and decimal 95 (the decimal 94 ^ cannot

be used in the ID Load process)
between and including decimal 123 and decimal 125
3.3.3.3 Requirement Designation

Segment Attributes:
NCPDP
X12
Description
Required/Mandatory - the segment must be used.
Situational/Conditional - the segment must be used if conditions are met.
Segments that are not used have been removed from the transaction
specifications.
Element Attributes:
NCPDP
X12
Description
Required/Mandatory - the element must be used.
Situational/Conditional - the element must be used if conditions are met.
Usage of the element depends on the presence of another element.
Elements that are not used have been grayed out (for NCPDP transactions) or
removed (for X12 transactions) from the specifications.
3.4
TRANSACTION VALIDATION
Surescripts will certify that participants are in compliance with the transaction
specifications outlined in this Guide during implementation and will continue to
validate once in production.
To validate a transaction, Surescripts:
Validates the sender identification and password.

Validates the recipient identification.
Verifies that the file is less than 1 MB.
Verifies that the sender and recipient are in agreement contractually to
exchange information.
Validates the syntax of the transaction including field lengths, data types and
code values.

PAGE 29
3.5
FAILURE MODE/RESPONSE APPROACH

Surescripts error processing approaches are defined below.
3.5.1
X12 ERROR PROCESSING

When a network communication or system failure occurs between the originating
Participant and Surescripts, there is the potential that Surescripts may not be able
to return an error message to the Participant. External participants to Surescripts
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 PBM.
3.6
In instances where Surescripts or a participant receives a transaction that is

unrecognizable, the recipient will send back an XML formatted NAK.
The TA1 acknowledges the receipt of a transaction. It validates the syntax of
the interchange ISA and IEA segments that were previously sent. It notifies
the sender that the receiver got the transaction, or it reports errors so the
sender is aware of interchange problems. Surescripts utilizes the TA1 to
only report errors. The sender will only receive a TA1 when an error
occurs within the header.
The 999 transaction reports errors with the syntax of segments and elements
included between the GS and GE segments. It reports functional problems to
the sender. The sender will only receive a 999 when an error occurs.
When an error occurs within the data elements of a 270 transaction, AAA
segments will be used to report the errors in the 271 response.
CONNECTIVITY
Surescripts has established standard connectivity methods for integration with
participants. Surescripts technical staff will work with the Participant during
implementation to determine the best connectivity method for their environment. The
implemented connectivity method depends on the Participants existing infrastructure
and the anticipated transaction volumes between the Participant and Surescripts.

PAGE 30

PAGE 31
SECTION 4
4.1
Eligibility
ELIGIBILITY
INTRODUCTION
This section provides guidelines for the data messaging interfaces between the
Physician System and Pharmacy Benefit Managers (PBMs). 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 PBMs using the currently accepted ANSI ASC 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.
4.2
RELATIONSHIP TO X12N 270/271 STANDARD

All eligibility inquiries and responses sent to Surescripts by participants 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 participants 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). Even though
Surescripts has implemented a subset of the X12N 270/271 standard,
participants should be able to handle receiving all the segments, elements and
related codes contained in the HIPAA X12N 270/271 standard. Refer to the Title
page of this document for the exact reference guides needed.
If a Physician System Participant 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 Participant 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.

PAGE 32
Eligibility
If a PBM Participant submits an eligibility response that does not comply with the
X12N 270/271 transaction standard, Surescripts will return a 999 response. If a PBM
Participant 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 Physician System Participant. However,
PBM participants should be aware that such responses may not be understood or
usable by the recipient Physician System Participant.
4.3
ELIGIBILITY MESSAGE 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 PBMs the Eligibility request should be directed.
5. The PBM verifies the patient, responds with a 271 transaction defining whether
the patient is eligible or not, and sends the 271 message back to Surescripts.
6. Surescripts validates the format of the incoming 271 and consolidates all 271
responses and sends the information back to the requester.
4.4
SUBSCRIBER/DEPENDENT DEFINED
The X12 Eligibility transaction is structured so that the requester can send in both a
subscriber and a dependant. From the requester point of view, the desire is to find
out eligibility for a patient, regardless if they are the subscriber or dependent. Since
the transaction differentiates between a subscriber and dependent, the following flow
is assumed if the requester sends in the patient only, and the patient is a dependent.
1. The requester sends a patient in the 270 within the subscriber loop.
2. The patient is found by Surescripts and sent to the PBM.
3. The PBM determines that the patient is a dependent and cannot be uniquely
defined. (They need to have the subscriber information along with the dependent
information to make them unique).
4. The PBM responds with the patient information in the dependent loop with:
a. Corresponding INS info in the dependent loop relaying the person code.
b. The Subscriber loop blank except for the placeholder (HL and NM12
segment).
Note: If possible, the PBM can populate the subscriber information in the
subscriber loop.
Also, if the patient is submitted in the dependent loop and its determined they are
subscriber they must be moved to subscriber loop.
When moving the patient, the TRN loops must also be moved. See section 1.4.2 of
the 005010X279 guide for more details.

PAGE 33
4.5
Eligibility
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. At this point,
Surescripts does not know if this patient is a subscriber or dependent.
4.5.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.5.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.6
PATIENT MATCH VERIFICATION

The main objective of patient match verification is to ensure that the requester and
the responder are referring to the same patient. The responder must send back the
patient information they have in their system, not the information that was sent in on
the 270. This applies to both a positive and negative eligibility response. If the patient
information sent back by the responder on the 271 is not the same as what the
requester sent on the 270, the change flag must be set indicating there has been a
change in the identifying patient information. This flag will alert the requester to
check with the patient and verify the information is correct.
The specific fields that identify the patient are:
Last Name NM1(3)

First Name NM1(4)
Middle Name NM1(5)
Suffix NM1(7) *
Street Address N3(1) *
Street Address2 N3(3) *
City N4(1) *

PAGE 34
Eligibility
State N4(2) *
Zip N4(3)
DOB DMG(2)
Gender DMG(3)
* These fields are not used by Surescripts in patient matching.

These fields could be in the subscriber or dependant loop or both; however
Surescripts strongly suggests refraining from using the dependent loop. If any of
these fields are different from what the requester sent in, the change flag must be
set. If a field comes in blank and the responder sends back a value, this is
considered a change. However if the requester sends a value in a field and the
responder 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 dependant information is sent, these
rules apply to both.
The change flag is in the INS segment. INS(3) = 001, INS(4) = 25.
In the case of error conditions including patient not found - AAA error 67, 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 technology vendor should disregard any patient information under
these error scenarios.
Here is an example where the responder should indicate that a change has been
made and set the change flag in the INS segment.
Request sends in: Joe M Doe, DOB 19550412, Gender Male, and Address 55111
Responder returns: Joseph M Doe, DOB 19550412, Gender Male, and Address
St. Paul, MN 55111
In this example, the responder does not need to set the change flag because they
have not changed any of the information returned, but some of the information
being returned is blank:
Request sends in: Joe M Doe, DOB 19550412, Gender Male, and Address MN,
55111
Responder returns: Joe M Doe, DOB 19550412, Gender Male, and Address 55111
In this example, the responder looks up the information and finds a blank for the
middle name. This is considered a change so the change flag needs to be set:
Responder returns: Joe Doe, DOB 19550412, Gender Male, and Address 55111

PAGE 35
Eligibility
This is an example where the patient is not found, so none of the patient
information is returned.
Responder returns: No Patient Data and an AAA segment with error 67 patient
not found.
4.7
RELATED TRANSACTIONS
Based on error processing, Surescripts is utilizing the following transactions to inform
the requester of particular system issues.
Interchange Acknowledgment: The TA1 is utilized to inform the requester
of errors when the errors occur at the header ISA/IEA level.
Implementation Acknowledgement: The 999 informs the requester of
errors for segments included in the GS/GE loop.
4.8
270 ELIGIBILITY, COVERAGE, OR BENEFIT INQUIRY
HS
Functional Group ID=
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. For the complete set of segments, refer to the X12 guide.
Since Surescripts uniquely identifies each patient, the subscriber level should be
used instead of the dependant level regardless of whether the patient is a subscriber
or dependent. However, receivers of the 270 should be able to handle patients at the
dependent level since the standard allows it.
Heading:
Page #
Seg ID
Name
Req
Des
Max
Use
ISA
GS
ST
BHT
Interchange Control Header

Functional Group Header
Transaction Set Header
Beginning of Hierarchical Transaction
R
R
R
R
1
1
1
1
Loop
Repeat
Header
38
41
43
44
Detail
46
HL
48
NM1
49
HL
LOOP ID 2000A
Information Source Level(PBM)
LOOP ID 2100A
Information Source Name
LOOP ID 2000B
Information Receiver Level(Physician)
LOOP ID 2100B

1
1
1
PAGE 36
50
52
NM1
REF
53
54
N3
N4
55
56
HL
TRN
58
60
61
62
63
64
NM1
REF
N3
N4
DMG
DTP
65
EQ
66
67
HL
TRN
69
71
72
73
74
75
NM1
REF
N3
N4
DMG
DTP
76
EQ
Information Receiver Name

Information Receiver Additional Identification (Physician System
Identification)
Information Receiver Address
Information Receiver City/State/ZIP Code
LOOP ID 2000C
Subscriber Level
Subscriber Trace Number
LOOP ID 2100C
Subscriber Name
Subscriber Additional Identification (SSN#, Person Code)
Subscriber Address
Subscriber City/State/ZIP Code
Subscriber Demographic Information
Subscriber Date
LOOP ID - 2110C
Subscriber Eligibility or Benefit Inquiry Information (Health
Benefit Plan Coverage)
LOOP ID - 2000D
Dependent Level
Dependent Trace Number
LOOP ID - 2100D
Dependent Name
Dependent Additional Identification
Dependent Address
Dependent City/State/ZIP Code
Dependent Demographic Information
Dependent Date
LOOP ID - 2110D
Dependent Eligibility or Benefit Inquiry Information (Pharmacy)
SE
GE
IEA
Transaction Set Trailer

Functional Group Trailer
Interchange Control Trailer
Eligibility
R
S
1
9
S
S
1
1
S
S
1
2
R
S
S
S
S
S
1
9
1
1
1
2
S
S
1
2
R
S
S
S
S
S
1
9
1
1
1
1
R
R
R
1
1
1
Trailer
78
79
80

PAGE 37
270 Segment:
Eligibility
ISA Interchange Control Header
Loop:
Level:
Usage:
Heading
Mandatory
Max Use:
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
Des.
Element
ISA01
I01
Name
Attributes
Authorization Information Qualifier
ID 2/2
Code to identify the type of information in the Authorization Information

00
M
ISA02
I02
No Authorization Information Present (No Meaningful

Information in 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
M
ISA04
I04
Password
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
M
ISA06
I06
Mutually Defined
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

PAGE 38
Eligibility
*From the POC/PPMS this is the POC/PPMS participant ID as assigned by

Surescripts.
*From Surescripts, this is Surescripts participant ID.
M
ISA07
I05
ID 2/2

ZZ
M
ISA08
I07
Mutually Defined
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 POC/PPMS this is Surescripts participant ID as assigned by
Surescripts.
*From Surescripts, this is PBM's participant ID.
M
ISA09
I08
Interchange Date
DT 6/6
TM 4/4
Date of the interchange

*Date format YYMMDD required.
M
ISA10
I09
Interchange Time
Time of the interchange
*Time format HHMM required.
ISA11
I65
Repetition Separator
M
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.
ISA12
I11
Interchange Control Version Number
ID 5/5
This version number covers the interchange control segments

00501
M
ISA13
I12
Draft Standards for Trial Use Approved for Publication by

ASC X12 Procedures Review Board through October 2003
Interchange Control Number
N0 9/9
A control number assigned by the interchange sender

*From the POC/PPMS, this is a unique ID assigned by the POC/PPMS 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.

PAGE 39
Eligibility
*Since these transactions are real time only, Surescripts does not use this
field to determine whether to create a TA1 acknowledgement.
ISA15
I14
No Acknowledgment Requested (Recommended by

Surescripts)
Interchange Acknowledgment Requested
Usage Indicator
ID 1/1
Code to indicate whether data enclosed by this interchange envelope is test,

production or information
ISA16
I15
Production Data
Test Data
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.

PAGE 40
270 Segment:
Eligibility
GS Functional Group Header
Loop:
Level:
Usage:
Heading
Mandatory
Max Use:
Purpose:
To indicate the beginning of a functional group and to provide control information
Syntax Notes:
Semantic Notes:
Comments:
GS04 is the group date.
GS05 is the group time.
The data interchange control number GS06 in this header must be identical to
the same data element in the associated functional group trailer, GE02.
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.
Ref.
Data
Des.
Element
GS01
479
Name
Attributes
Functional Identifier Code
ID 2/2
Code identifying a group of application related transaction sets

HS
M
GS02
142
Eligibility, Coverage or Benefit Inquiry (270)
Application Sender's Code
AN 2/15
Code identifying party sending transmission; codes agreed to by trading

partners
*From the POC/PPMS this is the POC/PPMS participant ID as assigned by
Surescripts. *From Surescripts, this is Surescripts participant ID.
M
GS03
124
Application Receiver's Code
AN 2/15
Code identifying party receiving transmission; codes agreed to by trading

partners
*From the POC/PPMS this is Surescripts participant ID as assigned by
Surescripts.
*From Surescripts, this is PBM's participant ID.
M
GS04
373
Date
DT 8/8
TM 4/8
Date expressed as CCYYMMDD

M
GS05
337
Time
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

PAGE 41
Eligibility
*The control number should be unique across all groups within this
transaction set. This ID will be returned on an AK102 of the 999
acknowledgement if an error occurs. Providing unique numbers will assist in
resolving errors and tracking messages.
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
GS08
480
Accredited Standards Committee X12
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
005010X279
Draft Standards Approved for Publication by ASC X12
Procedures Review Board through October 2003, as
published in this implementation guide.

PAGE 42
270 Segment:
Eligibility
ST Transaction Set Header
Loop:
Level:
Usage:
Heading
Mandatory
Max Use:
Purpose:
To indicate the start of a transaction set and to assign a control number
Syntax Notes:
Semantic Notes:
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.
Example: ST*270*0001*005010X279~
Ref.
Data
Des.
Element
ST01
143
Name
Attributes
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
M
ST02
329
Eligibility, Coverage or Benefit Inquiry
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.
*This ID will be returned on an AK202 of the 999 acknowledgement 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 005010X279.
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.

PAGE 43
270 Segment:
Eligibility
BHT Beginning of Hierarchical Transaction
Loop:
Level:
Usage:
Heading
Mandatory
Max Use:
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:
BHT03 is the number assigned by the originator to identify the transaction within
the originator's business application system.
BHT04 is the date the transaction was created within the business application
system.
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*13*199800114000001*19980101*1400~
Ref.
Data
Des.
Element
BHT01
1005
Name
Attributes
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
M
BHT02
353
Information Source, Information Receiver, Subscriber,

Dependent
Transaction Set Purpose Code
ID 2/2
Code identifying purpose of transaction set

13
Request
Note: Surescripts Participants utilize this option only;
(Cancellation) and 36 (Authority to Deduct) are not
utilized.
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 senders discretion, but cannot be
required by the receiver.
This element is to be used to trace the transaction from one point to the next

PAGE 44
Eligibility
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
M
BHT04
373
Date
DT 8/8
TM 4/8

Use this date for the date the transaction set was generated.
Format CCYYMMDD
M
BHT05
337
Time

HHMMSSD, or HHMMSSDD, where H = hours (00-23), M = minutes (00-59), S =
integer seconds (00-59) and DD = decimal seconds; decimal seconds are
Use this time for the time the transaction set was generated.
Time format HHMMSSDD required.

PAGE 45
270 Segment:
HL Information Source Level
Loop:
2000A
Level:
Detail
Usage:
Eligibility
Mandatory
Mandatory
Max Use:
Purpose:
To identify dependencies among and the content of hierarchically related groups of

data segments
Syntax Notes:
Semantic Notes:
Comments:
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.
Notes:
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.
HL02 identifies the hierarchical ID number of the HL segment to which the

current HL segment is subordinate.
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.
HL04 indicates whether or not there are subordinate (or child) HL segments
related to the current HL segment.
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~

PAGE 46
Eligibility
Ref.
Data
Des.
Element
HL01
628
Name
Attributes
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. It should begin with the
number one and be incremented by one 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 entity 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
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 additional hierarchical levels
subordinate to the current hierarchical level.
Because of the hierarchical structure, and because an additional HL always
exists in this transaction, the code value in the HL04 at the Loop 2000A level
should always be "1".
1
Additional Subordinate HL Data Segment in This

Hierarchical Structure.

PAGE 47
270 Segment:
NM1 Information Source Name
Loop:
2100A
Level:
Detail
Usage:
Eligibility
Mandatory
Mandatory
Max Use:
Purpose:
To supply the full name of an individual or organizational entity
Syntax Notes:
If either NM108 or NM109 is present, then the other is required.
Semantic Notes:
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, (e.g., insurance
company, HMO, IPA, employer).
Example: NM1*2B*2*SURESCRIPTS LLC*****PI*SURESCRIPTS~
Ref.
Data
Des.
Element
NM101
98
Name
Attributes
Entity Identifier Code
ID 2/3
Code identifying an organizational entity, a physical location, property or an

individual
2B
M
NM102
1065
Third-Party Administrator (Recommended by Surescripts)
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.
NM103
1035
Person
Non-Person Entity (Recommended by Surescripts)
Name Last or Organization Name
AN 1/60
Individual last name or organizational name

*From the POC/PPMS, 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
M
NM109
67
Payer Identification (Recommended by Surescripts)
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 POC/PPMS, the PBM is unknown so this will be Surescripts
participant ID.
*From the Surescripts, Surescripts will place the participant ID of the PBM here.

PAGE 48
270 Segment:
HL Information Receiver Level
Loop:
2000B
Level:
Detail
Usage:
Eligibility
Mandatory
Mandatory
Max Use:
Purpose:

data segments
* Physician identification
Syntax Notes:
Semantic Notes:
Comments:
Refer to X12 guide
Notes:
Refer to X12 guide

Example: HL*2*1*21*1~
Ref.
Data
Des.
Element
HL01
628
Name
Attributes
AN 1/12

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
M
HL03
735
ID 1/2

21
Information Receiver
Identifies the provider or party(ies) who are the recipient(s)
of the information
HL04
736
ID 1/1
1


PAGE 49
270 Segment:
NM1 Information Receiver Name
Loop:
2100B
Level:
Detail
Usage:
Eligibility
Mandatory
Mandatory
Max Use:
Purpose:
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, employer, IPA, or hospital).
Example: NM1*1P*1*JONES*TIM****XX*111223333~
Ref.
Data
Des.
Element
NM101
98
Name
Attributes
ID 2/3

individual
1P
M
NM102
1065
Provider (Recommended by Surescripts)
ID 1/1

organization.
NM103
1035
Person (Recommended by Surescripts)
Non-Person Entity
AN 1/60

Use this name for the organization's name if the entity type qualifier is a nonperson entity. Otherwise, use this name for the individual's last name. Use if
name information is needed to identify the receiver of eligibility or benefit
information.
* Physician Name
O
NM104
1036
Name First
AN 1/35
AN 1/25
AN 1/10
Individual first name

Use this name only if NM102 is "1".
O
NM105
1037
Name Middle
Individual middle name or initial
Use this name only if NM102 is "1".
NM107
1039
Name Suffix
Suffix to individual name

PAGE 50
Eligibility
Use this for the suffix to an individual's name; e.g., Sr., Jr. or III.
Use this only if NM102 is "1".
M
NM108
66
ID 1/2

Code (67)
See X12 Guide. 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
Health Care Financing Administration 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 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.
NM109
67
Identification Code
AN 2/80

Use this reference number as qualified by the preceding data element (NM108).

PAGE 51
270 Segment:
REF Information Receiver Additional Identification (POC Identification)
Loop:
2100B
Level:
Detail
Usage:
Eligibility
Mandatory
Optional
Max Use:
Purpose:
To specify identifying information
Syntax Notes:
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.
*Surescripts defined participant ID for the POC/PPMS Vendor.
Example: REF*EO*477563928~
Ref.
Data
Des.
Element
REF01
128
Name
Attributes
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 POC/PPMS.
REF02
127
AN 1/50

Use this reference number as qualified by the preceding data element (REF01).
O
REF03
352
Description
AN 1/80
A free-form description to clarify the related data elements and their content
*Not Used for the EO qualifier.

PAGE 52
270 Segment:
Loop:
2100B
Level:
Detail
Usage:
Eligibility
N3 Information Receiver Address
Mandatory
Optional
Max Use:
Purpose:
To specify the location of the named party
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Use this segment if the information receiver is a provider who has multiple locations and it
is needed to identify the location relative to the request.
Example: N3*201 PARK AVENUE*SUITE 300~
Ref.
Data
Des.
Element
N301
166
Name
Attributes
Address Information
AN 1/55
AN 1/55
Address information
Use this information for the first line of the address information.
O
N302
166
Address Information
Address information
Use this information for the second line of the address information.
Required if a second address line exists.

PAGE 53
270 Segment:
N4 Information Receiver City/State/ZIP Code
Loop:
2100B
Level:
Detail
Usage:
Mandatory
Optional
Max Use:
Purpose:
To specify the geographic place of the named party
Syntax Notes:
Eligibility
If N406 is present, then N405 is required.
A combination of either N401 through N404, or N405 and N406 may be adequate
to specify a location.
N402 is required only if city name (N401) is in the U.S. or Canada.
Semantic Notes:
Comments:
Notes:
Use this segment if the information receiver is a provider who has multiple locations and it
is needed to identify the location relative to the request.
Example: N4*NEW YORK*NY*10003~
Ref.
Data
Des.
Element
N401
19
Name
City Name
Attributes
O
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)
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 receivers address, if
other than the United States.
* Do not send the US County Code

PAGE 54
270 Segment:
HL Subscriber Level
Loop:
2000C
Level:
Detail
Usage:
Eligibility
Mandatory
Mandatory
Max Use:
Purpose:

data segments
Syntax Notes:
Semantic Notes:
Comments:
See X12 Guide
Notes:
See X12 Guide

Ref.
Data
Des.
Element
HL01
628
Name
Attributes
AN 1/12

M
HL02
734
AN 1/12
M
HL03
735
ID 1/2

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
HL04
736
ID 1/1
No Subordinate HL Segment in This Hierarchical

Structure.


PAGE 55
270 Segment:
TRN Subscriber Trace Number
Loop:
2000C
Level:
Detail
Usage:
Eligibility
Mandatory
Optional
Max Use:
Purpose:
To uniquely identify a transaction to an application
Syntax Notes:
Semantic Notes:
TRN02 provides unique identification for the transaction.
TRN03 identifies an organization.
TRN04 identifies a further subdivision within the organization.
Comments:
Notes:
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*9877281234*RADIOLOGY~
Ref.
Data
Des.
Element
TRN01
481
Name
Attributes
Trace Type Code
ID 1/2
AN 1/50
Code identifying which transaction is being referenced

Current Transaction Trace Number
1
M
TRN02
127
Current Transaction Trace Numbers

Use this number for the trace or reference number assigned by the information
receiver.
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
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.
O
TRN04
127
AN 1/50


PAGE 56
Eligibility

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.

PAGE 57
270 Segment:
NM1 Subscriber Name
Loop:
2100C
Level:
Detail
Usage:
Eligibility
Mandatory
Mandatory
Max Use:
Purpose:
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*ROBERT*B***MI*33399999~
Ref.
Data
Des.
Element
NM101
98
Name
Attributes
ID 2/3

individual
IL
M
NM102
1065
Insured or Subscriber
ID 1/1

organization.
1
O
NM103
1035
Person
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.
O
NM104
1036
Name First
AN 1/35

Use this name for the subscribers 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.
O
NM105
1037
Name Middle
AN 1/25

Use this name for the subscriber's middle name or initial. Use if information is
known and will assist in identification of the person named, particularly when not
utilizing the HIPAA search option.
O
NM107
1039
Name Suffix
AN 1/10
PAGE 58
Eligibility

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
ID 1/2

Code (67)
Use this element to qualify the identification number submitted in NM109. 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 POC/PPMS this is blank. Surescripts will put the PBM Unique ID into
this field.
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.).
NM109
67
Identification Code
AN 2/80

Subscriber Identification Code if available
*From the POC/PPMS this is blank. Surescripts will put the PBM Unique ID into
this field.

PAGE 59
270 Segment:
REF Subscriber Additional Identification
Loop:
2100C
Level:
Detail
Usage:
Eligibility
Mandatory
Optional
Max Use:
Purpose:
Syntax Notes:
Notes:
See X12 Guide

Example: REF*SY*660415~
Ref.
Data
Des.
Element
REF01
128
Name
Attributes
ID 2/3

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
M
REF02
127
Patient Account Number
AN 1/50


PAGE 60
270 Segment:
N3 Subscriber Address
Loop:
2100C
Level:
Detail
Usage:
Eligibility
Mandatory
Optional
Max Use:
Purpose:
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.
Required if the subscriber is a patient.
Example: N3*15197 BROADWAY AVENUE*APT 215~
Ref.
Data
Des.
Element
N301
166
Name
Address Information
Attributes
M
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

PAGE 61
270 Segment:
N4 Subscriber City/State/ZIP Code
Loop:
2100C
Level:
Detail
Usage:
Mandatory
Optional
Max Use:
Purpose:
Syntax Notes:
Eligibility
Semantic Notes:
Comments:
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.
Ref.
Data
Des.
Element
N401
19
Name
City Name
Attributes
O
AN 2/30
ID 2/2

Use this text for the city name of the subscriber's address.
O
N402
156

O
N403
116
Postal Code
ID 3/15
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

Use this code to specify the country of the subscriber's address, if other than
the United States.

PAGE 62
270 Segment:
DMG Subscriber Demographic Information
Loop:
2100C
Level:
Detail
Usage:
Eligibility
Mandatory
Optional
Max Use:
Purpose:
To supply demographic information
Syntax Notes:
If either DMG01 or DMG02 is present, then the other is required.
Semantic Notes:
DMG02 is the date of birth.
DMG07 is the country of citizenship.
DMG09 is the age in years.
Comments:
Notes:
See X12 Guide.

Example: DMG*D8*19430917*M~
Ref.
Data
Des.
Element
DMG01
1250
Name
Attributes
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.
See X12 Guide.
D8
O
DMG02
1251
Date Expressed in Format CCYYMMDD
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.
See X12 Guide.
O
DMG03
1068
Gender Code
ID 1/1
Code indicating the sex of the individual

Use this code to indicate the subscriber's gender
See X12 Guide.
Female
Male

PAGE 63
270 Segment:
DTP Subscriber Date
Loop:
2100C
Level:
Detail
Usage:
Eligibility
Mandatory
Optional
Max Use:
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:
DTP02 is the date or time or period format that will appear in DTP03.
Comments:
Notes:
See X12 Guide.

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*19950818~
Ref.
Data
Des.
Element
DTP01
374
Name
Attributes
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
DTP02
1250
ID 2/3
D8

*Surescripts is recommending D8. It should be within 24
hours of the date the transaction is sent.
RD8
M
DTP03
1251
Date Range expressed in Format CCYYMMDDCCYYMMDD
Date Time Period
AN 1/35

Use this date for the date(s) as qualified by the preceding data elements.

PAGE 64
270 Segment:
EQ Subscriber Eligibility or Benefit Inquiry Information (Pharmacy)
Loop:
2110C
Level:
Detail
Usage:
Eligibility
Optional
Optional
Max Use:
Purpose:
To specify inquired eligibility or benefit information
Syntax Notes:
At least one of EQ01 or EQ02 is required.
Semantic Notes:
Comments:
Notes:
See X12 Guide.

*Surescripts supports both Pharmacy & Mail Order Prescription Drug coverage. Thus both
EQ Loops will be sent.
In the same manner, Surescripts will always expect both EB Loops in the 271 response.
Example: EQ*30~
Ref.
Data
Des.
Element
EQ01
1365
Name
Attributes
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.

PAGE 65
270 Segment:
Eligibility
HL Dependent Level
Loop:
2000D
Optional
Level:
Summary
Usage:
Optional
Max Use:
Purpose:

data segments.
*Dependent level should not be sent when subscriber is the patient.
There should be only 1 dependent sent per subscriber transaction.
Syntax Notes:
Semantic Notes:
Comments:
Notes:
See X12 Guide.

Use the Dependent Level only if the patient is a dependent of a member and cannot be
uniquely identified to the information source without the member's information in the
Subscriber Level. If a patient is a dependent of a member, but can be uniquely identified
to the information source (such as by, but not limited to, a unique Member Identification
Number) then the patient is considered the subscriber and is to be identified in the
Subscriber Level.
used instead of the dependant level regardless of whether the patient is a
subscriber or dependent. However, receivers of the 270 should be able to handle
patients at the dependent level since the standard allows it.
Ref.
Data
Des.
Element
HL01
628
Name
Attributes
AN 1/12

M
HL02
734
AN 1/12
M
HL03
735
ID 1/2

23
Dependent
Identifies the individual who is affiliated with the
subscriber, such as spouse, child, etc., and therefore may
be entitled to benefits
HL04
736
ID 1/1
0

Structure.

PAGE 66
270 Segment:
Eligibility
TRN Dependent Trace Number
Loop:
2000D
Optional
Level:
Summary
Usage:
Optional
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Trace numbers assigned at the dependent level are intended to allow tracing of an
eligibility/benefit transaction when the dependent is the patient.
See the X12 HIPAA Implementation Guide (Section 1.4.6 Information Linkage).
TRN*1*109834652831*9XYZCLEARH*REALTIME~
Ref.
Data
Des.
Element
TRN01
481
Name
Attributes
Trace Type Code
ID 1/2
AN 1/50

1
M
TRN02
127

Use this number for the trace or reference number assigned by the information
receiver.
M
TRN03
509
AN 10/10

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
Use this number for the identification number of the company that assigned the
trace or reference number specified in the previous data element (TRN02).
O
TRN04
127
AN 1/50

Use this information if necessary to further identify a specific component of the

PAGE 67
Eligibility
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.

PAGE 68
270 Segment:
Eligibility
NM1 Dependent Name
Loop:
2100D
Mandatory
Level:
Summary
Usage:
Mandatory
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Notes:
Use this segment to identify an entity by name. This NM1 loop is used to identify the
dependent of an insured or subscriber.
See X12 Guide.
Example: NM1*03*SMITH*MARY LOU*R~
Ref.
Data
Des.
Element
NM101
98
Name
Attributes
ID 2/3

individual
03
M
NM102
1065
Dependent
ID 1/1

organization.
1
O
NM103
1035
Person
AN 1/60

Use this name for the dependent's last name.
Options of the X12 Implementation Guide for more information.
O
NM104
1036
Name First
AN 1/35

Use this name for the dependent's first name.
Options of the X12 Implementation Guide for more information.
O
NM105
1037
Name Middle
AN 1/25

Use this name for the dependent's middle name or initial. Use if information is
known and will assist in identification of the person named, particularly when not
utilizing the HIPAA search option.
O
NM107
1039
Name Suffix

AN 1/10
PAGE 69
Eligibility

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,

PAGE 70
270 Segment:
Eligibility
REF Dependent Additional Identification
Loop:
2100D
Mandatory
Level:
Summary
Usage:
Optional
Max Use:
Purpose:
Syntax Notes:
If either C04003 or C04004 is present, then the other is required.
If either C04005 or C04006 is present, then the other is required.
Comments:
Notes:
Use this segment when needed to convey identification numbers for the dependent. The
type of reference number is determined by the qualifier in REF01.
See X12 Guide.
Example: REF*1L*660415~
Ref.
Data
Des.
Element
REF01
128
Name
Attributes
ID 2/3

SY

EJ
M
REF02
127
AN 1/50


PAGE 71
270 Segment:
Eligibility
N3 Dependent Address
Loop:
2100D
Mandatory
Level:
Summary
Usage:
Optional
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Use this segment when needed to convey the address information for the dependent. Use
if information is known and will assist in identification of the person named, particularly
when not utilizing the HIPAA search option.
Ref.
Data
Des.
Element
N301
166
Name
Attributes
Address Information
AN 1/55
AN 1/55
Address information
O
N302
166
Address Information
Address information

PAGE 72
270 Segment:
N4 Dependent City/State/ZIP Code
Loop:
2100D
Level:
Summary
Usage:
Optional
Mandatory
Max Use:
Purpose:
Syntax Notes:
Eligibility
Semantic Notes:
Comments:
Notes:
Use this segment when needed to convey the city, state, and ZIP code for the dependent.
Use if information is known and will assist in identification of the person named,
Ref.
Data
Des.
Element
N401
19
Name
City Name
Attributes
O
AN 2/30
ID 2/2

Use this text for the city name of the dependent's address.
O
N402
156

O
N403
116
Postal Code
ID 3/15
O
N404
26
Country Code
ID 2/3

Use this code to specify the country of the dependent's address, if other than
the United States.

PAGE 73
270 Segment:
Eligibility
DMG Dependent Demographic Information
Loop:
2100D
Mandatory
Level:
Summary
Usage:
Optional
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
DMG07 is the country of citizenship.
DMG09 is the age in years.
Comments:
Notes:
Use this segment when needed to convey the birth date or gender demographic
information for the dependent.
See X12 Guide.
Example: DMG*D8*19430121*F~
Ref.
Data
Des.
Element
DMG01
1250
Name
Attributes
ID 2/3
See X12 Guide.
D8
O
DMG02
1251
Date Time Period
AN 1/35

See X12 Guide.
O
DMG03
1068
Gender Code
ID 1/1

Use this code to indicate the dependant's gender.
See X12 Guide.
Female
Male

PAGE 74
270 Segment:
Eligibility
DTP Dependent Date
Loop:
2100D
Mandatory
Level:
Summary
Usage:
Optional
Max Use:
Purpose:
To specify any or all of a date, a time, or a time period
Syntax Notes:
Semantic Notes:
Notes:
Comments:
See X12 Guide.
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*19950818~
Ref.
Data
Des.
Element
DTP01
374
Name
Attributes
Date/Time Qualifier
ID 3/3

291
Plan
Begin and end dates of the service being rendered
DTP02
1250
ID 2/3
D8

*Surescripts is recommending D8
RD8
M
DTP03
1251
Date Range expressed in Format CCYYMMDDCCYYMMDD
Date Time Period
AN 1/35


PAGE 75
270 Segment:
EQ Dependant Eligibility or Benefit Inquiry Information (Pharmacy)
Loop:
2110D
Level:
Detail
Usage:
Eligibility
Optional
Optional
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
See X12 Guide.

Example: EQ*88~
Ref.
Data
Des.
Element
EQ01
1365
Name
Attributes
Service Type Code
ID 1/2

88
Pharmacy (Recommended by Surescripts)

PAGE 76
270 Segment:
EQ
Dependant Eligibility or Benefit Inquiry Information (Mail Order

Prescription Drug)
Loop:
2110D2
Level:
Detail
Usage:
Eligibility
Optional
Optional
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
See X12 Guide.

Example: EQ*90~
Ref.
Data
Des.
Element
EQ01
1365
Name
Attributes
Service Type Code
ID 1/2

90
Mail Order Prescription Drug (Recommend by Surescripts)

PAGE 77
270 Segment:
Eligibility
SE Transaction Set Trailer
Loop:
Level:
Summary
Usage:
Mandatory
Max Use:
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:
Notes:
SE is the last segment of each transaction set.
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~
Ref.
Data
Des.
Element
SE01
96
Name
Number of Included Segments
Attributes
M
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
AN 4/9
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.

PAGE 78
270 Segment:
Eligibility
GE Functional Group Trailer
Loop:
Level:
Summary
Usage:
Mandatory
Max Use:
Purpose:
To indicate the end of a functional group and to provide control information
Syntax Notes:
Semantic Notes:
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:
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.
Ref.
Data
Des.
Element
GE01
97
Name
Number of Transaction Sets Included
Attributes
M
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
N0 1/9

Same control number as GS06.

PAGE 79
270 Segment:
Eligibility
IEA Interchange Control Trailer
Loop:
Level:
Summary
Usage:
Mandatory
Max Use:
Purpose:
To define the end of an interchange of zero or more functional groups and

Syntax Notes :
Semantic Notes :
Comments :
Ref.
Data
Des.
Element
IEA01
I16
Name
Number of Included Functional Groups
Attributes
M
N0 1/5
A count of the number of functional groups included in an interchange

M
IEA02
I12
N0 9/9

Same control number as ISA13.

PAGE 80
4.9
Eligibility
271 ELIGIBILITY, COVERAGE, OR BENEFIT INFORMATION
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.
used instead of the dependant level regardless of whether the patient is a subscriber
or dependent. However, receivers of the 270 should be able to handle patients at the
dependent level since the standard allows it.
Heading:
Page #
Seg ID
Name
Req
Des
Max Loop
Use Repeat

Beginning of Hierarchical Transaction
R
R
R
R
1
1
1
1
Header
84
87
89
91
ISA
GS
ST
BHT
Detail
93
94
HL
AAA
96
97
NM1
AAA
99
HL
100
102
NM1
REF
103
AAA
105
106
HL
TRN
108
110
NM1
REF
111
112
113
116
N3
N4
AAA
DMG
LOOP ID 2000A Information Source Level

Information Source Level(PBM)
Request Validation
LOOP ID 2100A
Information Source Name
Request Validation
LOOP ID 2000B Information Receiver Level
Information Receiver Level(Physician)
LOOP ID 2100B
Information Receiver Name
Identification)
Information Receiver Request Validation
LOOP ID 2000C Subscriber Level
Subscriber Level
Subscriber Trace Number
LOOP ID 2100C
Subscriber Name
Subscriber Additional Identification (Person Code, Cardholder ID, SSN,
Patient Account Number)
Subscriber Address
Subscriber City/State/ZIP Code
Subscriber Request Validation
Subscriber Demographic Information

R
S
1
9
1
R
S
1
9
R
S
1
1
S
S
1
3
1
1
1
R
S
1
9
S
S
S
S
1
1
9
1
PAGE 81
117
119
INS
DTP
120
122
EB
REF
124
123
127
128
DTP
AAA
MSG
LS
129
131
NM1
LE
132
134
135
137
138
EB
DTP
AAA
MSG
LS
139
141
NM1
LE
142
144
HL
TRN
146
NM1
148
REF
149
150
151
153
154
156
N3
N4
AAA
DMG
INS
DTP
157
EB
159
REF
161
Subscriber Relationship
Subscriber Date
LOOP ID 2110C1
Subscriber Eligibility or Benefit Information
Subscriber Additional Identification (Plan ID, Group ID/Name,
Formulary ID, Alternative ID, Coverage List ID, BIN/PCN, and Copay
ID)
Subscriber Eligibility/Benefit Date
Message Text
Loop Header2110C1
LOOP ID 2120C1
Subscriber Benefit Related Entity Name 2120C1
Loop Trailer 2110C1
LOOP ID 2110C2-5 (One loop for retail, one for mail order, and
optionally, one for specialty pharmacy, and/ or LTC)
Subscriber Eligibility or Benefit Information
Subscriber Eligibility/Benefit Date
Message Text
Loop Header 2110C2-5
LOOP ID 2120C2-5
Subscriber Benefit Related Entity Name 2120C2-5
Loop Trailer 2110C2-5
LOOP ID 2000D
Dependent Level
Dependent Trace Number
LOOP ID 2100D
Dependent Name
Eligibility
S
S
1
9
1
S
S
1
9
S
S
S
S
20
9
10
1
S
S
1
1
>0
S
S
S
S
S
1
20
9
10
1
S
S
1
1
S
S
1
3
S
S
S
S
S
S
1
1
9
1
1
9
1
9
DTP
Dependent Additional Identification (Plan ID, Group ID/Name, Formulary ID, S

Alternative ID, Coverage List ID, BIN/PCN, and Copay ID)
Dependent Eligibility/Benefit Date
S
20
162
AAA
Dependent Request Validation
164
MSG
Message Text
10
165
LS
166
168
NM1
LE
Loop Header2110D1
LOOP ID 2120D1
Dependent Benefit Related Entity Name 2120D1
Loop Trailer 2110D1
LOOP ID 2110D2-5 (One loop for 88-retail, one for 90- mail order, and
optionally one for specialty pharmacy, and/or LTC)
Dependent Eligibility or Benefit Information
S
S
1
1
169
EB
Dependent Additional Identification (Person Code, Cardholder ID, SSN,

Patient Account Number)
Dependent Address
Dependent City/State/ZIP Code
Dependent Demographic Information
Dependent Relationship
Dependent Date
LOOP ID 2110D1 (30-Health Benefit Plan Coverage)
Dependent Eligibility or Benefit Information

23
1
23
1
1
23
>1
S
PAGE 82
Eligibility
171
DTP
Dependent Eligibility/Benefit Date
20
172
174
AAA
MSG

Message Text
S
S
9
10
175
LS
Loop Header2110D2-5
LOOP ID 2120D2-5
176
178
NM1
LE
Dependent Benefit Related Entity Name2120D2-5 S

S
1
1
Loop Trailer2110D2-5
23
Trailer
179
180
181
SE
GE
IEA


R
R
R
1
1
1
PAGE 83
271 Segment:
Eligibility
Loop:
Level:
Usage:
Heading
Mandatory
Max Use:
Purpose:

Ref.
Data
Des.
Element
ISA01
I01
Name
Attributes
ID 2/2

00
M
ISA02
I02

Information in I02)
AN 10/10
Information used for additional identification or authorization of the interchange

Authorization Information Qualifier (I01)
*Blank
M
ISA03
I03
ID 2/2

01
M
ISA04
I04
Password
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 PBM to Surescripts, this is the Surescripts system assigned
password to the PBM.
*From Surescripts to the Physician System, this is Surescripts defined
password that is used to access the Physician System.
M
ISA05
I05
ID 2/2

ZZ
M
ISA06
I06
Mutually Defined
AN 15/15
sender ID element
*From the PBM to Surescripts, this is the PBM Participant ID.
*From Surescripts to the Physician System, this is Surescripts Participant ID.
M
ISA07
I05
ID 2/2


PAGE 84
Eligibility

ZZ
M
ISA08
I07
Mutually Defined
AN 15/15

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, this is Surescripts Participant ID.
*From Surescripts to the Physician System, this is the Physician Systems
Participant ID.
M
ISA09
I08
Interchange Date
DT 6/6
TM 4/4

M
ISA10
I09
Interchange Time
*Time format HHDD required.
ISA11
I65
M
1/1
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/
ISA12
I11
ID 5/5

00501
M
ISA13
I12

N0 9/9

*From the PBM, this is the PBMs 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.
M
ISA14
I13
ID 1/1

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 acknowledgement.
ISA15
I14
No Acknowledgment Requested
Usage Indicator
ID 1/1


PAGE 85
Eligibility
ISA16
I15
Production Data
Test Data
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.

PAGE 86
271 Segment:
Eligibility
Loop:
Level:
Usage:
Heading
Mandatory
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
When sending a TA1, the GS segment is not required.
Ref.
Data
Des.
Element
GS01
479
Name
Attributes
ID 2/2

HB
M
GS02
142
Eligibility, Coverage or Benefit Information (271)
Application Senders Code
AN 2/15

partners
*From the PBM to Surescripts, this is the PBMs Participant ID.
*From Surescripts to the Physician System, this is Surescripts Participant ID.
M
GS03
124
Application Receivers Code
AN 2/15

partners
*From the PBM to Surescripts, this is Surescripts Participant ID.
*From Surescripts to the Physician System, this is the Physician Systems
Participant ID.
M
GS04
373
Date
DT 8/8
TM 4/8

M
GS05
337
Time

M
GS06
28
N0 1/9


PAGE 87
Eligibility
The control number should be unique across all functional groups within this
transaction set.
*This number is returned on an AK102 of the 999 acknowledgement if an error
occurs. Providing a unique number will assist in resolving errors and tracking
messages.
M
GS07
455
ID 1/2
standard
X
M
GS08
480
AN 1/12
005010X279

PAGE 88
271 Segment:
Eligibility
Loop:
Level:
Usage:
Heading
Mandatory
Max Use:
Purpose:
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*005010X279~
Ref.
Data
Des.
Element
ST01
143
Name
Attributes
ID 3/3

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
ST02
329
Eligibility, Coverage or Benefit Information
AN 4/9
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 acknowledgement if an error
occurs. Providing a unique number will assist in resolving errors and tracking
messages.
M
ST03
1705
AN 1/35

PAGE 89
Eligibility

implementation convention reference takes precedence over the implementation
reference specified in the GS08 This element must be populated with
005010X279.
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.

PAGE 90
271 Segment:
Eligibility
BHT Beginning of Hierarchical Transaction
Loop:
Level:
Usage:
Heading
Mandatory
Max Use:
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:
BHT03 is the number assigned by the originator to identify the transaction within
the originators business application system.
BHT04 is the date the transaction was created within the business application
system.
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~
Ref.
Data
Des.
Element
BHT01
1005
Name
Attributes
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
M
BHT02
353
Information Source, Information Receiver, Subscriber,

Dependent
Transaction Set Purpose Code
ID 2/2
AN 1/50
Code identifying purpose of transaction set

11
M
BHT03
127
Response

*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
TM 4/8

Use this date for the date the transaction set was generated.
M
BHT05
337
Time
PAGE 91
Eligibility

Use this time for the time the transaction set was generated.

PAGE 92
271 Segment:
HL Information Source Level (PBM)
Loop:
2000A
Level:
Detail
Usage:
Eligibility
Mandatory
Mandatory
Max Use:
Purpose:

data segments
Comments:
See X12 guide.
Notes:
See X12 guide.

Example: HL*1**20*1~
Ref.
Data
Des.
Element
HL01
628
Name
Attributes
AN 1/12

M
HL03
735
ID 1/2

20
Information Source
Identifies the payer, maintainer, or source of the
information
HL04
736
ID 1/1
1


PAGE 93
271 Segment:
Position:
AAA Request Validation

025
Loop:
2000A
Level:
Detail
Usage:
Eligibility
Mandatory
Optional
Max Use:
Purpose:
To specify the validity of the request and indicate follow-up action authorized
Syntax Notes:
Semantic Notes:
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:
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~
Ref.
Data
Des.
Element
AAA01
1073
Name
Attributes
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.
Yes
Use this code to indicate that the request is valid,
however the transaction has been rejected as identified
by the code in AAA03.
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.

PAGE 94
41
Eligibility
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

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.
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).
Please Correct and Resubmit
Resubmission Not Allowed
Please Resubmit Original Transaction
Resubmission Allowed
Do Not Resubmit; Inquiry Initiated to a Third Party
Do Not Resubmit; We Will Hold Your Request and

Respond Again Shortly

PAGE 95
271 Segment:
NM1 Information Source Name
Loop:
2100A
Level:
Detail
Usage:
Eligibility
Mandatory
Mandatory
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Notes:
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~
Ref.
Data
Des.
Element
NM101
98
Name
Attributes
ID 2/3

individual
2B
M
NM102
1065
Third-Party Administrator (Recommended by Surescripts)
ID 1/1

organization.
NM103
1035
Person
Non-Person Entity (Recommended by Surescripts)
Organization Name
AN 1/60

* This will contain the actual source of the information (The PBM). It does not
include Surescripts at any point.
M
NM108
66
ID 1/2

Code (67)
* Surescripts will utilize PI to identify the Payer (The PBM).
PI
M
NM109
67
Payer Identification (Recommended by Surescripts)
Identification Code
AN 2/80

Use this code for the reference number as qualified by the preceding data
element (NM108).
* This is the PBMs Participant ID.

PAGE 96
271 Segment:
Position:
AAA Request Validation

085
Loop:
2100A
Level:
Detail
Usage:
Eligibility
Mandatory
Optional
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Use this segment to indicate problems in processing the transaction specifically related to
the information source data contained in the original 270 transactions information source
name loop (Loop 2100A) or to indicate that the information source itself is experiencing
system problems.
Example: AAA*Y**42*Y~
Ref.
Data
Des.
Element
AAA01
1073
Name
Attributes
ID 1/1

N
No
Yes
AAA03
901
Reject Reason Code
ID 2/2

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.

PAGE 97
41
Eligibility
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.
42

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 Sources system.
*PBM cannot process at current time.
79

* 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.
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.
AAA04
889
ID 1/1

applicable).
Please Resubmit Original Transaction
Please Wait 30 Days and Resubmit


PAGE 98
271 Segment:
HL Information Receiver Level (Physician)
Loop:
2000B
Level:
Detail
Usage:
Eligibility
Optional
Mandatory
Max Use:
Purpose:

data segments.
Comments:
See X12 guide.
Notes:
See X12 guide.

Ref.
Data
Des.
Element
HL01
628
Name
Attributes
AN 1/12

M
HL02
734
AN 1/12
M
HL03
735
ID 1/2

21
Information Receiver
Identifies the provider or party(ies) who are the recipient(s)
of the information
HL04
736
ID 1/1
1


PAGE 99
271 Segment:
NM1 Information Receiver Name
Loop:
2100B
Level:
Detail
Usage:
Eligibility
Mandatory
Mandatory
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Notes:
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~
Ref.
Data
Des.
Element
NM101
98
Name
Attributes
ID 2/3

individual
1P
M
NM102
1065
Provider (Recommended by Surescripts)
ID 1/1

organization.
NM103
1035
Person (Recommended by Surescripts)
Non-Person Entity
AN 1/60

Use this name for the organization name if the entity type qualifier is a nonperson entity. Otherwise, this will be the individuals last name.
O
NM104
1036
Name First
AN 1/35
AN 1/25
AN 1/10

Use this name only if available and NM102 is 1.
O
NM105
1037
Name Middle
Use this name only if available and NM102 is 1.
NM107
1039
Name Suffix
Use name suffix only if available and NM102 is 1; e.g., Sr., Jr., or III.
M
NM108
66

ID 1/2
PAGE 100
Eligibility

Code (67)
is the number that the information source associates with the information
receiver.
XX
Health Care Financing Administration 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.
NM109
67
Identification Code
AN 2/80

element (NM108).

PAGE 101
271 Segment:
REF

Identification)
Loop:
2100B
Level:
Detail
Usage:
Eligibility
Mandatory
Optional
Max Use:
Purpose:
Syntax Notes:
.
Comments:
Notes:
*Surescripts defined Participant ID for the Physician System vendor.

Example: REF*EO*477563928~
Ref.
Data
Des.
Element
REF01
128
Name
Attributes
ID 2/3

EO
Submitter Identification Number

A unique number identifying the submitter of the
transaction set
*Qualifier to define this is a Physician System Participant
ID.
REF02
127
AN 1/50

Use this information for the reference number as qualified by the preceding data
element (REF01).
O
REF03
352
Description
AN 1/80
*Not Used for the EO qualifier.

PAGE 102
271 Segment:
AAA Information Receiver Request Validation
Loop:
2100B
Level:
Detail
Usage:
Eligibility
Mandatory
Optional
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
the information receiver data contained in the original 270 transactions information
receiver name loop (Loop 2100B).
Example: AAA*N**43*C~
Ref.
Data
Des.
Element
AAA01
1073
Name
Attributes
ID 1/1

N
No
Yes
AAA03
901
Reject Reason Code
ID 2/2

data content.
15
Required application data missing

Use this code only when the information receivers
additional identification is missing.
*Not enough information given to identify the Physician
System.
41
*A contract does not exist between this Physician
System and the PBM to exchange eligibility information.

PAGE 103
Eligibility
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
79

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.
AAA04
889
ID 1/1

applicable).


PAGE 104
271 Segment:
HL Subscriber Level
Loop:
2000C
Level:
Detail
Usage:
Eligibility
Optional
Optional
Max Use:
Purpose:

data segments
Comments:
See X12 guide.
Notes:
See X12 guide.

This segment is required if this loop is used.
Ref.
Data
Des.
Element
HL01
628
Name
Attributes
AN 1/12

M
HL02
734
AN 1/12
M
HL03
735
ID 1/2

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.
HL04
736
ID 1/1
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).

Structure.


PAGE 105
271 Segment:
TRN Subscriber Trace Number
Loop:
2000C
Level:
Detail
Usage:
Eligibility
Optional
Optional
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Use this segment to convey a unique trace or reference number. See the X12 HIPAA
Implementation Guide (Section 1.4.6 Information Linkage) for additional information.
An information source may receive up to two RN segments in each loop 2100C of a 270
transaction and must return each of them in loop 2100C of the 271 transaction with a
value of 2 in TRN01.
If the subscriber is the patient, an information source may add one TRN segment to loop
2100C with a value of 1 in TRN01 and must identify themselves in TRN03.
If this transaction passes through a clearinghouse, the clearinghouse will receive from the
information source the information receivers TRN segment and the clearinghouses TRN
segment with a value of 2 in TRN01. Since the ultimate destination of the transaction is
the information receiver, if the clearinghouse intends on passing their TRN segment to the
information receiver, the clearinghouse must change the value in TRN01 to 1 of their
TRN segment. This must be done since the trace number in the clearinghouses TRN
segment is not actually a referenced transaction trace number to the information receiver.
TRN*1*209991094361*9ABCINSURE~
The above example represents how an information source would respond. The first TRN
segment was initiated by the information receiver. The second TRN segment was initiated
by the clearinghouse. The third TRN segment was initiated by the information source.
TRN*2*98175-012547*9877281234*RADIOLOGY~
The above example represents how a clearinghouse would respond to the same set of
TRN segments if the clearinghouse intends to pass their TRN segment on to the
information receiver. If the clearinghouse does not intend to pass their TRN segment on to
the information receiver, only the first and third TRN segments in the example would be
sent.

Ref.
Data
Des.
Element
Name

Attributes
PAGE 106
TRN01
481
Eligibility
Trace Type Code
ID 1/2

1

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).
TRN02
127
AN 1/50

M
TRN03
509
AN 10/10

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.
O
TRN04
127
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).

PAGE 107
271 Segment:
NM1 Subscriber Name
Loop:
2100C
Level:
Detail
Usage:
Eligibility
Mandatory
Mandatory
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Notes:
loop is used to identify the insured or subscriber.
* See the Patient_Match_Verification for more details.
Example: NM1*IL*1*SMITH*ROBERT*B***MI*33399999~
Ref.
Data
Des.
Element
NM101
98
Name
Attributes
ID 2/3

individual
IL
M
NM102
1065
Insured or Subscriber
ID 1/1
AN 1/60

1
O
NM103
1035
Person

Use this name for the subscribers 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.
O
NM104
1036
Name First
AN 1/35

Use this name for the subscribers first name.
O
NM105
1037
Name Middle
AN 1/25

Use this name for the subscribers middle name or initial.
Change second note: Required if this is available from the Information Sources
database unless a rejection response is generated and this element was not

PAGE 108
Eligibility

O
NM107
1039
Name Suffix
AN 1/10

Use this for the suffix to an individuals name; e.g., Sr., Jr., or III.
Use if available.
O
NM108
66
ID 1/2

Code (67)
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.).
NM109
67
Identification Code
AN 2/80

element (NM108).
*Subscriber or Dependent PBM Unique ID.

PAGE 109
271 Segment:
Loop:
2100C
Level:
Detail
Usage:
Eligibility
Mandatory
Optional
Max Use:
Purpose:
Syntax Notes:
Notes:
See X12 Guide.

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 sources system (See
Section 1.4.7).
* See the Patient Match Verification for more details.
Example: REF*SY*SOCSEC126329818~
REF*HJ*CARDID23111 ~
REF*49*01~
Ref.
Data
Des.
Element
REF01
128
Name
Attributes
ID 2/3

HJ
Identity Card Number (* Cardholder ID)

*Strongly recommended by Surescripts.
49
Family Unit Member (*Person Code)
SY

EJ
M
REF02
127
AN 1/50

element (REF01).
O
REF03
352
Description
AN 1/80

PAGE 110
271 Segment:
N3 Subscriber Address
Loop:
2100C
Level:
Detail
Usage:
Eligibility
Mandatory
Optional
Max Use:
Purpose:
Syntax Notes :
Semantic Notes :
Comments :
Notes:
Use this segment to identify address information for a subscriber.

Use of this segment is required if the transaction is not rejected and address information is
available from the information sources database.
Do not return address information from the 270 request.
Ref.
Data
Des.
Element
N301
166
Name
Attributes
Address Information
AN 1/55
AN 1/55
Address information
O
N302
166
Address Information
Address information

PAGE 111
271 Segment:
N4 Subscriber City/State/ZIP Code
Loop:
2100C
Level:
Detail
Usage:
Eligibility
Mandatory
Optional
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
A combination of N401 through N404 may be adequate to specify a location.
Use this segment to identify the city, state and ZIP Code for the subscriber.
available from the information sources database.
* See the Patient_Match_Verification for more details.
Ref.
Data
Des.
Element
N401
19
Name
City Name
Attributes
O
AN 2/30
ID 2/2

Use this text for the city name of the subscribers address.
O
N402
156

O
N403
116
Postal Code
ID 3/15
O
N404
26
Country Code
ID 2/3

Use this code to specify the country of the subscribers address, if other than
the United States.

PAGE 112
271 Segment:
AAA Subscriber Request Validation
Loop:
2100C
Level:
Detail
Usage:
Eligibility
Mandatory
Optional
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
the data contained in the original 270 transactions subscriber name loop (Loop 2100C).
Ref.
Data
Des.
Element
AAA01
1073
Name
Attributes
ID 1/1

N
No
Yes
AAA03
901
Reject Reason Code
ID 2/2

data content.
15

*At Surescripts Not enough information for Surescripts
to identify patient.
*At PBM PBM wants more info than what was
supplied.
35
Out of Network
42

PAGE 113
Eligibility
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).
AAA04
889
43
Invalid/Missing Provider Identification
45
47
48
49
Provider is Not Primary Care Physician
51
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
ID 1/1

applicable).
C
Use only when AAA03 is 42.

PAGE 114
Eligibility

Use only when AAA03 is 42.

PAGE 115
271 Segment:
DMG Subscriber Demographic Information
Loop:
2100C
Level:
Detail
Usage:
Eligibility
Mandatory
Optional
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
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 Sources database unless a rejection response is generated and the
elements were not valued in the request.
*See the Patient Match Verification for more details.
Ref.
Data
Des.
Element
DMG01
1250
Name
Attributes
ID 2/3
D8
O
DMG02
1251
Date Time Period
AN 1/35

Required if this is available from the Information Sources database 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
O
DMG03
1068
Gender Code
ID 1/1

Required if this is available from the Information Sources database unless a
Female
Male
Unknown

PAGE 116
271 Segment:
INS Subscriber Relationship
Loop:
2100C
Level:
Detail
Usage:
Eligibility
Mandatory
Optional
Max Use:
Purpose:
To provide benefit information on insured entities
Syntax Notes:
Semantic Notes:
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.
If not required by this implementation guide, do not send.
Example:
INS*Y*18*001*25~
See X12 Guide for more information.
*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.
Ref.
Data
Des.
Element
INS01
1073
Name
Attributes
ID 1/1

* For the Physician System, this will always be Yes (if supplied).
Y
M
INS02
1069
Yes
Individual Relationship Code
ID 2/2
Code indicating the relationship between two individuals or entities

* For the Physician System, this will always be Self (18). This is only
18
O
INS03
875
Self
Maintenance Type Code
ID 3/3
Code identifying the specific type of item maintenance

Use this element (and code 25 in INS04) if any of the identifying elements for
the subscriber have been changed from those submitted in the 270.
001
O
INS04
1203
Change
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
25
Change in Identifying Data Elements

A change has been made to the primary elements that

PAGE 117
Eligibility
identify a specific employee. Such elements are first
name, last name, social security number, date of birth, and
employee identification number
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.

PAGE 118
271 Segment:
DTP Subscriber Date
Loop:
2100C
Level:
Detail
Usage:
Eligibility
Mandatory
Optional
Max Use:
Purpose:

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~
*Surescripts recommends echoing back the date sent in the 270 for this DTP Segment.
Ref.
Data
Des.
Element
DTP01
374
Name
Attributes
Date/Time Qualifier
ID 3/3
ID 2/3

291
M
DTP02
1250
Plan
Use this code to specify the format of the date(s)/time(s) that follow in the next
data element.
D8

RD8
DTP03
1251
Range of Dates express in Format CCYYMMDDCCYYMMDD
Date Time Period
AN 1/35


PAGE 119
271 Segment:
EB Subscriber Eligibility or Benefit Information
Loop:
2110C1
Level:
Detail
Usage:
Eligibility
Optional
Optional
Max Use:
Purpose:
To supply eligibility or benefit information
Syntax Notes:
Semantic Notes:
If either EB09 or EB10 is present, then the other is required.
See X12 Guide.
Comments:
Notes:
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 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~
Ref.
Data
Des.
Element
EB01
1390
Name
Attributes
Eligibility or Benefit Information
ID 1/2
Code identifying eligibility or benefit information

1
Active Coverage
Inactive
*If the member is inactive, then no other EB loops are
required to be sent.
EB03
1365
Cannot Process
Service Type Code
ID 1/2
ID 1/3

30
O
EB04
1336
Health Plan Benefit Coverage
Insurance Type Code
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)

PAGE 120
EB05
1204
Plan Coverage Description
Eligibility
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.
*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, co-payment.
* Surescripts is utilizing this field for Out of Pocket Accumulator. EB01 set to G.

PAGE 121
271 Segment:
Loop:
2110C1
Level:
Detail
Usage:
Eligibility
Mandatory
Optional
Max Use:
Purpose:
Syntax Notes:
Comments:
Notes:
See X12 Guide.

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~
Ref.
Data
Des.
Element
REF01
128
Name
Attributes
ID 2/3

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)

REF02
127
AN 1/50

element (REF01).

PAGE 122
REF03
352
Description
Eligibility
AN 1/80
*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

PAGE 123
271 Segment:
DTP Subscriber Date
Loop:
2110C1
Level:
Detail
Usage:
Eligibility
Mandatory
Optional
Max Use:
20
Purpose:

Syntax Notes:
Semantic Notes:
Comments:
Notes:
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~
*Surescripts recommends sending back the date range of the health plan benefit for this
patients coverage.
Ref.
Data
Des.
Element
DTP01
374
Name
Attributes
Date/Time Qualifier
ID 3/3
ID 2/3

291
M
DTP02
1250
Plan
data element.
D8
RD8

*Surescripts is recommending RD8
DTP03
1251
Date Time Period
AN 1/35


PAGE 124
271 Segment:
Loop:
2110C1
Level:
Detail
Usage:
Eligibility
Optional
Optional
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
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:
Notes:
specific eligibility/benefit inquiry data contained in the original 270 transaction's subscriber
eligibility/benefit inquiry information loop (Loop 2110C).
Ref.
Data
Des.
Element
AAA01
1073
Name
Attributes
ID 1/1

N
No
Yes
AAA03
901
Reject Reason Code
ID 2/2

data content.
15
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.
52
53
Inquired Benefit Inconsistent with Provider Type

PAGE 125
Eligibility
54
Inappropriate Product/Service ID Qualifier
55
Inappropriate Product/Service ID
56
Inappropriate Date
57
60
61
62
63
69
Inconsistent with Patient's Age
70
Inconsistent with Patient's Gender
See X12 guide for additional codes.

M
AAA04
889
ID 1/1

applicable).


PAGE 126
271 Segment:
MSG Message Text
Loop:
2110C1
Level:
Detail
Usage:
Eligibility
Optional
Optional
Max Use:
10
Purpose:
To provide a free-form format that allows the transmission of text information
Syntax Notes:
If MSG03 is present, then MSG02 is required.
Semantic Notes:
MSG03 is the number of lines to advance before printing.
Comments:
MSG02 is not related to the specific characteristics of a printer, but identifies top
of page, advance a line, etc.
If MSG02 is "AA - Advance the specified number of lines before print" then
MSG03 is required.
Notes:
Free form text or description fields are not recommended because they require human
interpretation.
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. If the
need exists to use the MSG segment, it is highly recommended that the entity needing to
use the MSG segment approach X12N with data maintenance to solve the business need
without the use of the MSG segment.
Benefit Disclaimers are strongly discouraged. See X12 Guide (Section 1.4.11 Disclaimers
Within the Transaction). Under no circumstances is more than one MSG segment to be
used for a Benefit Disclaimer per individual response.
* 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.
Example: MSG*Unable to find patient in Surescripts system. Supplying some of these
fields will help find a match: patient zip code~
Ref.
Data
Des.
Element
MSG01
933
Name
Free-Form Message Text
Attributes
M
AN 1/264
Free-form message text

PAGE 127
271 Segment:
LS Loop Header
Loop:
2110C1
Level:
Detail
Usage:
Optional
Optional
Max Use:
Purpose:
To indicate that the next segment begins a loop.
Notes:
Eligibility
Use this segment to identify the beginning of the Subscriber Benefit Related Entity Name
loop. Because both the subscribers 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~
Ref.
Data
Des.
Element
LS01
447
Name
Loop Identifier Code
Attributes
M
AN 1/6
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".

PAGE 128
271 Segment:
NM1 Subscriber Benefit Related Entity Name
Loop:
2120C1
Level:
Detail
Usage:
Eligibility
Loop repeat 23 - Optional
Optional
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Notes:
loop is 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~
Ref.
Data
Des.
Element
NM101
98
Name
Attributes
ID 2/3

individual
NM102
1065
PRP
Primary Payer
SEP
Secondary Payer
TTP
Tertiary Payer
ID 1/1
AN 1/60

1
Person
Non-Person Entity
*Surescripts recommends using 2
NM103
1035

O
NM104
1036
Name First
AN 1/35
AN 1/25
AN 1/10

Use this name only if available and NM102 is 1".
O
NM105
1037
Name Middle
Use this name only if available and NM102 is "1".
NM107
1039
Name Suffix
Use name suffix only if available and NM102 is "1"; e.g., Sr., Jr., or III.

PAGE 129
NM108
66
Eligibility
ID 1/2

Code (67)
PI
O
NM109
67
Payer Identification
Identification Code
AN 2/80

element (NM108).

PAGE 130
271 Segment:
LE Loop Trailer
Loop:
2110C1
Level:
Detail
Usage:
Eligibility
Optional
Optional
Max Use:
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.
Because both the subscribers 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: LE*2120~
Ref.
Data
Des.
Element
LE01
447
Name
Attributes
AN 1/6
Notes:
used.
Example: LE*2120~
Ref.
Data
Des.
Element
LE01
447
Name
Attributes
M
AN 1/6

PAGE 131
271 Segment:
EB Subscriber Eligibility or Benefit Information
Loop:
2110C2-5
Level:
Detail
Usage:
Eligibility
Optional
Optional
Max Use:
1 (Loop Repeats >0
Purpose:
Syntax Notes:
Semantic Notes:
EB01 qualifies EB06 through EB10.
Notes:
*If the previous EB loop EB 30 was set to 6 for not active, then the loop is not 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~
Ref.
Data
Des.
Element
EB01
1390
Name
Attributes
ID 1/2

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
EB03
1365
Out of Pocket (Stop Loss)
Non-Covered
Service Type Code
ID 1/2
EB04
1336
88
Pharmacy (*Retail Benefit)
90
Mail Order Prescription Drug
Empty/Null
Specialty Pharmacy or LTC (See MSG segment)
Insurance Type Code
ID 1/3
Code identifying the type of insurance policy within a specific insurance

program

PAGE 132
Eligibility
Use if available.
EB05
1204
47
CP
MC
Medicaid
MP
Medicare Primary
OT
AN 1/50

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-23", 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

PAGE 133
271 Segment:
DTP Subscriber Date
Loop:
2110C2-5
Level:
Detail
Usage:
Eligibility
Mandatory
Optional
Max Use:
20
Purpose:

Syntax Notes:
Semantic Notes:
Comments:
Notes:
When using the DTP segment in the 2110C loop this date applies only to the 2110C
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~
patients coverage.
Ref.
Data
Des.
Element
DTP01
374
Name
Attributes
Date/Time Qualifier
ID 3/3
ID 2/3

291
M
DTP02
1250
Plan
data element.
D8
RD8

DTP03
1251
Date Time Period
AN 1/35


PAGE 134
271 Segment:
Loop:
2110C2-5
Level:
Detail
Usage:
Eligibility
Optional
Optional
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
specific eligibility/benefit inquiry data contained in the original 270 transaction's subscriber
eligibility/benefit inquiry information loop (Loop 2110C).
Ref.
Data
Des.
Element
AAA01
1073
Name
Attributes
ID 1/1

N
No
Yes
Use this code to indicate that the request is valid;
however, the transaction has been rejected as identified
AAA03
901
Reject Reason Code
ID 2/2

data content.
15
33
Input Errors
segment of the 2110C loop containing this Reject Reason
Code.
52
53

PAGE 135
Eligibility
54
55
56
Inappropriate Date
57
60
61
62
63
69
70
See X12 guide for additional codes.

M
AAA04
889
ID 1/1

applicable).


PAGE 136
Eligibility
MSG Message Text
271 Segment:
Loop:
2110C2-5
Level:
Detail
Usage:
Optional
Optional
Max Use:
10
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
MSG03 is required.
Notes:
interpretation.
Benefit Disclaimers are strongly discouraged. See section 1.3.10 Disclaimers Within the
Transaction. Under no circumstances is more than one MSG segment to be used for a
Benefit Disclaimer per individual response.
* 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.
Example: MSG*SPECIALTY PHARMACY~
MSG*LTC~
Ref.
Data
Des.
Element
MSG01
933
Name
Attributes
M
AN 1/264

PAGE 137
271 Segment:
LS Loop Header
Loop:
2110C2-5
Level:
Detail
Usage:
Optional
Optional
Max Use:
Purpose:
Notes:
Eligibility
Use this segment to identify the beginning of the Subscriber Benefit Related Entity Name
2120C is used.
Example: LS*2120~
Ref.
Data
Des.
Element
LS01
447
Name
Attributes
M
AN 1/6

PAGE 138
271 Segment:
NM1 Subscriber Benefit Related Entity Name
Loop:
2120C2-5
Level:
Detail
Usage:
Eligibility
Loop repeat 23 - Optional
Optional
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Notes:
Example: NM1*13*2*PHARMACY ABC*****SV*NCPDPID~
Ref.
Data
Des.
Element
NM101
98
Name
Attributes
ID 2/3

individual
13
Contracted Service Provider

* Use for Mail Only Benefit. Used to further clarify benefits,
including Mail Only, Specialty and Long Term Care.
NM102
1065
PRP
Primary Payer
SEP
Secondary Payer
TTP
Tertiary Payer
ID 1/1
AN 1/60

1
Person
Non-Person Entity
*Surescripts recommends using 2
NM103
1035

O
NM104
1036
Name First
AN 1/35
AN 1/25

O
NM105
1037
Name Middle

PAGE 139
NM107
1039
Eligibility
Name Suffix
AN 1/10

O
NM108
66
ID 1/2

Code (67)
SV
Service Provider Number (Recommended by Surescripts)

Use this code for the identification number assigned by
the information source.
PI
O
NM109
67
Identification Code
AN 2/80

element (NM108).

PAGE 140
271 Segment:
LE Loop Trailer
Loop:
2110C2-5
Level:
Detail
Usage:
Eligibility
Optional
Optional
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
used.
Example: LE*2120~
Ref.
Data
Des.
Element
LE01
447
Name
Attributes
AN 1/6
Notes:
used.
Example: LE*2120~
Ref.
Data
Des.
Element
LE01
447
Name
Attributes
M
AN 1/6

PAGE 141
271 Segment:
Eligibility
HL Dependent Level
Loop:
2000D
Optional
Level:
Summary
Usage:
Optional
Max Use:
Purpose:

data segments
Comments:
See X12 guide.
Notes:
See X12 Guide.

This segment is required if this loop is used.
Since Surescripts uniquely identifies each patient, the subscriber level should be used instead of the
dependant level regardless of whether the patient is a subscriber or dependent. However, receivers of
the 270 should be able to handle patients at the dependent level since the standard allows it.
Ref.
Data
Des.
Element
HL01
628
Name
Attributes
AN 1/12

M
HL02
734
AN 1/12
M
HL03
735
ID 1/2

23
Dependent
Identifies the individual who is affiliated with the
subscriber, such as spouse, child, etc., and therefore may
be entitled to benefits
Use the dependent level to identify an individual(s) who
may be a dependent of the subscriber/insured. This
entity may or may not be the actual patient.

PAGE 142
HL04
736
Eligibility
ID 1/1
Use this code to indicate whether there are additional hierarchical levels
subordinate to the current hierarchical level.
Because of the hierarchical structure, and because no subordinate HL levels
exist, the code value in the HL04 at the Loop 2000D level should be "0" (zero).
0

Structure.

PAGE 143
271 Segment:
Eligibility
TRN Dependent Trace Number
Loop:
2000D
Optional
Level:
Summary
Usage:
Optional
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Use this segment to convey a unique trace or reference number. See the X12 HIPAA
Implementation Guide (Section 1.4.6 Information Linkage) for additional information.
An information source may receive up to two TRN segments in each loop 2100D of a 270
transaction and must return each of them in loop 2100D of the 271 transaction with a
value of "2" in TRN01.
An information source may add one TRN segment to loop 2100D with a value of "1" in
TRN01 and must identify themselves in TRN03.
If this transaction passes through a clearinghouse, the clearinghouse will receive from the
information source the information receiver's TRN segment and the clearinghouse's TRN
segment with a value of "2" in TRN01. Since the ultimate destination of the transaction is
the information receiver, if the clearinghouse intends to pass their TRN segment to the
information receiver, the clearinghouse must change the value in TRN01 to "1" of their
TRN segment. This must be done since the trace number in the clearinghouse's TRN
segment is not actually a referenced transaction trace number to the information receiver.
The above example represents how an information source would respond. The first TRN
segment was initiated by the information receiver. The second TRN segment was initiated
by the clearinghouse. The third TRN segment was initiated by the information source.
TRN*2*98175-012547*9877281234*RADIOLOGY~
The above example represents how a clearinghouse would respond to the same set of
TRN segments if the clearinghouse intends to pass their TRN segment on to the
information receiver. If the clearinghouse does not intend to pass their TRN segment on to
the information receiver, only the first and third TRN segments in the example would be
sent.

PAGE 144
Eligibility
Ref.
Data
Des.
Element
TRN01
481
Name
Attributes
Trace Type Code
ID 1/2

1

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").
TRN02
127
AN 1/50

M
TRN03
509
AN 10/10

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.
O
TRN04
127
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).

PAGE 145
271 Segment:
Eligibility
NM1 Dependent Name
Loop:
2100D
Mandatory
Level:
Summary
Usage:
Mandatory
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Notes:
loop is used to identify the dependent of an insured or subscriber.
Example: NM1*03*SMITH*MARY LOU*R~
Ref.
Data
Des.
Element
NM101
98
Name
Attributes
ID 2/3

individual
03
M
NM102
1065
Dependent
ID 1/1
AN 1/60

1
O
NM103
1035
Person

Use this name for the dependent's last name.
O
NM104
1036
Name First
AN 1/35

Use this name for the dependent's first name.
O
NM105
1037
Name Middle
AN 1/25

Use this name for the dependent's middle name or initial.
Required if this is available from the Information Source's database unless a

PAGE 146
Eligibility

O
NM107
1039
Name Suffix
AN 1/10

Use this for the suffix to an individual's name; e.g., Sr., Jr., or III.
Use if available.

PAGE 147
271 Segment:
Eligibility
Loop:
2100D
Mandatory
Level:
Summary
Usage:
Optional
Max Use:
Purpose:
Syntax Notes:
Comments:
Notes:
See X12 Guide.

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 sources system (See
Section 1.4.7).
Example: REF*SY*111223333~
REF*HJ*CARDID23111 ~
REF*49*01~
Ref.
Data
Des.
Element
REF01
128
Name
Attributes
ID 2/3

HJ
Identity Card Number(* Cardholder ID)

49
Family Unit Member (*Person Code)
SY

EJ
M
REF02
127
AN 1/50

O
REF03
352
Description
AN 1/80

PAGE 148
271 Segment:
Eligibility
N3 Dependent Address
Loop:
2100D
Mandatory
Level:
Summary
Usage:
Optional
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Use this segment to identify address information for a dependent.

available from the information source's database.
Ref.
Data
Des.
Element
N301
166
Name
Address Information
Attributes
M
AN 1/55
AN 1/55
Address information
Use this information for the first line of the address information
*This data is to be returned from the PBM payer system..
O
N302
166
Address Information
Address information

PAGE 149
271 Segment:
Eligibility
N4 Dependent City/State/ZIP Code
Loop:
2100D
Mandatory
Level:
Summary
Usage:
Optional
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
A combination of N401 through N404 may be adequate to specify a location.
Use this segment to identify the city, state and ZIP Code for a dependent.
available from the information source's database.
Ref.
Data
Des.
Element
N401
19
Name
City Name
Attributes
O
AN 2/30
ID 2/2

Use this text for the city name of the dependent's address.
O
N402
156

O
N403
116
Postal Code
ID 3/15
O
N404
26
Country Code
ID 2/3

Required if address is outside the United States.

PAGE 150
271 Segment:
Eligibility
AAA Dependent Request Validation
Loop:
2100D
Mandatory
Level:
Summary
Usage:
Optional
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
the data contained in the original 270 transaction's dependent name loop (Loop 2100D).
Ref.
Data
Des.
Element
AAA01
1073
Name
Attributes
ID 1/1
ID 2/2
AAA03
901
No
Yes
Reject Reason Code

data content.
15
35
Out of Network
Use this code to indicate that the dependent is not
in the Network of the provider identified in the 2100B
NM1 segment, or the 2100B/2100D PRV segment if
present, in the 270 transaction
42

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 in generating a
response). Use only codes "R", "S", or "Y" for AAA04.
43
Invalid/Missing Provider Identification

PAGE 151
AAA04
889
Eligibility
45
47
48
49
Provider is Not Primary Care Physician
51
52
56
Inappropriate Date
57
58
Invalid/Missing Date-of-Birth
Code 58 may not be returned if the information source has
located an individual and the Birth Date does not match; use
code 71 instead.
60
61
62
63
64
Invalid/Missing Patient ID
65
Invalid/Missing Patient Name
66
Invalid/Missing Patient Gender Code
67
Patient Not Found
68
Duplicate Patient ID Number
71
Patient Birth Date Does Not Match That for the Patient on
the Database
77
Subscriber Found, Patient Not Found
ID 1/1

applicable).
C
Use only when AAA03 is "42".

Use only when AAA03 is "42".

PAGE 152
271 Segment:
Eligibility
DMG Dependent Demographic Information
Loop:
2100D
Mandatory
Level:
Summary
Usage:
Optional
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Use this segment to convey the birth date or gender demographic information for the
dependent.
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.
Ref.
Data
Des.
Element
DMG01
1250
Name
Attributes
ID 2/3
D8
O
DMG02
1251
Date Time Period
AN 1/35

O
DMG03
1068
Gender Code
ID 1/1

Female
Male
Unknown

PAGE 153
271 Segment:
Eligibility
INS Dependent Relationship
Loop:
2100D
Mandatory
Level:
Summary
Usage:
Optional
Max Use:
Purpose:
To provide benefit information on insured entities
Syntax Notes:
Semantic Notes:
INS01 indicates status of the insured. A "Y" value indicates the insured is a
subscriber: an "N" value indicates the insured is a dependent.
INS17 is the number assigned to each family member born with the same birth
date. This number identifies birth sequence for multiple births allowing proper
tracking and response of benefits for each dependent (i.e., twins, triplets, etc.).
Comments:
Notes:
Required when the Dependent is the patient unless a rejection response is generated
with a 2100D or 2110D AAA segment and this segment was not sent in the request. If
not required by this implementation guide, may be provided at senders discretion but
cannot be required by the receiver.
This segment may also be used to identify that the information source has changed some
of the identifying elements for the dependent that the information receiver submitted in
the original 270 transaction.
Example:
INSN193~
See X12 Guide for more information.
Ref.
Data
Des.
Element
INS01
1073
Name
Attributes
ID 1/1
ID 2/2

N
M
INS02
1069
No
Individual Relationship Code
Code indicating the relationship between two individuals or entities

01
Spouse
19
Child
Dependent between the ages of 0 and 19; age
qualifications may vary depending on policy
21
Unknown
Use this code only if relationship information is not
available and there is a need to use data elements
INS03, INS04, INS09, INS10 or INS17.
34
O
INS03
875
Other Adult
Maintenance Type Code
ID 3/3
Code identifying the specific type of item maintenance

Use this element (and code "25" in INS04) if any of the identifying elements for
the dependent have been changed from those submitted in the 270.

PAGE 154
001
O
INS04
1203
Eligibility
Change
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
25
Change in Identifying Data Elements

A change has been made to the primary elements that
identify a specific employee. Such elements are first
name, last name, social security number, date of birth, and
employee identification number
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,
and identification numbers.

PAGE 155
271 Segment:
Eligibility
DTP Dependent Date
Loop:
2100D
Mandatory
Level:
Summary
Usage:
Optional
Max Use:
Purpose:
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~
Ref.
Data
Des.
Element
DTP01
374
Name
Attributes
Date/Time Qualifier
ID 3/3
ID 2/3

291
M
DTP02
1250
Plan
data element.
D8

RD8
M
DTP03
1251
Date Time Period
AN 1/35


PAGE 156
271 Segment:
Eligibility
EB Dependent Eligibility or Benefit Information
Loop:
2110D1
Optional
Level:
Summary
Usage:
Mandatory
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Notes:
See X12 guide.
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~
Ref.
Data
Des.
Element
EB01
1390
Name
Attributes
ID 1/2
ID 1/2
ID 1/3
EB03
1365
Active Coverage
Inactive
Cannot Process
Service Type Code

30
EB04
1336
Insurance Type Code
Code identifying the type of insurance policy within a specific insurance program
Use if available.
47
CP
MC
Medicaid
MP
Medicare Primary
OT

PAGE 157
EB05
1204
Eligibility
AN 1/50

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.
*The health plan name for patients that are eligible will be sent at this level.
*Surescripts requires applications display this if sent.

PAGE 158
271 Segment:
Loop:
2110D1
Level:
Detail
Usage:
Eligibility
Mandatory
Optional
Max Use:
Purpose:
Syntax Notes:
Comments:
Notes:
See X12 Guide.

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~
Ref.
Data
Des.
Element
REF01
128
Name
Attributes
ID 2/3

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)

REF02
127
AN 1/50

element (REF01).
O
REF03
352
Description
AN 1/80

PAGE 159
Eligibility
REF01=6P, This is the group name

REF01=N6, This is the PCN Number

PAGE 160
271 Segment:
DTP Dependent Eligibility/Benefit Date
Loop:
2110D1
Level:
Detail
Usage:
Eligibility
Optional
Optional
Max Use:
20
Purpose:
Semantic Notes:
Comments:
Notes:
When using the DTP segment in the 2110D loop this date applies only to the 2110D
If a DTP segment with the same DTP01 value is present in the 2100D loop, the date is
overridden for only this 2110D Eligibility or Benefit Information (EB) loop.
Example: DTP*291*RD8*20100101-20101231~
patients coverage.
Ref.
Data
Des.
Element
DTP01
374
Name
Attributes
Date/Time Qualifier
ID 3/3
ID 2/3

291
M
DTP02
1250
Plan
data element.
D8
RD8
Range of Dates Expressed in Format CCYYMMDDCCYYMMDD

DTP03
1251
Date Time Period
AN 1/35


PAGE 161
271 Segment:
Loop:
2110D1
Level:
Detail
Usage:
Eligibility
Optional
Optional
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
specific eligibility/benefit inquiry data contained in the original 270 transaction's dependent
eligibility/benefit inquiry information loop (Loop 2110D).
Ref.
Data
Des.
Element
AAA01
1073
Name
Attributes
ID 1/1

N
No
Yes
AAA03
901
Reject Reason Code
ID 2/2

data content.
15
33
Input Errors
segment of the 2110D loop containing this Reject Reason
Code.
52
53

PAGE 162
AAA04
889
Eligibility
54
55
56
Inappropriate Date
57
60
61
62
63
69
70
ID 1/1

applicable).


PAGE 163
271 Segment:
Eligibility
MSG Message Text
Loop:
2110D1
Mandatory
Level:
Summary
Usage:
Optional
Max Use:
10
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
MSG03 is required.
Notes:
interpretation.
Benefit Disclaimers are strongly discouraged. See the X12 Guide, Section 1.4.11
Disclaimers Within the Transaction. Under no circumstances is more than one MSG
segment to be used for a Benefit Disclaimer per individual response.
* 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.
Example: MSG* Unable to find patient in Surescripts system. Supplying some of these
fields will help find a match: patient zip code ~
Ref.
Data
Des.
Element
MSG01
933
Name
Attributes
M
AN 1/264

PAGE 164
271 Segment:
LS Loop Header
Loop:
2110D1
Level:
Detail
Usage:
Eligibility
Optional
Optional
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Use this segment to identify the beginning of the Dependent Benefit Related Entity Name
2120D is used
Example: LS*2120~
Ref.
Data
Des.
Element
LS01
447
Name
Attributes
M
AN 1/6

PAGE 165
271 Segment:
NM1 Dependant Benefit Related Entity Name
Loop:
2120D1
Level:
Detail
Usage:
Eligibility
Optional
Optional
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Notes:
Ref.
Data
Des.
Element
NM101
98
Name
Attributes
ID 2/3

individual
NM102
1065
PRP
Primary Payer
SEP
Secondary Payer
TTP
Tertiary Payer
ID 1/1
AN 1/60
NM103
1035
Person
Non-Person Entity

O
NM104
1036
Name First
AN 1/35
AN 1/25
AN 1/10

O
NM105
1037
Name Middle
NM107
1039
Name Suffix
M
NM108
66

ID 1/2
PAGE 166
Eligibility

Code (67)
PI
M
NM109
67
Identification Code
AN 2/80

element (NM108).

PAGE 167
271 Segment:
LE Loop Trailer
Loop:
2110D1
Level:
Detail
Usage:
Eligibility
Optional
Optional
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Use this segment to identify the end of the Dependent Benefit Related Entity Name loop.
and LE segments are used to differentiate these two loops. Required if Loop 2120D is
used.
Example: LE*2120~
Ref.
Data
Des.
Element
LE01
447
Name
Attributes
M
AN 1/6

PAGE 168
271 Segment:
Eligibility
EB Dependent Eligibility or Benefit Information
Loop:
2110D2-5
Optional
Level:
Summary
Usage:
Mandatory
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Notes:
See X12 guide.
Example:
EB*1**88**RETAIL HEALTH PLAN NAME ~
EB*1**90**MAIL ORDER HEALTH PLAN NAME ~
EB*1****SPECIALTY HEALTH PLAN NAME ~
EB*1****LTC HEALTH PLAN NAME ~
MSG*LTC~
Ref.
Data
EB01
1390
ID 1/2

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
EB03
1365
Out of Pocket (Stop Loss)
Non-Covered
Service Type Code
ID 1/2
ID 1/3
EB04
1336
88
Pharmacy (*Retail Benefit)
90
Mail Order Prescription Drug
Insurance Type Code
Code identifying the type of insurance policy within a specific insurance program
Use if available.
47

PAGE 169
EB05
1204
Eligibility
CP
MC
Medicaid
MP
Medicare Primary
OT
AN 1/50

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-23", 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

PAGE 170
271 Segment:
DTP Dependent Eligibility/Benefit Date
Loop:
2110D2-5
Level:
Detail
Usage:
Eligibility
Optional
Optional
Max Use:
20
Purpose:
Semantic Notes:
Comments:
Notes:
When using the DTP segment in the 2110D loop this date applies only to the 2110D
If a DTP segment with the same DTP01 value is present in the 2100D loop, the date is
overridden for only this 2110D Eligibility or Benefit Information (EB) loop.
Example: DTP*291*RD8*20100101-20101231~
Ref.
Data
Des.
Element
DTP01
374
Name
Attributes
Date/Time Qualifier
ID 3/3
ID 2/3

291
M
DTP02
1250
Plan
data element.
D8
RD8
Range of Dates Expressed in Format CCYYMMDDCCYYMMDD

DTP03
1251
Date Time Period
AN 1/35


PAGE 171
271 Segment:
Loop:
2110D2-5
Level:
Detail
Usage:
Eligibility
Optional
Optional
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
specific eligibility/benefit inquiry data contained in the original 270 transaction's dependent
eligibility/benefit inquiry information loop (Loop 2110D).
Ref.
Data
Des.
Element
AAA01
1073
Name
Attributes
ID 1/1

N
No
Yes
AAA03
901
Reject Reason Code
ID 2/2

data content.
15
33
Input Errors
segment of the 2110D loop containing this Reject Reason
Code.
52
53
54

PAGE 172
AAA04
889
Eligibility
55
56
Inappropriate Date
57
60
61
62
63
69
70
ID 1/1

applicable).


PAGE 173
271 Segment:
Eligibility
MSG Message Text
Loop:
2110D2-5
Level:
Summary
Usage:
Optional
Mandatory
Max Use:
10
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
MSG03 is required.
Notes:
interpretation.
Benefit Disclaimers are strongly discouraged. See section 1.3.10 Disclaimers Within the
Transaction. Under no circumstances is more than one MSG segment to be used for a
Benefit Disclaimer per individual response.
* This free text is used for Specialty Pharmacy or 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. The text LTC will be used to indicate Long Term Care
Example: MSG*SPECIALTY PHARMACY~
MSG*LTC~
Ref.
Data
Des.
Element
MSG01
933
Name
Attributes
M
AN 1/264

PAGE 174
271 Segment:
LS Loop Header
Loop:
2110D2-5
Level:
Detail
Usage:
Eligibility
Optional
Optional
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Use this segment to identify the beginning of the Dependent Benefit Related Entity Name
2120D is used
Example: LS*2120~
Ref.
Data
Des.
Element
LS01
447
Name
Attributes
M
AN 1/6

PAGE 175
271 Segment:
NM1 Dependant Benefit Related Entity Name
Loop:
2120D2-5
Level:
Detail
Usage:
Eligibility
Optional
Optional
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Notes:
Example: NM1*13*2*PHARMACY ABC*****SV*NCPDPID~
Ref.
Data
Des.
Element
NM101
98
Name
Attributes
ID 2/3

individual
13
Contracted Service Provider

* Use for Mail Only Benefit
NM102
1065
PRP
Primary Payer
SEP
Secondary Payer
TTP
Tertiary Payer
ID 1/1
AN 1/60
NM103
1035
Person
Non-Person Entity

O
NM104
1036
Name First
AN 1/35
AN 1/25
AN 1/10

O
NM105
1037
Name Middle
NM107
1039
Name Suffix

PAGE 176
Eligibility

M
NM108
66
ID 1/2

Code (67)
SV
Service Provider Number (Recommended by Surescripts)

Use this code for the identification number assigned by
the information source.
PI
M
NM109
67
Identification Code
AN 2/80

element (NM108).

PAGE 177
271 Segment:
LE Loop Trailer
Loop:
2110D2-5
Level:
Detail
Usage:
Eligibility
Optional
Optional
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
Use this segment to identify the end of the Dependent Benefit Related Entity Name loop.
and LE segments are used to differentiate these two loops. Required if Loop 2120D is
used.
Example: LE*2120~
Ref.
Data
Des.
Element
LE01
447
Name
Attributes
M
AN 1/6

PAGE 178
271 Segment:
Eligibility
Loop:
Level:
Summary
Usage:
Mandatory
Max Use:
Purpose:
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~
Ref.
Data
Des.
Element
SE01
96
Name
Attributes
M
N0 1/10

segments
M
SE02
329
AN 4/9
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.

PAGE 179
271 Segment:
Eligibility
Loop:
Level:
Summary
Usage:
Mandatory
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:

header.
Ref.
Data
Des.
Element
GE01
97
Name
Attributes
M
N0 1/6

M
GE02
28
N0 1/9


PAGE 180
271 Segment:
Eligibility
Loop:
Level:
Summary
Usage:
Mandatory
Max Use:
Purpose:

Syntax Notes:
Semantic Notes:
Comments:
Ref.
Data
Des.
Element
IEA01
I16
Name
Attributes
M
N0 1/5

M
IEA02
I12
N0 9/9


PAGE 181
Eligibility
4.10 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 ID
Name
Req
Des
Max
Use
183
185
187
ISA
TA1
IEA

Interchange Acknowledgment
M
O
M
1
1
1

Loop
Repeat
PAGE 182
Segment:
Eligibility
Loop:
Level:
Usage:
Mandatory
Max Use:
Purpose:

Syntax Notes:
Semantic Notes:
Comments:
Ref.
Data
Des.
Element
ISA01
I01
Name
Attributes
ID 2/2

00
M
ISA02
I02

Information in I02)
AN 10/10

*Empty/Null
M
ISA03
I03
ID 2/2

01
M
ISA04
I04
Password
AN 10/10
*Password utilized by the sender to access the receiver system.
M
ISA05
I05
ID 2/2

ZZ
M
ISA06
I06
Mutually Defined
AN 15/15
sender ID element
*The Sender Participant ID. Participant ID is the Surescripts system Participant
ID.
M
ISA07
I05
ID 2/2


PAGE 183
ZZ
M
ISA08
I07
Eligibility
Mutually Defined
AN 15/15

*The Receiver Participant ID. Participant ID is assigned by Surescripts.
M
ISA09
I08
Interchange Date
DT 6/6
TM 4/4

M
ISA10
I09
Interchange Time
*Time format HHMM required.
ISA11
I65
M
1/1
segment terminator
ISA12
I11
ID 5/5

00501
M
ISA13
I12

N0 9/9

*A unique number assigned by the sender. Used to communicate from the
receiver back to the sender to identify this transaction.
M
ISA14
I13
ID 1/1

* No TA1s are returned for TA1s
ISA15
I14
Usage Indicator
ID 1/1

ISA16
I15
Production Data
Test Data
AN 1/1

PAGE 184
Segment:
Eligibility
TA1 Interchange Acknowledgment
Loop:
Level:
Usage:
Optional
Max Use:
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:
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.
TA1*000000905*940101*0100*A*000~
*Surescripts only supports the TA1 for errors. It is not sent as an acknowledgement for
successful messages.
Ref.
Data
Des.
Element
TA101
I12
Name
Attributes
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
The Transmitted Interchange Control Structure Header

and Trailer Have Been Received and Have No Errors.

and Trailer Have Been Received and Are Accepted But

PAGE 185
Eligibility
Errors Are Noted. This Means the Sender Must Not
Resend This Data.
R
M
TA105
I18

and Trailer are Rejected Because of Errors.
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

PAGE 186
Segment:
Eligibility
Loop:
Level:
Usage:
Mandatory
Max Use:
Purpose:

Syntax Notes:
Semantic Notes:
Comments:
Ref.
Data
Des.
Element
IEA01
I16
Name
Attributes
M
N0 1/5

M
IEA02
I12
N0 9/9


PAGE 187
Eligibility
4.11 999 IMPLEMENTATION ACKNOWLEDGEMENT FOR HEALTH CARE

INSURANCE
FA

Introduction:
Refer to the 005010X231 guide for purpose and scope of this transaction.
Heading:
Page #
Header
190
193
195
Detail
196
Seg ID
Name
M/C
Max
Use
ISA
GS
ST

M
M
M
1
1
1
AK1
1
>1
C
C
C
M
M
1
>1
1
>1
1
1
M
M
M
1
1
1
197
AK2
198
199
201
203
Trailer
IK3
IK4
IK5
AK9
Functional Group Response Header

LOOP ID - 2000 - AK2 TRANSACTION SET RESPONSE
HEADER
Transaction Set Response Header
LOOP ID - 2100 - AK2/IK3 ERROR IDENTIFICATION
Error Identification
Implementation Data Element Note
Transaction Set Response Trailer
Functional Group Response Trailer
205
206
207
SE
GE
IEA

Loop
Repeat
Transaction Set Notes

The 999 Acknowledgment shall 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
senders code and the application receivers code, taken from the functional group being acknowledged, are
exchanged; therefore, one acknowledgment functional group responds to only those functional groups from one
application receivers code to one application senders code.

PAGE 188
Eligibility
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.

PAGE 189
999 Segment:
Eligibility
Loop:
Level:
Usage:
Mandatory
Max Use:
Purpose:

Syntax Notes:
Semantic Notes:
Comments:
Ref.
Data
Des.
Element
ISA01
I01
Name
Attributes
ID 2/2

00
M
ISA02
I02

Information in I02)
AN 10/10

M
ISA03
I03
ID 2/2

01
M
ISA04
I04
Password
AN 10/10
*Password used by the sender to access the receiver system. Password
assigned by Surescripts.
M
ISA05
I05
ID 2/2

ZZ
Mutually Defined

PAGE 190
ISA06
I06
Eligibility
AN 15/15
sender ID element
*From the Physician System this is the Surescripts system Physician System
Participant ID.
*From Surescripts, this is Surescripts Participant ID.
M
ISA07
I05
ID 2/2

ZZ
M
ISA08
I07
Mutually Defined
AN 15/15
Identification code published by the receiver of the data. When sending, it is

ISA09
I08
Interchange Date
DT 6/6
TM 4/4

M
ISA10
I09
Interchange Time
*Time format HHDD required.
ISA11
I65
M
1/1
segment terminator.
ISA12
I11
ID 5/5

00501
M
ISA13
I12

N0 9/9
ID 1/1

*The senders unique identification of this transaction.
M
ISA14
I13

*No TA1s are returned for 999s

PAGE 191
ISA15
I14
Eligibility
Usage Indicator
ID 1/1

ISA16
I15
Production Data
Test Data
AN 1/1

PAGE 192
999 Segment:
Eligibility
Loop:
Level:
Usage:
Mandatory
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Notes:
*When sending a TA1, the GS segment is not required.
Ref.
Data
Des.
Element
GS01
479
Name
Attributes
ID 2/2
AN 2/15

FA
M
GS02
142
Implementation Acknowledgment (999)
Application Sender's Code

partners
*The Sender Participant ID. Participant ID is assigned by Surescripts.
M
GS03
124
Application Receiver's Code
AN 2/15

partners
M
GS04
373
Date
DT 8/8
TM 4/8

M
GS05
337
Time

*Time format HHMMSSDD required.
M
GS06
28
N0 1/9

transaction set.

PAGE 193
GS07
455
Eligibility
ID 1/2
standard
X
GS08
480
AN 1/12
005010X231

PAGE 194
999 Segment:
Eligibility
Loop:
Level:
Usage:
Mandatory
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Ref.
Data
Des.
Element
ST01
143
Name
Attributes
ID 3/3
AN 4/9

999
M
ST02
329
Implementation Acknowledgment
unique number also aids in error resolution research. Start with the number, for
interchanges.
M
ST03
1705
AN 1/35

implementation convention reference takes precedence over the implementation
reference specified in the GS08 This element must be populated with
005010X231.
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.

PAGE 195
999 Segment:
Eligibility
AK1 Functional Group Response Header
Loop:
Level:
Usage:
Mandatory
Max Use:
Purpose:
To start acknowledgment of a functional group
Syntax Notes:
Semantic Notes:
AK101 is the functional ID found in the GS segment (GS01) in the functional

group being acknowledged.
AK102 is the functional group control number found in the GS segment in the
functional group being acknowledged.
Comments:
Ref.
Data
Des.
Element
AK101
479
Name
Attributes
ID 2/2
AK102
28
HB
Eligibility, Coverage or Benefit Information (271)
HS
Eligibility, Coverage or Benefit Inquiry (270)
N0 1/9

transaction set.
M
AK103
480

O AN 1/12
A 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
Use the value in GS08 from the functional group to which this 999 transaction set
is responding.

PAGE 196
Segment:
Loop:
Eligibility
AK2 Transaction Set Response Header

AK2
Optional
Level:
Usage:
Optional
Max Use:
Purpose:
To start acknowledgment of a single transaction set
Syntax Notes:
Semantic Notes:
AK201 is the transaction set ID found in the ST segment (ST01) in the

transaction set being acknowledged.
AK202 is the transaction set control number found in the ST segment in the
transaction set being acknowledged.
Comments:
Ref.
Data
Des.
Element
AK201
143
Name
Attributes
ID 3/3
AK202
329
270
Eligibility, Coverage or Benefit Inquiry
271
Eligibility, Coverage or Benefit Information
AN 4/9

PAGE 197
999 Segment:
Loop:
Eligibility
IK3 Error Identification

IK3
Optional
Level:
Usage:
Optional
Max Use:
Purpose:
To report errors in a data segment and identify the location of the data segment
Ref.
Data
Des.
Element
IK301
721
Name
Attributes
Segment ID Code
ID 2/3
N0 1/10
Code defining the segment ID of the data segment in error (

M
IK302
719
Segment Position in Transaction Set
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
AN 1/4
O
IK304
620
Segment Syntax Error Code
ID 1/3
Code indicating error found based on the syntax editing of a segment
Unrecognized segment ID
Unexpected segment
Mandatory segment missing
Loop Occurs Over Maximum Times
Segment Exceeds Maximum Use
Segment Not in Defined Transaction Set
Segment Not in Proper Sequence
Segment Has Data Element Errors

PAGE 198
999 Segment:
Loop:
Eligibility
IK4 Implementation Data Element Note

IK3
Optional
Level:
Usage:
Optional
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:
In no case shall a value be used for AK404 that would generate a syntax error,
e.g., an invalid character.
Comments:
Ref.
Data
Des.
Element
IK401
C030
Name
Position in Segment
Attributes
M
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.

PAGE 199
IK403
621
Eligibility
Implementation Data Element Syntax Error Code
ID 1/3
Code indicating the error found after syntax edits of a data element
IK404
724
Mandatory data element missing
Conditional required data element missing.
Too many data elements.
Data element too short.
Data element too long.
Invalid character in data element.
Invalid code value.
Invalid Date
Invalid Time
10
Exclusion Condition Violated
Copy of Bad Data Element
AN 1/99
This is a copy of the data element in error

PAGE 200
999 Segment:
Loop:
Eligibility
IK5 Implementation Transaction Set Response Trailer

AK2
Optional
Level:
Usage:
Mandatory
Max Use:
Purpose:
To acknowledge acceptance or rejection and report errors in a transaction set
Ref.
Data
Des.
Element
IK501
717
Name
Attributes
Transaction Set Acknowledgment Code
ID 1/1
Code indicating accept or reject condition based on the syntax editing of the
transaction set
A
Accepted
Accepted But Errors Were Noted
Rejected, Message Authentication Code (MAC) Failed
Rejected
* Surescripts recommends R.
IK502
618
Rejected, Assurance Failed Validity Tests
Rejected, Content After Decryption Could Not Be Analyzed
Transaction Set Syntax Error Code
ID 1/3
Code indicating error found based on the syntax editing of a transaction set
Transaction Set Not Supported
Transaction Set Trailer Missing
Transaction Set Control Number in Header and Trailer Do

Not Match
Number of Included Segments Does Not Match Actual

Count
One or More Segments in Error
Missing or Invalid Transaction Set Identifier
Missing or Invalid Transaction Set Control Number
Authentication Key Name Unknown
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

PAGE 201
IK503
618
Eligibility
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
21

Segment
22

Segment
23
Transaction Set Control Number Not Unique within the

Functional Group
24

Segment
25

Segment
26

Segment
27

Segment
ID 1/3
Same Codes as IK502
O
IK504
718
ID 1/3
Same Codes as IK502
O
IK505
718
ID 1/3
Same Codes as IK502
O
IK506
718
ID 1/3
Same Codes as IK502

PAGE 202
999 Segment:
Eligibility
AK9 Functional Group Response Trailer
Loop:
Level:
Usage:
Mandatory
Max Use:
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:
If AK901 contains the value "A" or "E", then the transmitted functional group is
accepted.
Ref.
Data
Des.
Element
AK901
715
Name
Attributes
Functional Group Acknowledge Code
ID 1/1
Code indicating accept or reject condition based on the syntax editing of the
functional group
A
Accepted
Accepted, But Errors Were Noted.
Rejected, Message Authentication Code (MAC) Failed
Partially Accepted, At Least One Transaction Set Was

Rejected
Rejected
*Surescripts recommends use of R.
AK902
97
Rejected, Assurance Failed Validity Tests
Rejected, Content After Decryption Could Not Be

Analyzed
N0 1/6

M
AK903
123
Number of Received Transaction Sets
N0 1/6
N0 1/6
ID 1/3
Number of Transaction Sets received

M
AK904
Number of Accepted Transaction Sets

Number of accepted Transaction Sets in a Functional Group
AK905
716
Functional Group Syntax Error Code
Code indicating error found based on the syntax editing of the functional group
header and/or trailer
1
Functional Group Not Supported

PAGE 203
AK906
716
Eligibility
Functional Group Version Not Supported
Functional Group Trailer Missing
Group Control Number in the Functional Group Header

and Trailer Do Not Agree
Number of Included Transaction Sets Does Not Match

Actual Count
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
19

Segment
20
S1S Security Start Segment Missing for S1E End

Segment
21

Segment
22

Segment
23

Segment
24
S3S Security Start Segment Missing for S3E End

Segment
25

Segment
26

Segment
ID 1/3
header and/or trailer (Same codes as AK905)
O
AK907
716
ID 1/3
O
AK908
716
ID 1/3
O
AK909
716
ID 1/3

PAGE 204
999 Segment:
Eligibility
Loop:
Level:
Usage:
Mandatory
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:
Ref.
Data
Des.
Element
SE01
96
Name
Attributes
M
N0 1/10

segments
M
SE02
329
AN 4/9
interchanges.

PAGE 205
999 Segment:
Eligibility
Loop:
Level:
Usage:
Mandatory
Max Use:
Purpose:
Syntax Notes:
Semantic Notes:
Comments:

header.
Notes:
*When sending a TA1, the GE segment is not required.
Ref.
Data
Des.
Element
GE01
97
Name
Attributes
M
N0 1/6

M
GE02
28
N0 1/9


PAGE 206
999 Segment:
Eligibility
Loop:
Level:
Usage:
Mandatory
Max Use:
Purpose:

Syntax Notes:
Semantic Notes:
Comments:
Ref.
Data
Des.
Element
IEA01
I16
Name
Attributes
M
N0 1/5

M
IEA02
I12
N0 9/9

Same control number as ISA13

PAGE 207
Eligibility
4.12 270 AND 271 TRANSACTION EXAMPLES

This is an example of a prescriber/clinic checking a patients benefit plan. The
lifecycle consists of:
Prescriber System creates the 270 and sends to Surescripts.
Surescripts identifies the patient and sends a 270 to the PBM.
The PBM processes the 270 and returns a 271 to Surescripts.
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*005010X279~
ST*270*0001*005010X279~
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.*SV*3334444~
REF*EO*POCID~
N3*55 HIGH STREET~
N4*SEATTLE*WA*98123*US~
HL*3*2*22*0~
NM1*IL*1*JAMES*TINA~
N3*29 FREMONT ST*ATP# 1~
N4*PEACE*NY*10023*US~
DMG*D8*19430519*M~
DTP*291*D8*20091222~
EQ*30~
SE*17*0001~
GE*1*1~
IEA*1*000000001~

PAGE 208
Eligibility
Segment
Value
Note
ISA
ISA
PWPHY12345
POCID
The Password needed to correspond with the Surescripts system.

The Physician Systems Participant ID.
ISA
BHT
S00000000000001
3920394930203
HL1:NM1
SURESCRIPTS
LLC
TIM JONSON
3334444
Tina James
30
Participant ID for Surescripts.

The Transaction reference number that ties the request to the
response.
Source does not know PBM so they put in Surescripts.
HL2:NM1
HL2:NM1
HL3:NM1
EQ
Dr.s Name.
Dr Jonson DEA number 3334444.
Tina James is the patient.

PAGE 209
Eligibility
Eligibility Request (from Surescripts to PBM)

Note: Surescripts has located the patient and populated the PBM Unique ID.
ISA*00*
*01*PW12345PBM*ZZ*S00000000000001*ZZ*PBM123
*011217*0309*^*00501*000000001*1*P*>~
GS*HS*S00000000000001*PBM123*20011217*16150000*1*X*005010X279~
ST*270*0001*005010X279~
BHT*0022*13*3920394930203*20091217*16150000~
HL*1**20*1~
NM1*2B*2*PBM COMPANY*****PI*PBM123~
HL*2*1*21*1~
NM1*1P*1*JONSON*TIM*T**M.D.*XX3334444~
REF*EO*POCID~
N3*55 HIGH STREET~
N4*SEATTLE*WA*98123*US~
HL*3*2*22*0~
NM1*IL*1*JAMES*TINA****MI*PBM11356~
N3*29 FREMONT ST*ATP# 1~
DMG*D8*19430519*M~
DTP*291*D8*20091222~
EQ*30~
SE*17*0001~
GE*1*1~
IEA*1*000000001~
Segment
Value
Note
ISA
ISA
ISA
BHT
PW12345PBM
S00000000000001
PBM123
3920394930203
HL1:NM1
HL2:NM1
HL2:NM1
HL2:REF
HL3:NM1
EQ
PBM COMPANY
TIM JONSON
3334444
POCID
Tina James: PBM11356
30
The Password needed to correspond with the PBMs system.

Surescripts Participant ID.
The PBMs Participant ID.
response.
Name of the Source (PBM Name).
Name of the Physician.
Dr Jonson DEA number 3334444.
Participant ID for the Tech Vendor.
Tina James with PBM Unique ID PBM11356.
Health Plan Benefit Coverage.

PAGE 210
Eligibility
Eligibility Response (from PBM to Surescripts)

ISA*00*
*01*PWPBM12345*ZZ*PBM123
*ZZ*S00000000000001*091217*0345*^*00501*000000001*1*P*>~
GS*HB*PBM123*S00000000000001*20091217*16150000*1*X**005010X279~
ST*271*0001*005010X279~
BHT*0022*11*3920394930203*20091217*16150000~
HL*1**20*1~
HL*2*1*21*1~
NM1*1P*1*JONSON*TIM*T**M.D.*XX*3334444~
REF*EO*POCID~
HL*3*2*22*0~
NM1*IL*1*JAMES*TINA****MI* PBM11356~
REF*HJ* CARDHOLDERID~
REF*49*00~
N3*29 FREMONT ST*APT# 1~
DMG*D8*19480519*M~
INS*Y*18~
DTP*291*D8*20091222~
EB*1**30*MEDICA~
REF*18*PLANNUMBER~
REF*6P*GROUPNUMBER*GROUP NAME~
REF*ALS*ALTERNATIVEID~
REF*CLI*COVERAGE LIST ID~
REF*FO*FORMULARYID~
REF*IG*COPAYID~
REF*N6*BIN123*PCN123~
DTP*291*RD8*20091222~
EB*1**88~
EB*1**90~
SE*28*0001~
GE*1*1~
IEA*1*000000001~

PAGE 211
Eligibility
Segment
Value
Note
ISA
PWPBM12345
ISA
PBM123
ISA
S00000000000001
BHT
3920394930203

response.
HL1:NM1
PBM COMPANY
HL2:NM1
Tim Jonson : 3334444
Dr Jonson with DEA number 3334444.
HL2:REF
POCID
Participant ID for the Physician System.
HL3:NM1
HL3:REF
HJ
CardholderID
HL3:REF
49
00 Person Code.
EB 1:30
This patient has coverage.
HL3:REF
18
Plan Number
HL3:REF
6P
Group Number and Group Name
HL3:REF
ALS
Alternative List ID
HL3:REF
CLI
Coverage List ID
HL3:REF
FO
Formulary ID
HL3:REF
IG
Copay ID
HL3:REF
N6
Bin = BIN123: Processor Control Number = PCN123).
EB1:88
Eligible for Retail Pharmacy Benefits
EB1:90
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**005010X279~
The rest of this message is the same as the prior message Eligibility Response (from
PBM to Surescripts).
Segment
Value
Note
ISA
PW12345PHY
The Password needed to correspond with the Physician Systems

system.
ISA
S00000000000001
ISA
POCID
The Physician Systems Participant ID.

PAGE 212
Eligibility
Eligibility Response (Not Active)

ISA*00*
*ZZ*S00000000000001*091217*0345*^*00501*000000001*1*P*>~
GS*HB*PBM123*S00000000000001*20091217*16150000*1*X**005010X279~
ST*271*0001*005010X279~
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*19480519*M~
INS*Y*18~
DTP*291*D8*20091222~
EB*6**30*MEDICA~
SE*16*0001~
GE*1*1~
IEA*1*000000001~

PAGE 213
Eligibility
Eligibility Response (for Specialty and Long Term Care)

ISA*00*
*ZZ*S00000000000001*091217*0345*^*00501*000000001*1*P*>~
GS*HB*PBM123*S00000000000001*20091217*16150000*1*X**005010X279~
ST*271*0001*005010X279~
BHT*0022*11*3920394930203*20091217*16150000~
HL*1**20*1~
HL*2*1*21*1~
REF*EO*POCID~
HL*3*2*22*0~
REF*HJ* CARDHOLDERID~
REF*49*00~
DMG*D8*19480519*M~
INS*Y*18~
DTP*291*D8*20091222~
EB*1**30*MEDICA~
REF*18*PLANNUMBER~
REF*6P*GROUPNUMBER*GROUP NAME~
REF*ALS*ALTERNATIVEID~
REF*CLI*COVERAGE LIST ID~
REF*FO*FORMULARYID~
REF*IG*COPAYID~
REF*N6*BIN123*PCN123~
EB*1**88~
EB*1**90~
EB*1~
EB*1~
MSG*LTC~
SE*31*0001~

PAGE 214
Eligibility
GE*1*1~
IEA*1*000000001~

PAGE 215
Eligibility
Segment
Value
Note
ISA
PWPBM12345
ISA
PBM123
ISA
S00000000000001
BHT
3920394930203

response.
HL1:NM1
PBM COMPANY
HL2:NM1
Tim Jonson : 3334444
Dr Jonson with DEA number 3334444.
HL2:REF
POCID
Participant ID for the Physician System.
HL3:NM1
HL3:REF
HJ
CardholderID
HL3:REF
49
00 Person Code.
EB 1:30
This patient has coverage.
HL3:REF
18
Plan Number
HL3:REF
6P
Group Number and Group Name
HL3:REF
ALS
Alternative List ID
HL3:REF
CLI
Coverage List ID
HL3:REF
FO
Formulary ID
HL3:REF
IG
Copay ID
HL3:REF
N6
Bin = BIN123: Processor Control Number = PCN123).
EB1:88
Eligible for Retail Pharmacy Benefits
EB1:90
Eligible for Mail Order Pharmacy Benefits.
EB1
Eligible for benefit specified in the MSG segment.
MSG
SPECIALTY
PHARMACY
Eligible for Specialty Pharmacy Benefits.
EB1
Eligible for benefit specified in the MSG segment.
MSG
LTC
Eligible for Long Term Care Pharmacy Benefits.

PAGE 216
Eligibility
4.13 DIFFERENCES BETWEEN 4010 AND 5010

Following are some of the differences between 4010 and 5010 as it relates to the
ePrescribing implementation.
1. If patient submitted in dependent loop and its determined they are subscriber, on
the response they must be moved to subscriber loop by the PBM/Payer.
2. Additional information required on the 271 Response
a. TRN segment trace number if sent on request
b. REF*EJ patient account number if sent on request
c. 291 Plan Date must be returned
d. The information source is also required to return information supplied in
the 270 request that was used to determine the 271 response
3. When sending back 271s an additional service type code of 30 (Health Benefit
Plan Coverage) will be sent to indicate general coverage (active or inactive)
along with health plan name, plan begin date.
4. 271 Service codes 88 (Retail Pharmacy) and 90 (Mail Order Pharmacy) will
continue to be sent indicating active coverage (1) or not covered (I).
5. 270 and 271 lengths extended on some fields:
a. BHT-03 Reference code length changed from 30 to 50
b. NM1-03 Last Name/Org Name length changed from 35 to 60
c. NM1-04 First Name length changed from 25 to 35
d. REF-02, TRN-02, Reference Number length increased from 30 to 50,
requester /POC ID, trace number, formulary ID, etc.
6. 270 and 271 ISA-11 Changed from Interchange Control Standards ID to
Repetition Separator, ISA-12 changed to 00501
7. 270 and 271 GS-08 & ST-03 (new element) must be 005010X279
8. 270 and 271 NM1-08 Name Qualifier use MI member ID instead of ZZ
mutually defined for PBM unique member ID.
9. 271 Subscriber/Dependent REF Segment The cardholder name is no longer
supported in the REF segment. Instead the existing name in the 2100C/D should
be used. Most reference numbers moved from 2100C/D to 2110C/D benefit
loop. The following list has been moved to the 2110C/D loop:
a. Plan ID (18)
b. Plan Name (18) REF-03 moved to EB-05, Plan ID still in REF-02 (18)
c. Group Number (6P)
d. Alternative List ID (IF) REF-03 moved to REF-02 with new qualifier (ALS)
new length 50
e. Coverage List ID (1L) REF-03 moved to REF-02 with new qualifier (CLI)
new length 50
f. Formulary List ID (IF) new qualifier (FO)
g. Copay ID (IG) REF-03 moved to REF-02 new length 50
h. BIN/PCN (N6)
10. 271 Reference Numbers still in loop 2100C/D

PAGE 217
Eligibility
a. Cardholder ID (1W) changed qualifier from 1W to HJ

b. Person Code (49)
c. SSN (SY)
d. Patient Account Number (EJ)
11. New 271 AAA codes
a. Loop 2100A - 80 - No Response received - Transaction Terminated (in
4010, but not used by Surescripts)
b. Loop 2100C - 35 out of network code
c. Loop 2110 33 input errors
12. Obsolete 271 AAA codes Loop 2100C
a. 64 Invalid/Missing Patient ID
b. 65 Invalid/Missing Patient Name
c. 66 Invalid/Missing Patient Gender Code
d. 67 Patient Not Found
e. 68 Duplicate Patient ID Number
f. 77 Subscriber Found/Patient Not Found
13. 270 and 271 DTP Date of Service (472) has been replaced with Plan Date
(291). 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. Previously Surescripts populated this
date when sending the 270 on to the PBM.
14. 270 and 271 Subscriber City is mandatory N401 if the N4 segment is sent.
15. 270 and 271 Provider Specialty Quantifier PRV02 changed qualifier from ZZ
to PXC ( not used in 4010 ePrescribing)
16. 271 INS Segment INS09 Student Status Code and INS10 Handicap Indicator
were removed.
17. Information Source Name now required in Loop 2100A NM103 for both 270 and
271.
18. 270 Receiver Segment N4 State and Zip optional in 5010. Syntax note requiring
address is in the United States.
19. Dependent Name Segment in 271 5010 has ID code NM108 and qualifier
NM109 marked as not used.
20. For syntax errors in the 270 and 271 the 999 is returned instead of the 997.
21. 271 Loop 2120 increased from 1 repetition to 23. This is the loop used for mail
only benefit and primary/secondary payer designation.
22. 271 and 270 N404 - Country Code is not sent unless address is outside of United
States.
23. 270 2100B REF03 submitter participant name can no longer be sent in REF03.
24. 270 2100B NM103 receiver name now required.

PAGE 218
Eligibility
4.14 TRANSLATION
Some of the fields can be translated between versions while others will result in a
translation error. Following are a list of fields that will be translated.
1. AAA Error codes
Loop 2100C
4010
5010
64 Invalid/Missing Patient ID
65 Invalid/Missing Patient Name
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
Translation Error
66 Invalid/Missing Patient Gender

Code
67 Patient Not Found
68 Duplicate Patient ID Number
77 Subscriber Found/Patient Not
Found
2. Date qualifiers 472 Date of Service, 307 Eligibility, and 435 Admission will be
translated in 5010 to 291 Plan Date. When translated from 5010 to 4010 291 will
be translated to 472.
3. Reference Numbers will be moved to the appropriate loop and qualifiers changed
if necessary. REF segments in 4010 Loop 2100C/D will be moved in 5010 to
Loop 2110C/D in EB loop 30. When translating from 5010 to 4010 after the REF
segments are moved, the EB30 loop will be removed.
4. Service Codes 6 active (4010) and I not covered (5010) will be translated
between versions.
5. If no name is provided on Loop 2100A and 2100B in 4010, then UNKNOWN will
be mapped to 5010.
6. If no city name is provided in N401, the UNKNOWN will be mapped to 5010
7. If the dependant name segment in 4010 contains any ID code and qualifier
(NM108 and NM109, it will be rejected when translating to 5010 because 5010
does not support those elements at that level.
8. If the INS segment student status and handicap status are used it will be rejected
when translating to 5010.
9. When translating from 5010 to 4010, we will reject if field is too long. Fields that
have had the length increased in 5010 are listed in number 5 of the page above.

PAGE 219
SECTION 5
Eligibility Transaction Processing Summary
ELIGIBILITY TRANSACTION PROCESSING SUMMARY
Depending on the connectivity between participants, 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 transaction 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) transaction is a transaction where Surescripts is a defined participant 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:
Surescripts receives the 270 from the requesting party.
Surescripts processes the 270, identifying the coverage(s).
Surescripts passes the 270 on to the defined source. (If multiple coverages are found, multiple 270s are sent.)
The source processes the request(s) and returns a 271 response.
Surescripts combines the response(s) into one envelope.
Surescripts passes the response back to the original requester.

PAGE 220
5.1
SURESCRIPTS RECEIVES THE 270 FROM THE REQUESTING PARTY (TECH VENDOR)
Event
Id
Location
Event
Surescripts
Response
Error Description
Requestor Follow-Up
1.0
Connectivity Error
Cannot get response from Surescripts
None
None
Investigate and contact

Surescripts production support
1.1
Translation
Surescripts cannot identify the

transaction or does not have enough info
to create a TA1
NAK

1.2
Translation
TA1

1.3
Translation
Translator cannot identify the file (bad ISA

or IEA segments) but can produce a TA1
response
EDI Format has Fatal errors At any Level:
Data Segment
Data Element
Transaction Set
Functional Group
An Negative Acknowledgement (NAK)

with a message that says:
TRANSACTION CANNOT BE
IDENTIFIED NOR PROCESSED
Refer to X12 005010 Data Element
Dictionary for acceptable codes
999
Refer to the 999 spec for a complete list

of errors

5.2
SURESCRIPTS PROCESSES THE 270
Event
Id
Location
Event
Surescripts
Response
Error Description
Requestor Follow-up
2.0
Source Segment
Loop ID 2000A
Wrong platform participant ID and/or

password.
271
C Please correct and

resubmit
2.1
Source Segment
Loop ID 2000A
Responder system goes down at anytime

in the process (Surescripts).
271
2.2
Source Segment
Loop ID 2000A
Requester puts bad data in the source

segment. This should be Surescripts
participant ID.
271
2.3
Source Segment
Loop ID 2000A
Requester is not set up to send eligibility

transaction to Surescripts.
271
Loop ID 2000A
AAA Error 42 Unable to Respond a
current time
Loop ID 2000A
AAA Error 42 Unable to Respond a
current time
Loop ID 2000A
AAA Error 79
Invalid participant identification
Loop ID 2000A
AAA Error 41

P Please resubmit

resubmit
N Resubmission not allowed
PAGE 221
Event
Id
Location
Event
Surescripts
Response
Error Description
Requestor Follow-up
2.4
Source Name
Segment
Loop ID 2100A
271
Subscriber Segment Loop ID 2100C

AAA Error 75 - Subscriber/Insured Not
Found
2.5
Subscriber Name
Segment Loop ID
2100C
Subscriber Name
Segment Loop ID
2100C
Subscriber
Request Validation
Segment Loop ID
2110C
Requester does not have a contract set up

with the PBM that was determined through
patient lookup or the receiver is not
authorized to receive an eligibility request.
Surescripts cannot find the desired patient
271

AAA Error 75 - Subscriber/Insured Not
Found
Surescripts cannot find the desired

patient
One of the demographic fields is missing
271

AAA Error 75 Subscriber/Insured Not
Found. Hint is in MSG segment.

resubmit (Hint is sent
back))
Version translation fails for outgoing 270
271

resubmit
Surescripts cannot find the desired patient
271

AAA Error 15 - Required application
data missing
MSG Details of Error (check
w/development to see how this was
coded.)
Dependent Segment Loop ID 2100D
AAA Error 67 - Patient Not Found
Surescripts cannot find the desired

patient
One of the demographic fields is missing
271

AAA Error 67 - Patient Not Found

resubmit (Hint is sent
back)
Version translation fails for outgoing 270
271

AAA Error 15 - Required application
data missing
MSG Details of Error

resubmit
2.5a
2.5b
2.6
2.6a
2.7
Dependent Name
Segment Loop ID
2100D
Dependent Name
Segment Loop ID
2100D
Dependent
Request Validation
Segment Loop ID
2110D

PAGE 222
5.3
SURESCRIPTS ATTEMPTS TO CONNECT WITH SOURCE (PBM)
Event
Id
Location
Event
PBM
Response
PBM Error
Description
Surescripts
Follow up
Tech Vendor Error
Requestor Follow Up
3.0
Surescripts to
PBM Connector
Time Out PBM failed

to reply to Surescripts
in the specified time
None
None
Investigate and
create AAA
error for
requestor
P Please Resubmit
Original Transaction
3.1
PBM Internal
Some failure at PBM

where they cannot
produce a TA1 or 999
NAK
Text Error
Message
Investigate and
create AAA
error for
requestor
Source Segment
Loop 2100A
AAA Error 80
No Response received Transaction Terminated
New in 5010
Source Segment
Loop 2000A
AAA Error 42
Unable to respond at
current time
5.4
S Do not resubmit;
Inquiry initiated to a
third party.
PBM EVALUATES THE TRANSACTION
Event
Id
Location
Event
PBM
Response
PBM Error
Description
Surescripts
Follow up
Tech Vendor Error
Requestor Follow Up
4.0
Translation Initiation
Fatal Error with the

ISA, GS
TA1
Investigate and
create AAA
error for
requestor
Source Segment
Loop 2000A
AAA Error 42
current time
S Do not resubmit;
third party.
4.1
Translation Initiation
EDI Format has

Fatal errors At any Level:
Data Segment
Data Element
Transaction Set
Functional Group
999
Refer to X12
004010 Data
Element
Dictionary for
acceptable
codes
Refer to the 999
spec to
determine AK
level and
appropriate
error
Investigate and
create AAA
error for
requestor
Source Segment
Loop 2000A
AAA Error 42
current time
S Do not resubmit;
third party.

PAGE 223
5.5
PBM 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.
Even
t Id
Location
Event
PBM
Response
PBM Error
Description
PBM Follow
up
Surescripts
Follow up
Tech Vendor Error
Requestor
Follow Up
5.0
Source Segment
Loop ID 2100A
(Note:
Information
Source is the
PBM info that was
supplied by
Surescripts)
Any issue that caused

the process to halt
during processing
271
Source Segment
Loop 2100A
AAA Error 42
Unable to respond
at current time
None
Source Segment
Loop 2100A
AAA Error 42
current time
P Please
Resubmit
Original
Transaction
5.1
Source Segment
Loop ID 2100A
(Note:
Information
Source is the
PBM info that was
supplied by
Surescripts)
Source Name
Segment Loop ID
2100A (Note:
Information
Source is the
PBM info that was
supplied by
Surescripts)
PBM validates the

Source Identifier to
make sure its their own.
Surescripts puts in
wrong identifier
271
Source Segment
Loop 2100A
AAA Error 79
Invalid Participant
Identification
Investigate
and contact
Surescripts
production
support if
additional
information
or
clarification
is needed.
Investigate
and contact
Surescripts
production
support
Investigate and
translate to
AAA system
error for
requestor
Source Segment
Loop 2100A
AAA Error 79
Invalid Participant
Identification
S Do not
resubmit;
Inquiry
initiated to a
third party
PBM validates the

source contact
information. Surescripts
puts in wrong PBM
contact name, etc.
271
Source Segment
Loop 2100A
AAA Error 79
Invalid Participant
Identification
Investigate
and contact
Surescripts
production
support
Investigate and
translate to
AAA system
error for
requestor
Source Segment
Loop 2100A
AAA Error 79
Invalid Participant
Identification
S Do not
resubmit;
Inquiry
initiated to a
third party
5.2

PAGE 224
Even
t Id
Location
Event
PBM
Response
PBM Error
Description
PBM Follow
up
Surescripts
Follow up
Tech Vendor Error
Requestor
Follow Up
5.3
Receiver Segment
Loop ID 2100B
(This loop
contains the
physician info and
the Physician
System info)
PBM validates the

receiver. PBM wants
more fields populated
than what is required by
Surescripts; i.e. the
POC is not identified.
271
Receiver Segment
Loop ID 2100B
AAA Error 15
Required
application data
missing
None
None
Receiver Segment
Loop ID 2100B
AAA Error 15
Required application
data missing
5.4
Receiver Segment
Loop ID 2100B
(This loop
contains the
physician info and
the Physician
System info)
PBM validates receiver.

PBM cannot return
eligibility for this patient
because of the patients
group or plan.
271
Receiver Segment
Loop ID 2100B
AAA Error 41
Authorization/
Access
restrictions
None
None
Receiver Segment
Loop ID 2100B
AAA Error 41
Authorization/
Access restrictions
5.5
Receiver Name
Segment Loop ID
2100B
PBM validates the

physician Identifier
271
Receiver Name
Segment Loop ID
2100B
AAA Error 43
Invalid/Missing
Provider
Identification
None
None
Receiver Name
Segment Loop ID
2100B
Physician Loop
AAA Error 43
Invalid/Missing
Provider
Identification
C Please
correct and
resubmit
Surescripts
recommend
s this value,
however a
PBM/Payor
might send
a different
value
N
Resubmissi
on not
allowed
Surescripts
recommend
s this value,
however a
PBM/Payor
might send
a different
value
C Correct and
Resubmit
Surescripts
recommend
s this value,
however a
PBM/Payor
might send
a different
value

PAGE 225
Even
t Id
Location
Event
PBM
Response
PBM Error
Description
PBM Follow
up
Surescripts
Follow up
Tech Vendor Error
Requestor
Follow Up
5.8
Subscriber Name
Loop ID 2100C
271
AAA Error 75 Subscriber/Insure

d Not Found
None
None
AAA Error 75 Subscriber/Insured

Not Found
S Do not
resubmit;
Inquiry
initiated to a
third party
5.11
Dependant Name
Loop ID 2100D
Patient found at
Surescripts, but not in
the PBMs system
(could be caused by a
difference between
Surescripts and the
PBMs patient
databases or caused by
the patient demographic
mismatch between
requestor and PBM).
Patient found at
Surescripts, but not in
the PBMs system
(could be caused by a
difference between
Surescripts and the
PBMs patient
databases or caused by
the patient demographic
mismatch between
requestor and PBM).
271
Dependant Name
Segment Loop ID
2100D AAA
Error 67 Patient
not found
None
None
Dependant Name
Segment Loop ID
2100D AAA Error
67 Patient not
found
S Do not
resubmit;
Inquiry
initiated to a
third party

PAGE 226
5.6
PBM SENDS 271 BACK TO SURESCRIPTS

Surescripts evaluates the transaction.
Event
Id
Location
Event
Surescripts
Response
Surescripts
Error
Description
PBM Follow up
Surescripts
Follow up
Tech Vendor Error
Requestor
Follow Up
6.0
Translation of 271
from PBM
Fatal Error with ISA

or GS segments
TA1
Investigate and
contact
Surescripts
production
support
Investigate
and translate
to AAA system
error for
requestor
Source Segment
Loop 2100A
AAA Error 42
current time
S - Do not
resubmit;
Inquiry
initiated to a
third party
6.1
Translation of 271
from PBM
999
Investigate and
contact
Surescripts
production
support
Investigate
and translate
to AAA system
error for
requestor
Source Segment
Loop 2100A
AAA Error 42
current time
S - Do not
resubmit;
Inquiry
initiated to a
third party
6.2
Any Level in the

271
EDI Format has Fatal

errors At any Level:
Data Segment
Data Element
Transaction Set
Functional Group
Error in translating
between 4010/5010
Refer to
NCPDP Data
Element
Dictionary for
acceptable
codes
Refer to the 999
spec to
determine AK
level and
appropriate
error
Cannot
Translate to
Version
Investigate and
contact
Surescripts
production
support
Investigate
and translate
to AAA system
error for
requestor
Loop 2000A
AAA Error 42
current time
N
Resubmission
Not Allowed
5.7
Log Error
SUMMARY OF ERRORS SENT TO TECH VENDOR

The following is a summary of some of the errors a Tech Vendor can expect to see.
Error
Description
Source Segment
Loop 2000A
AAA Error 42
Generic error message for all errors that occurred that were
not caused by the Physician System.

PAGE 227
5.8
Error
Description
Receiver Segment
Loop ID- 2100B
AAA Error 15
If the Tech Vendor fails to give enough information in the

transaction to identify themselves or the physician to the
PBM.
Source Segment
Loop ID- 2000A
AAA Error 41
The sending participant is not set up to send an eligibility

transaction.
Subscriber Name
Segment Loop ID 2100C
AAA Error 75
Surescripts determines that there is no contract between the

Tech Vendor and the PBM. Coordinate with event ID 2.4
above.
Receiver Segment
Loop ID- 2100B
AAA Error 41
If the PBM determines that they cannot return information for

this patient based off of the plan or group.
Receiver Segment
Loop ID- 2100B
AAA Error 43
If the PBM requires a DEA or state license number for the

prescribing office but the Tech Vendor does not provide it.
Subscriber Name
Segment Loop ID 2100C
AAA Error 75
Surescripts cannot find the patient in the MPI.
Dependant Name
Segment Loop ID 2100D
AAA Error 67
Surescripts cannot find the dependant patient in the MPI.
SUMMARY OF TRANSLATED ERRORS

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

PAGE 228

PAGE 229
ID Load
ID LOAD
SECTION 6
6.1
INTRODUCTION
PBMs use the ID Load transaction to provide Surescripts with their member roster to
populate the Surescripts Master Patient Index (MPI). Surescripts uses these files
from the PBMs to establish uniqueness for individuals across PBMs. Surescripts
search process uses demographics to identify a patient and then uses the PBMs
unique member ID to communicate with the PBMs.
6.2
ID LOAD PROCESS FLOW

The following steps depict the flow of the ID load:
1. The PBM creates a directory of patients, assigning each occurrence a unique
member ID.
2. The PBM submits the initial load to Surescripts.
3. Surescripts populates the MPI internal directory.
4. The PBM creates a nightly update file utilizing the same format to keep
Surescripts 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.
5. Surescripts processes the updates.
6. Surescripts sends a response to the PBM indicating the process success and
failure details.
6.3
FORMAT TO BE USED
Surescripts has implemented a custom specification that contains demographic and
PBM specific information. There are two formats supported; one is a flat fixed width
file. The other is a delimited filed format. Use the same character set as referenced
in Section 4.4.3.2 except for the ^ character decimal 94 which cannot be used in
the ID Load Process.
6.4
MEMBER DIRECTORY MAINTENANCE FLAT FILE FROM PBM

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 Identifier
Identifies the Header

Section - Value = 1
N 1/1
Yes
Participant ID
ID as assigned by
Surescripts identifying the
PBM
AN 3/30
31
Yes

PAGE 230
ID Load
Field
Description
Type
Start
End
Required
Participant Password
Password for this

participant as assigned by
Surescripts
AN 10/10
32
41
Yes
Transaction Number
Unique identifier defined by

the sender
AN 1/10
42
51
Yes
Transaction Date
Date File was created (D8 CCYYMMDD)
DT 8/8
52
59
Yes
Transaction Time
Time File was created

(HHMMSSDD) where H =
hours (00-23), M = minutes
(00-59), S = integer
seconds (00-59) and DD =
decimal seconds (00-99)
TM 8/8
60
67
Yes
Usage Indicator
Test or Production (T/P)
ID 1/1
68
68
Yes
Version Number
Version of Member
Directory File Format (1.0)
AN 1/5
69
73
No
Filler
Filler field to extend row
AN 723
74
796
Yes
Detail Info
Field
Description
Type
Start
End
Required
Section Identifier
Identifies the Detail

Section - Value = 2
N 1/1
Yes
Record Sequence
Number
Number for this detail

row in the transaction
AN 1/10
11
Yes
Number that will be

utilized in the
response document.
PBM Unique
Member ID
Unique ID as
identified by the PBM
for the member
AN 1/60
12
71
Yes
Unique identification
number for this
member.
PBM Unique ID for

Subscriber
Unique ID as
identified by the PBM
for the subscriber of
the member
AN 1/60
72
131
No
Health Plan Member

Number
Health Plan Unique

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

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

group number
AN 1/30
192
221
No
Member Expiration
Date
Date that the member

is no longer eligible
(D8)
DT 8/8
222
229
No

Notes
If multiple dates are

available (i.e. Term
Date, Expired Date,
End Date), use the
earliest date of the
PAGE 231
ID Load
Field
Description
Type
Start
End
Required
Last Name
Last Name of the

Member
AN 1/35
230
264
Yes
First Name
First Name of the

Member
AN 1/25
265
289
Yes
Middle Name
Middle Name of the

Member
AN 1/25
290
314
No
Prefix
Member Prefix
AN 1/10
315
324
No
Suffix
Member Suffix
AN 1/10
325
334
No
Social Security
Number
Member SSN - No
dashes
N 9/9
335
343
No
Address Line 1
First Line of the

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

Address (No C/O type
info)
AN 1/55
399
453
No
City Name
Member City Name
AN 2/30
454
483
No
State or Province
Code
Member State Code
AN 2/2
484
485
No
Postal Code
Member zip code
AN 3/15
486
500
No
Country Code
Member Country
Code
AN 2/3
501
503
No
Comm Number 1
Type
1st Comm. Number

Type
AN 2/2
504
505
No
Communication
Number 1
1st Communication
Number
AN 1/80
506
585
No
Communication
Number 2 Type
2nd Communication
Number Type
AN 2/2
586
587
No
Communication
Number 2
2nd Communication
Number
AN 1/80
588
667
No

Notes
three.
EM = Email
EX = Telephone
Extension
FX = Facsimile
HP = Home Phone
TE = Telephone
WP = Work Phone
EM = Email
EX = Telephone
Extension
FX = Facsimile
HP = Home Phone
TE = Telephone
WP = Work Phone
PAGE 232
ID Load
Field
Description
Type
Start
End
Required
Notes
Communication
Number 3 Type
3rd Communication
Number Type
AN 2/2
668
669
No
EM = Email
EX = Telephone
Extension
FX = Facsimile
HP = Home Phone
TE = Telephone
WP = Work Phone
Communication
Number 3
3rd Communication
Number
AN 1/80
670
749
No
Date of Birth
Member DOB
(CCYYMMDD)
DT 8/8
750
757
No
Gender
Member Gender
(M,F,U, Blank)
AN 1/1
758
758
No
Employer Name
Employer Name
AN 1/35
759
793
No
Transaction Type
Type of Action
needed
AN 3/3
794
796
Yes
If gender not given,

a blank space will be
used.
001 - Change
021 - Addition
024 - Cancellation or
Termination
025 - Reinstatement
030 - Audit or
Compare
Trailer Info
Field
Description
Type
Start
End
Required
Section Identifier
Value = 3 (End of File)
N 1/1
Yes
Total Records
Total Records Processed
N 1/10
11
Yes
Filler
Filler Field to extend row
AN 785
12
796
Yes
6.5
MEMBER DIRECTORY RESPONSE FLAT FILE TO PBM
Header Info
Field
Description
Type
Start
End
Section Identifier
Identifies the Header Section Value = 1
N 1/1
Participant ID
ID as assigned by Surescripts
identifying the PBM
AN 3/30
31
Sender ID
ID of Surescripts
An 3/30
32
61
Transaction Number
Unique identifier that was assigned

to the incoming transaction
AN 1/10
62
71
Incoming Transaction
Date
Date Original Incoming File was

created (D8 - CCYYMMDD)
DT 8/8
72
79
Incoming Transaction
Time
Time Original Incoming File was

created (HHMMSSDD)
TM 8/8
80
87
Transaction Date
Date Response was created (D8 CCYYMMDD)
DT 8/8
88
95

Notes
Participant ID of
Original File
Sender
PAGE 233
ID Load
Field
Description
Type
Start
End
Transaction Time
Time Response was created

(HHMMSSDD)
TM 8/8
96
103
Transaction
Response
Code Explaining the status of the

load
AN 2/2
104
105
Records Loaded
Number of total records loaded
N 1/10
106
115
Records Failed
Number of total records Failed
N 1/10
116
125
Notes
01-17 See Table

Below
Detail Info
Field
Description
Type
Start
End
Section Identifier
Identifies the Detail Section Value = 2
N 1/1
Record Sequence
Number
Number that identified the row

in the incoming transaction
AN 1/10
11
PBM Unique ID for

the member
Unique ID as identified by the

PBM for the member
AN 1/60
12
71
Error Code
Describes error for this row

W - Signifies a Warning
E - Signifies a Error
AN 3/3
72
74
Filler
Filler Field to extend row
AN 51
75
125
Field
Description
Type
Start
End
Section Identifier
Value = 3 (End of File
N 1/1
Filler
Fill to make the row 125
AN 124
125
Notes
See Table Below
Trailer Info

Notes
PAGE 234
6.6
ID Load
MEMBER DIRECTORY MAINTENANCE DELIMITED FILE FROM PBM
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
Record Type
AN 3/3
Yes
Identifies record
type
Value = HDR
Version/Release
Number
AN 1/2
Yes
Version Number
of this
specification
2.1
Sender ID
AN 3/30
Yes
ID as assigned
by Surescripts
identifying
Participant
sending the file.
P11111111111111
Sender Participant
Password
AN 10/10
Yes
Password for
this Participant
identified in field
3 (Sender ID).
ABCDE12345
Receiver ID
AN 1/30
Yes
ID identifying
the receiver of
the file.
RXHUB
Source Name
AN 1/35
Not Used
Future use
Transmission
Control Number
AN 1/10
Yes
Unique identifier
defined by the
sender
0000001000
Transmission
Date
DT 8/8
Yes
Date
transaction was
created (D8 CCYYMMDD)
20060701
Transmission
Time
TM 8/8
Yes
Time
transaction was
created
(HHMMSSDD)
12200101
10
Transmission File
Type
AN 1/3
Yes
Identifier telling
the type of
transaction
MPI=ID load
MPI
11
Transmission
Action
AN 1/1
No
U=Update
F=Full file
If blank, default
to U=Update
12
Extract Date
DT 8/8
Yes
Date File was

created (D8 CCYYMMDD)
20060630
13
File Type
AN 1/1
Yes
Test or
Production T=Test,
P=Production

PAGE 235
ID Load
Detail Info
Field #
Field Name
Type
Required
Comments
Record Type
AN 3/3
Yes
Identifies record
type
Record Sequence
Number
AN 1/10
Yes
Number for this

detail row in the
transaction
PBM Unique
Member ID
AN 1/60
Yes
Unique ID as
identified by the
PBM for the
member
PBM Unique ID
for Subscriber
AN 1/60
No
Unique ID as
identified by the
PBM for the
subscriber of the
member
Health Plan
Member Number
AN 1/30
No
Health Plan
Unique Member
identification
number
Number on the
Health Plan card
identifying the
patient (Either a
subscriber or a
dependant)
Health Plan
Subscriber
Number
AN 1/30
No
Health Plan
Unique
Subscriber
identification
number - Number
on the Health
Plan card
identifying the
subscriber
Policy Number
AN 1/30
No
Health Plan policy

or group number
Member
Expiration Date
DT 8/8
No
Date that the

member is no
longer eligible
(D8)
Last Name
AN 1/35
Yes
Last Name of the

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

Member
11
Middle Name
AN 1/25
No
Middle Name of
the Member
12
Prefix
AN 1/10
No
Member Prefix
13
Suffix
AN 1/10
No
Member Suffix

Example
Value = MEM
If multiple dates are

available (i.e. Term
Date, Expired Date,
End Date), use the
earliest date of the
three.
PAGE 236
Field #
ID Load
Field Name
Type
Required
Comments
14
Social Security
Number
N 9/9
No
Member SSN No dashes
15
Address Line 1
AN 1/55
No
First Line of the

Address (No C/O
type info)
16
Address Line 2
AN 1/55
No
Second Line of
the Address (No
C/O type info)
17
City Name
AN 2/30
No
Member City
Name
18
State or Province
Code
AN 2/2
No
Member State
Code
19
Postal Code
AN 3/15
Can repeat
up to five
times.
No
Member zip code

5 or 9 numeric no
punctuation.
Use the tilde
character (~) to
send multiple zip
codes.
20
Country Code
AN 2/3
No
Member Country
Code
21
Comm Number 1
Type
AN 2/2
No
1st Comm.
Number Type
Example
55123~55102
EM = Email
EX = Telephone
Extension
FX = Facsimile
HP = Home Phone
TE = Telephone
WP = Work Phone
22
Communication
Number 1
AN 1/80
No
1st
Communication
Number
23
Communication
Number 2 Type
AN 2/2
No
2nd
Communication
Number Type
EM = Email
EX = Telephone
Extension
FX = Facsimile
HP = Home Phone
TE = Telephone
WP = Work Phone
24
Communication
Number 2
AN 1/80
No
2nd
Communication
Number

PAGE 237
Field #
25
ID Load
Field Name
Type
Required
Comments
Example
Communication
Number 3 Type
AN 2/2
No
3rd
Communication
Number Type
EM = Email
EX = Telephone
Extension
FX = Facsimile
HP = Home Phone
TE = Telephone
WP = Work Phone
26
Communication
Number 3
AN 1/80
No
3rd
Communication
Number
27
Date of Birth
DT 8/8
No
Member DOB
(CCYYMMDD)
28
Gender
AN 1/1
No
Member Gender
(M,F,U, blank)
29
Employer Name
AN 1/35
No
Employer Name
30
Transaction Type
AN 3/3
Yes
Type of Action
needed
001 - Change
021 - Addition
024 - Cancellation or
Termination
025 - Reinstatement
030 - Audit or
Compare
Field Name
Type
Required
Comments
Example
Record Type
AN 3/3
Yes
Identifies record
type
Value = TRL
2 Total Records
N 1/10
Yes
Total Records
Processed
If gender not given,

a blank space will be
used.
Trailer Info
Field #
6.7
MEMBER DIRECTORY RESPONSE DELIMITED FILE TO PBM
Header
Field
Description
Type
Record Type
Identifies record type
AN 3/3
Yes
Value = SHD
Version/Release
Number
Version Number of this

specification
AN 1/2
Yes
2.0
Sender ID
identifying Surescripts
AN 3/30
Yes
Recipient ID
ID assigned by Surescripts for

the recipient of the response
file (original sender of the ID
load file)
AN 3/30
Yes
Required

Notes
PAGE 238
ID Load
Field
Description
Type
Required
Notes
Recipient Participant
Password
Password assigned by
Surescripts for accessing the
payer/PBM system.
AN 10/10
Yes
Transaction Control
Number

the sender
AN 1/10
Yes
Transaction Date
Date transaction was created
DT 8/8
Yes
Transaction Time
Time transaction was created
TM 8/8
Yes
HHMMSSDD
Transaction File Type
Identifier telling receiver the

type of file.
AN 1/3
Yes
MPR
Transaction Number Originating
Number of the original report

transaction
AN 1/10
Yes
Transaction DateOriginating
Date Original Incoming File

was created (D8)
DT 8/8
Yes
CCYYMMDD
Transaction TimeOriginating
Time Original Incoming File

was created
TM 8/8
Yes
HHMMSSDD
File Type
AN 1/1
Yes
T=Test
P=Production
Load Status
Code Explaining the status of

the load.
AN 2/2
Yes
See chart
CCYYMMDD
Detail Info
Field
Description
Type
Required
Notes
Record Type
Identifies record type
N 1/1
Value=SDT
Record Sequence
Number
Number that identified the row

in the incoming transaction
AN 1/10
11
PBM Unique ID for the

member
Unique ID as identified by the

PBM for the member
AN 1/60
71
Error Code
Describes error for this row

W - Signifies a Warning
E - Signifies a Error
AN 3/3
74
Field
Description
Type
Required
Notes
Record Type
Identifies record type.
AN 3/3
Yes
Value = STR
N 1/10
Yes
See table
Trailer Info
Total Rows in Error
6.8
MEMBER DIRECTORY CODES

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)

PAGE 239
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 existFile not loaded
17
Invalid header version numberFile not loaded (Not Used)
ID Load
Detail Error Codes

Code
Description
E01
Missing PBM Unique 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.
A00
Audit Compare, record not loaded. This is used when the file header
transaction type is set to 030 Audit or Compare.

PAGE 240
ID Load

PAGE 241
SECTION 7
7.1
FORMULARY AND BENEFIT DATA LOAD
INTRODUCTION
During the prescribing process, technology vendor systems typically use the
information retrieved through the Formulary and Benefit Data Load service to inform
prescribers of the following:
Drugs that the patients benefit plan considers to be on formulary

(Formulary Status), and alternative medications for those which are not
preferred (Alternatives);
Limitations that may impact whether the patients benefit will cover a drug
being considered (Coverage);
The copay for one drug option versus another.
This section provides an overview of the information that can be communicated

using the Formulary and Benefit Data Load service.

PAGE 242
7.2
FORMULARY AND BENEFIT SUMMARY INFORMATION MODEL

Patient
Patient "keys" obtained through CrossReference lookup or Eligibility
Response:
Product Name - Health Plan
Formulary ID
Alternatives ID
Coverage ID
Copay ID
Classification ID
ID
Alt
ern
ati
v
es
ID
Formulary Status List

Keys:
Product Name - Health
Plan
Formulary ID
Drug identifier(s)
Alternatives List
ve
Co
ge
ra
ID
D
ay I
Cop
Classif
ication
Formulary ID
Keys:
Plan
Alternatives ID
Source drug identifier(s)
Alternative drug
identifier(s)
Preference Level
Classification List
Keys:
Plan
Classification ID
Drug identifier(s)
Coverage List
multiple sub-types
Copay List
sub-types:
Summary-Level
Drug-Specific
Keys:
Plan
Copay ID
Pharmacy Type
Drug-Specific Copay List
only:
Drug identifier(s)
Keys:
Plan
Coverage ID
Drug identifier(s)
Additional keys based on
sub-type
Text Message
Product Exclusion
Prior Authorization
Medical Necessity
Coverage
Sub-Types
Summary-Level Copay List

only:
Product Type
Step Medication
Quantity Limit
Age Limit
Gender Limit
Resource Link
Note: "Drug ID" represents several supported drug identifiers
sub-types:
Summary-Level
Drug-Specific

PAGE 243
7.3
FORMULARY AND BENEFIT DATA OVERVIEW

Formulary and Benefit data can consist of the following types: Formulary Status,
Payer-specified Alternatives, Coverage Information, Copay Information, and Drug
Classifications. A Cross-Reference list may also be used to tie the different types of
information to a particular benefit plan or group.
7.3.1
FORMULARY STATUS
Pharmacy benefit payers use the drug formulary as a way to promote high-quality
medical care that is affordable for patients. A drug formulary is a list of prescription
drugs; each one assigned a formulary status, which is a rating of that drugs
effectiveness and value. Payers periodically publish revisions to their drug
formularies, in order to represent the current clinical judgment of the payer and its
affiliated care providers.
Payers determine a drugs 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 (e.g. on-formulary or preferred).
If a therapeutic class contains multiple drugs, those with higher formulary statuses
are referred to as preferred alternatives to those with lower ratings. Drugs
deemed to have lesser effectiveness and/or value are called off-formulary. Payers
encourage doctors to prescribe drugs with on-formulary or preferred formulary
status in order to lower benefit costs and reduce the patients out-of-pocket
expense.
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 ghigher
status are more preferable.
Formulary Status
1 = Non-Formulary
2 = On Formulary
3 99 = On FormularyPreferred (higher number means more
preferred)
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 the payer does not know a status for a drug but it is listed within the file, the
receiver should interpret this as an unknown status for this drug and not use the
formulary status defaults in the header.
U = Unknown Status
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

PAGE 244
Brand Formulary Status, Non-Listed Prescription Generic Formulary Status, NonListed Brand Over-The-Counter Formulary Status, etc.).
It is possible for drugs within the same therapeutic class to have the same
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.
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, technology vendor systems can identify preferred alternatives by
comparing the status of drugs within a therapeutic class.
In addition, payers can explicitly state alternatives for specific drugs. These payerspecified alternatives are communicated in Alternatives lists, which contain the
following information:
Source drug: the off-formulary drug

Alternative drug: the preferred alternative
Alternative drug Preference Level: if there are multiple preferred alternatives,
the payers order of preference (higher number equals greater preference)
When payer-specified alternatives are available, technology vendor systems should

present them in the order indicated by the alternative drug preference level. The
technology vendor may present additional alternatives (chosen from therapeutic
equivalents), after those directed by the payer.
7.3.3
COVERAGE INFORMATION
Coverage information qualifies the conditions under which the patients 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
technology vendor systems using the file load:
Prior authorization requirements

Step therapy requirements
Step medications
Age limits
Gender limits
Quantity limits
Drug coverage exclusions
Medical necessity
The file load also enables payers to specify a single coverage-related text message
for each drug, and links to additional information available on the payers web site.

PAGE 245
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.
Payers can communicate the following copay terms to technology vendor systems
using the file load:
Flat copay (dollar amount)

Percentage copay
Combination flat / percentage
Copay tier (tier of given drug versus the number of tiers)
Minimum and maximum copay
Days supply per stated copay
Copay differences by type of pharmacy
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
drugs Formulary Status and its type (Branded or Generic). 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 state drug-level copays.
These copays apply to specific drugs, as identified with a representative 11-digit
NDC ID
7.3.5
DRUG CLASSIFICATION INFORMATION

The Drug Classification list enables payers to define drug groupings that their
benefit rules reference. For instance, a step therapy program may direct that a
medication in a specific drug class be tried prior to the requested drug.
In addition, by providing classifications for its formulary medications, the payer can
assist the technology vendor in identifying formulary alternatives - similar
medications that have a better formulary status.
The payer may associate a single Drug Classification list with a given membership
group (through the Cross-Reference) or member (via a real-time Eligibility
transaction).
Using the Drug Classification list, payers can provide the following information for a
medication:
Class ID
Class Name

PAGE 246
7.3.6
Subclass ID
Subclass Name
CROSS-REFERENCE INFORMATION
The Cross-Reference list enables payers to tie the different types of formulary and
benefits information to a particular benefit plan or group. A technology vendor uses
this list as a sort of index to locate the various lists that combine to form a
membership groups full benefits picture.
For instance, Membership Group As benefit is composed of the following pieces:
Formulary 101
Alternatives list 20
Coverage list A
Copay list A
Drug Classification 1
Using the Cross-Reference list, payers can associate the following data keys to a
membership group:
Formulary ID
Alternatives ID
Coverage List ID
Copay List ID
Classification ID
Note: An alternative to providing group-level cross-references using this list is for

the payer to provide patient-level keys (Formulary ID, Coverage ID, etc.) via a
real-time Eligibility transaction.
7.4
11-DIGIT REPRESENTATIVE NDC

In order to reduce the size of the files, it is possible to use an 11-digit representative
NDC to define a drug category. 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 maximize the opportunity that the selected NDC exists
among the various drug files, do not send repackaged NDCs, obsolete NDCs,
private label NDCs or unit dose NDCs as a representative NDC.
The RxNorm coding system, under development by the National Library of Medicine,
would be another means for similarly identifying multiple packaged products with the
same drug ingredient(s), dose(s) and dose form(s). Once finalized and adopted by
the industry, RxNorm could serve this purpose as well.

PAGE 247
7.5
HIGH-LEVEL PROCESSING EXAMPLES

The following examples show processing flows for:
7.5.1
Presenting Formulary and Coverage Information

Presenting Medication Copay
Presenting Formulary Alternatives
FLOW ONE: PRESENTING FORMULARY & COVERAGE INFORMATION

For each medication presented to the prescriber:
1. Note the medications NDC (drug ID hereafter).
2. Determine the patients Formulary ID and Coverage ID (using the Cross
Reference List or Eligibility transaction).
3. Determine the medications 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 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):
o Non-listed Prescription Brand Formulary Status
o Non-Listed Prescription Generic Formulary Status
o Non-Listed Brand Over The Counter Formulary Status
o Non-Listed Generic Over The Counter Formulary Status
o Non-Listed Supplies Formulary Status
4. Present coverage information:
a. Search the various coverage lists for this Drug ID and Coverage ID.
i. Display each coverage rule found.
ii. Reference the Drug Classification list if a drug Class ID or
Subclass ID is cited as a step medication (Coverage Information
Detail - Step Medications list).
7.5.2
FLOW TWO: PRESENTING MEDICATION COPAY

For each medication presented to the prescriber:
1. Note the medications NDC (drug ID hereafter).
2. Determine the patients Formulary ID and Copay ID (using the Cross-Reference
List or Eligibility transaction).
3. 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 retail pick-up and mail-order delivery copay terms and stop.

PAGE 248
4. If no drug-specific copay is found for this medication, look up the copay based on
the drugs characteristics.
a. Determine the medications formulary status: See step 3 in the previous
example, Flow One: Presenting Formulary and Coverage Information.
b. If the previous step results in a formulary status of Not Reimbursable, the
patient has full responsibility for its cost.
o Skip the remaining step. (Do NOT display copay information.
c. Search the Benefit Copay List / Copay Information Detail - Summary Level
for the record that matches this medications characteristics (below) and
present the copay terms for each type of pharmacy specified by the payer:
o Formulary Status
o Product Type (single source brand, branded generic, generic,
over-the-counter, compound, supply)
7.5.3
FLOW THREE: PRESENTING FORMULARY ALTERNATIVES

To present preferred alternatives for off-formulary medications, use the following
methods.
Method One: Use payer-specified formulary alternatives
1. Note the off-formulary medications NDC identifier (drug ID hereafter).
2. Using the Cross Reference List or Eligibility transaction, determine the patients
Alternatives ID.
3. Search the corresponding Formulary Alternatives Lists source drug field for the
off-formulary medications drug ID.
Note that this search may yield multiple record matches, indicating there
are multiple preferred alternatives for the off-formulary drug.
Present the matched alternative medications NDC Alternative fields), in
the order indicated by the Preference Level field (higher-numbered
medications are more preferred).
Method Two: Use a third-party drug classification system to determine
alternatives
1. Note the off-formulary medications NDC (drug ID hereafter).
2. Using the Cross Reference List or Eligibility transaction, determine the patients
Classification ID.
3. Search the corresponding Drug Classification List for the medications drug ID.
4. Note the Class ID and Subclass ID associated with this medication.
5. Search the Drug Classification List again for medications with the same Class ID
/ Subclass ID combination. Within those, reference the patients Formulary Status
List to identify preferred alternatives.
Method Three: Use a third-party drug classification system to determine
alternatives
1. Note the off-formulary medications NDC (drug ID hereafter).
2. Reference a third-party drug classification scheme to locate on-formulary
medications within the same drug class. Within those, reference the patients
Formulary Status List to identify preferred alternatives.

PAGE 249
7.6
FORMULARY AND BENEFIT DATA LOAD ROLES

Surescripts, Formulary Publishers (pharmacy benefit payers, such as PBMs and
health plans), and Formulary Retrievers (Technology 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:
Load and maintain updated formulary information (formulary drugs,

status, and alternatives) at Surescripts.
Maintain a formulary distribution list at Surescripts that indicates which
Technology 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 patients formulary,
view coverage/copay limitations, and consider alternative medications.
Surescripts
Surescripts role in the Formulary and Benefit Data Load process is to:
7.7
Facilitate the distribution of formulary and benefit lists between the

Formulary Publishers and Retrievers.
Document and communicate the Formulary and Benefit Data load
specification, process, and usage guidelines.
Validate the formulary and benefit files against the current Surescripts
specification.
Certify the Technology Vendors retrieval of the formulary and benefit
lists.
FORMULARY AND BENEFIT DATA LOAD PROCESS

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

PAGE 250
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 participants 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. Based on participant-to-participant contract relationships and the permissions
granted by the Formulary Publisher on the Distribution List, Surescripts makes
the appropriate subset of formulary status and alternatives lists available on the
WebDAV server for Formulary Retrievers to download.

PAGE 251
Formulary and Benefit Data Integration and Presentation to Prescribers
1. The Formulary Retriever checks the WebDAV server on a scheduled basis to

determine if there are new or updated formulary and benefit lists available.
2. The Retriever downloads the formulary and benefit lists to their system and
makes them available to prescribers via their point-of-care (POC) application.
3. During or before a patients office visit, a prescriber sends an Eligibility Request
(270) to verify the patients 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(s) for processing. Refer to the Eligibility section for more information on this
process flow.
4. The patients Formulary ID, Alternatives ID, Coverage ID, and Copay ID are
contained within the Eligibility response (271) sent back from the PBM(s). The
POC application links these IDs from the patients Eligibility response with the
corresponding lists.
5. 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 patients formulary and covered under the patients plan. If not, the prescriber
can view preferred alternative drugs within that medications therapeutic class
7.8
FORMULARY AND BENEFIT PUBLISHING

The following sections described how Formulary Publishers develop, set up, and
load their formulary and benefit files for processing at Surescripts.
7.8.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

PAGE 252
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, the
Surescripts system checks each section of the file to validate that the data is
formatted correctly. If the data does not contain any errors, the file is loaded into
the Surescripts database as separate formulary and benefit lists for distribution. 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. However, if any of the data contains errors or
cannot be validated, that formulary and benefit list is not loaded, and an error is
sent to the Formulary Publisher within the Response File.
When a Formulary Publisher would like to notify its partners of the discontinuation
of a list, they send an action code of (D)elete 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. Any formulary and benefit list
previously loaded in the database for that Publisher that is not included in the new
file is deleted. In this process, all file sections and data need to be error-free in
order to load the file. If there is any error at all found during the validation process,
no data in the file is loaded, the entire file is aborted, and an error is sent to the
Formulary Publisher within the Response File. Once the error is corrected, the
entire file must be resent and reprocessed. Note: full replace option should only be
used when all list types can be sent to Surescripts in one physical file.
7.8.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 implementation process with Surescripts. For more
information, refer to the Appendix B: Secure File Transfer.
7.8.3
FORMULARY AND BENEFIT FILE NAMING AND STRUCTURE

The Formulary Publishers 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.

PAGE 253
7.8.3.1 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 Participants ID; therefore, if two Formulary Publishers use the
same file name, the Participant ID is what distinguishes them within the system.
List Type
Key Field (with Participant ID)
Formulary ID
Alternative List
Alternative ID
Coverage List
Coverage ID
Copay List
Copay ID
Cross Reference List
N/A
Drug Classification List
Classification ID
Each list is available to Formulary Retrievers on the WebDAV server in a directory

respective to the lists type. The file name contains the date the list was extracted
from the Publishers system. The date the list was made available through
Surescripts is displayed as a date modified property. For coverage and copay lists
the first two characters of the file name are the type of coverage list.
File Name Structure
Example

/FSL/Formulary id_effective date_extract date
/FSL/123451_20050301_20050318
Alternative File List

/ALT/Alternative id_effective date_extract date
/ALT/214312_20050301_20050318
Cross Reference List

/CRF/_effective date_extract date
/CRF/20050301_20050318
Coverage List
/COV/List id_effective date_extract date
/COV/ALFFT_20050301_20050318
Copay List
/COP/List id_effective date_extract date
/COP/SLCDE_20050301_20050318

/DCL/Class id_effective date_extract date
/DCL/123DD_20050301_20050318

PAGE 254
7.8.3.2 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 Participant names:
ABC - ABC Corporation (Health Plan)

BMI - Benefit Management, Inc. (PBM)
Note: This structure assumes that the Formulary Retriever has access to files from
the following Formulary Publishers: ABC Corporation, and Benefit Management,
Inc..
Name
Size
Type
Modified
HEALTHA_20050301_20050318
30KB
File
3/12/2005
HEALTHB_20050301_20050318
24KB
File
3/12/2005
HEALTHC_20050301_20050318
100KB
File
3/12/2005
HEALTHA_20050301_20050317
630KB
File
3/12/2005
HEALTHB_20050301_20050317
362KB
File
3/12/2005
HEALTHC_20050301_20050317
424KB
File
3/12/2005
DSABCD_20050301_20050317
2230KB
File
3/12/2005
DSDFFG_220050301_0050317
242KB
File
3/12/2005
SLAAON_20050301_20050317
19KB
File
3/12/2005
ALABCD_20050301_20050317
877KB
File
3/12/2005
PATTHI_20050301_20050317
188KB
File
3/12/2005
QLFFVG_20050301_20050317
3900KB
File
3/12/2005
HEALTHD_20050301_20050316
630KB
File
3/11/2005
HEALTHE_20050301_20050316
362KB
File
3/11/2005
HEALTHG_20050301_20050316
424KB
File
3/11/2005
ABC
ALT
FSL
COP
COV
BMI
FSL
COV
QL1234_20050301_20050315
843KB
File
3/11/2005
QL11DE_20050301_20050315
128KB
File
3/11/2005
RL44DE_20050301_20050315
500KB
File
3/11/2005

PAGE 255
7.8.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
enter
File Type:
PBMB
T0000000000xxxx
10/13/2003
DIS
Receiving Participant
Name
List Type
Coverage List
Type
List ID
Participant ID
select from list
select from list
select from list

if List Type =
COV
enter
POC System, Inc.
P0000001
FSL
1111
POC System, Inc.
P0000001
FSL
2222
POC System, Inc.
P0000001
FSL
3333
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 participants 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 participant 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 Publishers complete, current set of formulary information as a
new load. If a particular Technology Provider has gained access to a file due to the
Publishers 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 participants folder. Surescripts also records
distribution lists that have references to lists that do not exist (for example, in cases

PAGE 256
where lists have been deleted). For more information, refer to the File Processing
Options section.
7.9
FORMULARY RETRIEVAL
Formulary Retrievers download Formulary Publisher information from Surescripts via
WebDAV. 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
Participant providing the data files. The Formulary Retriever is the Participant 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 referenced in Appendix A of
this Implementation Guide, creating a script that periodically checks for updates to
formulary and benefit data, or by using both a WebDAV client and a script.
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 Retrievers database and then displayed to physicians based
on the Retrievers system presentation rules.
7.9.1
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
transactions. 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 files
header and trailer information, which is wrapped around each individual list.
The distribution of formulary information to Participants 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.9.2
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).

PAGE 257
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.9.3
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:
For problems related to the WebDAV client/user interface, contact that

products manufacturer.
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.
If a Formulary Retriever receives a Formulary ID within an Eligibility
transaction 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.

PAGE 258
7.10 GENERAL STRUCTURAL OVERVIEW

7.10.1 FILE LEVEL FROM THE SENDER TO THE RECEIVER
File - 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 one to
six types of lists (Formulary / FSL, Alternatives / ALT, Coverage / COV, Copay /
COP, Cross Reference / CRF, Drug Classification / DCL) depending upon how the
lists are bundled.
List - Lists occur within files. Lists are comprised of data segments of related data
elements.
Formulary And Benefit File Header
Formulary Status Header
Formulary Status Detail
..
Formulary Status Trailer
If reporting, must occur 1 time per

formulary reported.
Occurs 0 if delete of full list. Occurs 1 to n for
updates/adds/deletes of detail records.
Must occur 1 time paired with each
Formulary Status Header.
Formulary Alternatives Header

Formulary Alternatives Detail
..
Formulary Alternatives Trailer
Coverage Information Header

Coverage List ID (911-BZ) = AAAAA
Coverage Information Detail Coverage Text Message
Coverage ID (910-BY) = 11111
..
Coverage Information Detail Coverage Text Message
Coverage ID = (910-BY) 22222
..
Coverage Information Trailer
Coverage List ID (911-BZ) = BBBBB
Coverage Information Header
Coverage Information Detail - Prior
Authorization (PA)
..
Coverage Information Detail - Prior
Authorization (PA)
Must occur 1

alternatives reported.
Formulary Alternatives Header.
Coverages reported.


Coverage Information Header.
Coverages reported.


PAGE 259

..
Coverage Information Trailer

Coverage Information Header.
Copay Header
Copay List ID (907-BV) = AAAAA
Copay Detail
Copay ID (906-BU) = 11111
..
Copay Detail
Copay ID (906-BU) = 22222
..
Copay Trailer

Copay reported.
Cross-Reference Header

Cross-References reported.
Cross-Reference Detail
..
Cross-Reference Trailer

Copay Header.

Cross-Reference Header.
Drug Classification Header

Drug Classification Detail
..
Drug Classification Trailer
If reporting, must occur 1 time per Drug

Classification reported.
Drug Classification Header.
Formulary And Benefit File Trailer

Must occur 1

PAGE 260
7.11 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, trailing delimiters are not required to be sent. This format promotes a bulk
load type transaction.
7.11.1 FILE HEADER/TRAILER DEFINITION

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

Field
Description
Type
M/C
Notes
Record Type
AN 3/3
Value = HDR
Version/Release
Number
Sender ID
AN 1/2
10
AN 3/30
The sender represents the entity

that is providing the data and
creating the file.
Sender Participant
Password

specification
identifying the sending
Participant (Formulary
Publisher)
Password for this Participant
as assigned by Surescripts
AN
10/10
Only populated when publisher is

sending file to Surescripts.
Receiver ID
S00000000000001
AN 3/30
Only populated when publisher is

sending file to Surescripts.
Source Name
AN 1/35
Transmission
Control Number
Name of Source supplying

the formulary - Formulary
Publisher
the sender
AN 1/10
Transmission
Date
Transmission
Time
Transmission File
Type
Transmission
Action
Date transaction was created

(D8 - CCYYMMDD)
Time transaction was created
(HHMMSSDD)
Identifier telling the type of
transaction
Action for the entire
transaction.
DT 8/8
CCYYMMDD
TM 8/8
HHMMSSDD
AN 1/3
AN 1/1
Extract Date
Date the file was extracted

from the internal Publishers
system
Test or Production
DT 8/8
FRM = Formulary And Benefit

Load
For formulary publishers this action
tells Surescripts if this 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.
CCYYMMDD
AN 1/1
File Type
T=Test
P=Production

PAGE 261
7.11.3 FORMULARY AND BENEFIT FILE TRAILER

Field
Description
Type
M/C
Notes
Record Type
Total Records

Total records processed
AN 3/3
N 1/10
M
M
Value = TRL
Do not include the file header and
trailer in this count. Total Records in
file minus 2.
7.12 FORMULARY STATUS LIST

7.12.1 FORMULARY STATUS HEADER
Field
Description
Type
M/C
Notes
Record Type
AN 3/3
Value = FHD
Formulary ID
Identification for the

formulary
AN 1/10
This is the formulary ID that was

returned on the Eligibility
transaction.
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
Non-Listed
Prescription
Brand Formulary
Status
Name given to the formulary

Tells the receiver how to
treat non-listed prescription
branded drugs.
The higher the number for
the preferred level, the more
preferred the drug is.
AN 1/35
AN 1/2
C
M
Non-listed
Prescription
Generic
Formulary Status

treat non-listed prescription
generic drugs.
AN 1/2
Non-listed Brand
Over The
Counter
Formulary Status

treat non-listed brand over
the counter drugs.
AN 1/2
U - Unknown
0 Not Reimbursable
1 Non Formulary
2 On Formulary (Not Preferred)
3 Preferred Level 1
4 Preferred Level 2
5 Preferred Level 3
Up to 99.
U - Unknown
0 Not Reimbursable
1 Non Formulary
3 Preferred Level 1
4 Preferred Level 2
5 Preferred Level 3
Up to 99.
U - Unknown
0 Not Reimbursable
1 Non Formulary
3 Preferred Level 1
4 Preferred Level 2
5 Preferred Level 3
Up to 99.

PAGE 262
Field
Description
Type
M/C
Notes
Non-listed
Generic Over
The Counter
Formulary Status

treat non-listed generic over
the counter drugs.
AN 1/2
Non-listed
Supplies
Formulary Status

treat non-listed supplies.
preferred the supply is.
AN 1/2
Relative Cost
Limit
Number of levels used within

the Relative value indicator.
N 1/2
U - Unknown
0 Not Reimbursable
1 Non Formulary
3 Preferred Level 1
4 Preferred Level 2
5 Preferred Level 3
Up to 99.
U - Unknown
0 Not Reimbursable
1 Non Formulary
3 Preferred Level 1
4 Preferred Level 2
5 Preferred Level 3
Up to 99.
Note, if relative value is not used in
the detail, this value is 0 (zero).
List Action
Tells the receiver that this is

a Full list replacement (Or
Add) or a delete list.
AN 1/1
DT 8/8
F = Full List Replacement (If exists,

replace, if not, add)
U = UPDATE LIST
D = Delete List
Note: If the Header Transaction
Action is a Delete, the detail records
should be ignored (if present) by the
Retriever.
CCYYMMDD
The update option is not

currently supported.
List Effective
Date
Date the list goes into effect.
7.12.2 FORMULARY STATUS DETAIL

Field
Description
Type
M/C
Notes
Record Type
Change Identifier

Only the Add option is
supported.
AN 3/3
AN 1/1
M
M
Product/Service
ID
Product/Service
ID Qualifier
Drug ID (NDC)
AN 1/19
Value = FDT
A Addition
C Change
D - Delete
Surescripts requires N 11/11
Drug ID qualifier
AN 2/2
Drug Reference
Number
Drug Reference
Qualifier
Identifier for the drug from

proprietary code sources.
Code value that identifies
the source and type for the
Drug Reference Number.
AN 1/35
AN 1/3
01 = Universal Product Code (UPC)

02 = Health Related Item (HRI)
03 = National Drug Code (NDC) This can be the representative
NDC Number. (Only NDCs
are supported by Surescripts
09 = Health Care Financing
Administration Common Procedural
Coding System (HCPCS)
28 = Universal Product Number
(UPN)
See Section 7.15.2 Drug

Classification Detail for values.

PAGE 263
Field
Description
Type
M/C
Notes
RxNorm Code
ID From RxNorm database.
AN 1/15
Future use once RxNorm is finalized
RxNorm Qualifier
Code qualifying the RxNorm

code submitted.
Status of the drug within the
formulary.
AN 1/3
AN 1/2
N 1/2
U - Unknown
0 Not Reimbursable
1 Non Formulary
3 Preferred Level 1
4 Preferred Level 2
5 Preferred Level 3
Up to 99.
Represents the cost of the drug to
the health plan. If used, the relative
value limit in the header must be
greater than 0 and this value must
be less than or equal to the header
value.
Formulary Status

Relative Cost
The relative value of this

drug within its classification.
7.12.3 FORMULARY STATUS TRAILER

Field
Description
Type
M/C
Notes
Record Type
Total Records

Total Records sent for this
formulary ID.
AN 3/3
N 1/10
M
M
Value = FTR
Do not include the Header and
Trailer records in this count. Total
of Detail records.
7.13 CROSS REFERENCE LIST

This format is the method for locating a patients formulary and benefits information
in cases where the prescribing system is offline or otherwise incapable of retrieving
formulary keys using the real-time Eligibility transaction.
The cross-reference links a user-recognizable health plan product name to its
associated Formulary ID, Alternatives ID, Coverage List ID, Copay List ID and
Classification ID. These IDs are then used to locate information provided through the
Formulary and Benefit File Load service.
7.13.1 CROSS REFERENCE LIST HEADER

Field
Description
Type
M/
C
Notes
Record Type
AN 3/3
Value = XHD
List Effective
Date
List Action
DT 8/8
CCYYMMDD
Tells the receiver that this is

a Full list replacement (Or
Add) or a delete list.
AN 1/1

U = UPDATE LIST
D = Delete List
Note: If the Header Transaction Action
is a Delete, the detail records should be
ignored (if present) by the Retriever.


PAGE 264
7.13.2 CROSS REFERENCE DETAIL

Field
Description
Type
M/
C
Notes
Record Type
AN 3/3
Value = XDT
Change
Identifier

supported.
AN 1/1
A Addition
C Change
D - Delete
AN
1/35
AN
1/10
AN
1/10
Product Name Health Plan

Formulary ID
Alternatives ID
Coverage List
ID
Copay List ID
Classification ID
Identification for the formulary

The Alternative Formulary ID
associated with the Product
Name - Health Plan.
The Coverage ID associated
with the Product Name Health Plan.
The Copay ID associated with
the Product Name - Health
Plan.
The Classification ID
associated with the Product
Name - Health Plan.
The Formulary ID associated with the

Product Name - Health Plan.
AN
1/10
AN
1/10
AN
1/10
Type
M/
C
Notes
Value = XTR
Do not include the Cross Reference

Header and Trailer records in this
count. Total of Cross Reference Detail
records.
7.13.3 CROSS REFERENCE TRAILER

Field
Description
Record Type
Record Count
Total Records sent for this

formulary ID.
AN 3/3
N 1/10
7.14 FORMULARY ALTERNATIVES LIST

Alternative drugs for a specified product.
7.14.1 FORMULARY ALTERNATIVES HEADER

Field
Description
Type
M/
C
Notes
Record Type
AN 3/3
Value = AHD
Alternative ID
The identification number for

this alternative list.
AN
1/10
The ID for the alternative list that may

have been returned on the Eligibility
transaction.
Must be unique across all lists of this
type.
Valid characters are (A-Z, a-z, Numeral
0-9, period ., and a dash -)

PAGE 265
Field
Description
Type
M/
C
Notes
List Action
Tells the receiver that this is a

Full list replacement (Or Add)
or a delete list.
AN 1/1
DT 8/8

U = Update File
D = Delete List
Note: If the Header Transaction Action
is a Delete, the detail records should be
CCYYMMDD

List Effective
Date
7.14.2 FORMULARY ALTERNATIVES DETAIL

Field
Description
Type
M/
C
Notes
Record Type
AN 3/3
Value = ADT
Change Identifier

supported.
AN 1/1
Product/Service
ID - Source
Drug ID (NDC)
AN
1/19
Product/Service
ID Qualifier
Drug ID qualifier
AN 2/2
A Addition
C Change
D - Delete
Note: Alternatives identified in a
formulary alternatives list indicate a
drug at the drug
name level only not the specific drug
name/strength/dosage form level
implied by the
NDC used to identify the alternative.
03 = National Drug Code (NDC) - This
can be the representative NDC
Number. (Only NDCs are
supported by Surescripts
28 = Universal Product Number (UPN)
Drug Reference
Number - Source

AN
1/35
Drug Reference
Qualifier Source
RxNorm Code Source
Code value that identifies the

source and type for the Drug
Reference Number.
AN 1/3
See Section 7.15.2 Drug Classification

Detail for values
AN
1/15
RxNorm Qualifier
- Source
Product/Service
ID - Alternative

code submitted.
Drug ID (NDC)
AN 1/3
AN
1/19

Note: Alternatives identified in a
formulary alternatives list indicate a
drug at the drug
name level only not the specific drug
name/strength/dosage form level
implied by the
NDC used to identify the alternative

PAGE 266
Field
Description
Type
M/
C
Notes
Product/Service
ID Qualifier
Drug ID qualifier
AN 2/2

Drug Reference
Number Alternative
Drug Reference
Qualifier Alternative
RxNorm Code Alternative
RxNorm Qualifier
- Alternative
Preference Level

AN
1/35
Code value that identifies the

source and type for the Drug
Reference Number.
AN 1/3

Detail for values.
AN
1/15
AN 1/3
N 1/2
1-99 Higher = more preferred

code submitted.
If there are multiple
alternatives for a given
Source NDC, this is the
payers order of preference
(a higher number equals
greater preference).
7.14.3 FORMULARY ALTERNATIVES TRAILER

Field
Description
Type
M/
C
Notes
Record Type
Total Records

Total Records
Processed for this
alternative list
AN 3/3
N1/10
M
M
Value = ATR
Do not include Header and Trailer records in
this count. Total of Detail records.
7.15 DRUG CLASSIFICATION LIST

These lists represent proprietary class definitions provided by the formulary
publisher. It is used to classify formulary drugs and step medications.
7.15.1 DRUG CLASSIFICATION HEADER

Field
Description
Type
M/
C
Notes
Record Type
Classification ID

This ID will tie the
classification list to a
patient or health plan.
AN 3/3
AN
1/10
M
M
Value = LHD
Must be unique across all lists of this type.
Valid characters are (A-Z, a-z, Numeral 0-9,
period ., and a dash -)

PAGE 267
List Action
Tells the receiver that

this is a Full list
replacement (Or Add) or
a delete list.
AN 1/1
DT 8/8

List Effective
Date
Date the list goes into

effect.

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.
CCYYMMDD
7.15.2 DRUG CLASSIFICATION DETAIL

Field
Description
Type
M/
C
Notes
Record Type
Change Identifier

supported.
AN 3/3
AN 1/1
M
M
Product/Service
ID
Drug ID (NDC)
AN
1/19
Product/Service
ID Qualifier
Drug ID qualifier
AN 2/2
Value = LDT
A Addition
C Change
D - Delete
Surescripts requires N 11/11. Drug Number
categorized within this Class ID and
Subclass ID
03 = National Drug Code (NDC) - This can
be the representative NDC Number.
09 = Health Care Financing Administration
Common Procedural Coding System
(HCPCS)
Drug Reference
Number
Identifier for the drug

from proprietary code
sources.
Code value that
identifies the source
and type for the Drug
Reference Number.
AN
1/35
AN 1/3
ID From RxNorm
database.
AN
1/15
Drug Reference
Qualifier
RxNorm Code
Code value that identifies the source and

type for the Drug Reference Number.
E = Medical Economic GFC
G = Medical Economic GM
FG = First Databank GCN Seq#
FS = First Databank Smartkey
FN = First DataBank Medication Name ID
(FDB Med Name ID)
FR = First DataBank Routed Medication ID
(FDB Routed Med ID)
FD = First DataBank Routed Dosage Form
ID (FDB Routed Dosage Form Med ID)
FM = First DataBank Medication ID (FDB
MedID)
MC = Multum Drug ID
MD = Medispan DDID
MG = Medispan GPI
MM = Multum MMDC
GS = Gold Standard Product Item Collection
US = U.S. Pharmacopoeia (USP)
AF = American Hospital Formulary Service
(AHFS)

PAGE 268
Field
Description
Type
M/
C
Notes
RxNorm Qualifier
Code qualifying the

RxNorm code
submitted.
ID for the proprietary
designated class that
the product falls within
ID for the designated
sub-class that the
product falls within
The proprietary
classification name for
the Class ID
The proprietary
classification name for
the Subclass ID
AN 1/3
N 1/5
N 1/5
AN
1/50
AN
1/50
Class ID
Subclass ID
Class Name
Subclass Name
If there is no subclass breakout, this field

must be populated. Must be greater than
zero.
If there is no subclass breakout, this field

must be populated. Must be greater than
spaces.
7.15.3 DRUG CLASSIFICATION TRAILER

Field
Field Name
Type
M/C
Comments
Record Type
AN 3/3
Value = LTR
Record Count
Total Records sent for

this formulary ID.
N 1/10
Do not include the Drug Classification

Header and Trailer records in this count.
Total of Drug Classification Detail records.
7.16 BENEFIT COVERAGE LIST

7.16.1 COVERAGE INFORMATION HEADER
Field
Description
Type
M/C
Notes
Record Type
Coverage List ID

ID for the list
AN 3/3
AN 1/10
M
M
Coverage List
Type
Code identifying the

type of coverage factor
being conveyed
AN 1/2
Value = GHD
Must be unique across all lists of this
type.
Valid characters are (A-Z, a-z, Numeral
0-9, period ., and a dash -)
Each Coverage List ID will have only one
List 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

PAGE 269
Field
Description
Type
M/C
Notes
List Action
Tells the receiver that

this is a Full list
replacement (Or Add) or
a delete list.
AN 1/1
DT 8/8
F = Full list replacement (If list with this

List Type / List ID exists, replace; if
not, add)
U = Update File
D = Delete List
Note: If the Header Transaction Action is
a Delete, the detail records should be
CCYYMMDD

List Effective
Date
7.16.1.1

effect.
Coverage Information Detail - Coverage Text Message (TM )
Field
Description
Type
M/C
Notes
Record Type
AN 3/3
Value = TDT
Change Identifier

accepted.
AN 1/1
Coverage ID
The membership
population to which the
coverage rule applies.
Drug ID (NDC)
AN 1/40
A Addition
C Change
D - Delete
Relates to the Coverage ID returned in
the Surescripts Eligibility response.
AN 1/19
Drug ID qualifier
AN 2/2


sources.
Code value that
Reference Number.
ID from RxNorm
database.
Code qualifying the
RxNorm code
submitted.
A text message to be
presented to the
prescriber.
A text message to be
presented to the
prescriber.
AN 1/35
AN 1/3

Detail for values.
AN 1/15
AN 1/3
AN
1/100
Only one text message may be

associated with each NDC.
AN
1/200
Optional long text message. When used

an abbreviated version should be placed
in the short message field.
Product/Service
ID
Product/Service
ID Qualifier
Drug Reference
Number
Drug Reference
Qualifier
RxNorm Code
RxNorm Qualifier
Message Short
Message - Long

PAGE 270
7.16.1.2
Coverage Information Detail Product Coverage Exclusion (DE),

Prior Authorization (PA), Medical Necessity (MN), Step Therapy (ST)
Field
Description
Record Type
Change Identifier
Coverage ID
Product/Service
ID
Product/Service
ID Qualifier
Drug Reference
Number
Drug Reference
Qualifier
RxNorm Code
RxNorm Qualifier
7.16.1.3
Type
M/
C
Notes
AN 3/3
Value = DDT

accepted.
AN 1/1
The membership
population to which
the coverage rule
applies.
Drug ID (NDC)
AN 1/40
A Addition
C Change
D - Delete
AN 1/19
Drug ID qualifier
AN 2/2


sources.
Code value that
Reference Number.
ID from RxNorm
database.
Code qualifying the
RxNorm code
submitted.
AN 1/35
AN 1/3

Detail for values.
AN 1/15
AN 1/3
Coverage Information Detail Step Medications (SM)
Field
Description
Type
M/
C
Notes
Record Type
Change Identifier

accepted.
AN 3/3
AN 1/1
M
M
Coverage ID
The membership
Drug ID (NDC)
AN
1/40
Value = MDT
A Addition
C Change
D - Delete
AN
1/19
AN 2/2

Product/Service ID Source
Product/Service ID
Qualifier - Source
Drug ID qualifier

PAGE 271
Field
Description
Type
M/
C
Notes
Drug Reference
Number - Source
Drug Reference
Qualifier - Source

the source and type for
the Drug Reference
Number.
ID from RxNorm
database.
Code qualifying the
RxNorm code submitted.
Drug ID (NDC)
AN
1/35
AN 1/3
Product/Service ID
Qualifier Step
Drug
Drug Reference
Number Step Drug
Drug Reference
Qualifier Step
Drug
RxNorm Code Source

RxNorm Qualifier Source
Product/Service ID
Step Drug
RxNorm Code
Step Drug
RxNorm Qualifier
Step Drug
Drug Qualifier - Step
Drug
Class ID - Step drug
Subclass ID - Step
Drug
Number of Drugs to
Try
C
C

Detail for values.
AN
1/19
Drug ID qualifier
AN 2/2
Mandatory if Class ID is not populated

or if Drug Qualifier Step Drug is
populated. Surescripts requires N
11/11
Mandatory if Product/Service ID
Step Drug is used.

the Drug Reference
Number.
ID from RxNorm
database.
Code qualifying the
Indicates whether the
Product/Service ID
represents a specific
medication versus a
pharmacological class
designated class that the
product falls within ID for
the proprietary
ID for the designated subclass that the product falls
within
The number of drugs to try
within a class, subclass,
AN
1/35
AN 1/3
AN
1/15
AN 1/3

Detail for values.
AN
1/15
AN 1/3
AN 2/2
Required when Product/Service ID Step Drug is specified.

SM = Specific Medication
PC = Pharmacological Class
N 1/5
Mandatory if Subclass ID exists.
N 1/5
N 1/2
Mandatory if Class ID is populated,

Subclass ID is populated, or Drug

PAGE 272
Field
Description
Type
M/
C
or pharmacological class.
Step Order
Diagnosis Code
Diagnosis Code
Qualifier
7.16.1.4
Notes
Qualifier - Step Drug = PC
The suggested order in

which the step medication
is to be tried
Code identifying the
diagnosis of the patient.
Code qualifying the
Diagnosis Code.
AN 1/1
AN
1/15
AN 2/2
C
C
1 = First to be tried
2 = second to be tried etc.
00 - Not Specified
01 - International Classification of
th
Diseases (ICD9) - the 9 edition
02 - International Classification of
th
Diseases (ICD10) - the 10
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
Coverage Information Detail Quantity Limits (QL)
Field
Description
Type
M/C
Notes
Record Type
Identifies record
type.
Only the Add option
is accepted.
AN 3/3
Value = QDT
AN 1/1
The membership
population to which
the coverage rule
applies.
Drug ID (NDC)
AN 1/40
A Addition
C Change
D - Delete
Relates to the Coverage ID
returned in the Surescripts
Eligibility response.
AN 1/19
Change Identifier
Coverage ID
Product/Service ID

PAGE 273
Field
Description
Type
M/C
Notes
Product/Service ID
Qualifier
Drug ID qualifier
AN 2/2
01 = Universal Product Code

(UPC)
02 = Health Related Item
(HRI)
03 = National Drug Code
(NDC) - This can be the
representative NDC
Number. (Only NDCs
are supported by
Surescripts
Administration
Common Procedural
Coding System
(HCPCS)
28 = Universal Product
Number (UPN)
Drug Reference
Number
Identifier for the

drug from
proprietary code
sources.
Code value that
and type for the
Drug Reference
Number.
ID from RxNorm
database.
Code qualifying the
RxNorm code
submitted.
Maximum amount
qualified by Amount
Qualifier
AN 1/35
AN 1/3

Classification Detail for
values.
AN 1/15
AN 1/3
Future use once RxNorm is

finalized
finalized
R 1/10
C required if
Maximum
Amount
Qualifier is
present.
This field qualifies

the amount in the
Maximum Amount.
Valid values are:
DL=Dollar Amount
DS=Days Supply
FL = Fills
QY=Quantity
AN 2/2
C required if
Maximum
Amount is
present.
Drug Reference
Qualifier
RxNorm Code
RxNorm Qualifier
Maximum Amount
Maximum Amount
Qualifier

If dollar amount, No dollar

sign. Decimal required if
value includes cents.
Currency: USD
The length includes the
decimal point.
If Max Quantity then quantity
is stated in this NDCs unit of
measure
PAGE 274
Field
Description
Type
M/C
Maximum Amount Time

Period
Type of time period

associated with the
overall Maximum
Amount Qualifier.
Valid values are:
DY= Days
LT=Lifetime
PD=Per
Dispensing
SP=Specific Date
Range
CY=Calendar
Year
CQ =Calendar
Quarter
CM=Calendar
Month
Starting date of
Specific Date
Range
AN 2/2
C required if
Maximum
Amount
Qualifier is
NOT DS
(Days Supply),
Optional if
Maximum
Amount
Qualifier is
DS.
DT 8/8
Maximum Amount Time

Period End Date
Ending date of
Specific Date
Range
DT 8/8
Maximum Amount Time

Period Units
Number of units
associated with the
overall Time Period
N 1/4
C required if
Time Period =
SP, otherwise
not populated.
C required if
Time Period =
SP,
otherwise not
populated.
C required if
Maximum
Amount Time
Period = DY,
CQ CY or
CM otherwise
not populated.
Maximum Amount Time

Period Start Date
7.16.1.5
Notes
CCYYMMDD
CCYYMMDD
Coverage Information Detail Age Limits (AL)
Field
Description
Type
M/C
Notes
Record Type
AN 3/3
Value = GDA
Change
Identifier

accepted.
AN 1/1
Coverage ID
The membership
Drug ID (NDC)
AN 1/40
AN 1/19
A Addition
C Change
D - Delete
Relates to the Coverage ID
returned in the Surescripts
Eligibility response.
Product/Serv
ice ID

PAGE 275
Field
Description
Type
M/C
Notes
Product/Serv
ice ID
Qualifier
Drug ID qualifier
AN 2/2
01 = Universal Product Code

(UPC)
(HRI)
representative NDC
Administration Common
Procedural Coding System
(HCPCS)
Number (UPN)
Drug
Reference
Number
Drug
Reference
Qualifier
RxNorm
Code
RxNorm
Qualifier
Minimum
Age

AN 1/35

ID from RxNorm database.
AN 1/3

AN 1/15
Code qualifying the

Minimum age at which the
drug is covered (inclusive)
AN 1/3
N 1/3
Minimum
Age Qualifier
Qualifier for the Minimum

Age field: Years or Days
AN 1/1
Maximum
Age
Maximum age at which the

drug is covered (inclusive)
N 1/3
Maximum
Age Qualifier
Qualifier for the Maximum

Age field: Years or Days
AN 1/1
C, if Minimum
Age Qualifier is
populated
C, if Minimum
Age is
populated
C, if Maximum
Age Qualifier is
populated
C, if Maximum
Age is
populated

finalized
finalized
If minimum does not apply,
leave blank
7.16.1.6
D = Days
Y = Years
If maximum does not apply,
leave blank
D = Days
Y = Years
Coverage Information Detail Gender Limits (GL)
Field
Description
Type
M/C
Notes
Record Type
Change
Identifier

accepted.
AN 3/3
AN 1/1
M
M
Coverage ID
The membership
Drug ID (NDC)
AN 1/40
Value = GDT
A Addition
C Change
D - Delete
AN 1/19
Product/Servi
ce ID

PAGE 276
Field
Description
Type
M/C
Notes
Product/Servi
ce ID
Qualifier
Drug ID qualifier
AN 2/2

Drug
Reference
Number
Drug
Reference
Qualifier
RxNorm
Code
RxNorm
Qualifier
Gender

AN 1/35

AN 1/3

Detail for values.
AN 1/15
Code qualifying the

Gender for which the drug
is covered
AN 1/3
AN 1/1
1 = Male
2 = Female
7.16.1.7
Coverage Information Detail Resource Link - Summary Level (RS)
Field
Description
Type
M/C
Notes
Record Type
Change
Identifier

accepted.
AN 3/3
AN 1/1
M
M
Coverage ID
The membership
Identifies the type of
coverage information
contained at the URL listed
below.
AN 1/40
Value = RDT
A Addition
C Change
D - Delete
AN 2/2
The web page address.
AN 1/255
Resource
Link Type
URL
7.16.1.8
AL - Age Limits
DE - Product Coverage Exclusion
GL - Gender Limits
MN - Medical Necessity
PA - Prior Authorization
QL - Quantity Limits
ST - Step Therapy
GI - General Info
CP - Copay
FM - Formulary
Only one URL may be associated with
each Coverage ID / resource type
combination.
Coverage Information Detail Resource Link - Drug Specific (RD)
Field
Description
Type
M/C
Notes
Record Type
Change Identifier

accepted.
AN 3/3
AN 1/1
M
M
Value = RRT
A Addition
C Change
D - Delete

PAGE 277
Field
Description
Type
M/C
Notes
Coverage ID
The membership
Drug ID (NDC)
AN 1/40
AN 1/19
Relates to the Coverage ID returned

in the Surescripts Eligibility
response.
Drug ID qualifier
AN 2/2

AN 1/35
AN 1/3

AN 1/15
AN 1/3
Resource Link
Type
Code qualifying the

Identifies the type of
coverage information
contained at the URL listed
below.
AN 2/2
URL
The web page address.
AN 1/255
AL - Age Limits
DE - Product Coverage Exclusion
GL - Gender Limits
MN - Medical Necessity
PA - Prior Authorization
QL - Quantity Limits
ST - Step Therapy
GI - General Info
CP - Copay
FM - Formulary
Only one URL may be associated
with each coverage id / resource
type combination.
Product/Service
ID
Product/Service
ID Qualifier
Drug Reference
Number
Drug Reference
Qualifier
RxNorm Code
RxNorm Qualifier

03 = National Drug Code (NDC) This can be the representative
NDC Number. (Only NDCs are
Administration Common
Procedural Coding System
(HCPCS)
28 = Universal Product Number
(UPN)
7.16.2 COVERAGE INFORMATION TRAILER

Field
Description
Type
M/C
Notes
Record Type
AN 3/3
Value = GTR
Record Count
Total Records included in

this list
N 1/10
This does not include the header

and trailer.
7.17 BENEFIT COPAY LIST

PAGE 278
7.17.1 COPAY HEADER

Field
Description
Type
M/C
Notes
Record Type
Copay List ID

ID for the list.
AN 3/3
AN 1/10
M
M
Copay List Type
Code identifying the type

of Copay being conveyed
AN 1/2
Value = CHD
Must be unique across all lists of
this type.
Valid characters are (A-Z, a-z,
Numeral 0-9, period ., and a dash
-)
SL Summary Level
DS Drug Specific
List Action
Tells the receiver that this

is a Full list replacement
(Or Add) or a delete list.
AN 1/1
DT 8/8

List Effective Date
7.17.1.1

effect.
F = Full list replacement (If list with

this List Type / List ID exists,
replace; if not, add)
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.
CCYYMMDD
Copay Information Detail Summary Level (SL)
Field
Description
Type
M/C
Notes
Record Type
AN 3/3
Value = CDT
Change Identifier

accepted.
AN 1/1
Copay ID
The membership
Copay rule applies.
AN 1/40
Formulary Status
Status of drug in formulary
AN 1/2
A Addition
C Change
D - Delete
Relates to the Copay ID
returned in the
Surescripts Eligibility
response.
1 Non-Formulary
2 On Formulary (Not
Preferred)
3 - Preferred Level 1
4 Preferred Level 2
Up to 99
Note: 0 (NonReimbursable) is not
allowed
A = Any

PAGE 279
Field
Description
Type
M/C
Notes
Product Type
Type of drug: Branded,

Multi-Source Branded,
Generic
AN 1/1
Pharmacy Type
Dispensing pharmacy type.
AN 1/1
Out of Pocket
Range Start
If the copay varies

according to the patients
out of pocket, this is the
lower range value.
R 1/10
Out of Pocket
Range End
If the copay varies

according to the patients
out of pocket, this is the
upper range value.
R 1/10
0 = Not Specified
1 = Single source brand
2 = Branded generic
3 = Generic
4 = O.T.C. (over the
counter)
5 = Compound
6 = Supply
7= Multi source brand
A = Any
R = Retail
M = Mail Order
S = Specialty
L = Long-term Care
A = Any
No dollar sign. Decimal
required if value includes
cents. Currency: USD
decimal point.
decimal point.
Flat Copay
Amount
Fixed Copay amount
R 1/10
Percent Copay
Rate
Percentage Copay rate
R 1/10
First Copay Term
First Copay term (flat

Copay amount or percent
Copay) to be considered
AN 1/1
Minimum Copay
Minimum total Copay to be

paid by the patient
R 1/10
C at least one of
the following
fields must be
populated: Flat
Copay Amount,
Percent Copay
Rate, or Copay
Tier
C - at least one
of the following
fields must be
populated: Flat
Copay Amount,
Percent Copay
Rate, or Copay
Tier
C if both Flat
Copay and
Percent Copay
are populated
C if Percent
Copay is
populated

Field not populated

indicates no upper limit
to range.
cents.
decimal point.
Currency: USD
Percentage expressed
as a decimal (e.g., 0.0
through 1.0 represents
0% through 100%)
decimal point.
F = Flat Copay
P = Percent Copay

decimal point.
PAGE 280
Field
Description
Type
M/C
Notes
Maximum Copay
Maximum total Copay to be

paid by the patient
R 1/10
C if Percent
Copay is
populated

decimal point.
Days Supply per

Copay
The days supply

associated with the stated
Copay terms
This medications Tier; an
indication of the cost to the
patient. Lower values
represent lower cost to the
patient (e.g., Tier 1 is less
costly to the patient than
Tier 2)
N 1/3
N 1/2
Provides the range within

which the Copay Tier is
stated. The highest Copay
tier within that range.
N 1/2
C - at least one
of the following
fields must be
populated: Flat
Copay Amount,
Percent Copay
Rate, or Copay
Tier
C if Copay
Tier is
populated
Copay Tier
Maximum Copay
Tier
7.17.1.2
The Copay Tier value

may not be greater than
the Maximum Copay Tier
value
Copay Information Detail Drug-Specific (DS)
Field
Description
Type
M/C
Notes
Record Type
Change Identifier

accepted.
AN 3/3
AN 1/1
M
M
Copay ID
The membership
Copay rule applies.
AN 1/40
Product/Service
ID
Product/Service
ID Qualifier
Drug ID (NDC)
AN 1/19
Drug ID qualifier
AN 2/2
Value = CRT
A Addition
C Change
D - Delete
Relates to the Copay ID
returned in the
Surescripts Eligibility
response.
Surescripts requires N
11/11
Code (UPC)
(HRI)
representative NDC
Number. (Only NDCs
are supported by
Surescripts
09 = Health Care
Financing Administration
Common Procedural
Number (UPN)
Drug Reference
Number
Drug Reference
Qualifier

the Drug Reference
Number.
AN 1/35
AN 1/3


Classification Detail for
values.
PAGE 281
Field
Description
Type
M/C
Notes
RxNorm Code
ID from RxNorm
database.
Code qualifying the
Dispensing pharmacy type
AN 1/15
AN 1/3
AN 1/1
Flat Copay
Amount
Fixed Copay amount
R 1/10
Percent Copay
Rate
Percentage Copay rate
R 1/10
First Copay Term
First Copay term (flat

Copay amount or percent
Copay) to be considered
AN 1/1
Minimum Copay
Minimum total Copay to

be paid by the patient
R 1/10
C - at least one
of the following
fields must be
populated: Flat
Copay Amount,
Percent Copay
Rate, or Copay
Tier
C - at least one
of the following
fields must be
populated: Flat
Copay Amount,
Percent Copay
Rate, or Copay
Tier
C if both Flat
Copay and
Percent Copay
are populated
C if Percent
Copay is
populated
Future use once RxNorm

is finalized
Future use once RxNorm
is finalized
R = Retail
M = Mail Order
S = Specialty
L = Long-term Care
A = Any
cents.
decimal point.
Currency: USD
Maximum Copay
Maximum total Copay to

be paid by the patient
R 1/10
C if Percent
Copay is
populated
Days Supply per

Copay
The days supply

associated with the stated
Copay terms
This medications Tier; an
indication of the cost to
the patient. Lower values
represent lower cost to the
patient (e.g., Tier 1 is less
costly to the patient than
Tier 2)
N 1/3
N 1/2
C - at least one
of the following
fields must be
populated: Flat
Copay Amount,
Percent Copay
Rate, or Copay
Tier
C if Copay
Tier is
populated
RxNorm Qualifier
Pharmacy Type
Copay Tier
Maximum Copay
Tier
Provides the range within

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

Percentage expressed
as a decimal (e.g., 0.0
through 1.0 represents
0% through 100%)
decimal point.
F = Flat Copay
P = Percent Copay

decimal point.
decimal point.
The Copay Tier value

may not be greater than
the Maximum Copay Tier
value
PAGE 282
7.17.2 COPAY TRAILER

Field
Description
Type
M/C
Notes
Record Type
Record Count

Total Records
Processed for this
Copay List
AN 3/3
N 1/10
M
M
Value = CTR
Do not include the Copay
Header and Trailer
records in this count.
Total of Copay
Information Detail
records.
7.18 FORMULARY AND BENEFIT FILE VALIDATION

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 Section 8.19.2.
7.18.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:
Validate the proper physical format of the header (required fields are present and
contain valid values as defined in Surescripts specification).
Validate the sender (source) Participant ID and password.
Validate that the Usage Indicator is valid for the system the file is sent to (i.e. T for
Test, P for Prod).
Validate the version number.
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.
Full Replace and Update Validations
The header of the formulary and benefit data load contains a qualifier that indicates
whether the load is a Full Replace or an Update.
The process for a Full Replace is:
c. The entire file is validated according to the rules in this section.
d. If an error occurs within the file, the entire file is rejected.
e. Once validated, all previously loaded formulary information across
all file types at Surescripts is removed and replaced by the new
formulary and benefit file.
The process for an Update is:
f.
The individual lists are validated separately at Surescripts. If a list

fails validation, the list does not load, and the old list remains
active. Validation continues on the other lists contained within the
file. Valid lists are loaded; lists with errors are rejected.
PAGE 283
For more information on Full Replaces vs. Updates, refer to the File Processing
Options section.
7.18.2 FORMULARY AND BENEFIT LIST HEADER AND TRAILER VALIDATION

For Update loads (as specified in the File Level Header):
If an error exists in the header, the entire detail section for that header is discarded
and an error is recorded and sent within the Response File. Validation of the other
lists continues. Any valid lists are loaded; lists with errors are rejected. If a file
comes in with the same identifier as a previously loaded file (either from a different
load, or this load) the file is replaced with the latest version.
For Full Replace loads (as specified in the File Level Header):
If an error exists in the header, the validation and processing of the file is stopped
and the entire file is rejected. An error is sent to the Formulary Publisher within the
Response File. None of the data or formulary and benefit lists are processed if any
errors exist.
7.18.3 FORMULARY AND BENEFIT DETAIL VALIDATION

For Update process loads (as specified in the File Level Header):
If there is an error in a row on the detail section, the entire list is discarded and
recorded. The error is sent within the Response File back to the Formulary
Publisher. In this instance, a list is defined as the detail between the header and
trailer.
For Full Replace process loads (as specified in the File Level Header):
If there is an error in a row on the detail section, the validation and processing of
the file is stopped and the entire file is rejected. An error is sent to the Formulary
Publisher within the Response File. None of the data or formulary and benefit lists
are processed if any errors exist.
7.19 FORMULARY AND BENEFIT RESPONSE FILE

A Response File is sent back to the formulary provider 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 Section 8.19.2.
Formulary And Benefit Response File Header
Formulary And Benefit Response File Detail
Must occur 1
Occurs 0 if no errors or system error
Occurs 1 to n if errors
Formulary And Benefit Response File Trailer
Must occur 1

PAGE 284
7.19.1 FORMULARY AND BENEFIT RESPONSE FILE HEADER

Header Info
Field
Description
Type
M/
C
Notes
Record Type
Version/Releas
e Number
Sender ID

specification
ID as assigned by
Surescripts identifying
Surescripts
ID assigned by Surescripts
for the recipient or
Formulary Publisher
(original sender of the
Formulary and Benefit Data
Load.)
Password assigned by
Surescripts for accessing
the PBM system.
the sender
AN 3/3
AN 1/2
M
M
Value = SHD
10
AN
3/30
AN
3/30
AN
10/10
AN
1/10
Recipient ID
Recipient
Participant
Password
Transaction
Control Number
Transaction
Date
Transaction
Time
Transaction File
Type
Transaction
Number Originating
Transaction
DateOriginating
Date transaction was

created
Time transaction was
created
Identifier telling receiver the
type of file.
Number of the original
formulary transaction
DT 8/8
CCYYMMDD
TM 8/8
HHMMSSDD
AN 1/3
FRE Formulary Transaction

Response
AN
1/10
Date Original Incoming File

was created (D8 -)
DT 8/8
CCYYMMDD
Transaction
TimeOriginating
File Type
Time Original Incoming File

was created
TM 8/8
HHMMSSDD
AN 1/1
T=Test
P=Production

PAGE 285
Field
Description
Type
M/
C
Notes
Load Status
Code Explaining the status

of the load.
AN 2/2
01 File loaded correctly

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. Note: If a row level
error has occurred, the entire list is
not loaded. This error code is only
used with File Update processes.
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
Field
Description
Type
M/C
Notes
Record Type
AN
3/3
Value = SDT
Absolute Row
Number
The absolute row or line

number in the file that
contains the error.
N
1/10
If the row number is 1 then the error

is for the file header.
Section
Column in
Error
Column number that

contains the error
N 1/2
Reject Code
Describes error for this

column
AN
4/4
Column number of error in row. The

first field - Record Type is
considered column 0, the next field
is considered column 1.
See Detail Errors table below
Note: If an error occurred,

the entire list that the error
was in did not load.
Free text description of the
error
AN
1/100
AN
1/100
Additional
Message
Information
Data in Error
Copy of the bad data
If the data in error is longer than 100

characters it will be truncated. If a
pipe character is in the data it will be
represented as [PIPE]

PAGE 286
Trailer Info
Field
Description
Type
M/C
Notes
Record Type
AN
3/3
N
1/10
N
1/10
Value = STR
Total Rows in
Error
Total Errors
M
M
7.19.2 REJECT CODE SUMMARY

When the Formulary and Benefit File Header field Load Status is 02 File loaded
with errors or 03 File contains errors File not loaded, the following Reject
Code values may be reported.
Reject
Code
Explanation
1001
1002
Required segment missing

Required list missing
1003
1004
Unknown segment
Unexpected segment
1005
Failed to parse embedded list
1006
1007
1008
Required field missing

Invalid field length
Field value not found in validation table
1009
1010
1011
Invalid character(s) in field

Extra data found after segment
Effective date processing error
1012
Invalid Record Count
1013
9000
Invalid Sender/Receiver Id or Password

Other Error
Only a file header HDR and trailer TRL

are present. No lists are present.
There is an extra blank line in the file.
A record is out of order or doesnt have a
valid record identifier.
The list type field in a list header is not
valid. Coverage list type is TS instead of
TM.
Valid values are 1,2,3 and a value of 4 is

found.
A space character is in a numeric field.
The date sent is in the correct format but
not valid considering the other effective
dates of lists published.
The file or list trailer has the wrong value
in the record count field.
Error is not one of the codes, see free
text for description.
If a detail row contains an error within an Update process, the entire occurrence of
that section (List) is not loaded. However, the processing for the rest of the file
continues.
If a detail row contains an error within a Full Replace process, the processing of the
entire file (not just the list that contained the error) is stopped and the entire file is
rejected.

PAGE 287
7.20 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.
The following example scenarios are included:
d.
e.
f.
g.
h.
i.
j.
k.
l.
m.
n.
o.
p.
q.
Formulary status drug listed in payers formulary

Formulary status drug not listed by payer
Formulary status product coverage exclusion applies
Formulary status using representative NDC
Formulary alternative lookup using payer specified formulary alternatives
Coverage - quantity limits and gender limits
Coverage - step medications in terms of drug class
Copay - summary level and drug specific
Copay - combination terms
Copay - patient out-of-pocket rules
Copay - patient out-of-pocket / Medicare example
Error scenario - Formulary Status List
Error scenario - Age Limits
Error scenario - Age Limits
7.20.1 FORMULARY STATUS DRUG LISTED IN PAYERS FORMULARY

In this scenario, the payer administering the patients 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
patients Formulary ID and a drug ID.
Step one: Retrieve the patients payers participant id (P00010) and Formulary ID
(100) from the 271 transaction.
Step two: Locate the medication (Paroxetine HCL 12.5 mg Tablet, NDC = 000293206-13) in the Formulary Status List 100, and note the Formulary Status (2 = OnFormulary)
The following shows excerpted example content.

PAGE 288
7.20.1.1
Formulary Status List Header (Received from Payer P00010)

Recor
d
Type
Formula
ry ID
Formular Non-Listed Non-Listed Nony Name

Prescriptio Prescriptio Listed
n Brand
n Generic Brand
Formulary Formulary Over The
Status
Status
Counter
Formulary
Status
NonListed
Generic
Over The
Counter
Formular
y Status
NonRelative File List

Listed
Cost
Actio Effective
Supplies Limit
n
Date
Formular
y Status
FHD
100
HealthOn U
e National
Formulary
20050101

Record Change
Type Identifier
FDT
Product
/
Service
ID
0002932
0613
Product / Drug
Drug
RxNorm
Service
Reference Reference Code
ID
Number
Qualifier
Qualifier
RxNorm Formulary Relative

Qualifier Status
Cost
03

Record Type
Record Count
FTR
Raw Data:
FHD|100|HealthOne National Formulary|U|U|U|U|U|0|F|20050101
FDT.
FDT|A|0029320613|03|||||2
FDT.
FTR|3
7.20.2 FORMULARY STATUS DRUG NOT LISTED BY PAYER

In this scenario, the payer administering the patients pharmacy benefit did not
include an entry in their Formulary Status List for the specific drug being
considered. The drug in the example is a branded prescription medication (Paxil
CR 12.5 mg Tablet, NDC# = 00029-3206-13)
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.

PAGE 289
Step one: Retrieve the patients payers participant ID (P00010), and Formulary ID
Step two: Search Formulary Status List 100 for the medication, looking for the
products NDC in the Product / Service ID field. The medications 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
7.20.2.1

Recor
d
Type
Formula
ry ID
Formular Non-Listed Nony Name

Prescriptio Listed
n Brand
Prescripti
Formulary on
Status
Generic
Formulary
Status
NonListed
Brand
Over The
Counter
Formulary
Status
NonListed
Generic
Over The
Counter
Formular
y Status
NonRelativ File List

Listed
e Cost Actio Effective
Supplies Limit n
Date
Formular
y Status
FHD
100
HealthOn 2
e National
Formulary
20050101

Record Change
Type
Identifier
Product
/
Service
ID
FDT
Product /
Service
ID
Qualifier
Drug
Drug
RxNorm
Number
Qualifier
RxNorm Formular Relative

Qualifier y Status Cost

Record Type
Record Count
FTR
Raw Data:
FHD|100| HealthOne National Formulary|2|3|1|2|0|0|F|20050101
FDT.
FDT
FTR|..
7.20.3 FORMULARY STATUS PRODUCT COVERAGE EXCLUSION APPLIES

In this scenario, the payer administering the patients pharmacy benefit uses the
Product Coverage Exclusion list to communicate specific medications that are not
covered by certain membership groups.

PAGE 290
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 CoverageExclusion list for the patients Coverage ID
and the medication being considered.
Step one: Retrieve the patients payers participant id (P00010), Formulary ID
(100), and Coverage ID (2222) from the 271 transaction.
Step two: Confirm theres no product coverage exclusion for medication being
considered, by searching the Product Coverage Exclusion list for the Coverage ID
2222 and the medications ID (Paroxetine HCL 12.5 mg Tablet, NDC = 000293206-13).
If the Coverage ID / Drug ID combination is present, the process stops. The
patients membership group does not cover the medication, and the Formulary
Status is equal to 0 Not Reimbursable.
7.20.3.1
Product Coverage Exclusion List
Coverage Information Header Product Coverage Exclusion (Received from Payer

P00010)
Reco
rd
Type
Coverage List ID
Coverage List
Type
File Action List Effective

Date
GHD
HEALTHONE
DE
20050101
Coverage Information Detail - Product Coverage Exclusion

Reco
rd
Type
GDT
Change
Identifier
Coverag Product /
e ID
Service ID
2222
Product /
Service ID
Qualifier
Drug
Reference
Number
Drug
Reference
Qualifier
00029320613 03
Coverage Information Trailer - Product Coverage Exclusion

Record Type
Record Count
GTR
Raw Data:
GHD|HEALTHONE|DE|F|20050101
GDT|A|2222|000293320613|03
GTR|..
7.20.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 medications packaging variations.

PAGE 291
On its Formulary Status List, the payer includes one NDC for each label name
medicationrepresenting 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.
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 patients payers participant ID (P00010), and Formulary ID
Step two: Reference a third-party or proprietary drug database to gather all NDCs
associated with the prescription-level medication being considered:
00002-4117-04 (1,000 count bottle)

00002-4117-33 (100 count blister pack)
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.
7.20.4.1

Recor
d
Type
Formula
ry ID
Formular Non-Listed Nony Name

Prescriptio Listed
n Brand
Prescripti
Formulary on
Status
Generic
Formulary
Status
NonListed
Brand
Over The
Counter
Formulary
Status
NonListed
Generic
Over The
Counter
Formulary
Status

Listed
Cost
Actio Effectiv
Supplies Limit
n
e Date
Formular
y Status
FHD
100
HealthOn U
e National
Formulary
2005010
1

Record Change
Type
Identifier
Product
/
Service
Product / Drug
Drug
RxNorm
Service
ID
Number
Qualifier

RxNorm
Qualifier
Formular Relative
y Status Cost
PAGE 292
FDT
ID
Qualifier
0000241
1760
03

Record Type
Record Count
FTR
Raw Data:
FHD|100|HealthOne National Formulary|U|U|U|U|U|0|F|20050101
FDT.
FDT|A|00002411760|03|||||2
FDT
FTR|..
7.20.5 FORMULARY ALTERNATIVE LOOKUP USING PAYER SPECIFIED

Formulary alternative lookup using payer specified formulary alternatives
Step one: Note the off-formulary medications NDC - Cardene SR 30 mg Oral
CpSR 00004-0180-91.
Step two: Retrieve the patients payers participant id (P00010), and Alternatives
ID (100) from the 271 transaction.
Step three: Search the corresponding Formulary Alternatives Lists NDCs of the
off-formulary medications 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)
00093-0822-01 Nifedipine ER
00069-1520-68 Norvasc
7.20.5.1
Formulary Alternatives List

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

PAGE 293
Record Change Identifier Source NDC

Type
ADT
ADT
A
A
00004018091
00004018091
Alternative NDC
00093082201
00069152068
Preference
Level
4
3

Record Type
Total Records Minus

Header and Trailer
ATR
Raw Data:
AHD|100|F|20050506
ADT|.
ADT|A|00004018091|00093082201|4
ADT|A|00004018091|00069152068|3
ADT|.
ATR|4

PAGE 294
7.20.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.
Medication: FemHRT 1/5 5 mcg-1 mg Tablet, NDC# 54868-4679-00
The steps below locate these coverage rules.
(100) and Coverage ID (2222) from the 271 transaction.
Step two: Search the various Coverage Lists for the Coverage ID 2222 and the
medications ID
Two matches are made:
Gender Limit: F = Female

Quantity Limit: Maximum Amount = 30, Maximum Amount Qualifier =
Days Supply
(30 Days Supply)
7.20.6.1
Gender Limits List
Coverage Information Header Gender Limits (Received from Payer P00010)

Record
Type
Coverage List ID
Coverage List
Type

Date
GHD
HEALTHONE
GL
20050101
Coverage Information Detail - Gender Limits

Record
Type
Change
Identifier
Coverag Product /
e ID
Service ID
GDT
2222
Product /
Service ID
Qualifier
Drug
Reference
Number
54868467900 03
Drug
Reference
Qualifier
Gender Code
Coverage Information Trailer - Gender Limits

Record Type
Record Count
GTR
Raw Data:
GHD|HEALTHONE|GL|F|20050101
GDT
GDT|A|2222|54868467900| 03|||2
GDT
GTR|

PAGE 295
7.20.6.2
Quantity Limits List
Coverage Information Header Quantity Limits (Received from Payer P00010)

Recor
d Type
Coverage List ID
Coverage List
Type

Date
GHD
HEALTHONE
QL
20050101
Coverage Information Detail - Quantity Limits

Recor
d Type
GDT
Chang
e
Identifi
er
Covera
ge ID
Product /
Service ID
Product Drug
Drug
Maximu
/ Service Referenc Reference m
ID
e Number Qualifier Amount
Qualifier
2222
54868467900 03
30
Maximu
m
Amount
Qualifier
Maximu
m
Amount
Time
Period
DS
Coverage Information Trailer - Quantity Limits

Record Type
Record Count
GTR
Raw Data:
GHD|HEALTHONE|QL|F|20050101
GDT
GDT|A|2222|54868467900|03|||30|DS
GDT
GTR|
7.20.7 COVERAGE - STEP MEDICATIONS IN TERMS OF DRUG CLASS

In this example, the payer requires a step therapy program be followed before a
certain medication will be covered.
Specifically, before the anti-inflammatory medication, Bextra (a Cox-2 Inhibitor) will
be covered; at least one drug from the Cox-1 Inhibitor category must be tried (such
as the medication, Ibuprofen)
Requested medication: Bextra 20 mg Tablet, NDC# 00025-1980-31

Step medication class: Drugs Acting Principally On Joints (Class ID 156)
Step medication sub-class: NSAIDS, Cox-1 Inhibitor (Class ID 156-22)
Number of drugs to be tried from the specified class / sub-class: one
Step medication example drug: Ibuprofen 300 mg Tablet, NDC# 002471423-20
In the example, the payer has identified a single step requirement; if more than one
step had been listed, then the Step Order data element would indicate which step
should be tried first, second, etc.

PAGE 296
The steps below locate these coverage rules.

(100) and Coverage List ID (2222) from the 271 transaction.
Step two: Search the various Benefit Coverage Lists for the Coverage ID 2222 and
the medications ID
One match is made:
Step Medications:
o Class ID - Step Drug = 156
o Subclass ID - Step Drug = 156-22
o Step Order = 1
o Number of Drugs to Try = 1
Step three: Locate a drug of the class / subclass indicated in the Step Medications
match:
Ibuprofen 300 mg Tablet, NDC# 00247-1423-20
7.20.7.1
Step Medications List
Coverage Information Header - Step Medications (Received from Payer P00010)

Recor
d Type
Coverage List ID
Coverage List
Type

Date
GHD
HEALTHONE
SM
20050101
Coverage Information Detail - Step Medications

Record
Type
GDT
Chang
e
Identifi
er
Coverag
e ID
Source
Product /
Service ID
Product /
Service ID
Qualifier
Class ID - Subclass Number Of

Step Drug ID - Step Drugs To
Drug
Try
Step
Order
2222
00025198031
03
156
156-22
Coverage Information Trailer - Step Medications

Record Type
Record Count
GTR
Raw Data:
GHD|HEALTHONE|SM|F|20050101
GDT
GDT|A|2222|00025198031| 03||156|156-22|1|1
GDT
GTR|

PAGE 297
7.20.7.2
Drug Classification List Header (Received from Payer P00010)

Record
Type
Classification ID

Date
LHD
20050101
Drug Classification Detail

Recor Change
d Type Identifier
LDT
Product /
Service ID
Product / Drug
Drug
Class ID Subclas Class Name Subclass
Service ID Referenc Referenc
s ID
Name
Qualifier e Number e
Qualifier
0024714232 03
0
156
156-22
Drugs Acting NSAIDS,

Principally Cox-1
On Joints
Inhibitor
Drug Classification List Trailer

Record Type
Record Count
LTR
Raw Data:
LHD|A|F|20050101
LDT...
LDT|A|00247142320|03|||156|156-22|Drugs Acting Principally On Joints
|NSAIDS, Cox-1 Inhibitor
LDT
LTR|
7.20.8 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.

PAGE 298
The steps below locate the copay information.

(100) and Copay List ID (COP300) from the Eligibility transaction.
Step two: 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:
Copay ID = COP300
NDC# = 50458-0320-06 (Risperdal 2 mg Tablet)
One match is made, specifying the copay that applies when dispensed at any type
of pharmacy.
For illustration, the example content below also contains the summary-level copay
that represented the general rule (which was overridden in this scenario):
Copay List ID = COP300

Formulary Status = A (Any)
Product Type = 1 (Single Source Brand)
Pharmacy Type = A (Any)
Flat Copay Amount = 20 ($20)
7.20.8.1
Drug-Specific Copay List
Copay Header (Received from Payer P00010)

Record
Type
Copay List ID
Copay List Type

Date
CHD
HEALTHONE
DS
20050101
Copay Information Detail - Drug Specific

Record
Type
Change
Identifier
Copay
ID
Source
Product /
Service ID
Product /
Service ID
Qualifier
CRT
COP300 50458032006 03
Pharmacy
Type
Flat Copay
Amount
10
Copay Trailer
Record Type
Record Count
CTR

PAGE 299
Raw Data:
CHD|HEALTHONE|DS|F|20050101
CRT
CRT|A|COP300|50458032006|03||A|10
CRT..
CTR|
7.20.8.2

Reco
rd
Type
Copay List ID
Copay List Type

Date
CHD
HEALTHONE
SL
20050101
Copay Information Detail - Summary-Level

Reco
rd
Type
CDT
Change
Identifier
Copay
ID
Formular Product
y Status Type
COP300 A
Pharmacy Flat Copay

Type
Amount
20
Copay Trailer
Record Type
Record Count
CTR
Raw Data:
CHD|HEALTHONE|SL|F|20050101
CDT
CDT|A|COP300|A|1|A|20
CDT..
CTR|
7.20.9 COPAY COMBINATION TERMS

In this example, the patients 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 drugs cost, plus 15% of
the remaining cost, not to exceed $30

PAGE 300
The steps below locate the copay information. The example assumes the user is
considering a single-source branded prescription medication.
Step one: Retrieve the patients payers participant ID (P00010), Formulary ID
(100) and Copay List ID (COP300)
Step two: Search the Copay Information Detail Drug-Specific list to determine
whether a drug-specific copay was provided by the payer. In this example, no drugspecific rule was supplied
Step three: 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
Product Type = 1 (Single source brand)

Percent Copay Rate = 0.15 (15%)
First Copay Term = F (Flat copay is applied first)
Minimum Copay Amount = 10 ($10)
Maximum Copay Amount = 30 ($30)
7.20.9.1

Record
Type
Copay List ID
Copay List Type

Date
CHD
HEALTHONE
SL
20050101
Copay Information Detail - Summary Level

Record
Type
CDT
Change
Identifi
er
Copa
y ID
Formular Produc Pharmac

y Status t Type y Type
COP3 A
00
Flat
Copay
Amount
Percen First
t
Copay
Copay Term
Rate
Minimu Maximu
m
m
Copay Copay
10
0.15
10
Copay Trailer
Record Type
Record Count
CTR

PAGE 301
30
Raw Data:
CDT
CDT|A|COP300|A|1|A| |10|0.15|F|10|30
CDT..
CTR|
7.20.10
COPAY - PATIENT OUT-OF-POCKET RULES
In this example, the patients health plan varies the patient copay based on their
current out-of-pocket balance the amount that the patient has contributed, todate, to the cost of their medications.
The illustration below presents a copay plan with different patient copays for the
three conditions below:
If the patient has contributed less than $100 to-date, their copay is $30
If the patients out-of-pocket balance is between $100 and $1,000, their
copay is $20
Lastly, if the patients out-of-pocket balance is greater than $1,000, their
copay is $10
The steps below locate those copay rules.

(100) and Copay List ID (COP300) from the 271 transaction.
Step two: Search the Copay Information Detail - Drug-Specific list to determine
Step three: 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
Product Type = A (Any)

Out-of-pocket Range Start = 0
(Patient out-of-pocket balance is between zero and $100)
Second record

Out-of-pocket Range Start = 100.01

PAGE 302

(Patient out-of-pocket balance is between $100.01 and $1,000)
Third record

Out-of-pocket Range Start = 1,000.01
Out-of-pocket Range Start = not populated
(Patient out-of-pocket balance is more than $1,000.01)
7.20.10.1

Record
Type
Copay List ID
Copay List Type

Date
CHD
HEALTHONE
SL
20050101

Record
Type
Change
Identifier
Copay Formular Produc Pharmacy Out-of- Out-of- Flat
ID
y Status t Type Type
pocket pocket Copay
Range Range Amoun
Start End
t
CDT
CDT
CDT
COP3
00
COP3
00
COP3
00
100
30
100.01 1000
20
1000.0
1
10
Copay Trailer
Record Type
Record Count
CTR
Raw Data:
CDT
CDT|A|COP300|A|A|A|0|100|30
CDT|A|COP300|A|A|A|100.01|1000|20

PAGE 303
CDT|A|COP300|A|A|A|1000.01||10
CDT..
CTR|
7.20.11
COPAY - PATIENT OUT-OF-POCKET / MEDICARE EXAMPLE
This example describes how the new Medicare prescription drug benefits out-ofpocket rules would be represented in the Benefit Copay Lists. The patients 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 patients out-of-pocket balance accumulates
according to drug purchases:
Medicare out-of-pocket accumulation

Drug cost
Range
begin
250
2,250
5,100
Range
Dollar cost in
end
range
250
250
2,250
2,000
5,100
2,850
unlimited
n/a
Patient's out-of-pocket
Percent
copay
100%
25%
100%
5%
For range
250
500
2,850
5% of add'l
Accumulated
250
750
3,600
3,600 + 5% of
add'l drug costs
Below are the associated copay rules:
If the patient has contributed less than $250 to-date, their copay is 100%
of the cost of the drug
If the patients out-of-pocket balance is between $250 and $750, their
copay is 25% of the cost of the drug
If the patients out-of-pocket balance is between $750 and $3,600, their
copay goes back up to 100% of the cost of the drug
Lastly, once the patients 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 patients Medicare benefit.
(100) and Copay List ID (COP300) from the 271 transaction.
Step two: Search the Copay Information Detail - Drug-Specific list to determine
Step three: Search the Copay Information Detail - Summary Level list to find the
general rule

PAGE 304
The four matching entries in the Copay Information Detail - Summary Level list
codify the rule described above...
First record

(Patient out-of-pocket balance is between zero and $250)
Second record

(Patient out-of-pocket balance is between $250.01 and $750)
Third record

(Patient out-of-pocket balance is between $750 and $3,600)
Fourth record
Out-of-pocket Range Start = 3,600.01

Out-of-pocket Range Start = not populated
(Patient out-of-pocket balance is more than $3,600)

PAGE 305
7.20.11.1

Record
Type
Copay List ID
Copay List Type

Date
CHD
HEALTHONE
SL
20050101

Record
Type
Chan
ge
Identi
fier
Copay
ID
Formular Product Pharmac Out- Out-of- Percent

y Status Type
y Type
ofpocket Copay
pocket Range Rate
Range End
Start
CDT
CDT
250.01 750
0.25
CDT
750.01 3600
1.0
CDT
COP30
0
COP30
0
COP30
0
COP30
0
3600.0
1
0.05
250
1.0
Copay Trailer
Record Type
Record Count
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|

PAGE 306
7.20.12
ERROR SCENARIO - FORMULARY STATUS LIST
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
Recor
d
Type
Versio Sende Sender Receive Receiver Source Transmis Transm Trans Trans Trans Extra File
n
r ID
Particip r ID
Participa Name sion
ission missio missio missi ct
Type
/Relea
ant
nt
Control Date
n Time n File on
Date
se
Passwo
Passwor
Number
Type Actio
Numbe
rd
d
n
r
HDR
01
ABC
PASS
XYZ
Publish 30011
er
PASS
200501 120530 FRM

01
01
20050 T
101
Formulary Status List Header

Recor
d
Type
Formul
ary ID
Formular Nony Name

Listed
Prescripti
on Brand
Formulary
Status
Non-Listed
Prescriptio
n Generic
Formulary
Status
Non-Listed
Brand Over
The Counter
Formulary
Status
NonListed
Generic
Over The
Counter
Formulary
Status

Listed
Cost
Actio Effective
Supplies Limit
n
Date
Formulary
Status
FHD
100
HealthOn U
e National
Formulary
20050101

Record
Type
Change
Identifier
Product
/
Service
ID
Product Drug
/
Reference
Service Number
ID
Qualifie
r
FDT
5486846
7900
03
Drug
RxNorm RxNorm Formulary Relative
Referenc Code
Qualifier Status
Cost
e
Qualifier

Record Type
Record Count
FTR
Formulary and Benefit File Trailer

Record Type
Total Records
TRL

PAGE 307
Raw Data:
HDR|01|ABC|PASS|XYZ|PASS|Publisher|30011|20050101|12053001|FRM|F|20050101|T
FHD|100|HealthOne National Formulary|||||| 0|X|20050101
FDT.
FDT|A|54868467900|03|||||2
FDT.
FTR|3
TRL|
Formulary and Benefit Response File Header

Reco
rd
Type
Versi Sende Receiv

on
r ID
er ID
/Rele
ase
Num
ber
Receive Transmi Transm Transmi

r
ssion
ission ssion
Particip Control Date
Time
ant
Number
Passwo
rd
SHD
01
PASS
XYZ
ABC
Transm Transmiss Transmis Transmis File Load

ission ion
sion Date sion
Typ Statu
File
Number - Time e
s
Type Originatin Originati Originati
g
ng
ng
445534 200501 1505300 FRE

01
1
30011
20050101 12053001 T
03
Formulary and Benefit Response File Detail

Record
Type
Absolute
Row
Number
Section
Column
In Error
Reject
Code
Additional Message Data In Error

Information
SDT
10
1008
Field value not found X

in validation table
Formulary and Benefit File Response Trailer

Record Type
Total Rows In Error
Total Errors
STR
Raw Data:
SHD|01|XYZ|ABC|PASS|445534|20050101|15053001|FRE|30011|20050101|15053001|T|0
3
SDT|2|10|1008|Field value not found in validation table |X
SRL|1|1

PAGE 308
7.20.13
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.
Reco
rd
Type
Versio Sende Sender Receive Receiver Source Transmis Transm Trans Trans
n
r ID
Partici r ID
Particip Name sion
ission missio missio
/Relea
pant
ant
Control Date
n Time n File
se
Passw
Passwor
Number
Type
Numbe
ord
d
r
HDR
01
ABC
PASS
XYZ
PASS
Publish 30012
er
200501 120530 FRM

01
01
Trans Extract File

missi Date
Type
on
Actio
n
F
200501 T
01
Coverage Information Header Quantity Limits

Record
Type
Coverage List ID
Coverage List
Type

Date
GHD
HEALTHONE
AL
20050101
Coverage Information Detail Quantity Limits

Record
Type
GDA
Chan
ge
Identi
fier
Covera
ge ID
Product /
Service ID
Product
/ Service
ID
Qualifier
2222
54868467900 03
Minimum Minimu Maximu Maximu

Age
m Age m Age m Age
Qualifier
Qualifier
18
Coverage Information Trailer Quantity Limits

Record Type
Record Count
GTR

Record Type
Total Records
TRL
Raw Data:
GHD|HEALTHONE|AL|F|20050101
GDA
GDA|A|2222|54868467900|03||||18
GDA

PAGE 309
GTR|
TRL|
Rec
ord
Typ
e
Versio Sende Recei Receiver Transm Transm Trans

n
r ID ver ID Participan ission ission missio
/Relea
t
Control Date
n Time
se
Password Number
Numbe
r
SH
D
01
XYZ
Trans
missi
on
File
Type
445535 200501 150530 FRE

01
01
ABC PASS
Transmissi Transmis Transmis File Load

on Number sion Date sion
Type Statu
Time s
Originating Originatin Originati
g
ng
30012
20050101 12053001 T
03

Record
Type
Absolute
Row
Number
Section
Column
In Error
Reject
Code
Additional
Message
Information
SDT
13
1006
Required Field
Missing
Data In Error

Record Type
Total Rows In Error
Total Errors
STR
Raw Data:
SHD|01|XYZ|ABC|PASS|445535|20050101|15053001|FRE|30012|20050101|15053001|T|0
3
SDT|4|13|1006|Required Field Missing
SRL|1|1
7.20.14
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.
Rec
ord
Typ
e
Versio Sende Sender Receive Receiver Source Transmis Transm Trans Trans
n
r ID
Particip r ID
Particip Name sion
ission missio missio
/Relea
ant
ant
Control Date
n Time n File
se
Passwo
Passwor
Number
Type
Numbe
rd
d
r
HD
R
01
ABC
PASS
XYZ
PASS
Publish 30013
er
200501 120530 FRM

01
01
Trans Extract File

missi Date
Type
on
Actio
n
F
200501 T
01
Coverage Information Header Quantity Limits (MISSING)

PAGE 310
Coverage Information Detail Quantity Limits

Reco
rd
Type
GDA
Chang
e
Identifi
er
Covera
ge ID
Product /
Service ID
Product
/ Service
ID
Qualifier
2222
54868467900 03
Minimum Minimu Maximu Maximu

Age
m Age m Age m Age
Qualifier
Qualifier
18
Coverage Information Trailer Quantity Limits

Record Type
Record Count
GTR

Record Type
Total Records
TRL
Raw Data:
(MISSING)
GDA
GDA|A|2222|54868467900|03||||18
GDA
GTR|
TRL|

Rec
ord
Typ
e
Versio Sen Rece Receive Transmiss Transmis Transmis Transmi Transmis

n
der iver r
ion
sion Date sion
ssion sion /Relea ID ID
Particip Control
Time
File
Number
se
ant
Number
Type
Originatin
Numbe
Passwor
g
r
d
SHD
01
XYZ ABC PASS
445536
2005010 1505300 FRE

1
1
30013
Transmi Transmissio File Load

ssion
n Time Type Status
Date Originating
Originati
ng
2005010 12053001
1
03

Record
Type
Absolute
Row
Number
Section
Column
In Error
Reject
Code
Additional Message
Information
SDT
1004
Unexpected Segment
Data In Error

Record Type
Total Rows In Error
Total Errors
STR

PAGE 311
Raw Data:
SHD|01|XYZ|ABC|PASS|445536|20050101|15053001|FRE|30013|20050101|15053
001|T|03
SDT|2|1|1004|Unexpected Segment
SRL|1|1

PAGE 312

PAGE 313
APPENDIX A:
WebDav Clients
WEBDAV CLIENTS
Surescripts has the ability to deliver provider directory and formulary and benefit files to its
Participants via WebDAV. WebDAV is a series of extensions to HTTP which allows users to
collaboratively edit and manage files on remote servers (more information on WebDAV can
be found at http://www.webdav.org).
This appendix is intended to give Surescripts Participants more information about the types
of WebDAV clients they can use to access Surescripts formulary and provider update
information.
WebDAV Clients
The WebDAV clients described in this appendix are being used by some Surescripts
Participants to access the Surescripts formulary and provider information. New
Participants may choose to use these or any other available WebDAV clients to
connect to the Surescripts WebDAV server.
WebDAV Client Support
Surescripts is not a developer or distributor of these WebDAV clients. Therefore, we
cannot provide extensive technical support for them.
If you are able to manually log in to WebDAV and download formulary data, this
confirms connectivity to Surescripts, and requires you to contact the support staff for
the WebDAV client you are using. Also, if you have problems installing or configuring
the clients in your environment, please call the WebDAV clients support staff.
Information such as the WebDAV URL, connectivity options, Participant User ID, and
Participant password are provided during the Participants implementation.
1.1. WEBDAV COMPRESSION

Surescripts supports HTTP compression for the download of formulary information.
This allows a client to request that the transfer of formulary information be
compressed during the HTTP transfer. Client side tools may differ in how to enable
this functionality. A configuration property typically controls if the http request will ask
for compression during transfer. Some tools have this property set by default. If it is
set by default, there is nothing for you to do to take advantage of the compression
feature. The download time should be decreased dramatically. If your tool, or custom
code, is not set, you now have the option of enabling compression. If you do not, no
change is required to operate as you are today. If you do, you will still receive the
files exactly as you do today, but they will be compressed and decompressed during
the file transfer. For more detail on HTTP compression, go
to: http://en.wikipedia.org/wiki/HTTP_compression

PAGE 314
WebDav Clients
1.2. WEBDAV COMMANDS

WebDAV client software uses a series of HTTP methods to retrieve files. Below is a
list of commands that the Surescripts WebDAV server supports.
HEAD
Retrieve HTTP header information for a file
GET
Retrieve a file
PROPFIND
List files/folders in a WebDAV folder
OPTIONS
Get list of supported WebDAV commands
1.3. MICROSOFT WEB FOLDERS

Microsoft Web Folders is a GUI WebDAV client implementation that comes
integrated into Microsofts operating systems and Internet Explorer products. For
more information, visit the Web Folders homepage at http://www.microsoft.com
1.3.1.
SUPPORTED PLATFORMS
1.3.2.
Microsoft Windows 2000

Microsoft Windows XP
Microsoft Windows Millennium
Microsoft Internet Explorer 5.x
INSTALLATION
There is no installation involved if you are running one of the above operating
systems or if Internet Explorer 5.x has been installed.
1.3.3.
CONNECTING TO A WEBDAV DIRECTORY
First, open Internet Explorer, go to the File menu, and select Open. The following
dialog will appear; fill in the location shown below (https://filescert.rxhub.net/webdav/) and click the Open as Web Folder checkbox. Note: if an
error message appears before the login dialog, then there may be a DNS problem
on your computer. Sometimes, running the following command from a DOS prompt
helps: ipconfig /registerdns
Then, authenticate using your Surescripts assigned Participant ID and password.

PAGE 315
WebDav Clients
The Web Folders are displayed in a browser. You can simply drag and drop the
information within the folders from the browser window into a local directory
structure.
In the above example, clicking the Formulary folder will bring up folders for each type of
formulary and benefit list this PBM (Formulary Publisher) has given this POC (Formulary
Retriever) access to within WebDAV.
Clicking on a particular list folder (in this example, ALT) brings up the files of that
type.

PAGE 316
WebDav Clients
1.4. CADAVER
Cadaver is a UNIX command-line, open source WebDAV client. This client is ideal
for scripting an automated process to download WebDAV folder information onto a
UNIX system. For more information, visit the Cadaver
Homepage: http://www.webdav.org/cadaver/.
1.4.1.
SUPPORTED PLATFORMS
Virtually any UNIX platform

Linux
BeOS

PAGE 317
1.4.2.
WebDav Clients
INSTALLATION
Before installing Cadaver, you must first install OpenSSL to get Cadaver working
with HTTPS support.
Open a web browser and navigate to the website: http://www.openssl.org/source/
Download OpenSSL, gunzip it, and untar it.
cd to the OpenSSL root install directory and do the following:
$ ./config
$ make
$ make test
$ make install (this will most likely need to be run as root)
Go to http://www.webdav.org/cadaver/ to download Cadaver.
o
o
o
Download the source code: cadaver-0.20.4.tar.gz

Unzip the file: gunzip cadaver-0.20.4.tar.gz
Then untar the file: tar xvf cadaver-0.20.4.tar
Modify the following line in the configure file:

#if OPENSSL_VERSION_NUMBER >= 0x00906060
to be the following:
#if OPENSSL_VERSION_NUMBER >=0x00906000
Then cd to the Cadaver root install directory and type:
$ ./configure with-ssl
$ make
$ make install (run as root)
Now Cadaver should be available. To test it out, type cadaver in a shell.
1.4.3.
Once Cadaver is installed on the UNIX system, it can be used to connect to

Surescripts and download WebDAV folder information. Start the Cadaver client by
typing cadaver in a UNIX shell. Then use the open command to connect to the
Surescripts WebDAV director. There will be a prompt for a User ID and Password.
Once login is successful, you will be able to navigate through the directory structure
using the cd and ls commands.

PAGE 318
WebDav Clients
When in a file directory, you may download files by issuing the get or the mget
command.
1.5. WEBDRIVE
WebDrive is a Windows WebDAV utility that allows you to map a network drive letter
to a WebDAV service. This makes it convenient for a Windows user to gain access
to their WebDAV folder information in much the same way they can access a
network drive. For more information, visit the WebDrive
Homepage: http://www.southrivertech.com/.
1.5.1.
SUPPORTED PLATFORMS
Windows ME/2000/XP
1.5.2.
INSTALLATION

PAGE 319
WebDav Clients
To install WebDrive, purchase and download it from:

http://www.southrivertech.com/
o
o
Follow the download installation instructions provided.

Once installed, a screen like the one below will appear.
Give the site an identifiable name and then map the WebDAV URL to the one
specified in the Participant connectivity documentation. Set the server type to
WebDAV, select the drive letter to a desirable letter, and enter your User ID and
Password. Once this is finished, click on the Connect button. Test the connection
by examining the contents of the mapped drive.
1.5.3.
Once installed, you can access formulary or provider information from Surescripts
WebDAV server by browsing the mapped drive with a Windows browser or by
accessing it via a DOS window. WebDrive will manage authentication, so you do
not need to re-enter your Participant User ID and password. You can download
files by using cut and paste techniques, or by using the copy command from a DOS
window.

PAGE 320

WebDav Clients
PAGE 321
WebDav Clients
1.6. CAQH
Formulary list naming in WebDAV is slightly different for CAQH files compared to the
example in Section 8.8.3 Formulary and Benefit File Naming and Structure.
In the example below CAQH formulary list naming is illustrated.
CAQH
COV
QLSTNATIONAL_20050301_20050415
QLANBLUSELCT_20050301_20050415
RLWPMISSOURI_20050301_20050420
FSL
STNATIONAL_20050301_20050415
ANBLUSELCT_20050301_20050317
WPMISSOUR_20050301_20050420
In the CAQH formulary implementation only Formulary and Coverage lists will be
created.
For Coverage lists, the first 2 bytes of the file name represent the coverage type (e.g.
QL=Quantity Limit). The next 10 bytes represent the Formulary ID value in the
formulary file detail header (FHD). This 10 byte value is defined such that the first 2
bytes represent the publisher name (e.g. AN=Anthem) and the remaining 8 bytes
represent the formulary name. Each publisher will have its own unique 2 byte
identifier. CAQH publishers also provide a 35 character formulary name in the
Formulary Name field of the formulary file detail header (FHD) record.

PAGE 322
WebDav Clients
1.7. SSL INFORMATION

Surescripts expects SSL (HTTPS) traffic on the standard SSL port, 443.
1.8. SERVER CERTIFICATES

When setting up a webserver to accept SSL, it is necessary to use a digital
certificate. The certificate that is used in the production environment must be signed
by an established certificate authority, such as VeriSign. In the certification
environment, the certificate can be self-signed. In the case of a self-signed cert, it will
be necessary to send a copy of the cert to Surescripts so it can be recognized as a
valid certificate when Surescripts connects to the site.

PAGE 323
APPENDIX B:
Secure File Transfer
SECURE FILE TRANSFER
Surescripts supports two methods for file transfer: CONNECT:Direct and Secure FTP.
1.1. 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 Participant should send to Surescripts is 1 GB. If
a Participant needs to send a file larger than 1 GB, they should notify
Surescripts to ensure we will be able to process the file.
1.2. CONNECT:DIRECT
Connect:Direct is a peer-to-peer file-based integration middleware solution that is
optimized for assured delivery, high volume and secure data exchange. PBM
participants currently use Connect:Direct to send formulary and benefit files
(Formulary and Benefit Data Load) and member directory files (ID Load) to
Surescripts.
This section provides guidelines for Participants on how to setup, configure, and use
Connect:Direct to exchange files with Surescripts.
Surescripts and the Participant need to provide the following network information to
each other in order to set up the Connect:Direct connection between their
environments:
Server Node Name

IP Address
Port Number
Node ID username
Node Password
File name requirements for Surescripts transfer of Response File
Note: Surescripts requires that participants set up connectivity to both the

Surescripts Certification and Production Connect:Direct environments.
1.2.1. CONNECT:DIRECT PROCESS SETUP

The Participant Run Process
A Connect:Direct process similar to the one below will be run by the Participant
through the Participants Connect:Direct server node. The syntax of the from
portion of the copy statement must be compatible with the participants host and file
type.

PAGE 324
The syntax of the to portion of the copy statement must be compatible with
Surescripts host and file type. Surescripts provides this portion of the copy
statement to the Participant. For more information, refer to the Connect:Direct
UNIX Copy Statement and Connect:Direct UNIX Run Task Statement sections in
the Connect:Direct Process Guide, Volume 3, located
at https://support.sterlingcommerce.com/content/documentation/ConnectDirect/CD
_ProcessGuides/CDProcessStatementsGuide.pdf
Submit proc1 process
snode=surescripts.node.name
snodeid=(username,password)
step1 copy from
(file=participant.data.filename pnode)
compress ext
to
(file=surescripts.filename
disp=(new)
sysopts=:strip.blanks=NO: snode)
step1a if (step1=0) then

step2 run task
(PGM=UNIX) sysopts = do_task

surescripts.filename snode
eif
pend;
Surescripts Run Process

A Connect:Direct process similar to the one below will be run through the
Surescripts Connect:Direct server node. The syntax of the from portion of the copy
statement must be compatible with Surescripts host and file type. The syntax of the
to portion of the copy statement must be compatible with the Participants host and
file type. The Participant provides the content of this portion of the copy
statement to Surescripts:
Submit sendFRM
process
snode=participant.node.name
snodeid=(username,password)
step01 copy from
to
(file=surescripts.filename pnode)
(dsn=participant.filename
dcb=(RECFM=FB,LRECL=137)
disp=(new,keep/catalog,delete)
snode)
pend;

PAGE 325
1.3. CONNECT:DIRECT PROCESS CONFIGURATION

The Implementation Manager must gather the following information from the
Participant in order for the Surescripts Operations staff and the Participants
technical staff to know how to configure the Connect:Direct processes.
PBM process statement (initiating file)
Considerations for records with trailing whitespace:
1. Do data records require trailing whitespace?
a. If Yes, the Health Plan must include the following in their SYSOPTS
configurations: SYSOPTS=STRIP.BLANKS=NO:
b. If No, the default value of STRIP.BLANKS=YES: can be used.
File DSN Definition:
2. What is the participants Data Set Name (DSN) of the file on their system
(PNODE)?
3. What will be the Data Set Name (DSN) for the file as it comes across to
Surescripts (SNODE)?
Run Task Requirement:
Surescripts requires that a Run Task step be added to the Participants process
statement. The Run Task step executes a file processing step at Surescripts. The
Run Task should be represented as SNODE (PGM=UNIX) SYSOPTS=do_task
Surescripts file name
Surescripts process statement (response file):
1. What is the participant node name that Surescripts will be connecting to?
2. What is the node ID/PWD that Surescripts will need to access the participants
node?
3. Do participants wish to receive email notification when their file is processed at
Surescripts? If so, what email address should be inserted into the Notify
statement?
4. What is the participant Data Set Name (DSN) that Surescripts should reference
for the response file?
5. What Data Control Block (DCB) characteristics should Surescripts set up for the
response file (e.g. GDG, RECFM, LRECL, BLKSIZE, etc.)?
6. What DISP characteristics should Surescripts set up for the response file (e.g.
new, keep, delete, etc.)?
Defining DISP characteristics with participant:
1. Will Surescripts always be creating a new file on the participants system? If yes,
the 1st DISP setting should be new. If no, Surescripts and the Participant need
to discuss this since Surescripts standard is new.

PAGE 326
2. Will Surescripts be writing to a Generational Data Group (GDG) on the

participants system? If yes, the 2nd DISP setting should be catalog. If no, the
DISP setting should be keep.
3. What should happen to the file if the process terminates abnormally? If the
participant wishes the partial file to be deleted, the DISP setting should be
delete. If the participant wishes the partial file to be kept on their end, the DISP
setting should be keep. Surescripts standard for this setting is delete.
1.4. SECURE FTP

Surescripts has implemented a Secure FTP server that supports the following file
transfer protocols: FTP with SSL; FTP over SSH; and HTTP/S. All of these protocols
use an X.509 digital certificate to facilitate data encryption during the file transfer
process. Clear-text file transfer is not allowed to or from Surescripts.
Secure FTP access in the Surescripts Certification environment is available on host
name transport-cert.Surescripts.net. FTP with SSL is available on port 990, using the
passive port range 53000-53999. FTP over SSH is available on port 22. HTTP/S is
available through this URL: https://transport-cert.rxhub.net.
Secure FTP access in the Surescripts Production environment is available on host
name transport.rxhub.net. FTP with SSL is available on port 990, using the passive
port range 53000-53999. FTP over SSH is available on port 22. HTTP/S is available
through this URL: https://transport.rxhub.net.
The participant will use their Surescripts-assigned Participant ID and Participant
Password to log into the Secure FTP server.
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 Participant using client software that is
compatible with the Surescripts Secure FTP Server. If the Participant has a
compatible Secure FTP server, Surescripts can optionally push Response files to the
Participants Secure FTP Server.

PAGE 327
APPENDIX C:
Dynamic Delimiters
DYNAMIC DELIMITERS
This section contains a full list of characters that are acceptable to use as delimiters.
Char
(bel)
(ht)
(nl)
(vt)
(cr)
(np)
(fs)
(gs)
(rs)
(us)
!
"
%
&
'
(
)
Dec
7
9
10
11
13
12
28
29
30
31
33
34
37
38
39
40
41
Oct
0007
0011
0012
0013
0015
0014
0034
0035
0036
0037
0041
0042
0045
0046
0047
0050
0051
Hex
0x07
0x09
0x0a
0x0b
0x0d
0x0c
0x1c
0x1d
0x1e
0x1f
0x21
0x22
0x25
0x26
0x27
0x28
0x29
*
+
,
.
/
:
;
<
=
>
?
@
[
\
]
^
_
`
{
|
}
~
42
43
44
45
46
47
58
59
60
61
62
63
64
91
92
93
94
95
96
123
124
125
126
0052
0053
0054
0055
0056
0057
0072
0073
0074
0075
0076
0077
0100
0133
0134
0135
0136
0137
0140
0173
0174
0175
0176
0x2a
0x2b
0x2c
0x2d
0x2e
0x2f
0x3a
0x3b
0x3c
0x3d
0x3e
0x3f
0x40
0x5b
0x5c
0x5d
0x5e
0x5f
0x60
0x7b
0x7c
0x7d
0x7e

PAGE 328

Prescription Benefit IG 2011-04-15

Hochgeladen von

Dokumentinformationen

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

Prescription Benefit IG 2011-04-15

Hochgeladen von

Copyright:

Verfügbare Formate

Prescription Benefit Implementation Guide

Eligibility Sections are based on the ASC X12N/005010X279 Guide

DATE: APRIL 15, 2011

PRESCRIPTION BENEFIT IMPLEMENTATION GUIDE

FOR SECTIONS OF THIS IMPLEMENTATION GUIDE

FOR SECTIONS OF THIS PARTICIPANT IMPLEMENTATION GUIDE

DOCUMENT CHANGE LOG

Added #21 Loop 2120 increased

Removed URL encoding requirement

Change N402 and N403 to optional

Clarified which differences are for 270,

Added Country Code and 2100B

Removed note on 2100B REF03 for

Changed the secure URL for

Formulary & Benefit

Changed the section number for all

Replaced RXHUB with

Added extra EB loop for test cases

Added note to N404 Country Code

Adding trailing slash to URL.

Formulary & Benefit

Replaced RXHUB with

SURESCRIPTS CONFIDENTIAL AND PROPRIETARY

Changed S00000000000001 back to

Corrected the key fields for search.

Changed 270 2100B NM103 Receiver

Receiver N4 Segment State and

Added situational rule to all N4

SURESCRIPTS CONFIDENTIAL AND PROPRIETARY

Surescripts Prescription Benefit Implementation Guide

HTTP-Level Authentication ............................................................................. 16

SECTION 3 Transactions Overview ................................................................................24

Delimiter Examples .................................................................................27

Choosing a Delimiter ....................................................................................... 26

Numeric Representation ................................................................................. 28

Transaction Validation ...............................................................................29

SURESCRIPTS CONFIDENTIAL AND PROPRIETARY,

Surescripts Prescription Benefit Implementation Guide

Eligibility Transaction Processing Summary .............................................. 220

ID Load ..................................................................................................... 230

Formulary and Benefit Data Load ............................................................. 242

SURESCRIPTS CONFIDENTIAL AND PROPRIETARY,

Surescripts Prescription Benefit Implementation Guide

File Naming ................................................................................................... 254

7.8.4 Formulary Distribution List Creation ......................................................256

SURESCRIPTS CONFIDENTIAL AND PROPRIETARY,

Surescripts Prescription Benefit Implementation Guide

7.14.1 Formulary Alternatives Header ............................................................. 265

Coverage Information Detail - Coverage Text Message (TM ) ...................... 270

7.16.2 Coverage Information Trailer ................................................................ 278

Copay Information Detail Summary Level (SL) .......................................... 279

7.17.2 Copay Trailer ........................................................................................ 283

Formulary Status List .................................................................................... 289

7.20.2 Formulary Status Drug Not Listed By Payer ...................................... 289

Formulary Status List .................................................................................... 290

7.20.3 Formulary Status Product Coverage Exclusion Applies ..................... 290

Product Coverage Exclusion List................................................................... 291

7.20.4 Formulary Status Using Representative NDC .................................... 291

Formulary Status List .................................................................................... 292

7.20.5 Formulary alternative lookup using payer specified .............................. 293

Formulary Alternatives List ............................................................................ 293

7.20.6 Coverage Quantity Limits And Gender Limits .................................... 295

Gender Limits List ......................................................................................... 295

Surescripts Prescription Benefit Implementation Guide