National Committee on Vital and Health Statistics (NCVHS)

Subcommittee on Health Data Needs, Standards and Security

Testimony Of:
The Blue Cross and Blue Shield Association
January 22, 1997


Prepared and submitted by:
Frank Pokorny
Manager, Electronic Commerce and National Standards
Blue Cross and Blue Shield Association
676 North St. Clair Street
Chicago, IL 60611
312.440.6223 (voice)
312.440.5674 (fax)
us993fjp@ibmmail.com

Dr. Starfield, members of the Subcommittee and my colleagues in the health care community. Thank you for this opportunity to provide a perspective from the Blue Cross and Blue Shield Association (the "Association"), and the confederation of 62 independent Blue Cross and Blue Shield Plans (the "Plans"), on the administrative simplification provisions contained in the Health Insurance Portability and Accountability Act of 1996 ("HIPAA").

The confederation of Blue Cross and Blue Shield Plans has a continuing interest, and demonstrated success, in implementing standardized and automated processes for the administration of health care benefits and services to our customers. Our customer base includes the provider community, employers, and individuals who are the ultimate recipients of timely, cost-effective and quality health care.

Standardized and automated processes have served the confederation of Plans for several decades, first at the local level between a Plan and its provider and member community, and then at the national level for service to both multi-location employer groups and individual members who may require health care when away from home. For Plan members who are traveling, the Blue Cross and Blue Shield Inter-Plan Teleprocessing system handles over 260,000 claim transactions every day. Across the board, I anticipate that the threshold of one billion electronic claims annuals will be crossed in 1997.

In addition to recognizing the value of internal standards and automation as a tool to manage administrative costs, the Blue Cross and Blue Shield Association and confederation of Plans have been active participants in national standards development activities. The Blue Cross and Blue Shield Association has been a voting member of the National Uniform Billing Committee since its inception in the 1970's and, likewise, is a voting member of the National Uniform Claim Committee as reconstituted in 1995 and in its original structure under the name Uniform Claim Form Task Force.

Both the Association and over one-half the Blue Cross and Blue Shield Plans are voting members of the American National Standards Institute (ANSI) Accredited Standards Committee (ASC) X12. Association and Plan staff are active leaders and participants in development of standard electronic data interchange (EDI) transactions under the auspices of ASCX12's health care task group.

Of particular relevance to the Health Insurance Portability and Accountability Act of 1996 has been the Association's active sponsorship and leadership, since its inception, in the Workgroup for Electronic Data Interchange (WEDI). During the course of WEDI's deliberations, and as captured in its milestone 1992 and 1993 reports, administrative simplification issues and objectives from the national perspective were on the forefront.

WEDI's concerns and recommendations covered the range of administrative issues addressed by the HIPAA: unique health identifiers, standard transactions, code sets, privacy and security. Endorsement of WEDI's recommendations in these areas, and more, was given by the Blue Cross and Blue Shield Association and confederation of Plans in the "EDI White Paper" issued in September 1994.

Since then, we have continued to pursue the objectives stated in the WEDI document that have now been given legislative credence and impetus.

The Subcommittee has asked that a response be given to four questions, and I will do so to the best of my ability at this time. Before doing so I would like to note that as a result of prior contact between the Department of Health and Human Services (the"Department") and the Association's Office of Policy and Representation, arrangements had been made to convene a meeting of representatives from all Blue Cross and Blue Shield Plans to discuss the administrative simplification provisions of the HIPAA, and their effect on Plan operations and practices. The results are to be reported and discussed with the Department.

This meeting is scheduled for tomorrow, January 23, 1997, and the discussion with the Department by the end of this month. I would not presume to speak to the overarching matters that will be conveyed at a later date. However, I am prepared to address the issues contained in the four questions from the perspective of unique health identifiers.

During the past two weeks there has been much discussion within the Blue Cross and Blue Shield confederation of Plans about unique health identifiers as required under the Health Insurance Accountability and Portability Act of 1996. This has been prompted both by growing interest in the legislation among Plans, and as a result of inquiries from both HCFA and WEDI regarding HCFA's proposal for selection of PAYERID and the National Provider Identifier as the national standards.

On January 8-9, 1997 the Association convened a special work group of Blue Cross and Blue Shield Plan and Association staff, representing a number of constituencies that would be affected by the law's requirements for unique health identifiers. This twenty-six person work group represented Plan constituencies that included: provider relations, information systems, electronic data interchange, Medicare, the BlueCard Program (for coverage to Plan members who are out of area), the Federal Employee Program, National Managed Care Programs, and the Association's Office of Policy and Representation.

The work group's rich deliberations have been distilled into a concise and relevant letter to HCFA and WEDI. Wider distribution of this letter to the consulting entities cited in the HIPAA has been anticipated, and the accompanying copy is for the National Committee on Vital and Health Statistics permanent record.

Moving to the first of the four questions that has been posed, we have what I believe are straightforward expectations regarding the results of the Administrative Simplification standards requirements. The outcome should establish a basic set of rules for the exchange of administrative information between distinct entities, in a clear manner that is neither open to interpretation nor burdensome in compliance.

For example, within the HIPAA there is a variable and pervasive level of ambiguity in definitions that can open the door to establishing rules of interchange at a very detailed level. Such ambiguity in, for example, the definition of "health plan" raises great concern that the rules may require application of a national identifier to a specific certificate of coverage offered by an insurer.

This form of micro-management would be burdensome for both the insurer and any administrator of the identifier by virtue of the dynamic number and nature of coverages that are offered in the marketplace. A more positive course in this example would be clearly defining "health plan" as the payer who has responsibility for covering a patient's episode of care.

Question two inquires about concerns the Blue Cross and Blue Shield Association and the confederation of Plans may have about the process being undertaken by the Department to carry out the requirements of the law. If the process is exemplified by the actions being taken by NCVHS and its subcommittees, no concern arises with the apparent goal of soliciting the widest range of commentary from all sectors of the health care community. Indeed, achievement of the HIPAA's overall objectives requires not only the force of law, but also the participation and cooperation of the parties that will be affected.

There is, however, one concern that has arisen during discussions with colleagues both within the Blue Cross and Blue Shield confederation, and with associates in other organizations. That concern is the lack of a clear, overall description of the process and the timetable to be followed that will result in promulgation of the regulations required by the Act.

There is a clear sense of urgency, but aside from HCFA's published timetable for NPI and PAYERID, there is no other information on the street. It would be a counter-productive mistake if an overall process and timetable has been set, but the health care community at large is unaware of it's existence.

The third question, concerning experience with the transactions specified under the HIPAA, is one that I can address indirectly, as the provision of health care and administration of benefits is the province of individual Blue Cross and Blue Shield Plans. I am also confident that this matter will be more fully explored in the meetings to be held between the Association and the Department that I mentioned earlier.

That being said, I can note that Blue Cross and Blue Shield Plans have developed automated processes to administer the transactions specified in the Act in accordance with the needs of their respective markets and their provider, member and employer customers. As conditions and requirements change, Plans respond in the most effective manner possible.

Likewise, inter-Plan programs supported by the Association are continually evolving to meet the needs of the managed care marketplace and promotion of effective preventive and palliative care. Neither Plans nor the Association are static in their efforts to obtain and utilize meaningful administrative and clinical information.

As to the final question: "How can the goal of administrative simplification best be achieved while meeting the business needs of all stakeholders?" There is no simple answer to that question. A partial answer may be to ensure that there is a high degree of sensitivity to the changes that will occur in all parts of the health care community.

Perhaps the following three comments that arose during the special meeting of Plan and Association representatives to discuss the unique health identifiers requirement of the HIPAA may give some dimension to this point.

  1. Clarity of purpose is crucial.
  2. Business needs for the Medicare program are relatively simple and straightforward because Medicare is essentially a single uniform coverage. The private sector programs: are extraordinarily diverse; are heavily focused on managed care; are custom-tailored for many large groups; include "Administrative Services Only" (ASO) contracts; must comply with many non-uniform state laws; and are administered much differently from the federal programs.
  3. In any system, there comes a point where automated processing of unique or very infrequent situations is more costly than handling those situations manually as an "exception." ... Dealing with the exceptions should be viewed as an inherent process in the overall scheme, rather than a major obstacle to adoption of a national identifier.

Let me close by expressing my appreciation of the interest expressed by the Subcommittee in learning of the Blue Cross and Blue Shield Association's views and experiences on administrative simplification in general, and in the context of the HIPAA. Today is but another step along a path that we believe will serve us well as we move to the next millennium.

Thank you very much for you time and attention.

ATTACHMENT TO TESTIMONY --

LETTER FROM THE BLUE CROSS AND BLUE SHIELD ASSOCIATION TO THE WORKGROUP FOR ELECTRONIC DATA INTERCHANGE (WEDI) AND THE HEALTH CARE FINANCING ADMINSTRATION (HCFA)

January 20, 1997

Mr. Gene Carruth
Chairman
Workgroup For Electronic Data Interchange (WEDI)
4515 South Wendler Drive, Suite 103
Tempe, AZ 85282-6411

Mr. Robert Moore
Director of Office Systems Management
Health Care Financing Administration (HCFA)
MS N2-14-17
7500 Security Boulevard
Baltimore, MD 21244-1850

Dear Messrs. Carruth and Moore:

Thank you for your interest in the comments, assembled by the Blue Cross and Blue Shield Association, on proposed unique health identifiers. In response to your request for our consideration of the national identifiers required by the Health Insurance Portability and Accountability Act of 1996 (HIPAA), the Blue Cross and Blue Shield Association convened an ad-hoc work group of Blue Cross and Blue Shield Plan (Plan) staff.

This special group's deliberations analyzed, at length, the concept of national identifiers, and assessed the anticipated effects of the proposed identifiers on work group member Plans' operations. Upon adjournment of the group's two-day meeting, there was clear consensus on two points:

Select concerns and position statements on the general subject of identifiers will follow immediately. Fuller details of our ad hoc work group's discussions on each identifier are in the five attachments to this letter. These attachments contain comments, suggestions and questions that must be addressed in order to effect a successful transition to unique health identifiers as required by the law.

Select Concerns and Position Statements

  1. Lacking full definition of the business purpose for each identifier, our understanding the intended uses of the identifiers is limited. Consequently, the precise effects of the identifier proposals on Blue Cross and Blue Shield Plan businesses and information systems cannot be fully assessed.
  2. We suggest that a full and unambiguous definition of business purpose will delineate the identifiers' multiple business functions. This will enable more precise definition of the national files associated with the identifiers and to establish clear policies for access to and re-release of the information in those files.
  3. It is critical that provisions be made to accommodate identifiers for foreign entities and any other entity outside the scope of the Secretary's mandate Such entities exist in all four categories of identifier cited in the legislation.
  4. We believe that the infrastructure needed to support national identifiers needs, among other things, to address 24 hour response times, maintenance, assurance of accuracy, accountability, auditing, security and anti-fraud measures.
  5. Use of the Social Security Number as the base for the individual identifier and the provider identifier would be as efficient and much less costly than creating a new number.
  6. There should be no prohibition against the use of non-standard identifiers within voluntary or contractual networks, as long as those network users use the standard identifiers for communications outside the network (e.g., Blue Cross and Blue Shield inter-Plan processing).

Please accept these items, and those to follow on the attached pages, as the consensus of the Plans represented on this special work group. These comments convey our thinking and concerns about the identifiers and associated processes, and anticipate that they will be useful in the formulation of the rules to be promulgated.

Again, thank you for providing the confederation of Blue Cross and Blue Shield Plans the opportunity to comment on the unique health identifiers and thereby play a role in shaping the future of administrative simplification in health care. On behalf of the confederation of Plans and the Blue Cross and Blue Shield Association, I look forward to a continuing dialog on the identifiers issues and other areas that will be addressed during the development of regulations required by the administrative simplification provisions of HIPAA.

Please do not hesitate to call upon us with any questions, concerns, or for further clarification of the information contained in this letter or its attachments.

Sincerely,

Patricia E. Monahan
Managing Director
Inter-Plan Teleprocessing Services

cc: D. Coolidge

Attachment To WEDI/HCFA Letter

Blue Cross and Blue Shield Association

Ad-Hoc Work Group On National Identifiers

January 8 and 9, 1997

BACKGROUND

In response to a request from HCFA and WEDI, the Blue Cross and Blue Shield Association convened an ad-hoc work group of member Plan business and technical experts. The work group discussed the issue of national identifiers as called for in the Health Insurance Portability and Accountability Act of 1996 (HIPAA). Comments and position statements that have been captured are presented as representative of the issues and concerns that we believe are common to most Blue Cross and Blue Shield Plans relative to HIPAA.

ISSUES PERTAINING TO ALL UNIQUE HEALTH IDENTIFIERS

Commentary

The role of identifiers in the administration of health care coverage must be understood before designing any identifier. Clarity of purpose is crucial. In its discussion of HIPAA's unique health identifier requirements the work group defined the business functions satisfied by current identifiers, and whose needs continue under any new identifier schema. Most of the examples cited during discussions centered on claims processing, but the issues identified are generically expandable to eligibility, enrollment and the other transactions specified in the legislation.

· Data Files

Business Need: Data files must be supported by a mechanism that assures timeliness (24 hour turnaround for new information) and reliability (quality control), and ensures auditability and addresses anti-fraud issues. Information from the files should be able to be used for any legitimate business purpose including marketing, profiling, compiling member handbooks for health care managed care networks, etc. The entity maintaining such centralized national files must be able to be held accountable for accuracy. File users should be able to download the files periodically rather than run individual transactions (e.g., claims) against the entire national file.

Rationale: Since the ID numbers serve as pointers to central data files, users of those numbers must have appropriate access to the associated data files. Data in the file must be timely and accurate to ensure accurate processing of the associated transactions. Information in the central file must be available for all legitimate business uses in order to avoid having each Plan (or commercial carrier) maintain duplicate data files for marketing, surveying and other standard business purposes. (Note: In the NPI documentation, HCFA proposed to prohibit the use of provider data for marketing purposes.) Periodic downloads are essential to avoid the insupportable traffic volume that would result if each individual transaction had to be run against the central file.

· Foreign Entities

Business Need: Provisions must be made to accommodate identifiers for foreign entities and any other entity outside the scope of the Secretary's mandate (e.g., foreign tourists treated in the U. S., laboratories in Canada or Mexico, foreign-based employers with U. S. work forces, etc.). The need for identifiers for foreign entities to carry a country code or other method of identifying the number as belonging to a foreign entity should be investigated.

Rationale: The health care system participants include providers, payers employers and individuals who are not U. S. companies or residents. All identifier systems must be able to assign valid identifiers for any entity that is a component of the health care information system regardless of residency or other reason.

· Embedded Logic

Business Need: With certain exceptions, "dumb" numbers without intrinsic meaning or codes (except for check digits) should be used rather than numbers with embedded logic.

Rationale: Developing and maintaining a system of "intelligent" numbers is much more complex and expensive than "dumb" numbers. The intelligence of the system should be from the associated data files, not the identifier itself.

· One Family of Administrative Transaction Sets

Business Need: The forthcoming mandates under HIPAA should stay within the confines of the ANSI ASC X12 standards and any modifications to the standards should be made through the X12 amending process rather than through federal government fiat.

Rationale: Using ANSI ASC X12 for all mandated transactions rather than using a combination of X12 and non-X12 transaction will simplify implementation and minimize implementation costs. The X12 transaction sets for health care have been designed to accommodate unique health identifiers as contemplated under the law.

Should the Secretary determine that the ANSI X12N Health Care Claim (837) transaction set is not to be the standard as required under the legislation, then the Blue Cross and Blue Shield Plans support the WEDI recommendation for a dual track of accepting both the National Standard Format (NSF) and the 837 immediately, with a specified sunset date on acceptance of the NSF. This alternative takes into consideration the expense and time requirements of making changes to Plans' information systems.

· Replacement of Current Internal identifiers

Business Need: The objective of national identifiers should be limited to consistency of identifiers used in inter-entity information exchanges.

Rationale: Current computer applications are supported by numerous internal, proprietary identifiers. The value of any requirement to universally substitute national identifiers for proprietary internal identifiers must be cost justified.

ISSUES PERTAINING TO PROVIDER IDENTIFIERS

Commentary

Work group discussion of Blue Cross and Blue Shield Plan needs for provider identification for a given occasion of service established a context for consideration of HIPAA's requirement for a uniform provider identifier, and HCFA's proposed solution (National Provider Identifier, or NPI). The business purposes of a provider identifier include identification of the:

  1. provider who treated the patient/subscriber;
  2. appropriate payee for IRS tax reporting purposes, including any special business arrangements of the provider;
  3. site where service was rendered;
  4. managed care network(s) or program(s) under which the service was provided;
  5. provider type, (e.g., MD, DO, DDS, PharmD, RN, DME, etc.);
  6. provider characteristics, (e.g., board certifications or specialties); and
  7. accessing the Provider Profile to check for sanctions, etc.

Discussion of these business needs prompted the following concerns and position statements.

· Functionalities Within the Provider Identifier

Business Need: The identifier itself should be essentially a "dumb" number that uniquely identifiers a provider and then points to an associated data file about that provider in the National Provider System (or elsewhere). All other functionalities must be in the associated file or in the standard transaction set.

Rationale: Review of the NPI documents from HCFA indicates that the above noted functionalities 1 and 3 will be incorporated into the NPI, although inclusion of 3 is not explicitly stated in the documentation. The real intelligence of the national identifier system is in the associated data files rather than in the identifier itself. Trying to build too many functionalities into the number itself will not meet the efficiency goals of the legislation.

· Downloading Associated Data Files Essential

Business Need: When the ID points to the associated National Provider System file, Blue Cross Blue Shield Plans and other payers should be able to periodically download the file in order to run claims (or other transactions) against it rather than run each claim against the central file itself.

Rationale: Running each claim against the national file would generate an insupportable volume of traffic on the system and cause delays in processing.

· Role of Identifiers Outside the Medicare Program

Business Need: The intended use(s) of the NPI for non-Medicare applications needs to be defined in terms of private sector business requirements.

Rationale: Group discussion concluded that NPI (as well as all other alternatives identified) has no real clarity as to what it can and cannot do outside the Medicare program. HCFA's needs for the Medicare program are relatively simple and straightforward because Medicare is essentially a single uniform coverage. The private sector programs: are extraordinarily diverse; are heavily focused on managed care; are custom-tailored for many large groups; include "Administrative Services Only" (ASO)contracts; must comply with many non-uniform state laws; and are administered much differently from the federal programs.

· Proof of Functionality Before Adoption

Business Need: Before NPI can be adopted as a national standard, it must prove that it meets private sector needs as well as HCFA's.

Rationale: NPI may meet HCFA's business needs, but there is no unambiguous demonstration that NPI meets the private sector's needs. Requiring the private sector to adopt NPI in its present form would not only be a waste of resources, but would fail to meet the intent of the Act.

· Use of Social Security Number as Provider Identifier

Business Need: Creation of NPI or any other new national identification system for providers is neither necessary nor desirable.

Rationale: Although the HCFA NPI documentation states that the Social Security Number (SSN) is "inappropriate" for a national provider ID, the current installed base and current business practices commonly and successfully use the combination of the provider's SSN and Internal Revenue Service Tax Identification Number (TIN) as the provider identifier. Since this practice is already fairly standard across most payers, it would seem that using SSN and TIN as the standard identifier would be equally effective as any newly created identifier but be much less expensive to implement. SSN/TIN could be linked to the NPS files as easily as an NPI-type number.

· Maintenance of National Provider System

Business Need: Maintenance of the NPI's associated National Provider System must meet specific performance standards including accuracy, verification and timeliness.

Rationale: The HCFA documentation is not clear on who is authorized to submit changes to the file. Our interpretation is that multiple payers may submit change information and that providers may also submit changes. There is no clear protocol for this or identification of the dominant maintenance entity. Further, we are concerned that any changes must be verified before entering into the data file, otherwise inadvertent errors (e.g., keying errors or information on the wrong provider) or fraudulent information may enter the file. The "periodic auditing" mentioned in the HCFA documentation does not seem to be sufficient diligence.

· Pay-to and Treating Providers

Business Need: NPI must be able to differentiate between Pay-to provider and Rendering/Treating provider.

Rationale: It does not appear that one number will be able to identify both. Plans must identify pay-to providers for IRS 1099 and other purposes and also be able to identify the treating provider for quality assurance and other purposes.

· Provider Groups and Individual Providers

Business Need: NPI must unambiguously distinguish between the physician group and the treating physician.

Rationale: If the NPI is used for the physician group, there must be a mechanism to tie in the identification of the individual treating physician.

· Accessing the National Provider System File from the Identifier

Business Need: The NPI must give access to the National Provider File.

Rationale: Since the NPI will essentially be a dumb number, it must provide access to the National Provider System files where the information about that provider can be accessed.

· National Practitioner Data Bank Link

Business Need: The NPI or the associated provider data file must be tied to the National Practitioner Data Bank and accessible by Plans.

Rationale: Information about provider sanctions is necessary to the Plans.

· Provider Numbers for Foreign Providers

Business Need: There must be NPI numbers and an assignment mechanism for foreign practitioners.

Rationale: Plans process claims and other transactions from foreign providers both from international coverage and for domestic coverage of individuals treated outside the U. S. Plans must have a valid provider ID for those providers.

· Distinction Between Groups and Organizations

Business Need: The distinction between "groups" and "organizations" as proposed by HCFA and the Act must be clarified.

Rationale: Blue Cross and Blue Shield Plans cannot reprogram their processing systems without precise definitions of the terms.

· Providers Not Recognized by Federal Programs

Business Need: NPIs must be available to providers not recognized by federal programs.

Rationale: Blue Cross and Blue Shield Plans may recognize and reimburse providers the federal programs do not (e.g., natural healers). Those providers must have valid provider identifiers.

· Location Suffix

Business Need: The nature and usage of the provider location suffix must be clearly defined.

Rationale: Under the current description of the NPI, the location suffix is neither clearly part of the provider identifier, nor a discreet data element. Clear and consistent usage requires a decision on incorporation of the suffix into the identifier, concatenation of the two elements, or complete separation.

· Medicare Participating Providers

Business Need: Providers are to have a valid national identifier, whether or not a provider is eligible to participate in Medicare or other federal programs. Therefore, there must be a supplemental method to establish Medicare eligibility.

Rationale: Previously, when a provider had a Medicare provider number, it meant they were eligible to participate in the Medicare program. With the NPI that will no longer be true. Provider number assignment will include practitioners that Medicare does not recognize or has sanctioned because those providers can still render services to private sector patients.

· Alphanumeric Identifier

Business Need: There must be a sufficient supply of valid identifier numbers for identification of all providers requiring or desiring enumeration.

Rationale: The group consensus was that the 8 digit alphanumeric number as proposed by HCFA in current NPI working papers has sufficient capacity to enumerate all providers who will be assigned an ID.

· Cross-regional Processing

Business Need: The provider identifier, associated data files and standard transaction sets must supply sufficient information to enable Blue Cross and Blue Shield Plans to process out-of-area claims correctly.

Rationale: The work group was interested in learning how similar Medicare's processing of claims involving out-of-region services is to Blue Cross Blue Shield inter-Plan processing. For instance, if a New York Medicare beneficiary receives treatment in Idaho, how will Medicare use the NPI and PAYERID to assure that proper payment (i.e., the Idaho rate) is made to the Idaho provider, with proper accounting, record keeping, etc. done by the New York Medicare contractor?

ISSUES PERTAINING TO HEALTH PLAN IDENTIFIERS

Commentary

During the course of the work group's deliberations there was a sense that the definition of health plan was markedly broad and all embracing. This was considered evidence that the business needs behind the administrative simplification section of the Act were not fully congruent with those for other sections of the Act (e.g., portability). A major part of the group's deliberation was on the conflicting uses for the payer ID described in the HCFA working papers, the lack of clarity of the legislation, and the apparent discrepancies between the HCFA initiative and the legislative language. Formulation of specific recommendations on design or implementation of the health plan identifier was inhibited, pending clarification of the identifier's scope and usage.

Our work group comments focused almost exclusively on the administrative simplification (i. e., transaction processing) aspects of the legislation. The key business need to be satisfied by the health plan identifier, as identified by the work group, is to uniquely identify the payer or payers who have, or may have, responsibility for covering a patient's episode of care. This includes identification of payers at some specific business unit level and not just a corporate level (e.g., HMO Illinois instead of Blue Cross and Blue Shield of Illinois).

· Identification to What Level of Detail

Business Need: The health plan identifier should be used to identify the financially responsible health plans and should not be used as a very deep level identifier (e.g., should not be used to identify each certificate of insurance issued).

Rationale: Using the health plan identifier as a very deep level identifier would necessitate an inordinate quantity of numbers and would make the issuing and maintenance of the national system too cumbersome to be effective.

· Definitions

Business Need: The terms "payer," "health plan," "carrier," and "issuer" need to be clearly and consistently defined.

Rationale: Clear definitions are essential before the identifier schema can be appropriately configured, and before Blue Cross and Blue Shield Plans can re-program their information systems. Current references in the Act and in HCFA's documentation are unclear and inconsistent.

· National Payer Data Files

Business Need: The data file linked to the payer ID needs to convey to the provider instructions on how to electronically handle a variety of situations involving claims, eligibility, and the other transactions.

Rationale: Those instructions may be other than, and more complex than, simply routing all transactions for that payer to a single electronic (or phone or fax or mail or other) destination. For example, Blue Cross and Blue Shield Plan business policy is, generally, that all claims from a provider should be routed to the local ("host") Plan. The "host" Plan is then responsible for either processing the claim or forwarding it to the "home" Plan. However, eligibility and other transactions not related to a submitted claim do not go to the local Plan. Inter-plan forwarding and settlement can follow one of several different processes. The Payer ID and the associated file must be able to accommodate this.

· Recognition of Blue Cross Blue Shield Payer within PAYERID

Business Need: PAYERID needs to ensure that the payer is somehow easily identifiable as a Blue Cross and Blue Shield Plan. Suggestions include assigning all Blue Cross and Blue Shield Plans a contiguous block of numbers to be administered through the Blue Cross and Blue Shield Association.

Rationale: The Blue Cross and Blue Shield Plans have various contracts involving inter-Plan processing. Transaction submitters must be able to recognize a Blue Cross Blue Shield payer and appropriate route for that transaction. Recognition is important regardless of whether the submitter is highly automated or not. Additionally, recognition of the Blue Cross and Blue Shield is a competitive issue that is clearly protected under the terms of the Act.

· NAIC Co-codes

Business Need: The National Association of Insurance Commissioners (NAIC) Company Codes is in common usage and should be reconsidered as the payer identifier.

Rationale: Many Plans already utilize the NAIC Co-codes as the payer ID, and have based their application systems on this identifier. Use of the NAIC code is also common among clearinghouses. Implementation of a Co-code based identifier could be simpler, quicker and less costly. With an installed base using this number, there is no clear argument against using the NAIC Co-codes as the base for the national identifier.

· Administrative Services Only (ASO) Situations

Business Need: PAYERID must be able to correctly identify the payer for ASO contracts.

Rationale: Many employers are self insured but contract with the Blue Cross Blue Shield Plans to administer those coverages. ASO contracts represent a significant portion of Plan business contracts. If PAYERID is used to denote group plans, it is not clear how it will handle ASO relationships. Employers may change their ASO company without changing their benefit plan. Clear definition of the use of PAYERID, the carrier/TPA's or the employer's, for ASO arrangements is necessary

· Partially Insured Coverage

Business Need: PAYERID must be able to correctly identify the payers and proper routing of claims where coverage contracts split payment obligations between the employer and the Plan (i.e., coverages that are partially self-funded and partially insured products).

Rationale: As proposed, PAYERID does not address situations where the financial responsibility for a claim (other than a reinsurance situation) is split between the employer and a Plan. Claim transaction submitters need to know how to route claims in these situations so that functionality must be built into the PAYERID and associated data files.

Note: This situation has parallels with Coordination of Benefits (COB) processing, where one payer is primary and another is secondary.

· Availability of PAYERID Numbers

Business Need: There must be a sufficient supply of valid identifier numbers, including alphanumerics, for all payers requiring or desiring enumeration.

Rationale: If the PAYERID refers to the entity that issues the check, the PAYERID schema may be sufficient to generate enough unique numbers. However, if the PAYERID is to be used to uniquely identify a group plan or a specific certificate of insurance, it will be unable to generate sufficient numbers by several orders of magnitude. It was suggested that PAYERID consider utilizing alphanumeric characters both to increase the number of available ID's and to allow Plans the flexibility of incorporating existing Plan Codes into the new ID format. (Please note our previous recommendation that PAYERID not be used for deep level identifications.)

ISSUES PERTAINING TO EMPLOYER IDENTIFIERS

Commentary

After discussion, the work group's consensus was that the employer identifier concerns are identical to the health plan identifier concerns over the definition of payer (above) and ASO identification (above). In addition, it was not clear whether the employer identifier would be assigned to all employers, or just those that offer an insured or self-insured health plan.

There are no other comments or position statements on unique identifiers for employers.

ISSUES PERTAINING TO INDIVIDUAL IDENTIFIERS

Commentary

The work group concurred that the intent of the individual identifier should be to identify each and every natural person who has presented themselves to the health care system for either coverage or care. This is nearly 100 per cent of the domestic population; internationally it is not. Further discussion focused on social security number (SSN) versus other possible individual identifiers, and reaffirmation of WEDI's recommendation of SSN as the individual identifier.

· SSN Recommended as Individual Identifier

Business Need: The Social Security Number makes the most sense as a national health care identifier due to its widespread use and established mechanism for assignment.

Rationale: Use of SSN (or a number where SSN is the base number) as the standard individual identifier has the most merit of any alternative that has been suggested. Social Security number is the most ubiquitous identifier in the nation, and the Blue Cross and Blue Shield confederation is already on record accepting the use of SSN as a national identifier. This position, however, recognizes that situations may arise where accommodation of other identifiers would be appropriate. Implementation of SSN would be less costly than other alternatives. Security and confidentiality concerns with SSN are no greater than those for any other national health care identifier.

· Financial Impact of Adopting a National Health Care Identifier

Business Need: The overall financial impact of transitioning to a national health care identifier for individuals must be minimized.

Rationale: There is a cost of creating an infrastructure to issue and maintain a new identifier that would be much greater than modifying and using the existing Social Security Administration infrastructure and adopting SSN as the standard individual identifier. There is major concern with the overall financial impact for every entity that must alter its Information Systems and business processes to adopt SSN: 1) payers (most non-federal payers identify only the subscriber/insured and do not identify all dependents); 2) providers (generally assign their own identifiers to each patient); 3) employers (many human resources systems utilize an employee ID that is tied to much more than just the health care benefits); etc.

· Security and Confidentiality of SSN

Business Need: Security and confidentiality of the Social Security Number must meet both technical and public opinion requirements.

Rationale: There are security and confidentiality concerns with SSN that must be addressed and resolved before SSN can be implemented as the national identifier. These concerns include: 1) the lack of a check digit; 2) existence of duplicate SSNs; and 3) one individual may have more than one SSN. It is noted that the same security and confidentiality concerns with SSN will apply equally or almost equally with any other standard ID chosen.

· Data Entry Accuracy

Business Need: The need for automated checking of Social Security Number data entry accuracy should be balanced between the cost of automation and the cost of the potential errors.

Rationale: While data entry accuracy is a concern and the use of some technology such as a check digit should be considered to prevent inaccurate entry of SSNs, there is no consensus on whether the magnitude of the data accuracy problem with SSN reporting is sufficient to justify the investment in the technology. SSN is commonly used and Plan representatives report no major problems with incorrect SSNs on current claim submissions.

· Persons Without an SSN

Business Need: Rapid issuance of an identification number should be a requirement of the system infrastructure for foreign individuals, newborns and any other persons who present themselves for care and who do not have an national individual identifier number.

Rationale: If an identification number is an essential element of the transactions, there must be an assignment mechanism that is responsive enough to generate identification numbers for all who do not have them.

· Automated vs. Manual Processing of Unusual Events

Business Need: The design of the national system need not ensure absolute perfection of the system. Manual processing of exceptions must be anticipated and accomodated.

Rationale: In any system, there comes a point where automated processing of unique or very infrequent situations is more costly than handling those situations manually as an "exception." The work group suggests that the intended efficiencies of administrative simplification can be achieved with an identifier system that does not have zero exceptions. Dealing with the exceptions should be viewed as an inherent process in the overall scheme, rather than a major obstacle to adoption of a national identifier.