Wed ihealth id card

Copyright 2005-2006 WEDI SNIP Page 1 of 33

WEDI Strategic National Implementation Process (SNIP) SNIP Transactions Workgroup Health ID Card Sub-Workgroup

Health Identification Card Implementation Guide

This implementation guide specifies WEDIs Health Identification Card Implementation of the American National Standard, Identification CardsHealth Care Identification Cards, INCITS 284-2006. INCITS is accredited by ANSI.

~ Version 1.0 ~ ~ June 3, 2006 ~

Workgroup for Electronic Data Interchange 12020 Sunrise Valley Dr., Suite 100, Reston, VA. 20191

(t) 703-391-2716 / (f) 703-391-2759 2005-2006 Workgroup for Electronic Data Interchange, All Rights Reserved

DRAFT For Public Comment Comments Due August 3, 2006

WEDI Health ID Card Implementation Guide For Public Comment June 3, 2006 DRAFT


WEDI Seeks Public Comment on this Proposed Implementation Guide

1. This implementation guide is a proposal published to obtain public comment. WEDI requests that health industry participants submit detailed written comments, suggestions, agreements, and disagreements. Please submit comments as follows:

Submit comments in Microsoft Word format to [email protected]. Please begin the comments by identifying your organization and a contact

person and email address to enable us to obtain clarification as needed. Please identify the paragraph number in this guide that pertains to each

comment. Comments from all submitters will be collated, duplicates summarized, and made

available in a public report. Submitters will not be identified in the report unless you request to be identified.

We will endeavor to include comments received prior to July 1, 2006, in the WEDI Forum in Chicago July 12, 2006 (see next page for details).

All comments are due by August 3, 2006. 2. Should you desire clarification about any part of this implementation guide, please send

questions to [email protected].

Disclaimer

This document is Copyright 2005-2006 by The Workgroup for Electronic Data Interchange (WEDI). It may be freely redistributed in its entirety provided that this copyright notice is not removed. It may not be sold for profit or used in commercial documents without written permission of the copyright holder. This document is provided as is without any express or implied warranty. While all information in this document is believed to be correct at the time of writing, this document is for educational purposes only and does not purport to provide legal advice. If you require legal advice, you should consult with an attorney. The information provided here is for reference use only and does not constitute the rendering of legal, financial, or other professional advice or recommendations by the Workgroup for Electronic Data Interchange. The listing of an organization does not imply any sort of endorsement and the Workgroup for Electronic Data Interchange takes no responsibility for the products, tools, and Internet sites listed. The existence of a link or organizational reference in any of the following materials should not be assumed as an endorsement by the Workgroup for Electronic Data Interchange (WEDI), or any of the individual workgroups or sub-workgroups of the Strategic National Implementation Process (SNIP). This document contains a number of quotations or paraphrases from the underlying standard, INCITS 284-2006, which is copyright by the Information Technology Industry Council (ITI). The sources are footnoted.



July 12th Forum for Public Comment on this Health ID Card Implementation Guide

The Workgroup for Electronic Data Interchange (WEDI) will be conducting a 2-part industry forum on July 10-12, 2006 in Chicago at the Wyndham OHare Hotel.

Health Savings Account Forum: 1-day: 1:00 PM July 10 to 5:00 PM July 11. Health Identification Card Forum: 1-day: 8:00 AM to 4:00 PM July 12, 2006

WEDI Health Identification Card Implementation Guide Forum July 12, Chicago The Health ID Card forum seeks your ideas and concerns about the WEDI Health Identification Card Implementation Guide. The intent of the guide is to standardize present practice, to bring uniformity of information, appearance, and technology to over 100 million health cards now issued by providers, plans, government programs, and others. The benefit is potentially very high. For health care providers, machine-readable health identification cards eliminate patient and insurance identification errors, reduce the costs and aggravation of rejected claims, reduce lengthy admission processes, and contribute to smoother office procedures and patient satisfaction. Use of machine-readable cards can re-admit patients quickly, eliminate photocopying front and back of cards, eliminate manual data key entry of card information, and eliminate filing of paper copies. Machine-readable health cards can also integrate with provider systems to initiate immediate automatic transactions such as eligibility inquiries, medical necessity inquiries, and pre-certification. For health plans, machine-readable health identification cards can (i) improve subscriber or member satisfaction, (ii) improve employer and plan sponsor satisfaction, (iii) reduce the cost of returning and subsequent reconciling of claims with errors, (iv) reduce the cost of both provider and member help desks and administrative record searches, and (v) improve provider relations. The July 12th Forum is your opportunity to learn the details and simplicity of the standard card. You will be given a copy of the WEDI implementation guide and a guided tour. Learn the reasons for choice of technology and data content. Learn how the pressing need for a comprehensive health plan identifier is being addressed, how one card may serve multiple types of benefits, how cards relate to patient financial settlement, how cards relate to electronic health records, how one standard supports cards issued by providers, by plans, and potentially by other entities such as RHIOs, health data banks, blood banks, and others. Most importantly, this forum is interactive. WEDI wants to hear your needs, your concerns, and your suggestions before the final guide is posted.



Table of Contents 1.0 Purpose, Scope, Implementation Strategy, and General Information

1.1 Purpose of This Implementation Guide 1.2 Scope of This Implementation Guide Is Identification Only 1.3 Purposes of the Health Identification Card Specified in this Implementation Guide 1.4 Economic Benefit of a Machine-Readable Card 1.5 Economic Strategy to Achieve Industry Implementation 1.6 This Implementation Guide and the Underlying Standard are Voluntary 1.7 This Card is not a National Personal Identification Card 1.8 Conformance 1.9 Where to Obtain Copy of the American National Standard 1.10 Other Implementation Guides for the Standard

2.0 Definitions

3.0 Human-Readable Information 3.1 Format Conventions 3.2 Essential Information Window 3.3 Card Issuer Identifier 3.4 Cardholder Identifier (ID) 3.5 Cardholder Name 3.6 Cards with Names of Dependents 3.7 Accented Characters Permitted in Printed Name only 3.8 Policy Number, Group Number, or Account Number 3.9 Claim Submission Name, Address, and Telephone Numbers 3.10 Card Issue Date 3.11 Other Information

4.0 Combined Benefit Health Identification Cards 4.1 Limitations Imposed by this Implementation Guide 4.2 Exception for Combining Drug Benefits with Other Coverage 4.3 Inclusion of Dependent Names on Combination Cards 4.4 Tradeoffs 4.5 Transition Period

5.0 Health ID Card Usage

6.0 Machine-Readable Information: USS PDF417 2-Dimensional bar Code 6.1 Conformance 6.2 Card Characteristics 6.3 Information Content and Format 6.4 Qualifier Code Values in Situational Data Loop 6.5 Person or Dependent Code 6.6 Card Purpose Code

7.0 Embossing of Health Care Identification Care Information Elements

8.0 Portrait

9.0 Frequently Asked Questions

10.0 Author Group

Attachment A: Algorithm for Card Issuer Identifier Check Digit Attachment B: Why was PDF417 selected for this Implementation Guide?


Health Identification Card Implementation Guide

1.0 PURPOSE, SCOPE, IMPLEMENTATION STRATEGY, GENERAL INFORMATION

1.1 Purpose of This Implementation Guide

The intent of this implementation guide1 is to standardize present practice, to bring uniformity to information, appearance, and technology of over 100 million cards now issued by health care providers, health plans or payers, government programs, and others. See 1.4 for benefits. This implementation guide specifies WEDIs Health Identification Card Implementation of the American National Standard, Identification CardsHealth Care Identification Cards, INCITS 284-2006. INCITS is accredited by ANSI. The standard is an application of International card standards to health care applications in the United States. 1.2 Scope of This Implementation Guide Is Identification Only

The scope of this Implementation Guide is to convey identification information only. The card may identify a medical record, but it does not carry the data content of that record. It does not convey diagnostic, prescriptive, medical encounter, bio-security, non-identifying demographic, or other data about the cardholder. The possible use of a card for such applications, using other technologies in the underlying standard, is outside the scope of this Implementation Guide. See also Section 9.3 about proposals to combine insurance and financial cards. 1.3 Purposes of the Health Identification Card Specified in this Implementation Guide

A health identification card minimally conveys two critical identifications: (i) the card issuer and (ii) the cardholder. It also conveys the purpose of the card and other information. The purpose of the card depends on the type of card issuer and the intended usage of the card.

---------------------------Card Issued By------------------------- Provider Health Plan Other

Card Issuer Identifier2:

National Provider Identifier (NPI) c.f. 3.3.1

Identifier for the health plan or payer authorized as described in 3.3.

Another identifier authorized as described in 3.3.

Cardholder Identifier:

Assigned by the provider, typically the patients Medical Record Number.

Assigned by health plan to identify subscriber or dependent.

Assigned by the card issuer to identify an individual, family, record number, or account according to the purpose of the card.

Cardholder Name:

Name of patient Name of subscriber or dependent; c.f. 3.6

Name corresponding to cardholder identifier.

1 Definition: an Implementation Guide applies a standard to specific application. A standard frequently offers more option or capability than may be needed for the application. This Implementation Guide focuses the health ID card standard to needs of health care providers and health plans or payers for identification. For example, a hospital may issue a card to identify a recurring patient. A payer may issue a card to identify an insurance plan and subscriber. 2 See 3.3 for description of the 80840 prefix also required by the card issuer identifier.



Health Cards Issued by Providers A typical provider-issued card is for identification of the patient who is admitted or treated repeatedly such as for rehabilitation or other treatment. On readmission, the patient presents the card, and accurate identification on the card allows the patient and provider to avoid a full admission process.

Health Cards Issued by Health Plans or Payers The health plan issues a health identification card to a subscriber who presents it to a health care provider to convey with accuracy and clarity the identifying information that the provider needs in order to conduct transactions such as eligibility inquiry and claims.

Health Cards Issued by Other Entities

There may be other entities besides providers and plans that issue health identification cards under this implementation guide. Examples of other entities may include Regional Health Information Organizations (RHIOs), Health Data Banks, Blood Banks, American Red Cross, and others.

1.4 Very Significant Economic Benefit of a Machine-Readable Card

1) For providers. Machine-readable health identification cards eliminate patient and insurance identification errors, reduce the costs and aggravation of rejected claims, reduce lengthy admission processes, and contribute to smoother office procedures and patient satisfaction. The costs of traditional photocopying the front and back of cards, manual data key entry of card information, and filing paper copies are eliminated over time. Machine readable identification cards, integrated with provider systems, will also facilitate immediate automatic transactions such as eligibility inquiries.

2) For health plans. Patient and insurance identification errors significantly increase

processing and service costs for plans; they aggravate providers; and they contribute to member dissatisfaction. Elimination of patient identification errors will benefit health plans as follows: (i) improve subscriber or member satisfaction, (ii) improve employer and plan sponsor satisfaction, (iii) reduce the cost of returning and subsequent reconciling of claims with errors, (iv) reduce the cost of both provider and member help desks and administrative record searches, and (v) improve provider relations. In addition, the universal health plan identifier conveyed by the card assists coordination of benefits.

3) For patients. Elimination of patient and insurance identification errors reduces the

hassle factor and increases patient and member satisfaction. 4) For employers. Elimination of patient and insurance identification errors increases

employee satisfaction with the companys benefit plans and reduces cost of helping employees resolve insurance problems.

5) For clearinghouses. The universal health plan identifier conveyed by the card,

connected with directories, assists all-payer routing without requiring translation of trading-partner specific identifiers.



1.5 Economic Strategy to Achieve Industry Implementation

In order for full value to be realized from cards specified in this implementation guide, two investments must be made:

1) Card Issuers must adopt this implementation guide, especially including the 2-dimensional bar code PDF417 machine readable information. When a card is being issued, the incremental cost to include PDF417 on that card is very low. It is simply printed on the card.

2) Card Users will invest in the systems capability to read and process automatically the

information on a PDF417 card. The investment is reasonable but not minimal. Therefore, it is reasonable for a provider or other card user to desire a large percentage of cards to have PDF417 before justifying the investment.

When the card issuer is a provider, then the provider controls the environment for use of the cards and would determine ROI based on its own operations. When the card issuer is a health plan, then in order for either the plan or the provider to realize the considerable benefits, each must make their respective investment described above. For the plan, the incremental investment to include PDF417 at the time it is issuing cards anyway is minimal. For the provider, the investment is not minimal such that, to be justified, there must be reasonably high frequency of use. Therefore, the first key to success is for health plans to adopt this implementation guide now, especially including PDF417, to be used on their cards as they are being reissued, and in that way to help build a large industry population of PDF417 cards. The second key to success is the earliest possible implementation of an authorized card issuer identifier for health plans or payers as described in Section 3.3. 1.6 This Implementation Guide and the Underlying Standard are Voluntary

The potential benefits to the health care industryto patients, health care providers, and health plans or payersare very significant, especially from uniformity, efficiency, automation, and error elimination; however, conformance is voluntary. There is at present no federal regulation3 to require this Implementation Guide or the underlying standard, INCITS 284-2006. 1.7 This Card is not a National Personal Identification Card

This is not a national ID card. The individual, family, or medical record ID number on the card continues to be the same proprietary identifier that providers, plans, and other card issuers now put on their cards. It does not require a national individual identifier. The cardholder ID has meaning only in context with the card issuer identifier.

3 However, there are certain state regulations requiring the underlying standard or the NCPDP Implementation Guide, which includes the underlying standard by reference, for prescription drug plan identification cards.



1.8 Conformance

An identification card is in conformance with this Implementation Guide if it meets all requirements specified directly or by reference contained in this Implementation Guide and the underlying standard, INCITS 284-2006. 1.9 Where to Obtain Copy of the American National Standard

To implement the specifications in this paper, a card issuer will need both this Implementation Guide and a copy of the underlying standard, INCITS 284-20064, which may be obtained from the American National Standards Institute, Inc. 25 West 43rd Street, New York, NY 10036, or on-line through www.ansi.org. The standard invokes a number of ISO standards by reference. A card issuer may wish to obtain copies of these from ANSI as well; however, typically, a card issuer may choose to rely on its card supplier to ensure compliance with these technical standards. 1.10 Other Implementation Guides for the Standard

The National Council for Prescription Drug Programs (NCPDP) publishes an Implementation Guide that applies the standard to Pharmacy ID Cards. A copy may be obtained from NCPDP, 9240 East Raintree Drive, Scottsdale, AZ 85260, or on-line at www.ncpdp.org. Medicare adopted the NCPDP Implementation Guide for the new Medicare Part-D drug program. 2.0 DEFINITIONS5

health care identification card: card used to identify the card issuer and the cardholder to facilitate health care transactions and to provide input data for such transactions.

card issuer: organization that issues health care identification cards. Card issuers include health care providers, health plans, Medicare, Medicaid state agencies, other government agencies, health insurance companies, third-party administrators, self-administered plans, purchasing cooperatives, employers with multiple payer plans, and others.

cardholder: individual, family, or organization to whom a health care identification card is issued. See 3.6 regarding dependents.

information element: variable data element

numeric: Digits 0 to 9.

special characters: ! " & ' ( ) * + , - . / : = A special character is removed from this category when it is used as a delimiter.

alphanumeric: Uppercase letters from A to Z, numeric characters, space, and special characters. See also accented characters in 3.7.

front side of card: Face of the card carrying visual information containing the card issuer and cardholder identifiers.

back side of card: The opposite face from the front. 4 However, INCITS 284-2006, which is a revision of INCITS 284-1997, may not be publicly available in final form until its expected publication date in 3rd quarter 2006. 5 INCITS 284-2006, 4 Definitions.



3.0 HUMAN-READABLE INFORMATION6

Human-readable information below must show all necessary information such that use of the card encourages but does not depend upon the card being machine read.

Information Element Standard Label Mandatory or Situational* **Location

Card issuer name or logo None required Mandatory Front Side

Card issuer identifier Issuer (80840)

Hospital (80840) or Plan (80840)

Mandatory Front Side

Cardholder identifier ID or RxID Mandatory Front Side

Cardholder identification name

Blank, Name, Subscriber, Sub,

Member, Patient, or Pat

Mandatory Front Side

Dependent name (c.f. 3.6.1)

Dependent Dep, or DepXX (c.f. 3.6.1 and 6.5)

Situational Front Side

below card-holder name

Policy Number, Group Number, or Account (such as provider billing number)

Group, Grp, Policy, Pol,

Account, Acct

Situational, Required when

requisite for identification

Front Side

Service type Svc Type Situational Front Side Care type Care Type Situational Front Side Date of birth DOB Situational Front Side Card issue date Issued Situational Front Side Card expiration date Valid Thru Situational Front Side Name(s) and address(es) such as claims submission address A suitable label Mandatory Back Side

Telephone number(s) and names(s) A suitable label Mandatory Back Side Signature panel A suitable label Situational Back Side Any other data None required Situational Either Side

* Situational data elements are permitted at any time; they are required when necessary for identification. ** Names, addresses, and phone numbers are located on the back side; however if they are variable data, they may be printed on the front side.

3.1 Format Conventions

Variable information. The general design is for variable or personalized data to be on the front side of card, and constant information to be on the back side of the card.

Standard labels. Standard labels are required when the corresponding information element is used. Preprinted labels should be smaller than the corresponding information element. Labels may be above, adjacent to, or below the corresponding information element so long as there is clear association. Recommended font size for standard labels is 7 point or larger. Other information may be smaller font.

Language. Labels and pre-printed information shall be in English. Redundant labels or other information may be in another language.

6 INCITS 284-2006, 6 Human-readable information.



Character set. Except where otherwise specified, information elements are alphanumeric. See 3.7 for note on accented characters in printed names.

Date Format. Human-readable dates shall be mm/dd/yy, mm/yy, mm/dd/ccyy, or mm/ccyy. Date of birth should use 4-digit year.

Physical characteristics. The PDF417 and Embossing technologies specify physical card characteristics by reference. See Sections 6.2 and 7.0 below.

Embedded spaces. Human readable identifiers, such as the card issuer identifier or the cardholder ID, may include embedded spaces or hyphens to assist readability; however, the spaces or hyphens are not included in machine readable information on the card or in electronic transactions. They are not significant for identification.

3.2 Essential Information Window7

The concept of an essential information window is to ensure the critical identification information is uniformly presented while at the same time permitting the highest degree of flexibility for presentation of other information on the card.

There must be a rectangular Essential Information Window with the following information elements, each on a separate line, in sequence of: Card Issuer identifier, Cardholder Identifier, and Cardholder name. No other data may be interspersed between these information elements within the Window. The Window is only a concept; it does not require a visual border. The Window must be justified to a left margin on the front of the card, but it may be located anywhere vertically along the left margin.

Only one Essential Information Window is permitted on a card, and only one card issuer identifier and cardholder identifier may be in the window. Data (as opposed to labels) within the Window should be 8-point font or larger. Larger is encouraged within the limits of space on the card. Boldfaced font is encouraged. Variable pitch is preferable unless embossed.

Illustration of Essential Information Window

7 INCITS 284-2006, 6.3 Essential Information Window.



3.3 Card Issuer Identifier8

The card issuer identifier identifies the health care provider, health plan or payer, government program, or other organization that issued the card. The first five digits of the card issuer identifier, "80840", which is an ISO prefix to indicate health applications (80) in the United States (840), are to be preprinted as part of the standard label as illustrated above. The only valid card issuer identifiers are those assigned within the 80840 number space by an entity authorized under ISO/IEC 7812 authority and procedures. The full card issuer identifier includes the 80840 prefix. 80840 nnnn nnn nnc where: 80840 = the preprinted prefix nnnn nnn nnc = (i) NPI, or (ii) an authorized health plan or payer identifier, or (iii) other authorized identifier; these identifiers include check digit. c = check digit, refer to Attachment A for calculation of the check digit Spaces shown are recommended for readability, but spaces or hyphens shall not be significant identifier characters. Caution: do not use until authorized. The card issuer identifier data element must not be populated until the issuer of the card has been assigned an authorized identifier as described above. Unauthorized use of this data element has serious potential to confuse industry systems and users.

3.3.1 When Card Issuer Is a Health Care Provider

An organizational provider, such as a large hospital, may have a number of NPIs for its subparts and subsidiaries. Choice of which of these several NPIs to use in the card issuer identifier is the option of the provider issuing the card.

When the card issuer is a health care provider, the card issuer identifier consists of the prefix, 80840, followed by the National Provider Identifier (NPI); for example:

80840 1234 567 893 where 1234 567 893 is the providers NPI

3.4 Cardholder Identifier (ID)

Defined by card issuer. The cardholder identifier is defined by the card issuer. Spaces and special characters are permitted for readability but shall not be significant for identification and may be ignored.

Character set. The identifier may contain alphanumeric characters; however, this

guide recommends avoidance of such letters that, when handwritten, may be easily confused with numeric digits such as letters O and I. Spaces and hyphens may be printed but are not significant for identification and may not be included in machine-readable data.

8 INCITS 284-2006, 6.4.1 Card issuer identifier.



3.5 Cardholder Name

The cardholder name shall correspond with the cardholder identifier. The cardholder name must fit on a single line. It must be formatted in sequence of: given names and initials, surname, and name suffix, separated by spaces. Punctuation, such as a period or comma, is discouraged. For example: JOHN Q SMITH JR D MICHAEL JONES JANE E MILLER-SMITH 3.6 Cards with Names of Dependents

Some issuers may include the name of dependents. There are two options for showing dependents:

3.6.1 When Each Dependent has a Separate Card

When a plan issues a separate card for each dependent, the dependents name should appear immediately below the cardholder name as illustrated in 3.2. Such individual cards for dependents are required in some states. For example, if a card is issued to dependent Susan Jones-Smith, and the subscriber is her husband, John Smith, the card would show: Sub JOHN Q SMITH JR DepXX SUSAN B JONES-SMITH (where XX = dependent person code; c.f. 6.5) A card issued to a dependent may carry a cardholder ID number that is the same or different from the ID of the subscriber. This is at the discretion of the issuer.

3.6.2 When all Dependents are listed on Subscribers Card

In other cases, especially on cards for drug coverage, all dependents are listed. Often just the first names are listed. The dependents may be listed with their dependent person code as shown (c.f. 6.3) or not. The dependents may be in columns to the right or below the cardholder name as illustrated below:

Sub JOHN Q SMITH JR Dep 02 SUSAN 03 AMY 04 MIKE 05 NIKOLAI 06 TIM 07 JUDY

3.7 Accented Characters Permitted in Printed Name only

Certain languages use diacritic characters which can have a mark placed over, under, or through a character, usually to indicate a change in phonetic value. These characters are referred to as accented characters. When accented characters are used in a persons name, they have significance to the individual. However, a computer will not treat these characters as equal to their base character. For example, is not the same as A.



Therefore, accented characters are permitted for human-readable names only. Machine readable data should never contain accented characters, and the card issuer should substitute any accented character with its base equivalent in the machine readable data. The originator of any transaction that carries the patients name should take steps to ensure that accented characters are not present within the transaction prior to transmission. Likewise, the processor of the received transaction should take steps to ensure that accented characters are not present in the data used for validation. 3.8 Policy Number, Group Number, or Account

The Policy number, Group number, or Account information element includes the group, plan, policy, contract, certificate, billing, or other account identifier assigned by the card issuer. Policy, Group, or Account numbers are mandatory when this information is required as part of the identification, transaction routing, or claims process. For example, some health plans still require the group number in order to identify the subscriber. These data elements are permitted even if not required for identification. Toward achieving greater simplicity, this implementation guide encourages health plans to discontinue requiring group numbers. 3.9 Claim Submission Name, Address, and Telephone Numbers

This implementation guide recommends that these information elements shall be shown as the lowermost elements on the back side of the card, and labeled appropriately such as Submission of Claims, Eligibility Information, Utilization Review, and Customer Service. 3.10 Card Issue Date

This implementation guide recommends inclusion of the card issue date. When Health ID cards are reissued, patients frequently carry both old and new cards, and a card issue date enables a provider quickly to determine which is the most recent card. The date should be formatted as mm/dd/yy. A card issue date does not imply an effective date of coverage, nor does it imply that a new card will be issued every year.

Issued 04/19/06 3.11 Other Information

After the requirements described above are met, the remaining real estate of the card is available for discretionary information. Examples of such information include: Co-Payments and deductibles Product or plan type (e.g. HMO, POS, EPO, PPO). Preferred Provider Organization or other network name or logo. Third-party administrator name or logo. Instructions for out-of-area benefits Such other as determined by the card issuer.



4.0 COMBINED BENEFIT HEALTH IDENTIFICATION CARDS

Health plans often desire to combine multiple benefits in a single card. For example, a card might combine two or more of the following insurance coverages:

Medical Dental Drug Vision

4.1 Limitations Imposed by this Implementation Guide

The design philosophy for human-readable information in this implementation guide is to simplify. Consequently, this Implementation Guide permits a card to have only one set of identifiersone card issuer identifier, one cardholder identifier, and one group identifierso in order for a card to combine benefits, each coverage must employ the same identifiers. To allow two sets of identifiers on a card would add significant confusion. If there are different destinations for electronic transactions for two benefits on a single card, the design is for the determining logic for the two benefits to be in directories and systems downstream from the card. If such determination cannot be made, then multiple cards must be issued for the multiple benefits. 4.2 Exception for Combining Drug Benefits with Medical Coverage

However, to accommodate widespread current practice, this implementation guide recognizes a transitional exception to enable combination of medical and drug benefits in a single card9.

The medical benefit information is identified in the Essential Information Window (c.f. 3.2). The reason for this is to ensure standard location of information on combined cards.

Drug benefit identifiers may be above, below, or right of the Essential Information Window and should be grouped together just as information in the Essential Information Window is grouped together.

Cardholder ID displayed with the label ID in the Essential Information Window will always represent the medical benefits cardholder ID with respect to human-readable identifiers.

The drug benefits cardholder ID must be clearly labeled as RxID. If one or more drug identifiers differ from the corresponding medical identifiers, the

identical values must be repeated. It is not necessary to repeat cardholder name. For example, if ID and RxID are the same, but there are different values for the group number, then both ID and RxID will be printed on the ID card. Place ID in the medical window and RxID in the pharmacy identifiers grouping. Since the medical policy number and pharmacy group numbers differ, but the member ID and RxID are the same, both ID and RxID, though the same, are printed as illustrated below:

9 The cause for the exception is that a drug ID card currently identifies the drug benefit manager (using a BIN number) instead of identifying the health plan. Without a plan identifier, cardholder IDs from two different medical plans can conflict within the same drug benefit manager; so it is necessary for the IDs used in drug plans in many cases to be made different from the corresponding ID for medical plans.



Illustration of ID and RxID when only Group and RxGroup are Different (Also illustrates PDF417 on Back of Card)

But when the identifiers for each benefit are identical, only the supplemental Rx identifiers must be grouped above, below, or right of the Essential Information Window as shown:

Illustration When Identifiers are Identical (Also illustrates Dependents List and PDF417 on Front of Card)

The above illustration also shows the employer name associated with the group identifier. Employer name may be printed at the issuers discretion. It is not included in machine-readable information. The label for a policy number or group number having the same value must be Group or Grp, rather than Policy, Account or other label. This is a necessary requirement since the NCPDP Pharmacy ID Card Implementation Guide has been nationally adopted with required compliance by legislation in many states. Pharmacy providers do not equate policy or account with group and may result in rejected online claims submissions.

4.3 Inclusion of Dependent Names on Combination Cards

The limited physical space of an ID card makes it difficult to produce a combination ID card containing dependent names unless the machine-readable PDF417 image is printed on the back of the ID card. If (i) the card conforms to the minimum font size requirements in this guide, (ii) the machine-readable PDF417 image is printed on the front of the card, and (iii) the



identifiers are not the same, there would typically not be enough room on the front to print medical and drug benefit information and also multiple dependent names on a single card. In addition, if dependents are included in the PDF417 image, the image would be larger such that there would be less physical space for human-readable information. In this case, the PDF417 image may have to be printed on the back of the card. When dependents are printed on a card, they should be included in the machine-readable data.

4.4 Tradeoffs

The card issuer must decide what is feasible with respect to printing medical and drug benefit combination ID cards. Questions to consider in this analysis include:

Is the issuer able to print variable information on the back of their ID cards such that the PDF417 image could be printed on the back of the ID card?

Could the issuer meet regulatory requirements for certain text or images on the ID card while including all the necessary information for both medical and drug plans?

Is it necessary to print co-payment information? Are dates required for the issuers business application?

Based on industry experience, the table below lists likely scenarios with respect to the number of ID cards printed for a family of seven one cardholder and six dependents.

Printing Scenarios (standard credit card-sized ID card)

Minimum Number of

Cards Combination card including dependents when PDF417 image is printed on back side of card

1

Combination card including dependents when PDF417 image is printed on front side of card

1, but there may not be space

Combination card for each family member 7 Separate medical and drug benefit cards including dependents 2 Separate medical and drug benefit cards for each family member 14

4.5 Transition Period

When an authorized card issuer identifier becomes available as described in 3.3, it will be possible to return fully to the design simplicity of having only one identifier set per card. So it is anticipated that this Implementation Guide will then be modified to repeal the drug plan exception described above for combination cards, because with the health plan instead of the pharmacy benefit manager being identified, differing values for other identifiers will no longer be necessary and will no longer be commonplace. Different transaction destinations will be determined from directories and systems downstream from the card. Such repeal will include an appropriate transition period.



5.0 HEALTH ID CARD USAGE

The purpose of a health identification card depends on the type of card issuer and the intended usage of the card. This section describes two typical uses of a health ID card. 5.1 Patient Admission Card issued by a Health Care Provider such as a Hospital

A hospital or other organization provider frequently issues an admission card to a patient who is admitted or treated repeatedly such as for rehabilitation or other treatment. A provider issues a health ID card to (i) identify the provider and (ii) to identify the patient. A patient presents the card at the time of readmission or treatment, and a good deal of the admissions process can be eliminated, and it enables the provider immediately to locate all relevant medical records.

Notes on the above example:

The card issuer is the provider. The card issuer identifier is 80840 + National Provider Identifier (NPI); that is, the providers NPI in this example is 1234 567 893. (c.f. 3.3.1).

The ID identifies the patient or the patients medical record number. It is an identifier assigned by the provider. (c.f. 3.4)

This illustration is not intended to imply specific placement of situational information. 5.2 Health Insurance Card issued by a Health Plan or Payer

Health plans include Medicare, Medicaid, other government health plans, health insurance companies, self-funded plans, employer group health plans, and other health plans. A health plan issues a health ID card to (i) identify the health plan and (ii) to identify the subscriber. It may identify dependents. It typically conveys other information such as provider network, type of plan (HMO, PPO, etc.), co-pay information, phone numbers, and addresses. Its purpose is to convey the information that a health care provider requires in order to inquire into eligibility and to submit claims. A possible health insurance card might look like:



Notes on the above example:

The card issuer identifier identifies the health plan. (c.f. 3.3) The ID is the subscriber identifier assigned by the health plan. (c.f. 3.4) The card is being issued to a dependent. (c.f. 3.6.1) RxBIN indicates that this is a combined medical & drug card. RxBIN identifies the

pharmacy benefit manager rather than the health plan. (c.f. 4.0); ID and RxID in this example are the same so are not repeated. (c.f. 4.2 first illustration) In this example all variable data elements are printed on the front side of the card. But, other than placement of the Essential Information Window, this illustration is

intended only as a possible example for placement of situational information. The above illustration also shows the employer name associated with the group

identifier. Employer name may be printed at the issuers discretion. It is not included in machine-readable information.

Usage of a health insurance card:

Patient presents card to provider. A health insurance card is the means by which a patient conveys insurance identification to the provider, who will use the information to inquire into eligibility, pre-certify, learn about medical necessity requirements, and submit a claim.

Providers system reads the PDF417 image to obtain the insurance identification. This capability requires enhancement to provider software systems or outsourced services. The economic strategy described in Section 1.5 calls for health plans to begin including the PDF417 image on cards as they reissue them. As increasing percentages of cards have a PDF417 image, vendors will have increased incentive to enhance provider systems to read the image and to generate standard transactions.

Providers system generates standard electronic transactions. When the providers system has obtained the insurance identification, it is in position to generate standard transactions such as eligibility inquiry, pre-certification, claims, and claims attachments. Some transactions, such as eligibility inquiry, may be generated automatically immediately upon the system reading the patients insurance card.

Routing directories and systems. When insurance identification includes a universal health plan identifier, it will be possible for directories to include addressing, protocol, and security information to enable different destinations depending on type of transaction and type of claim.



6.0 MACHINE-READABLE INFORMATION: USS PDF417 2-DIMENSIONAL BAR CODE10

This Implementation Guide requires use of PDF417 2-dimensional bar code technology for machine-readable information. 6.1 Conformance

This Implementation Guide requires conformance with: American National Standard INCITS 284-2006: Identification CardsHealth Care

Identification Cards Uniform Symbology SpecificationPDF417 (USS PDF417). This document may be

ordered from AIM International at www.aimglobal.org. ISO/IEC 15438, Information technologyAutomatic identification and data capture

techniquesBar code symbology specifications PDF417. 6.2 Card Characteristics

This Implementation Guide encourages the physical characteristics of the card to conform to ISO/IEC 7810 (like a charge card) or to ISO/IEC 15457-1, Thin flexible card. However, the card may be printed on paper card stock, such that after normal folding, if any, there is a front side and a back side to the card as defined in the standard.

The PDF417 image shall conform to the specifications in ISO/IEC 15438. The PDF417 image may be located anywhere on either front or back side of the

card.

Illustration of PDF417 Shown on Either Side of Card (not drawn to scale)

10 INCITS 284-2006, 7 Machine-readable information; and Annex B: Mapping of health care identification card information to USS PDF417 2-dimensional bar code.



6.3 Information Content and Format

Information Element Maximum Length Format Mandatory

or Situational* Loop

Repeat Start of Text 1 % Mandatory Format Character 1 "H" Mandatory Card Issuer Identifier 19 Numeric Mandatory

Field Separator 1 ^ Mandatory

Cardholder Identification Number 20 Alphanumeric Mandatory

Field Separator 1 ^ Mandatory Card purpose code (c.f. 6.6) 5 Alphanumeric Mandatory Field Separator 1 ^ Mandatory Reserved Field 1 0 null Mandatory Situational Data Loop: Situational* 0 to 9911 Field Separator 1 ^ Qualifier Code 2 Alphanumeric Qualified Data 30 Alphanumeric End of Text 1 ? Mandatory

* The situational data loop is required if it contains any entry. Length. Maximum number of characters depends on mix of characters, presence of

the situational data loop, level of error correction, and other technical factors. Delimiters. The card issuer must ensure that no data element contains the field

separator character (^ ) or the end of text character (?). Date format. Use ccyymmdd without spaces, slashes, or hyphens. Reserved fields must not be used. Card issuer identifier must be zero-length until the card issuer is assigned an

authorized card issuer identifier as described in 3.3. The card issuer identifier is 15 digits = 80840nnnnnnnnnc, where c is the numeric check digit. The 80840 prefix is always included in the machine readable data element.

Cardholder identifier. The machine-readable cardholder identifier may not include

spaces, hyphens, or other special characters.

Cardholder name. The machine-readable cardholder name may not include accented characters (c.f. 3.7). Accented characters must be replaced by their base character values.

Situational data loop. Each entry, if any, in the situational data loop shall consist of

three elements: a field separator, a qualifier code, and qualified data.

11 The number of iterations is limited by the capacity of the PDF417 bar code.



6.4 Qualifier Code Values in Situational Data Loop

The qualifier code is an external code list, Health Care ID Card Qualifier Code List, which is maintained by the National Council of Prescription Drug Plans (NCPDP). As of the date of publication of this Implementation Guide, the valid code values are as follows; however, more values may be added from time to time. Any one qualifier code value may occur in the situational loop only once.

Qualifier code Occurs Description

Cardholder and Dependent Name, DOB, Gender (see 6.5 for qualifier code explanation) PD, P1-P9 0-1 Person or Dependent Code; c.f. 6.5 FN, F1-F9 0-1 First name or initial; initial is used when space is an issue MI, M1-M9 0-1 Middle name or initial LN, L1-L9 0-1 Last name SF, S1-S9 0-1 Name suffix; e.g. JR, III. DB, D1-D9 0-1 Date of birth of cardholder. Format ccyymmdd GC, G1-G9 0-1 Gender code: 1 = male; 2 = female; null = unknown

Additional Cardholder Identification

GR

0-1 Account or Group number, required if necessary for identification. Account is preferred by providers; Group preferred by plans.

A1 0-1 Address line 1 A2 0-1 Address line 2 CY 0-1 City ST 0-1 State ZP 0-1 Zipcode, 5 or 9 digits

Data for Drug Benefits

RG 0-1 Drug group number; included only if card combines medical and drug coverage and this ID differs from the Group Number (GR) above. If GR is included for the medical plan, but this identifier is null for the drug plan, include RG followed by null data value.

BN 0-1 Drug benefit manager identification number (BIN). PC 0-1 Drug processor control number. RI 0-1 Drug cardholder ID; included only if card combines medical and

drug coverage and this ID differs from the Cardholder Identification Number in the 6.3 table above.

Dates

DI 0-1 Date Card Issued. Format ccyymmdd. Used for version control. DX 0-1 Date Card expires. Format ccyymmdd. DE 0-1 Date benefits became effective. Format ccyymmdd.

Other Data

PP 0-1 Individual NPI of primary care physician PN 0-1 Name of primary care physician



6.5 Person or Dependent Code

The situational data loop is structured to permit the name (first, middle, last, suffix) and other information for the subscriber and up to 9 dependents. The qualifier codes for dependents include a number from 1 to 9. In many cases, that number, 1 to 9, may correspond to the number by which the plans adjudication system identifies the dependent, and no Person or Dependent code is needed. But sometimes it only serves to group related name and other data together for a given dependent, and in that case, the adjudication identifier number for the person is specified by the Person or Dependent code. For example, say the adjudication number for a dependent is 22, then the dependent might be identified by, say, P5, F5, M5, L5, and so forth, and the data value for P5 = 22. If there are more than 9 dependents, an issuer may issue more than one card to the family and use the Person or Dependent code to convey correct adjudication identifiers. Qualifier codes for the subscriber are those that do not contain a number of 1 to 9. The subscriber may also have a Person Code. If there is no Person Code for the subscriber, the adjudication identifier is understood to be zero.

6.6 Card Purpose Code

The card purpose code (c.f. 6.3 table) consists of one or more 1-letter code values to describe the purpose or insurance coverage being identified by the card. The card purpose code is an external code list, Health Care ID Card Purpose Code List, which is maintained by the National Council of Prescription Drug Plans (NCPDP). As of the date of publication of this implementation guide, the valid code values are as follows; however, more values may be added from time to time. Multiple values may be included when more than one purpose code applies; for example, a value of MRV would indicate Medical, RxPrescription, and Vision insurance coverage.

Card Purpose Code Description

A Admission or readmission card issued by a health care provider M Medical Surgical insurance ID card R Rx Prescription drug insurance ID card V Vision insurance card D Dental insurance card



7.0 EMBOSSING OF HEALTH CARE IDENTIFICATION CARE INFORMATION ELEMENTS12

This Implementation Guide permits, but does not require, use of embossing, in conformance with the underlying standard, INCITS 284. Information embossed may include the Essential Information Window, the Group Number, and other information elements on the front side of the card. Refer to INCITS 284 for the specifications for embossing. 8.0 PORTRAIT13

This Implementation Guide permits, but does not require, inclusion of a portrait in conformance with the underlying standard, INCITS 284. The portrait of the cardholder must be of photographic quality in color or black and white. Refer to INCITS 284 for the specifications for portraits. An issuer is cautioned that some states may have privacy restrictions on how a portrait may be required and used.

Illustration with portrait (not drawn to scale)

12 INCITS 284-2006, Annex F: Embossing of health care identification card information elements. 13 INCITS 284-2006, Annex G: Display of card holder portrait on health care identification card.



9.0 FREQUENTLY ASKED QUESTIONS

9.1 Why was PDF417 selected instead of magnetic stripe?

Please refer to Attachment B for the analysis resulting in selection of PDF417.

9.2 May a card issuer also include a magnetic stripe on the card?

This implementation guide requires PDF417 machine-readable technology. Optionally, there are circumstances in which the card may also have a magnetic stripe. The circumstances include: a. During a transition period from existing use of magnetic stripe

This implementation guide is designed to facilitate transition to a common national standard health card. There are some card issuers that currently issue health identification cards with magnetic stripe technology. For example, Medi-Cal publishes on its web site magnetic stripe formats that map required data for the Medi-Cal Benefits Identification Card. Other plans have other formats and other data. This implementation guide permits these magnetic stripes in addition to the PDF417 technology in order to facilitate transition or to support non-health uses of these cards. Placement of the magnetic stripe should be at the top of the back of the card as specified in the underlying standard. Placement of the PDF417 image may be elsewhere on the front or back of the card.

b. In combination with a financial card

See the FAQ 9.3.

9.3 Does the scope include a combined health insurance and financial account card?

It is not the intent of this implementation guide to impede innovation; so it is possible within the specifications here to combine in one card both identification for health insurance and for credit or debit access to a financial account. However, this Implementation Guide specifies only the health identification card aspects of such a combined purpose card.

9.4 Can the card combine medical/surgical, drug, dental, and vision insurance?.

Yes, with certain limitations. Refer to Section 4.0.

9.5 Do some states place additional requirements on health identification cards?

Yes. Some states have legislation or regulations requiring additional information on health identification cards. In some cases, the additional information may be required by a state but is situational in this implementation guide. Each card issuer should be familiar with applicable state requirements.



10.0 AUTHOR GROUP

Peter Barry* Peter T Barry Company [email protected] Alan Gardner* Remettra [email protected] Martin Jensen* Healthcare IT Transition

Group [email protected]

Michael Apfel Truman Medical Center [email protected] J. Robert Barbour Montefiore Medical Center [email protected] Holly Blodgett ASI [email protected] Dale Chamberlain Express Scripts [email protected] Kim Delaney Health Partners [email protected] Gabel Medco Health [email protected] Debra Green Express Scripts [email protected] Wayne Karp R.Ph. Pharmacy Industry

Consultants [email protected]

Patrice Kuppe Allina [email protected] Susan McClacherty Kansas Medicaid MaryKay McDaniel Arizona Medicaid [email protected] Rich McNeil Southcoast Hospitals

Group [email protected]

Karen Phillips California Medicaid Tom Polhemus BCBS of Minnesota [email protected] Gale Scott Tampa General Hospital [email protected] Marge Simos Express Scripts [email protected] Walter Suarez, MD Institute for HIPAA/HIT

Education & Research [email protected]

Teresa Titus-Howard Mid-America Coalition on Health Care

[email protected]

* Co-chairs of WEDI Health ID Card Implementation Guide Group In addition, the authors would like to credit the many individuals who worked to create the underlying standard, especially Tom Keane of Blue Cross Blue Shield of Florida who co-chaired the ASC X12 workgroup with Peter Barry, Joel Ackerman who co-chaired the 1993 WEDI workgroup with Peter Barry, the members of ASC INCITS B10 who wrote the technical specifications, and Harvey Rosenfeld of ANSI who edited the final standard.



Attachment A Algorithm for Card Issuer Identifier Check Digit

Check Digit Formula (Luhn Formula with 80840 Prefix Adjustment) 1. The 10-digit number after the 80840 prefix consists of a root number and a check digit: 1234 567 89C where: 123456789 = root number C = check digit, which is the 10th digit Spaces or hyphens, if any, are not significant 2. Double the value of alternate digits beginning with the first right-hand (low order) digit of

the root number. 3. Add all the individual digits of the root. If one of the products obtained in step 2 consists

of 2 digits, add those digits into the sum. For example, the digit 7 doubled = 14; so add 1 + 4.

4. Add 24 to the result to account for the 80840 prefix. 5. Subtract the sum from the next higher number ending in 0. This is the same as

calculating the tens complement of the low order digit of the sum. If the sum ends in zero (40, 50, etc.), the check digit is 0.

6. Example. Let the root identifier = 12345 6789C Root Number 1 2 3 4 5 6 7 8 9 Double alternate digits x2 x2 x2 x2 x2 Interim 2 2 6 4 10 6 14 8 18 Sum individual digits 2 + 2 + 6 + 4 + 1 + 0 + 6 + 1 + 4 + 8 + 1 + 8 = 43 Adjustment for prefix +24 Sum 67 Check Digit (Mod 10) Check Digit = 70 67 = 3 7. Alternatively, the calculation may be made on the number when the prefix is included or

inapplicable, in which case the calculation is simply the Luhn formula and the adjustment in 4 is omitted.



Attachment B Why was PDF417 selected for this Implementation Guide?

All health identification cards complying with this implementation guide must have a PDF417 machine-readable image. In addition to PDF417, a card may optionally carry other machine-readable technology as specified in the underlying standard or in a financial card standard. B.0 Summary of the Analysis

Tracks 1, 2, & 3 magnetic stripe have insufficient capacity for a general purpose health identification card standard; the high capacity technologies are not cost justified; and RFID chips pose serious privacy and implementation risk.

So the resulting technology choice is PDF417, which fully meets all requirements. This implementation guide should specify a single, primary technology The same technology should be standard across regions and health care segments. There exists no installed technology that would serve as a foundation upon which to

build a standard. This implementation guide conserves prior investment by allowing transition and dual

use of existing technologies. PDF417 has significant advantages. Consequently, this analysis concludes PDF417

best meets the requirements of this implementation guide. The remainder of this attachment is the detailed analysis resulting in PDF417 selection. B.1 The possible technologies

Selection of a technology is made from the several technology options available in the underlying standard, INCITS 284-2006 Identification CardsHealth Care Identification Cards. The standard contains specifications for the following technologies: B.1.1 PDF417 2-dimensional bar code symbology

PDF417 is a read-only, linear bar code symbology. An image is printed by the same printing methods used to print human-readable identifiers, names, labels, and other information. It may be printed on standard plastic, thin-plastic, or paper cardstock. Printing on thin-plastic or paper cardstock enables printing the mailing or carrying document and the card simultaneously on one 8 x 11 sheet. The PDF417 image may be printed anywhere on the front or back of the card. Printers may be high volume, special card production machines, or they may be simple laser printers, enabling for example a hospital to print readmission cards with the same equipment and at the same time as it prints wristbands. Readers are inexpensive devices attachable to personal computers or other equipment; so machine-reading a card can be integrated into provider systems. Most bar-code readers sold since 2000 are capable of reading PDF417. PDF417 is widely used on drivers licenses, government employee health ID cards, and other applications. So PDF417 is inexpensive to produce, inexpensive to use, and proven. The capacity of a PDF417 image suitable for an identification card is several hundred characters with extensive error correction.



B.1.2 Magnetic Stripe, Tracks 1 & 2

Magnetic Stripe, Tracks 1 & 2, is the most widely used card technology. It is read-only. It is generally encoded on standard plastic but may be encoded on thin-plastic. It is even possible to encode magnetic stripe on a paper cardfor example, this method is used for subway ticketsbut durability is questionable. There are special card production machines that will print human-readable information and encode magnetic stripe information in one process. Printing of the carrying document is a separate step except by high volume, generally off-site equipment. Readers are inexpensive and may be connected to personal computers or other equipment; so machine-reading a card can be integrated into provider systems. All readers now in service are capable of reading Tracks 1 & 2, although software is often locked into the data format of financial cards. So magnetic stripe is more expensive than PDF417 to produce, inexpensive to use, and proven. Track 1 is limited to 79 alphanumeric characters, including control characters. Track 2 is 40 numeric-only characters.

B.1.3 Magnetic Stripe, Tracks 1, 2, & 3

Track 3 carries 113 to 125 5-bit characters, numeric only. With Track 3 a magnetic stripe is about one half inch wide. Track 3 is seldom used at present. It is not known what percentage of card producing equipment is currently capable of producing Track 3, but the percentage is understood to be low. Very few currently installed readers are capable of reading Track 3, probably none in provider locations. As with Tracks 1 & 2, Track 3 requires special card production machines, a separate step for printing the mailing or carrying document except in outsourced high volume sites. Readers are inexpensive and may be connected to personal computers or other equipment; so machine-reading Track 3 could be integrated into provider systems. There is no software currently installed to process the health card data format from Track 3, and there is no installed base of card readers in provider locations.

B.1.4 Integrated Circuit with contacts and without contacts

Integrated circuit (often called a smart card) is a microprocessor imbedded in the card. There are two capability types: programmable and memory-only. There are two interface types: one with electrical contacts and one without electrical contacts such that the card requires only close proximity. The underlying standard specifies use of an integrated circuit as a memory card. It may have read and write capability. It can carry several thousand characters of data. Production costs vary from about $2.50 to $6.00 per card. Readers are somewhat more expensive than for bar code or magnetic stripe.

B.1.5 Optical Memory

The surface of an optical memory card has an appearance similar to a CD-ROM disk except that it is rectangular. An optical memory card can carry hundreds of thousands of characters depending on the amount of space used on the card. It can have read and write capability. Cost to produce is understood to be at the low end of the cost of an integrated circuit card. Readers are somewhat more expensive than bar code or magnetic stripe readers. An optical memory card is usually carried in a protective sleeve, because it is somewhat more vulnerable to damage than other cards.



B.1.6 Radio Frequency Identification (RFID) Chips

Radio Frequency Identification (RFID) is a wireless technology that allows objects to be tagged and tracked. It is being widely applied to inventory routing, control, and theft prevention. RFID tags are included in U.S. Passports. They have high capacity and are inexpensive, currently costing 5 to 10 cents and expected to drop to 1 cent in a few years. An RFID microchip could serve nicely on a health identification card, although it is not one of the technologies specified in the underlying standard. But unlike bar codes, such as PDF417, RFID chips may be read surreptitiously from as far away as 750 feet.14 RFID poses an unacceptable privacy risk for its use on health identification cards. In addition, there may be public objection and legislation that would seriously impede implementation of standard health identification cards if RFID were selected.

B.2 Tracks 1, 2, & 3 Magnetic Stripe are not able to carry Standard Health ID Information

The following table of health ID card data totals space needs without regard to specific format:

Information Element Required Length Card issuer identifier 15 Cardholder ID 20 Card purpose code 5 Cardholder Name (longer name allowed) 35 Group number 15 Cardholder DOB 8 Dependent Name (longer name allowed) 35 Card Issue date 8 Drug benefit manager ID Number (RxBIN) 6 Drug benefit processor control number 15 Drug cardholder ID 15

Subtotal before control characters 177

Control characters 12-16 Total requirement 193

Track 1 capacity alphanumeric 79 Track 2 capacity numeric-only 40 Track 3 capacity numeric-only 107-125

Track 1 does not have enough capacity to support a general purpose health identification card standard. Track 2 has even less capacity and is numeric only. Track 3 is numeric only.

Certain payers may be able to minimize encoded data and combine data between the three tracks to create proprietary cards; however, the result would not be a workable standard that can be used by all health issuers and applications. Consequently, Tracks 1, 2, and 3 are not suitable for the general purpose health ID card standard in this implementation guide. There is also new, higher capacity magnetic stripe technology; however, employing new technology carries significant implementation risk with no advantage from installed base or compatibility with current usage. 14 Consumer Reports, June 2006. Consumer Reports has begun a campaign called Federal Privacy Now calling for greatly increased legislative controls on the use of RFID.



B.3 There should be a single, primary technology.

Early during development of a standard health identification card, a survey of providers, provider participation, and research showed overwhelming demand that the project select a single low cost technology. In the phrasing of providers who stated their requirements to payers, "Don't ask us to implement every medium, choose one, don't come back until you agree on one". Given one technology on every card, a card could then have additional technologies if justified by the application. Note this demand came from health care providers, admitting personnel and physician office representatives, that is, from the primary users of the technology. B.4 The technology should be standard across regions and health care segments.

The question is whether the primary technology should be the same nationally and the same between segments of health care? This question goes to the heart of standardization. If two different regions of the country use different primary technologies, then providers at the boundaries of the regions would have to support multiple technologies, and plans would have to issue different technology cards depending on where subscribers will use them. If, say, government plans used one technology and major health care payers used another technology, then providers would have to support multiple technologies. If medical insurance cards use one technology and drug insurance cards use a different technology, then patients would have to carry two cards or have a card with both technologies. If medical insurance uses one technology, a hospital that issues readmission cards to patients must either use the same technology, which might require special equipment, or it must support readers of both technologies. All these problems are eliminated if the health industry selects a single, primary technology for all regions and industry segments; so the technology should be standard on all health ID cards. B.5 The primary technology should be low cost.

The underlying standard permits PDF417, magnetic stripe, contact integrated circuit, contact-less integrated circuit, and optical memory technologies. The low cost technologies are PDF417 and magnetic stripe. Tracks 1, 2, and 3 magnetic stripe are not capable of carrying the data for standard health ID cards. Integrated circuit and optical memory are capable of carrying thousands of characters, have higher costs to produce, and generally have higher costs to use. The project was not able to justify the higher costs of these technologies for a standard identification card. There is no requirement for the high capacity and expense at present for these technologies. RFID poses serious privacy concerns, and it would risk interference with implementation of the standard. The scope of this Implementation Guide is identification. It is designed to bring uniformity to existing practice, not to try to create new applications; so high capacity within the scope is not justified. If this Implementation Guide were to specify the expensive technologies, the result will be that it will not be implemented. Therefore, the choice of primary technology is PDF417. B.6 Conservation of Prior Investment

An attractive goal would be to conserve prior investment to the extent that is reasonable. There are two approaches to conservation of prior investment:



1) One approach would be to build the standard on a large installed base. However, there

is no installed base that is able to serve as the general foundation for standardization. 2) The second approach is for the standard not to interfere with prior investment. This

implementation guide endeavors to achieve this goal. For example:

Some state Medicaid plans use Track 1 magnetic stripe. These plans may implement this implementation guide with PDF417 on the front of the card and also continue to include a Track 1 and 2 magnetic stripe on the back of the card. This approach enables the plan to conserve its existing investment while moving to the national standard. These plans may treat dual technology as a transition or continue it permanently. Medicaid cards often serve more than health care ID.

There are Federal employee health identification cards that currently use

PDF417 but with different data content and format than specified in this implementation guide. Most of the data content can be mapped to the standard data content specified in this implementation guide. The important missing data element is uniform identification of the health plan. During transition the software to process the machine-readable data can ascertain which data content and format is on the card, and it can process accordingly.

B.7 Detailed Review of Prior Investment

This section reviews other possible elements of prior investment:

There is insignificant technology investment in the cards now in circulation. There are over 100 million health ID cards now in circulation. Only a very small part currently uses any card technology, and what exists is not standard. So there is insignificant investment in existing cards that can be conserved. Introduction of technology on health ID cards will occur as the cards are reissued over time.

Moreover, technology on health ID cards only makes sense when there is a universal card issuer identifier, and when that identifier becomes available, cards will need to be reissued. The exception to this statement are drug cards, which as a temporary measure employ routing codes and a BIN number identifying the pharmacy benefit manager instead of the health plan.

Existing card production investment.

o Most cards carry no technology. For these there is no existing investment in producing technology on a card. Many cards are produced on paper card stock. PDF417 can be printed on paper card stock, thin-plastic, or standard card plastic; magnetic stripe requires either standard thin-plastic or standard plastic cards. So only PDF417 can continue to use all existing media.

o Pharmacy industry adopted PDF417. NCPDP wrote an Implementation Guide

based on the underlying standard, and the standard was revised to meet NCPDP requirements. The NCPDP Implementation Guide specifies PDF417. NCPDP



determined that an industry standard magnetic stripe cannot adequately accommodate the mandatory and situational data elements specified in [the NCPDP] Implementation Guide. A number of pharmacy benefit managers have implemented or are in the process of implementing the NCPDP guide using PDF417 and the data and format specified in the NCPDP guide. This implementation guide has been written to preserve existing implementations of the NCPDP guide.

o Some health plans use magnetic stripe. Investment in the ability to produce

magnetic stripe cards is not affected by a change to PDF417 because the same equipment to produce magnetic stripe cards is capable of printing PDF417 on the front of the card, and magnetic stripe may be continued, at least during transition.

Card readers in provider offices

o Track 1 magnetic stripe readers Many providers have financial card readers in their offices. These will continue to be needed to process credit and debit card payments. However, these readers cannot be used for standard health identification because the capacity of Track 1, data content, and format of bank cards will not support a national standard health identification card. (c.f. B.2) Some of the magnetic stripe card readers are employed for Medicaid and other health identification. They may operate with merchant terminals, but few are integrated into provider systems. A very few can process real-time claims. These usages apply to a small part of health care, they are not standard, and they are not an adequate foundation for all health care identification. The cost of any card reader is low. The real cost is in software to use the information. The financial card readers now installed will continue to be needed for financial transactions; so the investment in them will not be lost.

o Track 3 magnetic stripe readers Track 3 requires a wider magnetic strip on the back of the card. It does not provide adequate capacity. The project does not know of any prior investment in readers or software capable of reading Track 3. It is understood that most magnetic stripe encoding machines are not capable of encoding Track 3. Consequently, there is no prior investment in Track 3 to conserve.

o PDF417 readers Most commercial bar code readers installed after 2000 are capable of reading PDF417 images, although they may require software upgrades.

Prior investment in software applications

o Software for card production. Present systems to produce health identification cards will require change only at the point of preparing the card and mailing. Most of the other system capabilities are unaffected by this change.



Consequently, the main part of existing investment to produce cards is conserved.

o Software for card usage. The primary purpose of a health identification card is

to identify the card issuer and the cardholder. At present, these data elements are usually key-entered into computer applications. There is no application software investment in the industry that would be affected by a decision between PDF417 and Track 3 magnetic stripe.

B.8 PDF417 Fully Meets Requirements

Criteria PDF417 Can use thin-plastic or standard plastic Yes Can use paper card stock Yes Can be printed with an ordinary laser printer Yes Can be printed in same step as printing mailing or carrying document

Yes

Can be produced in real-time in issuers office Yes Organizations adopting the INCITS 284 standard

NCPDP, Medicare Part-D, state legislation

Well accepted, effective, inexpensive to use Yes. Used by state departments of transportation, military, and government for identification.

Cost to produce Low, printed on paper card stock, thin or standard plastic

Data capacity is adequate Yes Can support combined drug and medical card Yes Can support combined financial and health card Yes Can support locally defined magnetic stripe used for other purposes (e.g. Medicaid)

Yes

Therefore, PDF417 has significant advantages. It can fully meet the needs of all health ID card applications; it is just as practical for the lowest volume as for the highest volume applications; it was adopted by the drug industry; and there is a large base of installed bar code readers. Moreover, PDF417 is more compatible with the many bar code operations now in provider locations. There is currently widespread industry effort to apply bar code technology to medical supplies, prescription medications, surgical instruments and implanted devices. The benefits of bar code technology in terms of ROI and quality of care are settled issues. PDF417 is compatible with financial combination cards if such a card would be desired. Consequently, this analysis concludes that PDF417 fully meets the requirements of this implementation guide.

Wed ihealth id card

Documents