[This Transcript is Unedited]

NATIONAL COMMITTEE ON VITAL AND HEALTH STATISTICS

SUBCOMMITTEE ON STANDARDS

ADMINISTRATION SIMPLIFICATION UNDER THE
PATIENT PROTECTION AND AFFORDABLE CARE ACT
NATIONAL HEALTH PLAN IDENTIFIER AND
OPERATING RULES FOR ELIGIBILITY AND CLAIMS STATUS

July 19, 2010

Hamilton Crowne Plaza Almas Building
1315 K Street, NW
Washington, D.C.

Proceedings by:
CASET Associates, Ltd.
Fairfax, Virginia 22030

P R O C E E D I N G S

Agenda Item: Welcome/Introductions

DR. SUAREZ: Good morning, everyone. My name is Walter Suarez. I’m the
director of health IT for Kaiser Permanente and a member of the National
Committee on Vital Health Statistics and one of the co-chairs of the
Subcommittee on Standards. On behalf of the committee and my other co-chair, we
want to welcome you all to this first hearing in what we expect to be a series
of hearings related to the new provisions on the Affordable Care Act related to
administrative simplification.

Today and tomorrow and Wednesday we are going to focus our attention on the
national health plan identifier. That will be today. Tomorrow we will be
looking at the comments and presentations about the new operating rules that
are called for in the Affordable Care Act. On Wednesday we will devote the time
to our discussions as a committee and subcommittee, and deliberations.

I’ll make a few introductory remarks and then we will go around and do the
introductions and so forth. But I just want to mention that our structure for
the hearings is pretty much the same for both of them. The first part of the
hearing will be a series of proposals that we will be listening to. Then the
second part will be a reaction and perspective, a series of panels from
different sectors of the health-care industry.

We are being broadcast via audio, and so we want to make sure that everybody
who is speaking mentions his or her name as they make comments so that people
on the phone can identify who is addressing the subcommittee.

I want to also express a thank-you to all the testifiers today and tomorrow.
We really appreciate your time, the time you have taken to not only prepare and
organize your remarks and submit, but also the time that you have taken to come
to present your testimony here today. This is probably one of the first times
that we have, in fact, been able to upload and put most of the testimonies —
but not all of them — on the Web, with some significant time available for
people to review them if they wanted to review them before the hearing. We are
now in that venue of trying to make sure that the information is available in
advance of the hearings, and we appreciate having your submissions in time for
that.

Secondly, I want to thank our staff, Lorraine Doo, for her leadership in
organizing this hearing at such short notice. This is truly an amazing effort,
to get all the individuals and all the organizations represented today and
tomorrow to come and testify. We really want to thank Lorraine and Marietta and
the rest of the staff.

We also want to thank our lead consulting person for our project here,
Margret, for her leadership and her expertise in providing us with very, very
important information ahead of the hearing.

With that, I think we are going to move forward with the agenda. We’re going
to start by having people introduce themselves. If you could please state any
conflicts of interest that you are aware of that you want to describe or any
relationship you want to state before the hearing starts, we would appreciate
that. Then we will go into the first set of presentations. We will have Karen
Trudel follow me with her presentation, and then we’ll go to the panel of
presenters for proposals.

Again, I want to state, my name is Walter Suarez, with Kaiser Permanente. I
do want to state that I am a member of the WEDI organization and the WEDI Board
of Directors, one of our testifiers today. I am also involved with the American
Health Insurance Plans Association. I’m also, of course, a member of Kaiser,
employed by Kaiser. There will be some testimony provided by a Kaiser employee
as well. Finally, I want to state that I’m also a member of the Public Health
Data Standard Consortium, its past-president and member of the Board of
Directors, another one of our testifiers today.

I do not believe there are any conflicts with respect to those
presentations. I was not involved in the preparation, discussion, or
development of any of those testimonies. Ultimately, I think there is no
conflict, as I see it, but I wanted to declare that.

DR. WARREN: I’m Judith Warren. I work at the University of Kansas School of
Nursing. I’m co-chair of the subcommittee and member of NCVHS. I have no
conflicts.

MS. DOO: Lorraine Doo, Office of E-Health Standards and Services at CMS,
lead staff to the subcommittee. No conflicts.

DR. SCANLON: Bill Scanlon, National Health Policy Forum, member of the
subcommittee and the committee. No conflicts.

DR. CARR: Justice Carr, Caritas Christi Healthcare, chair of the committee,
member of the subcommittee. No conflicts.

MS. GREENBERG: Good morning. I’m Marjorie Greenberg, from the National
Center for Health Statistics, CDC, and executive secretary to the committee.

MS. TRUDEL: Karen Trudel, CMS, liaison to the full committee.

DR. SORACE: Jim Sorace, ASPE, staff to the committee. No conflicts.

MS. WILLIAMSON: Michelle Williamson, CDC’s National Center for Health
Statistics and staff to the committee.

MS. AMATAYAKUL: Margret/A, Margret/A Consulting, contractor.

DR. FITZMAURICE: Michael Fitzmaurice, Agency for Healthcare Research and
Quality, liaison to the full committee, staff to the Subcommittee on Standards
and the Quality Subcommittee.

DR. SUAREZ: Okay. In the interest of time, we are not going to go with
introductions of the public. Rather, as they will be presenting this morning —
I think most of the people in the public are going to be testifying today — we
will introduce you when your time comes up.

One of the things I want to remind everyone of is that, given the
significant amount of information we are going to process today, we are going
to be keeping a very close watch on the time. We really appreciate your
commitment to stay within the time. We have a few reminder cards about time
remaining as you present, a few warnings. They are high-tech art. We will be
using them as we need to.

With that, I’m going to turn it over to Karen, who will be walking us
through some of the important aspects of the health plan identifier provisions
in the Affordable Care Act and some of the perspectives around the need for
this new set of regulations. Karen?

MS. TRUDEL: Thank you. Good morning.

I’m just going to take a few minutes to walk quickly through the appropriate
sections of the Affordable Care Act and try to provide some context for the
next three days. We are talking about Sections 1104 and 10109. Taken together,
they provide a fairly broad set of additional administrative simplification
provisions, which build on top of the ones from the HIPAA Act of 1996. We are
talking about not just a unique health plan identifier, which is what we are
going to talk about today, but new standards and operating rules, the
requirement that Medicare providers utilize electronic funds transfer; for the
first time, we have a compliance certification requirement for plans, which
will happen in 2013 and 2015, where plans will need to proactively certify that
they are in compliance with all of the appropriate administrative
simplification requirements in place at that time. There also are significant
penalties and the ability for audits. There is a review of some existing
standards and operating rules to determine places where we could add value. The
provision also adopts the ICD-9 to ICD-10 crosswalks.

So it’s fairly comprehensive.

The other thing that the act contains are some extremely aggressive
publication and compliance dates. We do have the ability to do interim final
rulemaking instead of notice and comment rulemaking, which makes this process
somewhat shorter. We are talking about a publication date for the health plan
identifier of August of 2011. The operating rules for the first set of
eligibility and claims status transactions are in July of next year. The EFT
standard requirement is January of 2012. The next set of operating rules is
July of 2012. Operating rules for claims, enrollment, premium payment — the
last bunch — are July of 2014. The operating rules and standards for claims
attachments are also in 2014. These implementation compliance dates range from
October of 2012 all the way through January of 2016. So we are talking about a
very long road, one with a lot of stops along the way. Think about this as a
progression and a process, not as a destination, because it will continue after
this point in time.

Our strategy for executing the Affordable Care Act is to conduct NCVHS
hearings — and this is the first one. We will be looking at industry input
related to the options, the opportunities, the challenges, the costs. What we
are interested in doing is, in a very, very proactive way, getting as much
industry input from as many different parties as we can now. This is crucial
because we will not be doing notice and comment rulemaking, so we need to get
it exactly right the first time. That’s why we are here and you are here, to
help us do that.

We also need to monitor industry participation in the creation and
development of the standards and the operating rules, and we need to make sure
that all of these organizations are collaborating appropriately, that the
consensus process is working, that the processes are inclusive, and that we
have all of the right people in the room. If the right people aren’t in the
room when the standards and the operating rules are being developed, then we
are going to have a much harder job when we get to this point in time. So we
need to make sure that providers are in the room, plans are in the room, that
we have everybody in the room when the standards and operating rules are being
developed.

We are also looking at synergies with other provisions of the Affordable
Care Act. As you know, the Affordable Care Act is — I think it’s even longer
than the meaningful use final rule. It’s very complex. There are a lot of
provisions, and we need to look for areas where these standards and these
processes can actually leverage some other aspects of the act.

We need to develop and implement powerful outreach and education to support
industry efforts. We say this every time we do something. We continue to work
on it. I think we continue to get better. But again, with the short deadlines
and the fact that we are not doing notice and comment rulemaking, this takes on
a lot more significance.

I want to talk a little bit about the drivers here. I was fortunate enough
to be able to listen to some of the staff discussion in hammering out these
provisions.

What was Congress trying to do with these two provisions of the Affordable
Care Act? The first one was that they realized that the industry had already
gone quite a ways in terms of administrative simplification and electronic data
interchange. They were hearing that there was a need to move the ball down the
field, to realize some additional benefits that weren’t there. One example of
that would be the, in some places, abysmally low utilization of electronic
funds transfer, the rather disappointing uptake with the eligibility
transaction. There is a lot of benefit to be mined there. We need to be mindful
that this section of the industry costs are for us to try to reduce. So that’s
what we are doing here.

Standardize the standards: Everybody realized and recognized that there were
standards out there, that there were implementation guides, that they were very
specific, and that there was still a lot of flexibility underneath the
standards. People kept mentioning the issue of companion guides. They wanted to
add to the standards portfolio. We don’t have at this point a standard for
electronic funds transfer, but we’re going to. We didn’t have a standard for
health plan identifier, although there was one in the original legislation. We
just hadn’t gotten to it. So they added that back in and they gave us a due
date.

They have made the rulemaking process more nimble, the whole adoption
process, by providing this interim final rulemaking authority. I think a lot of
people were hearing that this just takes too doggone long, and by the time we
get someplace, we need to be someplace else. We’re never skating to where the
puck is going to be; we’re skating to where the puck was three years ago. So we
need to do something about that.

We need to build on successes and lessons that we have learned, in an
iterative fashion. They didn’t give us all these deadlines at one time, and
they didn’t expect that this was going to be the last time we were going to do
something. The expectation is that we will continue to move, to be evolving.
I’ll probably use the term “leaps” a couple of times. This is a first
leap that we are talking about today. There will be leaps after that, and we
will continue to make progress on that basis.

This is an interesting thing, because Congress actually revised the
statement of purpose that was at the beginning of the administrative
simplification provisions from the original HIPAA legislation. What you see
there, boldface, is what they added. They said to improve the Medicare and
Medicaid program and the efficiency and effectiveness of the health-care system
by encouraging the development of a health information system through the
establishment of uniform standards and requirements — not just standards and
requirements, but uniform standards and requirements — for electronic
transmission of certain health-care information and — new — to reduce the
clerical burden on patients, health-care providers, and health plans.

That’s a really good set of marching orders. I suggest that we kind of keep
this in the back of our minds as a yardstick to look at all of the provisions
and all of the proposals that we are going to be talking about in this hearing
and in all of the subsequent hearings.

They gave us some more hints, in terms of telling us what they thought
standards and operating rules should do:

Enable determination of eligibility and financial responsibility
determination prior to or at the point of care. That’s a good one. That speaks
right to the eligibility query and response transaction.

Be comprehensive.

Require minimal augmentation by paper or communication. We are trying to
get farther away from paper and make these standards and operating rules
self-sufficient.

Timely acknowledgment, response, and status reporting that supports
transparent claims and denial process. That’s going to require a little bit of
thought, because that could mean a lot of different things to a lot of
different people. But what I take away from it is that we are trying to be, in
our standards development, enabling useful communication between providers and
health plans, which is, in my point of view, what “transparent”
means. It means, “Don’t give me a reason code I can’t do anything with.
Give me a reason code that means something.”

Describe all data elements in unambiguous terms conditioned on set values
and prohibit additional conditions. This one, again, if you read it absolutely,
means that there is absolutely no possible ability for any kind of wiggle room
here. That’s going to be difficult to get to. We have to think about how to
make that work over time.

I think the context for these hearings — my suggestion to you all — would
be to use Congress’ guidance to set the context. We are talking about uniform
standards, mitigating ambiguity, reducing need for paper, and moving towards
real efficiencies. Again, I have to bring that word “transparency”
back, because that’s another thing that we are going to be having to look at.

I want to evaluate options in terms of how we can move towards these goals
of moving the ball down the field, minimizing the burden on all players — not
just one set of players, but all the players. If we are doing this right,
everybody will be sort of happy. No one will be deliriously happy and no one
will be very unhappy, but everyone should be pretty happy at the end of the
day. And we want to position the industry for future progress.

What I think these things mean is, in terms of moving the ball down the
field, trying to find the biggest bang for the buck. When I talk about
positioning the industry for future progress, I’m talking about, again, a
series of leaps. We are not going to do it all at one time, but we need to make
sure that every leap we make puts us in a position to jump to the next
steppingstone.

The health plan identifier — just a little bit about this. I’m, frankly,
going into these discussions totally agnostic. I want to hear what you all have
to say. I think the committee members want to hear what you all have to say. So
I’m not going to tell you what I think, because I have no opinion.

We are trying to support the original HIPAA legislation to establish a
unique health plan identifier. When you look back at that, it also says that we
should take into account multiple uses for identifiers. So that’s important.
The complexity here — and I know you all know this — is:

There are a wide variety of health plans, ranging from commercial group
health plans, HMOs, government programs, high-risk pools.

A variety of levels and entity types which could be enumerated. Am I
enumerating Blue Cross/Blue Shield of South Carolina? Am I enumerating one of
their lines of business? Am I enumerating their PDM? Am I enumerating a TPA?

The current use of the standards. What exactly are we trying to make a
plan identifier do for us? What are the business reasons to have one — not
just to have one because Congress said we needed to have one? We need to have
one that works and that saves everybody money. Let’s figure out how that works.

We need to understand the issues and problems that plans and providers
experience — and everybody else   in the absence of a standard
health plan identifier today. We need to understand how any particular proposal
will improve the efficiency and effectiveness, blah, blah, blah. How will it
move the ball down the field? How will it improve transparency?

We need to understand the impact on the industry and ways to assist with the
implementation. Are there pieces of processes and systems that don’t exist that
we would have to invent in order to make something work?

Operating rules: Congress said that these were necessary business rules and
guidelines for the electronic exchange of information that are not defined by a
standard or its implementation specifications. It gives us a lot of room there
to discuss.

The process requirement that Congress put around this was that we want a set
of operating rules, with a goal of uniformity and implementation. The operating
rule developer should be consensus-based, and the rules should reflect
necessary business rules affecting health plans and health-care providers. It
has to be a nonprofit entity. The Secretary needs to think about not just the
operating rules themselves and how well they work and how well they move the
ball down the field, but also who the entity is who is developing the operating
rules and how they actually conduct business. We will be having recommendations
submitted by NCVHS. We will be ensuring consultation with providers.

Again, a leap. The first leap is eligibility and claims status. The second
one is electronic funds transfer and remittance advice. The third is a big
bunch of all of the other ones. The last one is claims attachments.

While there is a requirement that the operating rules be standardized and
that they be interoperable, there is no requirement that one authoring
organization is identified or selected for all the operating rules. We will be
talking tomorrow to a number of organizations that are in the operating-rule
space today. Other authoring organizations may step forward in the future, for
instance, for EFT. Someone who is not involved in the field right now may say,
“Well, I think I can do that.”

Because we are operating with the first leap on such a short timetable,
what’s out there is what we are going to have to look at. We are not going to
be able to give someone a year to go out and establish an organization and
develop operating rules. It’s not going to work that way. We have to look at
what we have now available, and that’s what we will be doing. But in the
future, I can see that there could be a new landscape for developing standards
and operating rules, through stronger collaboration, industry representation,
and more consensus building. We have a lot of organizations — and we will be
hearing from a lot of them tomorrow — that all have a place at this table.
Some of them are beginning to collaborate. Some of them aren’t. It would be
really nice to see more of that in the future. But we will have more
flexibility in the future, because we have a little bit more time when we look
at the second and the third and the fourth leaps.

What I want to talk about, then, is that in the future, as we look at this,
I hope people around the table and in the room are thinking about opportunities
for coalitions. I would be just as happy, and I think everybody would be just
as happy, if the next time we go to do this — the second leap — one group
that is a coalition of all the interested stakeholders comes to the table and
says, “We’ve got it. This is it. This is the operating rule for the
EFT,” or whatever. I think that’s very possible, and I would urge people
listening to think about how to accomplish that.

Thank you.

Any questions?

DR. SUAREZ: Thank you so much, Karen.

Before we go to questions, let me just give a chance to John. I don’t want
to put you in a spot, but, John, if you want to introduce yourself.

MR. HOUSTON: My name is John Houston. I’m a member of NCVHS. I’m actually
one of the chairs of the Privacy, Confidentiality, and Security Subcommittee.
We’re here as representatives from that subcommittee.

DR. SUAREZ: Thanks, John.

Is there anybody on the teleconference, a member of the committee or a
member of our Subcommittee on Standards, on the phone?

DR. GREEN: (via telephone) Hi. This is Larry Green. I’m not in Denver. I’m a
member of the full committee and an eager observer of the subcommittee’s work.
No conflict.

DR. FERRER: (via telephone) Hi, Walter. This is Jorge Ferrer, staff to the
committee. No conflicts.

DR. SUAREZ: Anyone else?

(No response)

Let’s move to the questions to Karen. Is there any question from any of the
committee members to Karen on her remarks?

PARTICIPANT: Just that I thought it was an outstanding job of giving us a
charge from Congress, explaining what Congress meant, and focusing on the task
to be done. Good job, Karen.

DR. SUAREZ: Okay. Thank you.

We will move on with our agenda. The next part of this agenda — and this
will be pretty much the remaining part of the morning through noon today — we
will hear presentations from five different perspectives on the plan
identifier. The idea is that we will spend about half an hour for each of the
individuals. So that’s about two and a half hours for five. Within that, I
expect that we will have a chance at the end of the remarks, within each of the
proposals to ask questions. So I believe your remarks could be within 15 to 20
minutes and then leave about 15 or 10 minutes to the committee for questions.

We’re going to go in the order that we have in the agenda. The first
presentation will be from Jim Daley, from the Blue Cross and Blue Shield
Association and AHIP.

Jim, I don’t know if you have some brief introduction that you want to make
before presenting your testimony.

MR. DALEY: My testimony has a little introduction, but I would like to
disclaim. I am part of WEDI as well. I did work on their testimony, as a health
plan input to it. But I’m speaking today strictly for the plan perspective,
BCBSA and AHIP.

DR. SUAREZ: Great. Thank you. The floor is yours.

Agenda Item: Session A1: Proposals for a national
health plan identifier

Proposal from Health Plans

MR. DALEY: Good morning. As you heard, my name is Jim Daley. I’m director of
IS risk and compliance for BlueCross BlueShield of South Carolina, speaking on
behalf of the Blue Cross and Blue Shield Association, BCBSA, and America’s
Health Insurance Plans, AHIP.

AHIP is the national association representing approximately 1,300 health
insurance plans that provide

coverage to more than 200 million Americans. AHIP’s member health insurance
plans offer a broad range of health insurance products in the commercial
marketplace and also have demonstrated a strong commitment to participation in
public programs.

The Blue Cross and Blue Shield Association is made up of 39 independent,
community based and locally operated Blue Cross and Blue Shield companies that
collectively provide health-care coverage for nearly 100 million –-
one in three –- Americans. BlueCross BlueShield of South Carolina, in
Columbia, South Carolina, is an independent licensee of the Blue Cross and Blue
Shield Association. BlueCross BlueShield of South Carolina comprises more than
30 companies involved in health insurance services, U.S. Department of Defense
health programs, Medicare contracts, and other insurance and employee benefits
services.

On behalf of BCBSA and AHIP I would like to thank you for the opportunity to
provide our comments on the national health plan identifier. Our comments will
focus on the following topics: basic principles, the purpose of the identifier,
enumeration levels, format of the identifier, and other issues and concerns.

Let’s start with the principles.

Health plans strongly support the implementation of the national health plan
identifier. We believe effective implementation will further streamline claims
processing, as well as help advance the implementation of fully electronic
business processes in the claims processing cycle. To fully realize the
benefits of the plan ID, we recommend that the implementation of the national
health plan identifier must be in accordance with some basic principles:

First, the purpose of the health plan identifier must initially be narrow
in scope and focus on identifying where electronic transactions are to be sent.

Second, it should support the objectives of administrative simplification.

Third, administrative procedures associated with the health plan
identifier must be easy to understand and implement.

• Fourth, the health plan identifier should not adversely impact
existing contractual arrangements between any trading partners.

Now on to the purpose. We believe the purpose of the identifier is to
identify entities that fall within the definition of a health plan that are
responsible for administering health-care standard transactions. The Heath plan
identifier is used to determine either where the standard electronic
transactions are to be sent, if the receiver is a health plan, or from where
they came, if the sender is a health plan. This would include the use of
standard transactions for electronic COB processing based on trading partner
agreements.

Other potential uses for a national health plan identifier may include their
use on identification cards, to aid in the auto reconciliation of claims and
claims payments, and in other electronic exchanges of health-care information
outside the scope of HIPAA administrative transactions.

Including additional requirements for those purposes within this rule,
however, will lead to more complexity and greater administrative burden for all
stakeholders. We believe it is critical to keep the health plan identifier
requirements as simple as possible, given the timeframe for the plan ID
adoption and all the other Patient Protection and Affordable Care Act and HIPA-
related changes, such as implementation of the 5010/D.0 standards and ICD-10
codes.

We recommend that the health plan identifier is not linked to specific
reimbursement agreements. While we acknowledge the importance of providers
being able to clearly identify the basis of the reimbursement calculations, we
believe this issue should be addressed either in future versions of the
transaction standards, the TR3 implementation guides, or as part of the
operating rules associated with the eligibility and remittance transactions.
Adding additional complexity to the health plan identifier would result in
significant administrative overhead in order to establish and maintain such
linkage and add to the implementation effort.

While identification of specific fee schedules within the plan ID has been
recommended by some, this is only one reimbursement methodology being used by
health plans today. Health plans are also using payments based on capitation,
pay for performance, and other factors that would need to be considered if the
health plan identifier were to reflect specific reimbursement methodologies.
Additionally, the data required to definitely ascertain this information is not
available on the standard eligibility and benefits request. Even if all the
required data were present, health plans would essentially have to process a
claim-like transaction in order to produce an eligibility and benefits
response, adding to the administrative effort and potentially causing delays or
failures in the response. As a result, requiring the health plan identifier to
incorporate reimbursement methods along with product variations would create a
level of complexity that should not be required within the scope of this rule
by significantly increasing the number of identifiers that would be needed and
adding to the maintenance requirements, as provider affiliation and
reimbursement arrangements change.

Enumeration levels: We believe enumeration should occur at a plan level and
should support the ability to obtain and utilize a more granular identifier
schema when a plan’s business needs require further differentiation to
appropriately route standard electronic transactions. As an example, entity 1
may choose to have all electronic transactions administered through a single
gateway, and therefore would choose to have a single identifier. Entity 2 may
administer electronic transactions for various lines of business or product
lines independently and would choose to obtain multiple identifiers to support
that structure.

For purposes of discussion we would define a line of business as a major
grouping within an entity for which all of the electronic transactions would be
administered in the same way. We do not believe enumeration is needed beyond
the line-of-business or product-line level. In our opinion, further enumeration
would unnecessarily require the assignment of a large number of identifiers,
creating a significant administrative burden to update and maintain. While we
do not believe many plans have a need to enumerate to a line-of-business level,
we support and recommend allowing for the flexibility to do so.

Some BCBSA and AHIP member plans are single-state entities while others are
part of larger multistate corporations. We envision our member plans that only
need to identify at the state level might obtain one health plan identifier.
For member plans that have a need for more granular enumeration, whether due to
multistate-licensed business or due to different business lines, we envision
they will obtain multiple plan identifiers. These alternative approaches are
further defined in Figure 1.

If you look at the picture in your handouts, we see three scenarios for
enumeration. Scenario 1 would be where all electronic transactions administered
are both sent and received at one central location. Only one identifier would
be required for all units and could be assigned to the corporate entity. That
is that one dotted box at the top of the picture, the only plan identifier they
would need.

In scenario 2, each unit would have electronic transactions processed at
unique locations or business units. Each unit would have its own identifier and
the corporate entity would not have an identifier. Those would be those solid
boxes at the second tier down, where you see a Medicare contractor, Medicare
Advantage contractor, maybe a couple of commercial subsidiaries, and perhaps a
TPA. Each would have its own health plan identifier.

Scenario 3 would be a variation of some units using one location and the
others having unique locations. In this scenario one number would be required
for the combination units and separate numbers for the other units. You will
see near the right part of that page that the third-party administrator
actually has two boxes, one below the other. They might have in-state claims
processed at one repricer and perhaps out-of-state would go to a different
repricer, and both of those would require a health plan identifier.

As to the structure of the identifier, the format of the plan ID should
conform to ISO standards — that is, the ANSI INCITS 284 ID card standard,
which is a nine-digit-plus-check-digit ID prefixed by 80840, issued by an
entity registered with ISO. It is our understanding that this is the format
that the National Plan and Provider Enumeration System, NPPES, can support.
Enumeration should not be hierarchical or in an organization with subparts
arrangement. If a plan wishes, for example, to have three plan IDs for three
medical product lines, a higher level medical ID should not be required. The
10 digit numeric identifier, which includes a check digit, must contain no
embedded intelligence that could be parsed apart. We believe that entities that
require more than one identifier should be able, if they so choose, to request
a sequential set of numbers that would enable others to associate the numbers
with a single entity. However, this should not be a requirement.

Since the numbering structure as described is currently being used by health
plans that have implemented the WEDI health ID card implementation guide, we
support grandfathering of those identifiers previously issued and currently
being used for this purpose. This would avoid the need to have cards reissued
because of a change to that number. We are not in favor of using other existing
identifiers for the national plan identifier. Using common numbers currently
being used for completely different purposes could lead to limitations and
restrictions that may hamper achieving the purpose of this identifier.

Additional considerations:

A centralized registry should be used to assign and maintain all health plan
identifiers. The administrator of the registry would validate health plan
information and administer policies and procedures with respect to access and
dissemination of related information.

There should be a single implementation date for all stakeholders. Both AHIP
and BCBSA and their member companies believe that this would be the most
efficient way to implement the national plan identifier. However, a dual use
period should be a consideration if after evaluation it was determined a dual
use period would be beneficial to the industry implementation efforts.

In summary, our recommendations are as follows:

Limit the scope of the plan ID standard to replace currently used
proprietary identifiers with a standard identifier.

Allow enumeration to occur at a level that supports appropriate routing of
standard transactions as determined by the health plan entity.

Support using future operating rules versions of the standards — for
example, the 6020 version of X12 — and implementation guides to address
options to better identify the reimbursement methodology.

Use a standard numeric identifier with no embedded intelligence.

Establish a central registry to assign and maintain all health plan
identifiers.

Consider grandfathering identifiers that conform to the standard
established.

In conclusion, we believe that moving the industry to a national health plan
identifier within the timeframes specified in the Affordable Care Act can be
efficiently and effectively accomplished, providing the purpose of the
identifier is limited to the routing of standard administrative transactions.
Expanding the scope beyond that purpose will add complexity to the enumeration
of health plans and require significant changes to internal systems to meet any
additional requirements. When the industry moved to the national provider
identifier, health plans adjusted their processing to use other means to obtain
information that was previously provided by their legacy numbers. This reduced
the numbering requirements for providers and supported the goals of
administrative simplification. We believe the same should hold true for the
health plan identifier.

We appreciate the opportunity to testify. I would be happy to answer any
questions.

DR. SUAREZ: Thanks so much, Jim.

We are going to turn to questions. Judy, I think you have our first
question.

DR. WARREN: Jim, under your principles, your fourth principle was that the
identifier should not adversely impact existing contractual agreements between
trading partners. Can you give me a couple examples of what might be an adverse
impact?

MR. DALEY: For example, within our state we have certain agreements for the
state health plan. We have FEP, things such as that. And we wouldn’t want to
say that we cannot process that and separate it out now, as a result of a plan
identifier having some sort of a format or restriction that wouldn’t allow us
to segregate those products, those lines of business, things of that nature. We
may have some other agreements with repricers who we work with. If they know we
can’t distinguish those anymore through the plan identifier, that would impact
our ability to operate under those contractual arrangements.

I’m sure there are many others out there. We want to be able to continue
doing business with our trading partners, and certainly our insurers, as we are
today, but do it more efficiently.

DR. WARREN: So help me understand. I’m still a little confused. What you are
really talking about is the granularity of what’s being identified? You don’t
want this identifier to interfere with current business arrangements where you
are not using identifiers currently?

MR. DALEY: We have many identifiers at many levels today. We want the
granularity and the requirements for assigning the plan ID to allow us to
continue to support those business requirements, whatever those are. I’m sure
they vary across all different health plans. But don’t do something that says
you have to change your business, resign contracts, because you can’t do it the
way you are doing it today. This should just make what we are doing more
efficient.

DR. WARREN: Okay, that’s what I needed. Thank you.

DR. SUAREZ: Michael?

DR. FITZMAURICE: I want to follow up on Judy’s question. Does that mean that
if somebody is currently using the health plan number for each given contract
— so you have a different number for each contract — to put a single health
plan identifier would disrupt that business? On the other hand, if you created
another field in a claim form, you could keep your same numbering system and
you could continue doing business. It just wouldn’t be the health plan
identifier; it would be what you used to call the health plan identifier that
is unique to each contract. Would that be okay?

MR. DALEY: That would be okay. A lot of this depends on whether those fields
are present today, whether you can perform that sort of processing. Certainly
in future versions of standards or operating rules, they could be incorporated.
But if you said that in the assignment of the identifier we have to stop all of
that and there’s no way to capture it, that conceivably could be a significant
disruption to some health plans.

DR. FITZMAURICE: Suppose it was said that this field is now used only for
the unique health plan identifier, and not for all of these other contracts?
You would have to find another field or, in the longer term, the standard would
have to create another field for that. Is that what you’re saying?

MR. DALEY: Right. We would have to pursue specifically which arrangements
those are to make sure we didn’t bring the system to its knees.

DR. FITZMAURICE: All right, that’s something for us to consider.

DR. SUAREZ: Marjorie?

MS. GREENBERG: Thank you for your testimony. I have two kind of related
questions.

The first is, I understand that you are recommending some level of
flexibility, depending upon the business needs or way of doing business of
particular plans. But you are at the same time recommending a central registry.
I know there have been proposals in past years about giving some numbers to an
individual plan and then letting them assign them, et cetera. But it’s my
understanding that you are supporting a central registry. Is that correct?

MR. DALEY: Definitely a central registry. The plan would determine whether
we need one, whether we need five, ten, whatever it is.

MS. GREENBERG: And then they would come in and get them.

MR. DALEY: Right, and say, that’s how many we need, and these are the
subsets of our company that those would belong to. Then the registry would
assign those.

MS. GREENBERG: Okay. I also appreciate that you don’t want to add
complexity, particularly in the short timeframe. But do you support having a
database behind the enumeration system, such as we have for the national
provider identifier? I believe that system actually can accommodate the plan as
well. I know you don’t want reimbursement methodologies, but would you see
value to there being any information associated with the number — not embedded
in the number, but associated in the system or database for the plan — that
might provide some information beyond the address and name of the place?

MR. DALEY: I think there should be something out there — we would have to
define what those are — to say, this number equals this commercial Medicare
Advantage plan operating out of the eastern region or something. Something on
that level would be appropriate, so you know what that number is associated
with.

MS. GREENBERG: Some descriptive information, but not specified at this
point.

MR. DALEY: Not way down to all the gory details.

MS. GREENBERG: Okay, thank you. That’s helpful.

DR. SUAREZ: I think Bill was next.

DR. SCANLON: (Off-mic) I’m not quite sure I understand the level of detail
(inaudible) what you are proposing versus what I think of as the longer-run
objective. I think one of the reasons that Karen’s sort of summary of where the
Congress was on (inaudible) quite important that we are here in part because
the simplification didn’t occur, because we didn’t make the investment
initially. We kind of did a little more bare-bones approach, and then people
started adding on information requirements. That really complicates things.

When you talk about having the ID sort of identify where the claim needs to
go to be paid, but then, in response to Judy’s question, you talk about FEHBP
and there are distinctions among their plans — that’s getting closer to kind
of what I would think of as a plan level. I think, when we talk about Medicare
Advantage, we are going to hear this afternoon from CMS about the whole issue
of — when we get to Medicare Advantage, there is the insurer, there is the
plan contract, and then, within the contract, there are the multiple plans,
which are down to the level of geography and benefit structure, et cetera.

I worry that if we don’t sort of think about getting down to that level, we
don’t satisfy the Medicare Advantage needs, we don’t potentially satisfy
Medicaid program needs, we don’t necessarily deal with exchange needs, which we
are creating sort of in 2014, and we will be back in the same position, which
is that we have a plan identifier and we are going to be asking for
supplementary information in order to characterize where this claim is coming
from, because it’s going to be critical for oversight purposes to know where
this claim is coming from. That’s not the reimbursement issue that you
mentioned. It’s much more benefits, network, and basically the block that is
being sold.

I guess I’m sort of at a point of confusion. Why wouldn’t we want to make
the bigger investment now? We are going to have to make it sort of at some
point in the future? Are we going to be making it continuously through
supplements that cause much more administrative burden?

MR. DALEY: I think we are very similar in what we are talking about. That’s
why we say each health plan should determine what’s appropriate for them. A
very simple one may just say it just does one kind of business in one location,
and everything is right. In our company we have multiple subsidiaries. We have
in-network, out-of-network. We have a ton of things. They all come in through
primarily a single EDI gateway, but then they are moved from there to various
parts of our company. We need to be able to move them to the part that is going
to be handling that particular piece of business, which could be a
line-of-business or product-line level. We support getting it down to that
particular granularity. I agree.

DR. SUAREZ: Judy?

DR. WARREN: I just want to follow up on Marjorie’s question. What you are
recommending is that we have a centralized database where someone can come in
and look up the plan and look up their ID, so they could fill out whatever form
or anything that they are doing. Do you have any idea about what kinds of
information should be about the plan? I know we don’t want to get down to
business information, because that should be held private for you. But what
kinds of data should be available in that database for us to look up?

As you think about that answer, are you thinking about the central
repository working the same way as the NPI does?

MR. DALEY: Not being as familiar with NPI, I think the kinds of information
should be the data items that allow you to know who you are talking about —
this is that little unit there that does this kind of business for whatever
products it is — identify that. Names and addresses are great, but those can
change over time. But you need to clearly know the entity you are dealing with
as you do that.

I’m definitely against having any kinds of relationships built into there
that say, this is also a brother of this company or it’s owned by this company.
Those things change over time as companies internally reorganize, mergers and
acquisitions, and you don’t want to have to re-enumerate this every time and go
on with the ID card. It would be a difficult situation to maintain that.

But down to that level of granularity that we agree is appropriate, we
should clearly know that’s who we are talking about, with the information on
that. If there are any other additional items that we feel are appropriate
associated with that, we could put them in there. But many of those are going
to be accommodated through trading partner agreements and things of that
nature, and wouldn’t necessarily have to be in the database.

DR. SUAREZ: Karen?

MS. TRUDEL: Now I’m really confused. What I thought I heard you say in your
testimony was that the enumeration was of a place, the place where all the
transactions are going, no matter what line of business or product or anything.
Now I think I’m hearing something a little bit different. Could you clarify
that?

MR. DALEY: Really, it’s both. I think I used the word “entity.” If
the entity is in more than one location, you would need both of those locations
identified so they could route it to East Coast, West Coast, or whatever
processing facility it might be. But you also need the entity as well. In my
situation, a lot of things would come to Columbia, South Carolina, one place.
You need them broken out according to Medicare, commercial HMO, that kind of
thing as well.

So you would have to look at both of those to determine — and that’s why
the health plan itself should determine how many I really need to get it to the
right granularity for the line of business product level and the number of
locations I have for processing.

DR. SUAREZ: Jim, thank you so much again for the testimony. I do have a
question. It kind of combines all these concepts. I think one of the principles
that you highlight is flexibility. At the same time, health plans have
different levels of complexity, depending on line of business, and different
levels of requirements for how currently they are enumerated. For example, a
health plan might have a commercial line, a Medicaid line, a Medicare Advantage
line. For the commercial, they might need just one number, for the Medicaid
line, perhaps one — or if they are in multiple states, perhaps one for each
state — and then for the Medicare Advantage one, they might have different
numbers as well.

Would the flexibility that you are referring to support all those options?
In that case, a plan would have one commercial number, three Medicaid numbers,
and five Medicare Advantage numbers, let’s say. If that is the situation, if
your concept of flexibility supports that, how would a provider that is seeing
a patient know which number to use when billing, now that the number would be
required to be put in the transaction — if, say, a health plan has eight, nine
different numbers?

So two questions. The first one is, does the concept of flexibility support
that multiplicity of enumeration options based on line of business —
commercial, one number, Medicaid, three, and Medicare Advantage, five, let’s
say.

The second question is, how would a provider be able to figure out which one
to use?

MR. DALEY: If you look at the diagram I put in, it was a very simplistic
model of how my company actually works, with the various lines of business,
with a TPA that has multiple crossing locations. That’s the flexibility we are
talking about. It could vary according to the way the plan is set up and how
they really need to have the information broken out.

How would a provider know that? A couple things. Certainly the ID card would
be important on there. If you have some kind of Medicare ID card or, in our
case, a Blue Choice card or a Blue Cross commercial card, that would help
identify who those are. As the patient enrolls, I’m sure there is other
information they capture as well that identifies who their carrier is.

DR. SUAREZ: In the case where a patient shows up without a card, but just
knows that they are covered by X plan, would you expect that the provider would
be able to use, for example, as Judy was pointing out, the central repository,
whatever it is, to figure out which number to use?

MR. DALEY: That would be difficult. If the patient walked up and said,
“I’ve got some kind of Blue coverage. I forgot what it is — HMO or PPO.
It’s one of those, and it’s in one of those Carolinas,” I don’t think
that’s going to work. There would have to be something, either from the card or
from the patient, to let them know roughly where to go to get that information.
I don’t think that could be captured in the overall registry.

DR. SUAREZ: Okay. The last question.

PARTICIPANT: In your view of flexibility, if I’m a patient, I have my number
on my card. At any given point in time, does that number uniquely map to a
single set of business rules within the insurance company?

MR. DALEY: The plan ID, you’re saying?

PARTICIPANT: The number which we are talking about here for identifying the
plan, yes.

MR. DALEY: I wouldn’t say a single set of business rules. It would get you a
single processing facility location, business unit, and product line. But when
you know the actual company or the plan that person is enrolled in, those
benefits and rules could vary, based on what the arrangement is for that
particular insured plan.

PARTICIPANT: But one number would map —

MR. DALEY: It would get to the right place, but then whether they chose
maternity coverage or not and that kind of stuff, that would be when you go to
the benefits files and —

PARTICIPANT: So in some ways, it’s a pointer to a database that stores the
information as to what the patient actually has. In other words, it’s a pointer
to a database that allows you to resolve which plan they are really, at that
point in time, covered by.

MR. DALEY: I have to be sure what we are talking about. If we enroll as a
plan, that’s not the plan that says you are enrolled under the City Fish Market
benefits plan with Blue Cross. The one that says we are Blue
Cross   that plan ID would to get you to specific benefit levels.
The one that says I’m an employee of City Fish, that would get you to their
benefit levels.

DR. SUAREZ: Thank you, Jim, again —

PARTICIPANT: Walter, could I ask, when a claim comes in, how are we going to
know that you are working for City Fish? Is it going to be within the plan ID
or is it going to be that I’m going to have to send you a second set of
information that I’m working for City Fish?

MR. DALEY: There is an identifier similar to the X12. I’m not really
familiar with the X12. There is also a member ID number. We match up to who
their employer is and then the actual plan they chose. From there, we get to
the specific benefits.

DR. SUAREZ: All right. Thank you again, Jim. Very good testimony.

We are going to move on to our next testifier, Tammy Banks, from the
American Medical Association.

Agenda Item: Proposal from Providers

MS. BANKS: Thank you.

The American Medical Association would like to thank the NCVHS Standards
Subcommittee for the opportunity to present our proposal on the national health
plan identifier, NHPI. This proposal is a result of conversations with industry
partners over the last three years. The proposal is supported by the American
Dental Association, the American Hospital Association, and the Medical Group
Management Association, and consistent with the movement towards the
standardized ID card set forth in the “Swipe It” initiative by MGMA.

The purpose of the national health plan identifier is to achieve Congress’
goal of an automated health-care system that reduces administrative expenses
and maximizes resources committed to keeping patients healthy and healing them
when they are sick. Although the 5010 transactions are a step in the right
direction, in the absence of a robust national health plan identifier as
proposed by the AMA, the 5010 standards will not substantially reduce the
manual processes required today.

The adoption of an NHPI provides an invaluable opportunity to eliminate the
ambiguity that makes health-care transactions so costly today. This ambiguity
stems from the fact that the term “health plan” can mean a host of
different things, ranging from the specific health insurance product an
individual buys to the national company that sells that product, including each
of the intermediaries involved in the multitude of transactions which occur
when administering our third-party payment system.

The increasing complexity of health plan transactions is staggering. In the
early 1990s, identification of the health plan was fairly simple and
straightforward. The ultimate payer, generally an employer or a pension and
welfare fund, contracted with a health insurer to either provide a fully
insured HMO or PPO plan to its employees, or to at least handle the provider
network services and administrative functions associated with its self-insured
plan.

Today, there are numerous entities serving in health plan roles, and many of
these entities provide a variety of services, some overlapping with other
entities. Even national health insurers subcontract with various carved-out
benefit-management companies, such as pharmacy benefit managers, behavioral
health benefit managers, and with preferred provider networks, to augment their
directly contracted networks. Self-insured benefit plans similarly utilize
various different entities to handle various administrative functions. And the
traditional PPO/HMO benefit plan models have been replaced by a wide variety of
different benefit structures, each with different administrative and patient
financial requirements.

A complete health plan enumeration system, coupled with the upcoming
implementation of the 5010 electronic transaction standards, will finally make
it possible to make sense out of the current chaos and enable the automation of
our third-party payment system. By clearly enumerating each of the discrete
attributes of the complex third-party payment process, computers will finally
be able to process transactions that currently require human intervention.

Just think: This slide represents the complexity associated with a single
patient visit. Imagine how exhausting this gets day after day. What if we were
able to remove this hassle and let physicians spend their time with their
patients?

A robust national health plan identifier system could eliminate the
confusion that arises today from the following factors:

Ambiguity tied to the proliferation of administrative intermediaries.
It is common for a self-insured employer’s health benefit plan to contract
with a health insurer to perform administrative services that the health
benefit plan would otherwise perform itself. That health insurer, in turn, very
often subcontracts administrative services to other intermediary entities, such
as PBMs, mental health benefit managers, radiology benefit managers, PPNs
and/or fee negotiating companies to perform various administrative functions
that would otherwise be undertaken by the health insurer in its administrator
role.

The ambiguity arising from multiple provider contracts. An example
is, the average physician practice contracts with 12 different health insurers
simultaneously. Each of these contracts, in turn, requires the physician to
participate in up to five different products, and each of these products may be
tied to a different fee schedule. To add an additional level of ambiguity, many
health-care providers also contract with PPNs, or preferred provider networks,
which in turn rent their networks to self-insured employers or health insurers,
or even other PPNs. As a result, health-care providers who assume they are
out-of network with respect to a patient who presents an ID card with the name
of a health insurer with whom they do not contract may, in fact, be in-network
as a result of a contract with a PPN that has been rented to that health
insurer.

Ambiguity stemming from numerous benefit plan designs. There are
hundreds, if not thousands, of patient-specific benefit plans today. Each of
these benefit plans imposes a different set of requirements for physicians and
other health-care providers to learn and negotiate. There are different
copayments, coinsurance and deductible requirements, some of which may vary
based on the services that are rendered and/or the referral source. There are
also widely varying prior authorization and other rules. There are even
different processes for resolving disputes.

Ambiguity resulting from ERISA preemption. Different rules apply to
health benefit plans that are subject to state insurance laws and those that,
because they are sponsored by self-insured employers, are not.

Ambiguity resulting from the widespread lack of transparency. To
efficiently manage a patient’s care, a health-care provider must know all of
the following:

The identity of the insurance product/benefit plan in force for the specific
patient. This information is necessary to determine the patient’s benefits,
deductible amount, copayment and coinsurance percentage, prior authorization
requirements, and the patient’s in- or out-of-network status. Moreover, it is
not enough to merely identify the product type. For example, the fact that a
standard transaction identifies that a patient has a PPO plan is not specific
enough to identify which PPO plan. Many payers offer numerous PPO products —
PPO Gold, Silver, Bronze, Medicare Advantage Gold — each with varying benefit
levels, patient financial benefit levels, prior authorization requirements, and
other contract requirements.

The identity of the entity that will initially receive the transaction. This
is needed to expedite proper routing of the transaction.

The identity of the entity responsible for administering the health-care
transaction. This information is needed to enable resolution of any issues
concerning the transaction.

Identify the entity that will fund the claim payment, not the payment of the
premium. Clearly identifying when a patient’s benefit plan is funded by a
self-funded employer assists the physician and patient in understanding what
the legal obligation and ramifications are for the provision of the patient’s
medical care. Many physician contracts establish different rules for insured
versus self-funded claims, and many state departments of insurance will only
assist with issues concerning insured claims. Patients also need to know who
holds the fiduciary responsibility to determine medical necessity and benefit
coverage.

The identity of the entity that contracts directly with the health-care
provider. This is needed to establish which contract is in force for the claim.
Oftentimes, there may not be any direct relationship between the contracted fee
schedule and the patient’s specific benefit plan.

The identification of the fee schedule that applies to the claim. This
information is necessary to access the fee schedule applicable to the claim
from the contracting entity to predict the patient’s financial responsibility
prior to or at the time of service and also to enable the physician or other
health-care provider’s practice management system to automatically reconcile
and post the claim payment. This is simply an identifier to access the fee
schedule, not the fee schedule itself nor the pricing and payment rules that
are to be applied to a specific claim.

However, it is rare that all this information is included in the electronic
transactions today. The current lack of clear identification of each of these
attributes adds enormous cost to the health-care system, as all parties are
forced to resolve these ambiguities with manual processes, including telephone
calls, faxes, letters, e-mails and appeals. The single-routing payer ID
typically used today cannot provide the necessary information in most cases. A
routing number is not a health plan identifier. However, we have no obligation
to use an NPI as a routing number, in addition to using the routing numbers in
use today.

Routing of transactions is the least problematic aspect of the electronic
system. Indeed, there are many entities that need routing numbers besides
health plans and those agents, such as subrogation entities.

There are billions of dollars of cost savings associated with a robust
health plan identifier system that does more than just identify where health
plan transactions should be routed.

Based on our investigation and discussions with participants throughout the
system over the last three years, we recommend a national health plan
identifier that clearly identifies the patient’s specific benefit plan, or NHPI
Type 1, and each organization that performs a health plan function in the
health-care electronic standard transactions, NHPI Type 2.

Products could include health insurance product, employee benefit plan, or
other product defining the patient’s coverage. We would recommend that each
separate benefit package would have a separate Type 1 NHPI.

We understand that there are a large number of group health plans. We
believe further investigation is necessary to determine whether it is necessary
to separately enumerate the patient-specific benefit plans that are offered by
each of those group health plans that have purchased health insurance, or
whether it is enough to simply enumerate the specific benefit plans that are
purchased by these group health plans from health insurers. From the provider
perspective, the identity of the employer that paid the health insurance
premiums on behalf of a patient who is covered by a fully insured plan is
generally unnecessary. On the other hand, group numbers identifying these
employer-purchased health insurance benefit plans are available today.

Type 2: Entity that performs a health plan function. Entities to receive an
NHPI would include entities that have responsibility for receiving
standard transactions, administering standard transactions
responsibility for contracting directly with health-care providers, and have
responsibility for funding of the benefit. Each of these entities
would receive only one identifier. If an entity plays more than one role in any
given transaction, that will be indicated by placement of the national health
plan identifier in the appropriate fields in the standard transaction.

Finally, to enable full automation of the eligibility and claim standard
transactions, entities that have responsibility for contracting directly with
health-care providers must also disclose which of the health-care provider’s
contracted fee schedules will apply to the services to be provided to a
particular patient by disclosing on the eligibility-response and
remittance-advice standard transactions an identifier for the specific fee
schedule applicable to the transaction. The AMA recommends this be done with a
fee schedule identifier following a national standard format. To be clear, the
fee schedule identifier is just an identifier that enables the health-care
provider to load the appropriate fee schedule, just as the entity that is
administering the claims transaction must do to price the claim. The AMA is not
proposing, again, that the fee schedules themselves be made public.

With respect to the types of entities that would be required to obtain a
Type 2 NHPI, the AMA proposal adopts an approach very similar to that taken by
CMS in the NPI final rule. In that rule, CMS required covered
health-care provider organizations — e.g., hospital — to obtain Type 2 NPIs
for organizational components that themselves were legally separate covered
health-care providers, even though the health-care organization was already
required to have an NPI. For example, an ambulatory surgery center that is a
separate legal entity from a hospital must obtain its own NPI if it is a
covered health-care provider, even if the ASC is a component of that hospital.
However, CMS did not require, but merely permitted, covered health-care
provider organizations to obtain NPIs for so-called subparts. In contrast to
component-covered health-care providers that are legally distinct from their
overarching organizations, subparts are not separate legal entities from
their larger covered health-care provider organizations. For example, a
psychiatric unit that is not a legal entity distinct from its hospital would
constitute a subpart of that hospital under the NPI final rule. The NPI final
rule would not, therefore, require the hospital to obtain a separate NPI for
that unit. The hospital may, however, obtain an NPI for its psychiatric unit if
the hospital would so choose.

Similarly, under the AMA proposal, organizations performing health plan
functions would not be required to obtain a Type 2 NHPI for any of their
divisions, units, or programs that are not separate legal entities, but they
would be permitted to do so if the entity wished to do so for business reasons.
For example, a health insurer administering claims processing functions
utilizing various processing platforms would not be required to obtain NHPIs
for each of those platforms, so long as those platforms were not legal entities
distinct from the health insurer. But the health insurer would be permitted to
obtain NHPIs for each of those platforms if it chose to do so.

This chart here demonstrates the similarity between the AMA NHPI proposal
and the NPI final rule. Similar to the NHPI, which enumerates physicians and
other health-care providers both as individual professionals and as
organizations, this proposal breaks down the complex third-party payment
process into its discrete attributes and allows for enumeration of each of
those attributes. This will enable the NHPI to be used not just to route
electronic transactions, but also to identify each relevant entity and
patient-specific benefit plan each time they are relevant to a specific
electronic transaction between the trading partners.

The AMA proposal does not take a position on the composition of the NHPI.
This could be a number with or without intelligence and/or could continue the
use of existing identifiers.

We envision a fully automated process for health-care transactions. We
contend that NHPIs can be used with other standard identifiers within the 5010
version of the X12 health-care standard transactions to facilitate automated
transactions and claims-adjudication processes.

To illustrate the concept, we will use the 270/271, in which an employer
contracts with a health insurer to provide a single fully insured plan for its
employees that is entirely administered by the health insurer, which also has
the direct contract with the physician who has provided services.

Step 1: The patient schedules an appointment. The physician submits
an eligibility request.

 

Step Two: The 271 eligibility response in which the single NHPI for the
health insurer would appear in each field in the transaction, denoting each of
the four roles it is performing: the claim routing entity; the funder of
benefit; the claims administrator; and physician contract holder. In addition,
the health insurer would provide the NHPI Type 1 of the patient’s specific
benefit plan, and, associated with its role as the contracting entity, would
provide the fee schedule identifier.

Each entity may receive one or more NHPI numbers, depending on the subparts
it chooses to enumerate, as needed for routing and identification purposes. The
NHPI can be used in any transaction in which it is referenced in the existing
Technical Report type 3 to define any of the roles identified in the
transaction —

DR. SUAREZ: Tammy, we need to wrap up in about four to five minutes. Thank
you.

MS. BANKS: No problem.

In addition, when more than one entity serves in the same role, more than
one NHPI could theoretically be reported on a single 271 transaction, as shown
in this example. You will see that Health Insurer A, serving in the multiple
roles, is placed in each of the different loops in the standard transaction,
which each of these file drawers represents.

With this information, the physician knows where to submit the claim, what
the specific benefit plan is for the patient, whether the patient is in- or
out-of-network, if the claim is self-funded by the employer or fully funded by
a health insurer, allowing the physician to know whether this visit is subject
to the general or commercial agreement to ensure prior authorization and other
requirements and determine what fee schedule will apply.

To look at a more typical transaction, an employer maintains a self-funded
plan and subcontracts with a health insurer to provide the administrative
services for its employees. In turn, the health insurer subcontracts with a PPN
that has the direct contract with the physician who has provided services. The
same steps occur, but what the physician would receive back is a response that
contains the health insurer Type 2 or the claim-routing entity, which would
identify the file cabinet. The health insurer NHPI Type 2 would be indicated
for the claim-routing entity. The employer would appear in the field for the
funder of the benefit, which could be the national employer identifier number.
The health insurer NHPI would again appear in this field for the claims
administrator. The PPN’s NHPI would appear in the field for the entity holding
the direct contract with the physician, along with the fee-schedule identifier,
and the patient’s specific benefit package would also apply.

We also in the testimony have provided a breakdown of the 835.

What I would like to do is skip over to the benefits.

Who benefits from a robust national health plan identifier? Everyone does —
the patients, health-care providers, health insurers, employers, third-party
administrators, provider networks, and government payers. In your testimony,
you will see the bullets that describe the exact value and benefits that arise.

The bottom line is, it’s going to save money by reducing the need for manual
processes to obtain the necessary information and by increasing the number of
claims that are automatically reconciled and posted, without the need for
manual intervention or appeals, which reduces the manual processes across all
stakeholders.

Given the complexity of the third-party payment process, only robust health
plan identification requirements can achieve the types of efficiencies and
significant cost savings to the health-care system that Congress intended to
achieve when it mandated the national identifiers and standard health-care
transactions. Only when physicians and other health-care providers receive
complete, accurate, and transparent information concerning all relevant aspects
of a health-care transaction that is covered by a third-party payer can these
transactions be fully automated.

We believe that the adoption of a robust national health plan identifier
standard for use within the 5010 version of the X12 health-care standard
transactions will achieve this goal in the most expeditious manner.
Historically, waiting for the implementation of a new version of the
transaction is likely to entail extended delays. We cannot afford another
delay, such as the nine years to move from the 4010 to 5010 transactions, to
solve the current problems. While the adoption of an NHPI as we have proposed
would not entirely eliminate manual processes, we believe it would eliminate
their need in 80 to 85 percent of the transactions in which they are currently
required. Thus, the adoption of an NHPI as we have proposed would dramatically
increase the value of electronic transactions to the provider community and
justify the investment necessary to take advantage of them. This increased
automation would lead to significant savings across the health-care industry.
Indeed, studies have indicated that as much as $210 billion could be saved
through standardization and simplification of the health-care billing, payment
and claims reconciliation process.

Thank you for your time.

DR. SUAREZ: Thank you so much, Tammy, for this very detailed proposal.

Let’s turn it to questions from the committee here on location or from
anyone on the phone, members of the subcommittee or the committee. Any
questions?

I’ll jump in. I just wanted to confirm a couple of things that I think I
heard. The first one is, this proposal is consistent with the current 5010
structure or do you believe there is a need to adjust the 5010 structure to
support this?

MS. BANKS: Thank you for the question. We created this proposal based on the
5010. Obviously, there is an urgency to implement and reduce these costs that
are associated with the systems. But that said, obviously the standards bodies
are the ones who can make the appropriate recommendations for the placement of
information within the 5010 standards.

DR. SUAREZ: My second quick question is, is there an expected connection
between what you call NHPI Type 1 and NHPI Type 2? In other words, are there
any defined relationships between the two that will have to be declared in,
say, the registry system, the NPS system, if that’s the one that is used? Or
are they completely separate? For example, with NPI, Type 1s and Type 2s —
people have to connect them in the backend after pulling them up. But the
actual NPS, there isn’t really any link between the two. In this case, do you
see relationships built and required to be declared in the NPS system, if
that’s the one used, between NHPI Type 1 and Type 2?

MS. BANKS: From the provider perspective, we don’t have a position on
enumeration, just that that information needs to come back in the standards. So
if you are asking how the health insurers would program their systems or make
the connection between the specific benefit plan and the information that they
have in their systems, I would have to defer to colleagues here. But from the
physician practice perspective, that information has to come back in the same
standard transaction. So the decision of whether the patient is in-network,
out-of-network, or if there is another underlying contract with the provider,
would need to be made visible.

DR. SUAREZ: But what I mean is, when I’m a health plan and I’m applying for
NHPI Type 1, and then I’m also applying for my NHPI Type 2, in the application
of the Type 1, do I have to declare which Type 2s the Type 1 relates to or are
they completely independent identification numbers?

MS. BANKS: I would defer to the health plans on how they would want to apply
for these numbers. Obviously, as long as there are distinct, separate numbers
between the specific benefit plan and the actual entity itself, the physician
would not have a problem, because that information would come back. But how
they wish to apply for these numbers, that would depend on the enumeration
system and the registry or how that information is housed. So I hate to dictate
a recommendation for another colleague.

DR. SUAREZ: Thanks. Karen and then Judy.

MS. TRUDEL: Identifiers in and of themselves don’t actually do anything.
They just point you to places. I’m assuming that you have made some assumptions
behind the scenes as to what kind of infrastructure is needed to take you to
the place where the information actually is. For instance, you have an
identifier that says what the fee schedule is, but how do you get to actually
see the fee schedule? You have a whole bunch of identifiers that are coming
back on your 271. What information do you need and where do you go to get it to
actually make that do something for the physician?

MS. BANKS: If I can take that question in two different parts, one is for
the entities and the specific patient benefit plan. We would anticipate that
that would be housed in a registry similar to the national physician
identifier. So that information could be compiled in a public manner.

As for the fee-schedule identifier, the way it occurs today is that you
contract with a health insurer preferred provider network and you are supposed
to be given the fee schedule at the time of service. At that time they either
assign a number to the contract or they assign a number to the fee schedule.
All we are asking is that that number be brought back in the standard
transaction so the computers can match it with what is already programmed in
the practice-management system. If by some chance they aren’t able to program
in their practice-management system, they would know what entity to go to. With
some health insurers, you can go, put in your information, and download the fee
schedule from their Web site. So the fee-schedule identifier would be made
public on the standard transaction that is received back, but the physician
would have to go to the entity who actually negotiated that contract and fee
schedule to obtain the actual CPT code and fee that is associated with it on
the fee schedule.

Another confusing part sometimes is that people confuse the contract terms
with the fee schedule. The fee schedule, in our perspective, is just the CPT
code and the allowed amount or the agreed amount for the CPT code. It’s not the
contract terms. It’s just trying to get that building block, so you can
determine what the pricing is for the encounter.

DR. SUAREZ: Thanks. Judy?

DR. WARREN: One of the things that I was struck by in your testimony was
that you kept coming back to –currently we do this with faxes, telephones,
mail, et cetera — so all of our old processes. Now the intent that I got from
your testimony is that you want to move this all online and all computerized.

My question is, if I work in a small clinic or I’m in a one- or two-man
physician office, how do you train me or help me get through all of this and
switch from telephone and fax and talking to a person I know to going all
online? Has that been discussed at all as you get the testimony read?

MS. BANKS: If I can move over to HIPAA compliance and compliance with the
4010 transactions, physicians have been compliant for a long time, for the most
part. The reason is that they have to outsource a lot of those functions to the
billing services, to the clearinghouses. If they don’t submit a compliant
claim, the claim is not going to be received. So there is a strong enticement
in order to send it correctly the first time.

Your question is that information is going to come back. It’s going to be
the clearinghouses, it’s going to be the practice-management systems that are
going to be able to automate the system within the practice-management system.

DR. WARREN: So you are not suggesting that a physician look all this up.

MS. BANKS: No.

DR. WARREN: You are suggesting that his administrative team do this work.

MS. BANKS: What I am suggesting is that this information comes back in an
electronic transaction. This will be able to be computer-read. Right now a lot
of the reasons for the mismatch — if we can just go to the reconciliation, the
top three reasons — one, the fee schedule isn’t being matched. You don’t know
if it’s the Medicare Advantage PPO, the various different PPOs. You don’t know
who the underlying contract holder is, who the provider network is. Sometimes
just identifying the provider network is an amazing amount of time in itself.

All the components of why the match doesn’t occur are the attributes that we
are trying to get identified so the computer can actually automate and process
this, and you only have to deal with exceptions. If we can just deal with
exceptions, that would free up the time in order to do what physicians want to
do in the first place, and that’s treat patients.

DR. WARREN: But that’s what is confusing me. You are saying it will free up
physician time. Yet what you are telling me is that these other places are
doing the work.

PARTICIPANT: I was following on both lines as well. In your picture, it
alluded to the fact that — and, actually, in Karen’s early advice — reduce
the clerical burden on patients, health-care providers, and health plans. In
that picture, it looked like the physician or provider was wondering, does this
patient have a prescription drug benefit? Is this tier 1 or tier 2? If I
prescribe any kind of intervention, will the patient be able to afford it or
are they covered for it?

That is what I was thinking about in terms of the physician piece. What Judy
was talking about was the back office piece of pushing things through. Could
you clarify that?

MS. BANKS: Exactly, and you’re right. You always have the front and the
back, and each of them is looking at these standards for different reasons. But
when you do an eligibility verification — and you can do it at the time of
service or even before the patient arrives — you can have a lot of these
questions answered, so you don’t have to wonder, where do I go to do the prior
authorization? Some of these transactions don’t even work. Then where do I need
to call? Or I go to the website and then that’s extra time to figure out, do I
need prior authorization for this service? If I do, then they don’t necessarily
have the phone call where I have to call. That’s just prior authorization.

But again, any way that we can automate it so the computer pulls up this
information so that we have it in advance — we see eligibility as being
critical to be performed prior to the patient even coming into the office, so
you have those answers before the patient visit even occurs. If prior
authorization needs to occur, you already know where you need to go. Hopefully,
your practice-management system — you can send a prior authorization that will
come back with a meaningful response. Right now, unfortunately, a yes/no
doesn’t quite cut it. But we’ll get there, right?

With the back office, as these claims come back and they don’t auto post —
and the reasons for that auto posting — we have done a big study on that for
the past three years that we are happy to share with the committee  – are
not being able to pull the right fee schedule and making a match there, not
knowing that the provider network is involved, not knowing if it’s in or out of
network. It doesn’t have the information so that when the standard transaction
comes in, it meets with the information in your practice-management system,
billing system, clearinghouse, and then auto-posts, so you only have to deal
with those that may have a payment error on them.

That’s what we are trying to do. We have to get rid of the workarounds, if
it’s not working. If we can get this so that it works in a standardized,
transparent fashion, we will be able to reduce the costs for everybody. Who do
those calls go to? They go to the health insurers. They go to the provider
networks. They go to the formularies. All this manual stuff is very
time-intensive.

PARTICIPANT: Just a follow-on. I’m just curious, in your study, have you
quantified the number of calls, faxes, et cetera, that go on in an average
encounter?

MS. BANKS: I’m so glad you asked that. MGMA did a survey of their
administrators. They are going to be giving a response on the administrator
perspective on these issues in their reactor panel. So they will come up and
give you clear-cut examples on that.

DR. SUAREZ: I do have one other question. One of the challenges of driving
granularity into the number is the chance of changes happening in the market
and the issue that, while this number was applicable two weeks ago, it doesn’t
apply anymore because it doesn’t exist. If we go down to the level of
granularity, for example, of enumerating fee schedules, how often do you see
that having to change? What are the challenges of having to re-enumerate it or
change a different number? How does that get handled?

MS. BANKS: I can take that in two parts. One is, all the information that we
are asking to be enumerated, all the attributes, they are already in existence
today. Health insurers need to use them to adjudicate the claim. There are
numbers out there. It just depends on how you want to enumerate them and how
you want to identify them. It’s not just keeping them in the adjudication
system, but making them transparent so that it can also be reconciled on the
physician side as well.

The second point is, with the fee schedule, how many times does a physician
renegotiate or re-contract that fee schedule, max, on a yearly basis? Very
rarely will it occur on a yearly basis. But the point is, it’s still the
interaction between the contracting entity and the physician. So if that would
occur on an annual basis — which is, fortunately, much more frequent than it
occurs  that number can be exchanged in the transaction with the
physician. It doesn’t necessarily need to be on a registry or need to be
anywhere other than coming back in the standard transaction, so it can
auto-reconcile in the practice-management system.

DR. SUAREZ: Bill.

DR. SCANLON: On this issue of granularity, the way I interpreted what you
are saying is that you really want this identifier to be a pointer, a pointer
to information, and you want it to be granular enough so that it’s a unique
pointer, so that it gets you to all the right information, which can be
changing at any interval that occurs. It’s not important. The identifier
remains unique in terms of its pointing ability to those other sets of
information. Is that essentially it?

MS. BANKS: You put it much more eloquently.

DR. SUAREZ: Karen?

MS. TRUDEL: I’m coming back to the issue of the underlying data. I’m hearing
that this would almost have to be an extremely robust and very detailed
database. I guess I’m asking whether you have thought of — or could you
provide the subcommittee members with a list of the data elements that would
have to be in that database along with the identifier in order for the
identifiers to work the way you intend them to work? Could you do that?

MS. BANKS: I hate to keep taking these as two parts, but one is that we
weren’t really looking at the registry concept that was previously discussed as
the solution. At this point in time I couldn’t give you all the data points.
But I would be happy to supply you what we would recommend.

The way we looked at this originally was purely from a standard transaction
perspective, where you would route the eligibility transaction to the receiver,
and the receiver typically would be the administrator of the claim, who should
have all this information already in their systems, that could pull it in and
respond back in the eligibility response. So we were seeing this more from a
system-to-a-system/coming-back perspective than having to pull from any other
registry or any other type of list.

MS. TRUDEL: Actually, though, all you are going to see is a bunch of plan
IDs, right?

MS. BANKS: Right.

MS. TRUDEL: So where do you go for the additional data? It has to be
someplace. If it’s not in a registry, it has to be someplace else.

MS. BANKS: Understood.

MS. TRUDEL: I would just like to see the list of data elements and where you
think you would get them.

MS. BANKS: We can supply that to you.

MS. TRUDEL: That would be great. Thank you.

DR. SUAREZ: I think we are going to have to move on. Thank you so much,
Tammy, for that very detailed testimony.

We are going to go next to the testimony from WEDI. Don Bechtel is going to
present it.

Agenda Item: Proposal from WEDI

MR. BECHTEL: Members of the committee, good morning. I am Don Bechtel. I
work for Siemens Medical Solutions, where I am the patient privacy officer for
our Health Services Division. I’m also the chair-elect of the Workgroup for
Electronic Data Interchange, otherwise known as WEDI, for which I am speaking
today.

WEDI is a multi-stakeholder organization in the health-care industry that
has focused on administrative simplification and other topics over the years,
advocating for changes and providing implementation strategies and educational
outreach to the industry.

WEDI would like to thank you for the opportunity to present our testimony
today concerning the national health plan identifier.

At WEDI, we convened a sub-workgroup to discuss the national health plan
identifier, or plan ID< through which the following initial thoughts have
been developed. However, considerable discussion and evaluation still needs to
occur within the industry due to the varying needs of the different
stakeholders. The concepts of enumeration discussed in this testimony do not
necessarily reflect stakeholder consensus at this time. Given the timeframes
available, it was not possible for us to hold such discussions. However, WEDI
does intend to convene a policy advisory group later in the summer in order to
bring the stakeholders together to work towards a single consensus-based
approach, after considering all needs and current practices.

We were asked to consider several questions: purpose, format, what should be
included in the enumeration of plan IDs, what data should be included in a plan
ID directory, and other considerations.

To begin, the purpose: WEDI understands the original purpose of the plan ID,
based on several Health Care Financing Administration publications, was to
facilitate the routing of electronic transactions between providers, payers,
and clearinghouses and other intermediaries. However, some in the industry see
an opportunity to consider the use of the plan ID not only for routing
purposes, but to accomplish other business needs. For example, within the plan
ID sub-workgroup, some subgroup members have suggested the following be
considered for inclusion on the health plan to help address certain business
problems:

Identifying the product line within the plan or payer in which the patient
is enrolled.

Identifying the communications network the plan or payer is using through
which the provider accesses the payer.

Identifying the entity within the plan that is paying for the claim to
enable the provider to determine if expected reimbursement matches what is
paid, based on their contract they might have with that line of business.

To be able to ensure at the time of registration that the appropriate
entity for plan administration is determined so that any expectations of the
payer-provider relationship can be handled appropriately.

With respect to the HIPAA transactions, WEDI would not recommend changing
the identifiers used currently within transaction envelopes for routing to the
plan ID. Current plan identifiers used within the ASC X12 transactions are also
used, in some instances, for sorting of transactions, primarily by health-care
clearinghouses. Again, WEDI’s would not want to break what is currently in
place and working today. The WEDI Health Identification Card Implementation
Guide also refers to the use of a plan ID to facilitate the
communication of routing information to providers. In addition, clearinghouses
and vendors are stakeholders in the plan ID. They are affected not just as
routers of transactions, but also because the ASC X12 5010 transaction
standards require that the plan ID, when mandated, replace the identifiers to
edit transactions that assist all senders of transactions, insuring their
transactions meet business requirements of the recipients.

In terms of the format, the format of the plan ID used on the WEDI and the
NCPDP standard ID card must be consistent with the identifier requirements in
the ANSI INCITS 284 ID card standard. In practice, this means a nine-digit,
plus the self-check digit, which is issued by an entity registered with
International Standards Organization. Currently, identifiers with a first digit
1 through 8 are issued by the Department of Health and Human Services, and
those with the first digit of 9 are issued by Enumeron. The only existing
identifiers in use in this format today are those issued by Enumeron, which
have been adopted by some payers for their electronic health ID cards. We are
not aware of any use of these identifiers in electronic transactions at this
time. Payers currently using the Enumeron identifiers would prefer to continue
their use of those identifiers when the plan ID regulation goes into effect.
However, WEDI does not believe this requires that Enumeron be the issuer of new
plan IDs going forward.

In order to universally adopt a new 10-digit plan ID in all transactions and
in all locations called for by the ASC X12 version 5010 standards, and
potentially other locations, the following will need to occur:

At the provider site, patient registration, billing applications, and
insurance verification processes will all need to be updated or crosswalked to
the new plan IDs, and data entry screens and databases that capture the
identifiers may also need to be expanded to allow for the 10-digit plan ID.

Clearinghouses and vendors will need to update or crosswalk identifiers
used to support edit requirements.

Payers will need to accept these new plan IDs as valid on all transactions
they receive and generate.

Implementing the additional granularity proposed will be a new requirement
and will have a significant impact on many, if not all, stakeholders, but the
format chosen, we do not believe, will create an additional significant impact
on the work required.

In answer to the question of what should be included in the enumeration of
plan IDs, in order to determine what entities need to be enumerated and at what
level of granularity, the following uses need to be considered:

Routing of the original transactions and any responses required.

Provider, vendor, and clearinghouse editing to insure claims will continue
to meet payer business requirements.

To identify key provisions of coverage that affect eligibility for benefits,
precertification, and referral requirements, the enumeration and use of the
plan identifier could allow for, but not require, granularity at the level of
product line and type of coverage. Providing product-line level of enumeration
for things like PPO networks or an HMO network would support the identification
of whether a patient is in or out of a network. This granularity would allow
providers to identify the patient’s product-line coverage, via eligibility
responses, and then to determine whether the provider has contracted with that
particular line of business. The provider can then communicate the network
status to the patient before services are provided which supports the
transparency.

Prospective payment organization networks, repricers, and the self-insured
versus fully insured scenarios need further exploration, as this might be a
routing issue as well. This granularity would allow providers to identify
authorization requirements, which may be different by product line. Enumerating
the product line would reduce the number of phone calls between providers and
payers verifying coverage and authorization requirements, including type of
coverage for thing like worker’s compensation, auto insurance, and health
insurance. In the event that a payer does not have a more granular product
line, this level of granularity is appropriate for the provider to understand
the patient’s coverage and their own network relationships at the point of
care.

The concept is that product line and type of coverage granularity would be
indicated by use of the plan ID assigned at the level of granularity in the
eligibility and benefits responses and electronic remittance advice
transactions. The number used in transactions sent by payers for the same
patient and provider should be consistent across these transactions.

Ultimately, WEDI’s plan ID sub-workgroup sees the determination of the
number of and granularity of plan IDs to be a decision that each health plan
must make, based upon their business needs. Less granular plan IDs could be
used for routing transactions and on WEDI standard ID cards. However, we are
not recommending at this time a hierarchical structure to the plan ID.

Before the above concepts are included within the plan ID, further
discussion is needed with the ASC X12 and the NCPDP organizations on whether
the existing transaction standards are sufficient to permit and appropriately
support them.

Product line and type of coverage may not require enumeration as plan IDs.
If the enumeration of the product line and type of coverage is needed, the
identifier should provide flexibility to accommodate the uniqueness of each
payer. Further review and discussion is needed to determine if they could be
communicated by use of code lists already in the ASC X12 and NCPDP transactions
or by using payer-assigned identifiers.

For other considerations, further discussion needs to occur to determine
whether the following items should be included in the enumeration schema — for
example, line of business, or medical, dental, or pharmacy; funding entity,
such as a self-insured plan sponsor; self-insured and fully insured, group plan
numbers, and reimbursement arrangements.

Regarding the question of which data elements should be captured and made
publicly available from a plan ID directory, we have really no comment on this
question at this time. We have not had an opportunity to discuss this with our
membership.

However, in order for the industry to meet the October 1, 2012 date,
assigned identifiers must work with transaction standards under HIPAA that will
be in place at the time of implementation — namely, the ASC X12 version 5010
and NCPDP version D.0., which require the national plan ID be used in place of
existing identifiers in specific locations for those transactions. Proposals to
establish rules requiring identifiers in other locations in the ASC X12 005010
or NCPDP D.0 transactions should also be discussed with those standards bodies
in order to ensure that consequences are adequately considered. For example,
putting identifiers in the remittance advice header segments that are more
granular than are currently used today would increase the number of separate
bank account deposits providers need to reconcile.

Requirements to support worker’s compensation, state reporting, coordination
of benefits, and other things need further discussion as well.

In conclusion, to summarize, both routing of the original transactions and
the responses generated, along with current provider, vendor, and clearinghouse
editing need to be considered as part of defining and developing the plan ID.
The enumeration process is best served to include some flexibility to
accommodate payer uniqueness, by allowing but not requiring product line or
type of coverage enumeration. Plan identifiers should be used using the ANSI
INCITS 284 ID card standard for health plans, and any existing identifiers
issued using this standard should be grandfathered in as the plan ID.

As mentioned earlier in our testimony, considerable discussion and
evaluation still needs to occur within the industry due to the varying needs of
the different stakeholders. These concepts of enumeration do not reflect
stakeholder consensus at this time, given the limited timeframes available to
hold such discussions. WEDI does plan to convene a policy advisory group later
in the summer in order to bring the stakeholders together to work towards a
single consensus-based approach, and after considering all needs and current
practices. WEDI will share our findings with you when we complete that work.

That at this time completes my testimony. Again, WEDI and I thank you for
the opportunity to present today.

DR. SUAREZ: Thanks so much, Don.

We are going to take questions now. We will be taking a 10-minute break
right after the questions. Any questions from the committee members?

PARTICIPANT: A real quick one. We have seemingly been talking about a model
in which patients present to physicians, physicians submit a claim with an ID
on it, and the information follows. Is there available in WEDI standards models
where insurance companies push data to practices about the coverage — and I’ll
use these plan ID 2s, which were mentioned earlier — directly, as the plan
actually changes?

MR. BECHTEL: The last part of that question, as the plan changes?

PARTICIPANT: The plan has been structured thusly, and suddenly one of the
entities involved in it changes. They decide to go with some different
intermediary for some function or they decide that they are going to change the
fee schedule somehow. But no patient has come in the door yet. Is there a way
in which they could preemptively send that out?

MR. BECHTEL: Not at this time. However, some work has been identified as
wanting to do something like that at the now-defunct ITSPI (phonetic)
organization. There was some effort to look at that at ASC X12, and if there is
a business need for that, that’s certainly something X12 would be interested in
developing. But without somebody bringing that forward as a business
requirement, that’s probably not going to happen.

On the other hand, when someone does an eligibility inquiry, they are
obviously going to get, for instance the payer is responding fully, what
information is current at that time. The business model that was described by
WEDI and other organizations when we initially did HIPAA was that you would do
an eligibility inquiry at the start of an event, when you register or schedule
a patient for a service or a visit, and at that time you would get back the
information that was currently relevant for that patient. That would be
specific to the plan sponsor, the contracts that are in place for that
individual’s coverage.

But to do it preemptively, no, we haven’t defined a standard for that — I
take that back. There is also a standard within ASC X12 that was primarily
designed for HMO transactions. It’s called an eligibility roster. It is not a
HIPAA transaction, but it is a transaction that is supported by X12. That would
be for the purpose of a health plan to communicate to a provider all the
benefit information, who is associated to that provider for that plan and those
particular benefit coverages. It is not, to my knowledge, widely used in the
industry because it’s not HIPAA-required, but there is a transaction that would
support that function.

So I take back my earlier comment. There actually is something that was done
on that.

DR. SUAREZ: Thank you. I do have a couple quick questions, Don.

At the beginning of your testimony, you mentioned that WEDI has no intent to
recommend changes in the identifier used currently within transaction envelopes
for routing transactions, which prompted me to think that, of course, there are
a number of specific places in which X12 implementation guides define where the
new national health plan ID will be used. There are other identifying elements
of a plan used for routing purposes, for example, that do not reference the
plan ID as the one to be used.

Could you elaborate a little more about that? These identifiers, who gives
them? It currently looks like they are used by clearinghouses primarily to
identify in the envelope the actual routing places.

MR. BECHTEL: Typically the routing instructions for how a provider would
communicate with a health plan are defined in the trading partner agreement
between the health plan and that provider. There they would say, this is the
identifier that you would use to route that transaction to us; here is the URL
address or whatever it is that we are communicating to you electronically. We
are not looking to see that go away. If the health plan wants to use that plan
ID for that purpose, that would be fine.

DR. SUAREZ: Okay. The other comment is on the other considerations that you
listed, like line of business   medical, dental, pharmacy — funding
entities, self-insured versus fully insured. Do you see that this can be
addressed also through other means — for example, a codification of a type of
payer? As we will hear later on, there is a standard for payer typology. Are
some of these addressable through those other codes rather than expecting that
a new identifier would have to be used in order to identify this type of
element?

MR. BECHTEL: I think that’s the dilemma that WEDI was facing, and the reason
we wrote the testimony the way we did. We need to have more discussion on this.
But, absolutely, there are ways to identify some of these things in the
transactions today. Currently that information in 4010 is not always provided.
In 5010, the rules have become much stricter, and we expect that this will be
improved. But it may not yet address all the needs. We need to make sure that
we are fully considering what those needs are that either are not being
satisfied or that can be satisfied by the transactions as we would implement
them with 5010.

So I think we need the opportunity to sit down and fully understand what
those issues are and what we can do with 5010 and whether or not we have
addressed everything. That’s what we are calling for.

DR. SUAREZ: Okay, thank you.

Any other questions from any of the members of the committee?

(No response)

All right, it’s 11:04. We’re going to take a 10-minute break — let’s say an
11-minute break. We’ll come back at 11:15 and we’ll start again. We will
probably have to use a little bit of the lunch time.

Thank you.

(Brief recess)

DR. SUAREZ: We will listen to our two last testifiers. Hopefully we will
have a chance to, at the end, spend a few minutes to have any questions for the
entire panel and some cross-related questions between the different
testimonies.

Next we are going to be listening to Lynne Gilbertson, from NCPDP. So I’ll
turn it to Lynne.

Agenda Item: Proposal from Pharmacy Industry

MS. GILBERTSON: Good morning. I am Lynne Gilbertson, with the National
Council for Prescription Drug Programs. The presentation from NCPDP will be
jointly done by me and Annette Gabel, who is our Strategic National
Implementation Process, or SNIP, Committee chair. We are pleased to present to
you today.

For those not aware of NCPDP, we are a standards-development organization,
ANSI-accredited. We bring the many entities in the pharmacy industry together
for consensus building on standards — payers, processes, plans,
clearinghouses, switches, pharmacies, vendors, prescribing entities, all those
different people. Our standards have been named in HIPAA and in the Medicare
Modernization Act.

The recommendations packet that we provided to the subcommittee includes a
couple of different documents that we want to make sure you are aware of. The
first one is the 2010/07/08 NCPDP recommendations for plan ID. This document is
detailed information about our presentation today, to provide some examples,
some situations, and a little bit more beef than what we have time for today.

We also have an important document — Don mentioned a little bit about it in
the WEDI presentation   which is the NCPDP Health Care
Identification Card Implementation Guide. We have included the fact sheet in
the presentation materials, to give you a couple-page overview on what the
pharmacy industry uses for a pharmacy and/or combo ID card.

We have also included a page on the ANSI IIN, the industry identification
number, that shows you the enumeration that is being done today, which we will
get into more detail on in the testimony, and, as well, a little sheet about
the NCPDP BIN number, which is an identifier that we use when entities do not
obtain an ANSI IIN number.

The recommendations from the Strategic National Implementation Process
Committee:

The very first one is an important one about industry involvement. There are
a lot of misconceptions going on right now. We don’t know the intent, the size,
what was proposed years ago, what is still current today. Really, what we need
to do is get some key representatives of the industry together and lock them in
a room, to not come out until we have some recommendations.

While it’s very appreciated to have the high-level summarization, for some
of us, we need the details. We need to see what the identifiers being used
today are, what the problems are that they are not solving, and how we go about
solving those. We need to be aware, together, that perhaps we come out with
100,000 more numbers than we have today, but we agreed that that is a good
solution, or we come out with 100,000 fewer numbers than we have today, but
agree that that is the better solution.

We really need to lock people in a room and get down to the brass tacks of
the actual data elements and how we are going to enumerate, taking the existing
business structures today, what IDs are being exchanged and how they would fit
into a new plan.

We saw some real problems in the enumeration of the NPI, not so much the tip
of the nose, the actual providers’ IDs, but in the organizational entities. I’m
sure you will be hearing some more testimony later today on that as well. We
would like to make sure we don’t repeat those mistakes with this next
identifier.

The pharmacy industry is actively working on what Karen would call the data
elements to try to build some spreadsheets that show that this is what the IDs
look like today, what they are exchanging, and then how the impact of a
national plan ID would affect that.

One recommendation from the SNIP Committee is, one ID can’t handle all
needs. It’s really suicide to expect that it could. It should not be a smart
ID. We would have problems with longevity in the future if we are going to
embed too much intelligence into an ID. The balancing act of how you give an ID
a construction at a level high enough so it’s really enough to inform, but not
too specific so that you cause confusion — one unintended consequence could be
thousands of rejections because you didn’t get the right ID, because it was way
too specific and you’re off, you guessed wrong, whatever it would take. There
are other solutions versus guessing wrong.

The big recommendation from the pharmacy industry is, leave the health plan
ID out of our routing. We are routing billions of transactions today —
billions — with approximately 6,300 identifiers. The BIN, which is the bank
identification number, or the IIN, the industry ID — that’s a six-digit
number; it’s either assigned by ANSI or assigned by NCPDP if they do not obtain
an ANSI number — and the PCN, which is the processor control number, are the
two identification numbers we use for routing billions of transactions. And
they work.

We have some statistics, if you are interested, on how those BINs and PCNs
break down. But for now, that’s the biggest point.

This standard BIN-and-PCN combination — the BIN was based on the credit
card industry, from 100 years ago, it feels like. The methodology works. The
processor control number is a secondary identifier which is used when needed to
further define the benefits in the routing and information.

The BIN and the PCN are used in routing. Part of the question earlier was,
how do you exchange this information? The pharmacy industry I don’t believe is
unique. In our particular world, there are things called payer sheets. They
work very well. They are information that’s exchanged about the
transaction-processing requirements and different lines of business
requirements that are important for pharmacies, for vendors, for clearinghouses
and switches, to know the plans that the processors support. The payer sheets
are distributed out to people in the industry, for that very reason.

When there is a change in the information, of a business rule or a routing
change, those plan sheets are sent out again. Information comes out ahead of
time. I would think that this would also happen in the medical environment.
That information is shared. People know when plans change, in June, July, or in
January. Everybody knows to shake and quake when that part changes.

This early notice provides the industry the ability to be prepared for a
change coming, and how to prepare your systems for that transition environment.

This payer sheet information tells who will be processing the transaction,
where to route the transaction, and what rules are to be expected, for example,
if there is a transition or a cut-over timeframe.

The other impact of the BINs and the processor control numbers is their
downstream effects. We use them in other transactions. It’s typically thought
of in terms of claims. Obviously, eligibility transactions are important. In
the pharmacy world, eligibility is only really used in the Medicare Part D
environment. In the non-Part D environment, you send the claim and get the
real-time response. You don’t go hunting for the Medicare Part D. The
information that’s returned on the eligibility is from a TrOOP facilitator,
which is true out-of-pocket information, and it tells about other payers that
this patient may be involved with, other plans. So you get coordination of
benefits information with that eligibility check.

The other transactions that are used, in importance, are:

The information-reporting transactions, which are reporting for
coordination of benefits, reporting from downstream payers to the primary
payer, about true out-of-pocket updates that have occurred on behalf of the
beneficiary. So that information, once again, uses the BIN and the processor
control number as the important identifiers to get it to the right place.

We also have financial information reporting transactions, which report
benefit accumulation changes when a beneficiary has changed from one Medicare
plan to another. That also uses the BIN and the processor control number as the
important identifiers for when the beneficiary has changed.

We also have post-claim reporting, which is the post-adjudication
reporting functions.

We also have rebate processing.

Now I’m going to turn it over to Annette.

MS. GABEL: I think what you have heard so far today — at least what I think
I’ve heard so far today, loud and clear — is that in order for routing to work
correctly, an ID card must contain the routing information. In the two
implementation guides that exist today, which are the NCPDP Health Care
Identification Card and Combination ID Card Implementation Guide, there is
information contained in the guide that explains how to use a standardized card
and what format is necessary. It also contains information about identification
usage. We did include in the presentation that we submitted what the pharmacy
ID card fact sheet looks like. It indicates what is required on the card.

There is also, as you heard earlier, a WEDI Health Insurance Identification
Card Implementation Guide. In that guide there is a section that refers to the
combination medical and pharmacy ID card. If we don’t have standardization in
the ID card usage, it’s going to be difficult to obtain administration
simplification. So I think even listening to the AMA discussion — in order for
them to route the transaction, they need to know who to route it to. I don’t
know how they would know that information unless the individual presented them
with their ID card. So it’s very important that when we talk about routing
information, we include the ID card implementation guides. If there are going
to need to be changes to those ID cards as a result of the regulation, then
it’s important that the two entities that came together and created the
implementation guides — those being NCPDP and WEDI — be involved in those
discussions.

What we also think is very important — and I see this a lot in the business
that I’m in — is that if an individual moves from one benefit administrator to
another benefit administrator, those cards have to be reissued. In order for
the providers to have the correct information, that individual needs to have a
new ID card with the information that the provider will need to identify the
benefit and the routing information.

Lynne mentioned earlier some of the uses of the BIN/INN. What we heard loud
and clear on our SNIP calls was that today for the coordination of benefits,
they don’t have a unique way to identify the plan. Typically this happens in
the Medicaid program. When they submit a claim to the Medicaid payer, they get
a response back from the Medicaid payer indicating to them, “We’re not the
primary. You need to go to the primary,” and they give them a very
specific code to that Medicaid plan. Then the provider in that situation has to
go and look at some other sheet he has hanging on his wall, or maybe he has the
information in his database, to try to determine what that coded information
that he received back on the reject means so he knows who to send that primary
claim to.

They express to us that in that situation, where an identifier doesn’t exist
today, if we could either get the Medicaid payers to adopt the BIN/INN-PCN
combination or create plan IDs for those specific situations — so that when
they get that information back in the claim, it’s not a specific number unique
to that Medicaid agency; it is a number that is nationally used for that payer
— that would be very helpful.

Again, if we put out these rules and the Medicaid agencies don’t follow the
process, then it’s not really going to help at all. So that’s another item they
wanted to make sure we referenced in our testimony.

When we looked at other entities that need to be identified, one of the
discussions that we had is that today in the X12 835 there is a requirement to
report the payer ID back on the 835. In the transactions that are sent today in
the pharmacy industry, the payer identification field contains the entity who
issues the payment. Typically today, we are using tax ID to send that
information back to the provider. The tax ID is based on the check stock or the
bank account that the money is being drawn from. It’s common practice today for
the PBM or the administrator to issue the checks to the pharmacy on behalf of
all of the plans that they support. There are some situations where the
processor or PBM could be using one of their administrator’s check stock, and
in that case, the tax ID of that administrator is sent back to the pharmacy.

We think that, as we look at purposes for the national plan ID, in the 835
5010, it establishes that once a national plan ID has been created, that plan
ID will be used in the field in the payer ID identification in the 835. So we
do see the need there to have a payer ID that would identify the administrator
or the processor, as it is being used today, representing the tax ID.

Then we give you a little bit of information on our thoughts for a health
plan database. I have to tell you that we had compressed time as we were going
through some of the recommendations that we wanted to make to the committee, so
we didn’t provide all of the information. We are hoping that we get to be
involved in further discussions.

What we have come up with so far is that it’s going to be very important,
when we look at creating the database, that we have all sectors of the industry
involved. As Lynne said earlier, I think it’s going to be a necessity that, as
you pull these people into the discussion, you have examples of benefit
structures. What do you do today? What’s the hierarchy of that benefit
structure today? What do you really need enumerated, and for what reason?

We also believe that the database should be secure and that the access
should be limited to those entities that are deemed appropriate to have access,
but not be so restrictive that it would impact claims submission, payment, or
other transaction processing.

We think that in order for the database to be accurate, there has to be a
clearly defined method of updating the information. There have to be parties
that are responsible to keep the information current. If that means assessing
penalties to those parties to ensure that they keep that information current,
then that is something that should also be considered.

We think, if there is a possibility for the database to be interactive, that
would be great. The database should provide robust lookup capability, so that
if there is a need to do something manually, you would have the information. We
believe that for the pharmacy side of the world, the BIN/INN and PCN should be
included in that database, as well as any other relevant routing information.
We also believe that in order for that database to be effective, it has to be
available 24/7, it should have real-time processing, and there should be
redundancy provisions included in the building of the database to handle any
situations where the database would fail.

That’s it, right on time. So that’s the conclusion of the SNIP Committee
information. Lynne and I would be happy to answer any questions that you have.

DR. SUAREZ: Thank you, Lynne and Annette, for this testimony. Very telling,
about the impact of requiring the use of a health plan ID on the pharmacy
transactions.

Questions from the committee? Judy?

DR. WARREN: I think what I’m hearing is you would like for us not to have
the health plan ID for NCPDP. Do you see any need —

PARTICIPANT: For routing.

DR. WARREN: So for routing, no. What other ways would you see using it?

MS. GILBERTSON: What I mentioned earlier — I know there has been some
discussion, and probably some information put out, that plan ID and payer ID
could be somewhat similar. We see a need, in some cases, to identify the payer
ID. We also think, in the situations where there — I know today that there are
codes that are used for insurance companies. I think the Medicaid agencies try
to use some of those codes when they respond back in the
coordination-of-benefits situations. But what we have seen is that the
information that they send back might be specific to their needs. They might
have — and I’m going to use Aetna as an example — Aetna billing locations,
four different billing locations, throughout the country. They set up four
different IDs that are very specific to their needs. It may be AET1, AET2. Then
the provider, on the other hand, when they get that information back, needs to
know that AET1 refers to the Connecticut office. But if they are billing
another state, the other state might not use AET1 to identify the Connecticut
office.

In those situations it would be helpful to have a plan ID that identifies
those entities.

DR. WARREN: Let me just restate that and make sure that I got it. For
coordination of benefits, you see a need for the identifier, when we are
coordinating pharmacy benefits.

MS. GILBERTSON: Yes.

DR. WARREN: When it’s routing the stuff around, that’s when you don’t want
to use it, right?

MS. GILBERTSON: Correct, because we have a process today that works very
well for pharmacy.

MS. GABEL: And the other is the recommendation that routing information be
on a standard card.

DR. WARREN: Thank you. I missed that.

DR. SUAREZ: I’ll ask a question. I think there are some important concepts
here. You have 6,300 BINs at this point identifying plans and others —

MS. GILBERTSON: Not BINs, but 6,300 combination BIN-PCNs. The number of BINs
is much less, but when you put the BIN-PCNs together, then you get to the
6,300.

DR. SUAREZ: Okay. At what level of granularity are they identifying? Is it
just the health plan as a single entity or do you go below that? The PBMs, of
course. But besides the NCT — let’s call it that way, the legal entity or
whatever — do you identify any elements inside the —

MS. GABEL: It really depends on the processor. You have some processors that
are really true processors, so they are not doing benefit administration. In
that case you will see a greater number of PCNs. They might only have one BIN,
but they identify either the benefit administrator or the plan that they are
supporting by that PCN.

On the Medco side — and I’ll use Medco as an example — we don’t have that
many PCNs. When we create PCNs, we are creating them to identify a different
line of business. Today we have a PCN for Medicare, for example. The pharmacies
know that when they submit a claim to this BIN and put in this PCN, they have
to follow the rules for claim submission for Medicare Part D.

DR. SUAREZ: The reason I’m asking is because in order to create a crosswalk,
if you will, between BIN PCN and plan ID, one would need to understand the
logic behind, of course, the structure and make sure that there is a way to
connect what would be health plans and health plan identifiers with the BIN
numbers. Would you expect to see that kind of matching, a one-to-one match,
exist or would there be one-to-many? How does that get addressed, if we have
the BIN PCN numbers that you have currently and then we have a plan identifier
and we need to cross-connect the two?

MS. GABEL: We’re not recommending a crosswalk. When we say the BIN/INN-PCN
number should be in the database, if someone needs to go and query information
on a particular health plan, then they could see that this is the BIN/INN-PCN
for the pharmacy business. We are not saying that you should have a plan ID
that replaces the BIN-PCN. We are saying, leave the BIN-PCN alone. It has to
exist on its own.

DR. SUAREZ: Not for replacement, but for relationship, should there be at
least some way of connecting the BINs and the plan identifiers? Or you don’t
see any reason for it?

MS. GABEL: I think it depends on the level of the plan ID. We were
struggling with that a little bit in the committee discussions. When you decide
what the plan ID is really going to be, then we could put the hierarchy in for
where that BIN-PCN comes into play. But without understanding what that
database is going to look like, it’s hard for me to answer your question.

DR. SUAREZ: Okay. Mike.

DR. FITZMAURICE: I’m going to ask the same question. In here you say that
the BIN and the PCN identifier should be included with other relevant routing
information. Do you mean included in the national health plan ID file? That is,
it doesn’t replace or isn’t equivalent to the national health plan ID, but when
you identify the health plan and assign it a number, along with the other
identifying things like phone numbers and addresses, you should have the BIN
and PCN for that particular health plan ID?

MS. GABEL: Right.

DR. FITZMAURICE: Would you have more than one BIN and PCN ID for that health
plan?

MS. GABEL: You could. Again, it depends on how you set up the database.

DR. FITZMAURICE: So that’s something you would have maintained by the
national health plan ID file, as opposed to having it maintained by the health
plan alone. Do we have these payer sheets that go out and update this
information or do we have a national health plan ID registry that updates this
information?

MS. GABEL: That was part of what I had in the testimony. I think you have to
determine who is responsible. Who is the entity responsible for maintaining the
database? That individual, if it is the health plan — if you are looking at a
benefit administrator up here and they change their pharmacy benefit processor,
if it’s their responsibility to maintain that database, then they have to go in
and update that BIN and PCN for their new benefit administrator.

DR. FITZMAURICE: Today we don’t have a national health plan ID. Whose
responsibility is it now? Is it the health plan’s to maintain this and to send
out sheets?

MS. GABEL: When they are providing information to the providers?

DR. FITZMAURICE: When the BIN changes or when they are changing something
along with the routing?

MS. GABEL: If the health plan is administering their own benefits, then yes.
But if the health plan is using someone like Medco, who is their prescription
benefit manager, we update that information and provide it to the pharmacy.

DR. FITZMAURICE: So this is something to be determined once the structure of
the health plan ID is determined. The pharmacy part of the industry and the PPM
part of the industry would not mind if it were maintained in a national health
plan ID data file, as opposed to having it circulated with payer sheets.

MS. GABEL: You would still have to have the payer sheets, because the payer
sheets serve a specific purpose. But we agree that it should be on the
database.

MS. GILBERTSON: If you are taking the perspective that you need to look at
the database for some reason, we were trying to think of what kind of
information  obviously, name, address, contact, fax numbers, websites,
all those kinds of data elements. We thought it would be helpful if we put the
pharmacy routing information out there as well, and medical routing
information, whatever it’s called, and things like that, just as adjunct
information.

DR. FITZMAURICE: And you anticipate that it could be used as a telephone
book, a routing book, that people could look in and get the information for a
particular health plan.

Thank you for great testimony.

DR. SUAREZ: I do have one other question. On your slide 12, you mentioned
that you are recommending that the processor or the administrator that the
processor supports be considered to be eligible to obtain a plan ID. This goes
to the scope of who would be eligible to obtain a plan ID. There are PBMs, of
course, which are processors. Are there instances where entities that are not
PBM-like are administering this that could make it difficult to extend the
definition of a health plan into, to make it eligible for a plan identifier —
for example, a third-party administrator?

MS. GABEL: I think if you were to ask a third-party administrator, the
answer would vary. I think in some cases the third-party administrator, when
they identify themselves on the 835, since they are responsible for paying for
all their plans, they would say they are the payer in that situation. But there
are situations where there is a third-party administrator that processes
claims, but has no financial responsibility for those claims. In that case,
then, the entity that they are paying on behalf of would be the entity that
would be enumerated.

DR. SUAREZ: Okay, thank you.

Other questions? Mike?

DR. FITZMAURICE: But the routing information would go to the third-party
administrator, not the plan. So you have the health plan and you have the
routing information. The routing information goes to the third-party
administrator since they are paying the claim on behalf of the health plan.

MS. GABEL: Right. That’s correct.

DR. FITZMAURICE: Thank you.

DR. SUAREZ: Any other questions?

(No response)

Thanks so much, Lynne and Annette.

We are going to go to our last testifier this morning, Peter Barry, from
Enumeron.

Agenda Item: Independent Proposal

MR. BARRY: Thanks, Judith and Walter and the committee. This is quite an
honor, to have a chance to talk, especially associated with all these
representatives of the huge organizations. I’m of a nature in which I win the
employee of the month every month.

Walter, at the beginning you said you would like us to indicate involvements
that intersect in one way or another with the subject today. I would like to do
that. The first is that I’m the managing principal of Enumeron. We are here to
talk about that in just a little bit more depth. I’m a chair of the WEDI Health
Identification Card Implementation Guide Committee. I am a chair of the ANSI
INCITS committee that developed the ANSI INCITS 284 health identification card,
which is the underlying ANSI standard for the WEDI implementation guide and for
the NCPDP implementation guide of the health card. I’m a member of the
workgroup that helped put together the testimony that Don Bechtel gave. So I do
have some intersecting things.

On the other hand, I am completely objective and have no real point of view.
You understand that.

What strikes me in the testimony today are not the differences that exist —
there are some, sure — it’s the remarkable level of agreement on the basics of
what we need for this plan. I see progress. I have been involved in this
subject for 19 years, and it’s really kind of hard to believe that the thing
might actually take place. We’ll take it from there.

My involvement began in the fall of 1991, when X12 asked me to chair a
standard health card initiative. The biggest problem with health cards was and
still is that they are missing a standard card issuer number to identify a plan
and give us the basis for saying where we send the first transaction. It would
be like an American Express card that didn’t have an identifier on it for
American Express. The first four to six digits of a charge card number identify
the bank. We don’t have that. What we were missing was a comprehensive standard
number.

I had another involvement. That involvement was that between 1995 and 1998,
I was the outside consultant to what was then HCFA — it’s now CMS — on the
payer ID initiative. Just about nothing has changed since then, except in a few
details. In 1999, we changed the plan identifier to 10 digits instead of nine.
And that’s about it.

I will pass this around. This was from May of 1996, pre-HIPAA. What we are
going to talk about today is all in here. When I say it has been around for a
while, it really has. This is not a new subject. Michael Fitzmaurice was a
young man when I met him back then, on this subject.

I’m going to straighten up a couple of things. I am not going to talk from
slides, but I have a four-page abbreviated outline that has been passed around.
It references a 40-page report that I sent in to you earlier. The 40 pages
would be a little much for you guys. You probably would like to have lunch. So
there is this four-page one. I have a few extra copies of it. If anybody didn’t
get one and wants one, just raise your hand and we’ll send it around to you.

Let’s look at that health card that is on the front of this four-page thing.
You can see that there is a health plan identifier. It begins in this example
with 91405 and then five digits. It happens that the last five digits, 67881,
are the payer’s NAIC company code, which is the most widely used payer
identifier in the nation right now. Putting that in like that is an aid to
transition. It might help out for the chicken-and-egg problem of who converts
first. It’s a way of getting the cards out there using old numbers. Then, over
time, you can forget that that distinction is being made.

That 10-digit health plan number tells us where to send transactions.
Through the database, it can tell us where to send any kind of transaction
related to this thing, including a car route for mental health in Minnesota or
something like that, if needs be.

The process is, first, you use this card; second, you send an eligibility
inquiry; third, you get back all of the other information that has been talked
about. That’s the way it ought to work. Some of that information is more
identifiers. Some of it may be textual or codes and various things of that
sort.

Before we begin, the staff of NCVHS has asked that I make a reasonable
statement of my involvement in this company called Enumeron. I have three
points to make.

The first point is that the national plan identifier was delayed more than
10 years, when CMS decided they would no longer control all of the number
space, and they released back the 9-row. Remember, the NPI is row 1, and CMS
controls right now numbers 1 through 8. They released the 9-row back to ISO.
That 9-row alone has capacity for 100 million identifiers. So there is plenty
of space.

We tried very hard to find a nonprofit organization that would administer a
health plan identifier using that 808409 ISO scheme. We were not successful. We
did get it to the board of directors of one organization, and then the board
voted 5-to-4 no.

We then decided — we had been using Enumeron to hold this identifier so it
didn’t disappear into some Japanese company or something — we decided, let’s
have Enumeron do it. That’s how we got involved.

Enumeron to date has issued these 10-digit plan identifiers — they look
exactly like NPI, except that they begin with a 9 and not a 1 — to insurance
companies that collectively represent about 100 million insured lives. Last
year some of these companies issued WEDI-compliant cards, 25 million of them.
So there is an existing thing.

Last point on Enumeron. Enumeron designed an online Internet system and an
all-payer electronic directory. It is a system that could be deployed yet this
quarter, if we are willing to take that risk, that investment at this stage.
Frankly, I didn’t figure that even the new legislation was going to put this on
quite as fast a track as it is. So I may be looking at a write-off. I will tell
you that the tax loss write-offs so far have been really very nice.

I have one of the books of specifications of Enumeron. I’ll pass it around
the table. In the back of it is Section 7.3. It defines the data that is
currently designed into the identifier table and in the directory, or
transaction destination table. That question came up a number of times in
earlier testimony. You can see what one cut of this thing would look like.

I am willing to answer any question you have on Enumeron, but that’s not
really why I’m here. I’m here because for 19 years I have wanted this plan
identifier. It isn’t that I was in love with the plan identifier; I wanted to
complete the assignment of a standard health card, and we have one missing
ingredient yet. When that is solved, then I can fade into the distance.

Page 2 of this four-page thing — these recommendations are numbered, and so
I’ll refer to them by number.

First, I think there are four primary purposes of the plan identifier. They
are to identify who receives the transaction, who administers the health plan,
who is financially responsible, and who the counterparty to the provider’s
contract is. There are two others that have been talked about, and those are to
identify specific patient benefits and, minimally, to identify the business
line or the product. I think that’s something that could be readily done.

Another one is the fee schedule. You have talked about that a good deal.

Let’s look at recommendation 3. First, what entities should be identified?
Let’s look at page 4. There is a table that looks like this. The reason for my
showing you this is to put some perspective on how many identifiers we are
talking about. These are old numbers. They are taken off of a HCFA working
document in 1997, I think. So, sure, these numbers are probably off right now,
but they are adequately accurate for understanding what we are dealing with.

How many insurance companies and HMOs that are independent of insurers are
there? Let’s say there are 1,500. I think there are 1,720 or something like
that. The number of identifiers would be multiples of that, because you need it
for product identification or lines of business, or because of a mess of other
factors.

The multiple employer trusts, MEWAs, and Taft-Hartleys and stuff like that
— there are about 10,000 of them. After that we get some pretty small numbers.

I would identify the communications portal of a health plan. A health plan
has at least two. They have an interactive portal and they have a batch portal.
You have to, somewhere along the line, be able to tell the difference between
them.

I would also include other trading partners that are not plans and not
providers. This is sort of like the atypical provider problem of the plan
identifier. I would include them. Many of them have just as much need for a
standard identifier. You can put them in a different number range. That’s easy
to do. There are about 3,000 that might be involved. They are, like the CDC, a
health-information exchange. We send stuff to them. Let’s bring all of health
care into one comprehensive numbering scheme. We have NPI. We have the standard
plan identifier. Maybe we can also have the rest of these entities brought into
the same numbering scheme. It would have to be voluntary, because they are not
covered entities.

So you tally that up and we end up with 22,000. Then we go into the group
health plans. There are roughly 70,000 self-funded plans. There are 4 million
fully insured plans. I can identify no reason to issue a standard identifier to
a fully insured group health plan. I can’t find one. They are not the
financially responsible party. They don’t get the transactions. They already
have a numbering scheme with the IRS for their 5500 employee welfare benefit
plan. There’s no need.

Self-funded plans — that’s to be decided. I think that’s an open issue.

We go back to page 2.

Recommendation 4: I’m just listing here other trading partners — I think a
different number range, but they should be able to get these identifiers
voluntarily if they want to.

I believe that the national plan identifier should look exactly like NPI.
That’s what we have been planning for a long time. In the full report, there is
a full page on all the reasons why we would use that.

Recommendation 6 is that I would permit a limited amount of intelligence in
the plan identifier. What I would not recommend is a scheme whereby digits 3
and 4 tell you the state and digits 5 and 6 tell you the type of plan and so
on. That’s a lousy identifier scheme. But almost all identifiers do have
intelligence in them, like your Social Security number. No Social Security
number begins with 39, because that’s a different kind of tax ID that exists.

Enumeron set aside 9140, such that the last five digits are the NAIC company
code. It set aside 916, such that the last six digits are an ISO IIN, which is
the second-largest existing payer identifier. So you get a one-to-one
correspondence, ease of transition, and so forth.

We also set aside something for the pharmacy industry that we talked about.
We are still talking about that. I would say, permit it. But that’s NCPDP’s
domain. We will do it if they want it. It does, however, give us a one-for-one
way to say on the 835 to come back with a standard plan identifier that happens
to have their Rx BIN number in it, and so it would be there.

The limited intelligence that is use of different number ranges could, if
it’s decided we want it — what Tammy brought out, a Type 1 and a Type 2. It
could do it that way. We could tell by the number, and that would still be
efficient.

Recommendation 7: I would grandfather the existing plan identifiers, the 160
million lives that are represented by companies that already have these
identifiers — I would grandfather it in. I see no problem from Enumeron in
authorizing or allowing that. That would not be an issue.

Then the directory. The directory is something that is used in direct
transactions, as much as anything. It would direct transactions according to
the kind of benefits. You could have a card that has both dental and medical on
it, and one identifier, and it will figure it out. It goes to different places
depending on the type of transaction, at different places sometimes depending
on the location of the provider, and a match on the PPO or a carve-out.

Let’s look at the top of page 3. We have a flow chart up here. This is a
schema. Somehow, the card or the information off the card — remember, there
are really only two numbers on the card. It’s the plan identifier and the
subscriber identifier, and some plans need a group number. It’s that simple.
You can get it over the phone. You can tell the patient, the elderly patient —
well, not that old, because that would be Medicare — not the brightest light
bulb — you say, “There’s a big number on there that begins with 9. What
is it?” Then she or he rattles it off. You can do it over the phone.

That goes into the provider’s systems or the provider’s business associates’
systems, such as billing service or clearinghouse. When it gets to the EDI
server, that server has standard software that it gets from the central site.
We call it an API, application programming interface. It’s a standard server
that inquires into the electronic directory. The location of that directory can
be the central site, but it also can be replicated to the largest users and
clearinghouses and service organizations that are authorized. It comes back and
it tells it where to send the transaction. You can send medical inquiries here
and dental inquiries there.

Take another example. This is the service for, say, mental health in
Minnesota. I use that as an example. The payer is subcontracting with a TPA
that specializes in mental health claims in Minnesota. This directory would
figure that out and say, no, don’t send this thing to the payer; send this to
that TPA in Minnesota.

Recommendation 9: I believe that API software ought to be centrally
developed and made developed so that it’s all consistent and we don’t have
variations in implementation.

What should be in the directory and not in the directory? I think the
directory should carry data that identifies the plan, which would include the
type of plan and crosswalk indices, legacy identifiers, and that sort of stuff.
It should tell how to contact the plan. It should tell how to send transactions
or where to send transactions for the plan. It should not talk about the
benefits or too much in the way of attributes. That is better obtained from
eligibility response.

Granularity: I think each plan should make its own judgment of what it
needs. The question that would be before us would be, what are you going to
mandate and what are you going to make voluntary? We should permit the maximum
and mandate the minimum, I think.

Since a plan would have more than one identifier, it needs affiliation.
Unlike the MDI system, we need the ability to tell that these sub-plans belong
to one big plan. We need that kind of scheme.

I want to just point out recommendation 13. HIPAA has a trade secret clause.
This directory should not enable somebody to mine it to learn the customer list
of administrators and insurers.

Recommendation 14 I’ll just let you read. I recommend that CMS relieve the
uncertainty by announcing certain basic principles as early as they can. I
believe the system ought to be online.

Recommendation 17a: The way to achieve accuracy is to make the entity the
person that feels the pain if it’s inaccurate, make them the ones that are
responsible for keeping it accurate. It’s a simple principle.

I also believe that the identified entity should overtly apply for and get
the identifier. We should not take a big database of some sort and issue them,
push them out.

That’s my testimony. I’m appreciative of the opportunity to talk.

DR. SUAREZ: Thanks so much, Peter. Great testimony as well.

Let’s open it for questions from the committee. Are there any questions at
this point? Judy?

DR. WARREN: On your number 14 recommendation, you want to set aside certain
ranges in the ID number that would accommodate the BIN number that NCP —

MR. BARRY: And the NAIC and the existing ISO IINs that are currently in use.

DR. WARREN: So you are recommending that we put intelligence into this
identifier.

MR. BARRY: Yes. We often hear that the identifier ought not to have
intelligence. Jim said that today. He also said that you ought to be able to
get a block of numbers. Those are contradictory. A block of numbers is a
reasonable type of intelligence. What’s not a reasonable type of intelligence
is where you say a certain digit or couple of digits mean this and a certain
other couple of digits mean that. Then you either end up with the need for a
huge identifier, like the VIN number on your car — it’s about this long — or
you run out of space. So don’t put that kind of intelligence in. But number
ranges for different things — NPI has intelligence. If it begins with 1, I
know it’s NPI. If it begins with something else, I know it’s not. Social
Security numbers, product code numbers, they all have some degree of
intelligence — just not that lousy kind, where you set aside digits.

DR. WARREN: Maybe I’m misunderstanding what you are saying here. It seems to
me that within this 10-digit number — what I heard you say is that you are
going to take some of those digits and reserve them for a BIN number.

MR. BARRY: Yes, I would suggest —

DR. WARREN: That is putting a lot of intelligence into that number.

MR. BARRY: First, it’s up to Lynne and Annette and their team to make the
decision whether they really want it. I’m just saying that we have provided it.

DR. WARREN: That distinction is helpful.

MR. BARRY: We are setting 1 percent of the capacity of the 9-row aside for
that purpose. That would be accurate.

DR. SUAREZ: To follow up on that, Peter, one of the numbers is NAIC co-code.
It looks like that is how Enumeron has enumerated plans already. Are you
recommending that everyone that has an NAIC number right now would get an NAPI
that starts with a 9140, and then the remaining sequence would be the actual
NAIC code?

MR. BARRY: Yes, but I would change the word. They wouldn’t get one; they
could get one. They can ask for it. Remember, the last statement was that they
have to overtly apply.

DR. SUAREZ: Oh, sure, yes.

MR. BARRY: What we want is accountability, responsibility for these things.

For the NAIC code, we are setting aside one-tenth of 1 percent of the
capacity of the 9-row for transitional reasons, the benefits during transition,
and that’s all. The Rx BIN set-aside has a more permanent character to it, if
they choose to use it. The ISO IIN set-aside is — it’s arguable whether it’s
worth 50 percent or not.

DR. SUAREZ: I also have another quick question on the table. This is very
helpful, by the way, the table on page 4, the list of all the potential rough
numbers. The very last row, medical group health plans — these are the group
health plans that an employer buys from an HMO?

MR. BARRY: Just a simple group health plan. Acme Transfer Corporation has an
employee welfare benefit plan, and they buy health insurance to benefit their
employees. They allow the employees to choose between, say, three products. If
you mandate every one of those, then we are going to need 4 million. If you
mandate every one of the employee options, you are mandating 12 million. That’s
a lot of identifiers. I can’t find the reason. That’s in that larger report. I
go through a table examining what the potential reasons are.

I didn’t say they shouldn’t be able to get one. I say it should be
voluntary. There are reasons why a group health plan may want it.

Moreover — AT&T is a mix of these, I believe — if AT&T wants an
identifier, I would just like to see this committee tell them they can’t have
it, when they just point to the law that says they can.

DR. SUAREZ: Thanks.

DR. WARREN: I forgot the second question I had. You talk about other trading
partners. I was kind of surprised to see research organizations. Are you
talking about the clinical trial groups or anybody that is doing research?

MR. BARRY: The idea is that any entity that routinely is involved in
electronic commerce in health care that wants a standard identifier, I think we
ought to give it to them.

DR. WARREN: And the same thing for the RHIOs and the HIEs?

MR. BARRY: Yes.

DR. WARREN: Because those also surprised me in here. You are talking about
giving them health plan identifiers or just other identifiers.

MR. BARRY: Call them something else, but put them in the same comprehensive
numbering scheme. As it stands right now, if it were Enumeron, it would be any
number beginning with 90.

DR. WARREN: Okay.

DR. SUAREZ: Any other questions for Peter?

DR. FERRER: Walter, this is Jorge. I thought that was very good testimony in
the morning. I would just make the observation that the API idea that Peter put
forward is very much in line with how Connect(?) is addressing the same
problem.

Another thing I would add would be that perhaps as folks are testifying
throughout the day and a half that is left — Peter has put a roadmap or a
solution forward. If people feel that that is not solving their needs, perhaps
they should voice that as part of their testimony.

DR. SUAREZ: Okay. Any reactions from the panel? Peter?

MR. BARRY: If I understood him right, I liked it.

DR. SUAREZ: He liked what you said and you liked what he said.

Michael?

DR. FITZMAURICE: I just want to say that — I won’t say it’s such a unique
experience here, but it’s kind of rare — Congress has given NCVHS a specific
charge. Karen has given us a clear explanation of that charge. I would like to
thank the testifiers for their directness and their simplicity. They
communicated a lot of complex relationships, saying this is responsible for
this part of the relationship, without getting us all immersed in a lot of
other things. It’s testimony like this that keeps us focused on the
straight-and-narrow and lets us make as good an adjustment as we can,
reflecting what the industry wants, with input from the public. Just a public
thank-you.

DR. SUAREZ: Thanks, Mike, yes. Actually, Peter was the one who mentioned it.
I think we had what, in my mind, sounded like a lot of very good information
across the board — excellent information, excellent detail — a lot of
commonalities, actually, a lot of consistency across a lot of the testimony.
That’s going to be very helpful.

We do have a number of areas where we would need to hear more. I’m sure
during the afternoon session we will hear more about some of those areas where
there are differences in perspective about enumeration applicability, et
cetera.

I think we are probably ready to take the lunch break. It is about 12:25. I
think we are going to give everybody an hour, until 1:30, let’s say.

Thank you again to all the panelists.

(Whereupon, at 12:25 p.m., the meeting was adjourned for lunch.)

AFTERNOON SESSION

DR. SUAREZ: Good afternoon, everyone. We are going to go ahead and get
started with our afternoon session.

The structure that we are going to follow for the afternoon is, we have
divided the groups into groups of four, in the order that they appear in the
agenda. We will hear testimony from the first four individuals. We are not
going to stop and ask questions after each person. We are going to just hear
the four individuals and then have a Q&A with the committee for about 15
minutes. Each person has been allocated about 10 or 12 minutes to provide their
testimony. Again, at the end of the first four individuals, we’ll have about 15
minutes or so with the committee for Q&A with any of the four. Then we will
go to the next group of four. So that’s the structure for the afternoon.

I don’t know if any member of the committee or the subcommittee has joined
on the phone who wants to introduce himself at this point. Anyone on the phone
from the committee or the subcommittee?

(No response)

Okay. Let’s start with the first group of four. We are going to hear from
Cathy Graeff, from Lori Robinson, Margaret Weiker, and Randy Miller first. I
know Randy is on the phone —

PARTICIPANT: And Lori should be.

DR. SUAREZ: Is Lori on the phone?

MS. ROBINSON: Yes, I’m here.

DR. SUAREZ: Perfect. And Randy Miller?

MR. MILLER: Yes, I’m here.

DR. SUAREZ: Okay, wonderful. Thank you so much.

So we’ll start with Cathy and then we’ll go down the list.

Agenda Item: Session A2: Reactions and
Perspective

MS. GRAEFF: Thank you. Good afternoon. I want to thank the Subcommittee on
Standards for inviting me to testify. My name is Cathy Graeff, and I’m the
consulting principal of Sonora Advisory Group, an independent consultancy that
provides consulting service to the health-care industry.

I have no conflicts, but I am a member of WEDI. I am a member of NCPDP. I
want to state that one of my current clients is Fox Systems, who is also the
NPI enumerator. I provide no consulting services to that business unit of Fox,
and none of my comments are directed towards the services of the enumerator.

You heard testimony this morning from Lynne Gilbertson, from NCPDP. I
participated in the drafting of that testimony, and I concur with her
testimony. I have either been a member of NCPDP or on staff for the past 20
years. It was while I was on staff at NCPDP during the implementation of the
NPI, and responsible for NCPDP’s two provider databases, which provided
crosswalks to the NPI, that I was invited to testify regarding the lessons
learned that we had from implementing the NPI at NCPDP.

Lynne testified this morning that the pharmacy industry developed a solution
for the routing of electronic transactions in real time over 20 years ago and
that the industry doesn’t see much benefit in transitioning to a health plan ID
for that purpose. In fact, I think she said, leave our BIN-PCN numbers alone.
NCPDP also had already developed a solution for identifying providers before
the NPI came out, but the industry did transition to the NPI for HIPAA standard
transactions. It was at great cost to the pharmacy industry, and they have
realized very little benefit from doing so.

Although there were many lessons learned, I’m attempting to bring forth
those that I believe have some relevance as we implement a national health plan
ID. I have grouped these into categories today. They fall under enumeration,
systems design, data dissemination, and other issues.

Under enumeration, what business problems is the health plan ID intended to
satisfy? This was brought up more than once today. I think as we strive to
develop a 21st-century system that improves the quality, safety, and
efficacy of the health-care system, we may be thinking beyond the original
intent of the identifier as it was envisioned by Congress in 1996. This isn’t
really bad in itself, though I believe from some discussions I have had with
others that, depending upon perspective, entities have very different visions
of what the business needs are for the health plan ID and what needs we intend
on satisfying. We need to be clear, as an industry, on what stakeholder needs
we have to solve with the health plan identifier and determine whether or not
the health plan ID is the right solution for those requirements. Certainly we
need to undergo this requirements analysis as an industry before we design any
sort of enumeration schema.

Involve industry early and often. I guess this would be the first
opportunity. This did come up today many times. During the implementation of
the NPI, we had hearings such as this, along with the participation of many
dedicated individuals in the Program Integrity Group at CMS, as well as OESS,
and also the WEDI NPI OI workgroups, and also many individual meetings with
concerned organizations.

Those of us who were in the trenches really believe that our concerns were
listened to often b CMS. They resulted in lots of FAQs that were on the CMS
website. Those were very helpful. I would encourage us to do a similar thing.

However, not enough CMS resource was developed to outreach during the NPI
implementation. That was especially true for smaller providers. Because CMS
wore two hats — really three, two hats, the Medicare hat and the regulator hat
— oftentimes small providers were confused as to which CMS was speaking when
they were being provided with guidance. Oftentimes the Medicare side of CMS was
the most visible to the small provider.

I have an example of that in the pharmacy industry. Many pharmacies also
handle DME. We found that in the case of Medicaid there were some Medicaid
agencies that were requiring pharmacies to get a DME NPI, as well as their
pharmacy NPI, which, we all know, they were supposed to enumerate as they chose
to. But if they wanted to get paid, that’s what was going to be required. I
must have had 50, if not 100, phone calls from sole proprietorship pharmacies,
Type 1 pharmacies, who wanted to enumerate so they could get paid for DME by
Medicaid, and yet the only solution I had for them was to incorporate so that
they could get Type 2 NPIs.

We need to think through some of those business rules as an industry before
we implement those rules. I think similar errors could happen as well when we
move towards a health plan ID.

Providing an electronic file interchange capability — no one has discussed
this today. There were some benefits that we realized that I think were not
expected. Of course, NCPDP was the EFIO, and is an EFIO, electronic file
interchange organization, for the nation’s pharmacies and enumerated tens of
thousands of pharmacies in batch. That allowed the pharmacy chains, especially,
not to have to individually key data. But there were some unexpected benefits.
Through that process, we developed edits at NCPDP and we did data validation
edits before we submitted that information in batch to the NPPES system. Those
data-validation edits helped to avoid many of the errors that people utilizing
the online process did encounter. In the case of a health plan ID, I would
expect that similar circumstances could exist, so I would suggest a batch
capability.

Another example was Target Corporation. The legal business name of Target
Corporation is The Target Corporation, but they enumerated themselves under
“Target Corporation,” and later on, when the system bumped up against
the IRS files, all of a sudden all of the Target Corporation claims were being
denied because of an invalid legal business name. We were able to correct that
situation with thousands of pharmacies in a batch mode.

So the capabilities of that batch were important in the industry.

We work closely, as I mentioned before, with people in the Program Integrity
Group and people in OESS during those months of transition, primarily on
business issues and process challenges during the enumeration process. As I
said, the FAQs were very helpful in helping to clarify process issues. A good
number of these issues could have been avoided if industry had been more
involved in the beginning of the process of requirements gathering for the
system and identifying business rules, as identifying gaps between various
systems within CMS itself. Because we were not as involved prior to the design
and the development of the NPPES system, some of that flexibility was lacking.
It lacked in areas of edit granularity. Some of those edits were added later,
like the legal business name edit that I just brought up that was not there on
day one, but showed up months later. The SSN EIN validation edits were not
there in the beginning. They did show up later and they did result in a rework
that was required. These kinds of things should, in a health plan ID
especially, be in the beginning of a system — those kinds of edits.

Another example was change of ownership. We talked to the Program Integrity
Group. The concept was that the NPI would be the number for the life of the
entity. Well, that makes sense if it’s a Type 1 human, but if it’s a Type 2
organization, how do you define the life of the entity? We ran into challenges
with switching NPIs when an organization was acquired or parts of the
organization were acquired but not the entire organization. The tax ID may
change. Can the NPI change, for example, when the tax ID changes? Can the
health plan ID change, or must the health plan ID change, when a tax ID changes
due to acquisition?

So it’s another consideration. I think some of these same business issues
could very easily come up in the future.

We were involved in testing of the EFIO capability within the NPPES system.
That was very helpful to us in better understanding the edits within the NPPES
system. But one of the things that we didn’t have a chance to assess until
after go-live was the impact of the real-time nature of the NPPES system
interacting with other internal CMS systems for Medicare and other areas that
were not real-time systems. If I was that Type 1 pharmacy that needed a number
for DME and for my pharmacy line of business and I bit the bullet and I became
incorporated, I had to submit a CMS 855 to change the Medicare Part B system
and I had to change the NPPES system. The NPPES system was a real-time system,
and at that time the system housing my data that the 855 was for was not a
real-time system. The lag was between four and six weeks. So the actual best
practice was to update using the CMS 855 first, wait until that system had the
new data in it, and then go and update the NPI system in real time. If you
updated them both at the same time, you were going to receive a problem with
claims payment. So I think when we do our assessments, we need to see what the
downstream systems are.

Privacy concerns slowed the release of the dissemination notice. Some very
simple questions were difficult to answer. I would suggest that the same kinds
of questions are relevant to the health plan ID. The NCPDP testimony this
morning was that “access to information should be restricted to entities
that are deemed appropriate to have access, but not so restrictive as to impede
timely claims submission payment and other transaction processing.” I
think that’s going to be a tough line to find. So I do think that
dissemination, which did delay the full implementation of NPI, is something
that we need to address early, especially as it relates to providers. It
appears that most providers would need access to the system. How do we
authenticate whether an individual is a provider and provide them with access?

We talked — and I’m not going to go into it any further — regarding health
plan ID cards and the downstream impacts of health plan ID cards, other than to
say if, for some reason, we enumerate improperly the first time, there are
going to be millions of health plan ID cards that might need to be reprinted.
This could be disruptive.

As a result of my early involvement in designing the WEDI ID card and NCPDP
ID cards, I did come to the realization that real estate on an ID card is a
major issue, both the human readable real estate and the magnetic stripe on the
back of an ID card. It seems likely that transitioning may result in a majority
of, if not all, ID cards needing to be reissued. This is going to be expensive
for the payers.

I appreciate the opportunity to testify, and I hope this insight will
provide you with more valuable information as we move forward. Thank you.

DR. SUAREZ: Thanks so much, Cathy.

Lori Robinson, you’re on the phone?

MS. ROBINSON: Thank you, everyone. Good afternoon. I’m Lori Robinson. I’m
the director of the Division of Plan Data here at CMS.

Here at the agency, I am the system owner and maintainer for the health plan
management system, or HPMS. HPMS is a secure Web-based information system that
is the system of record for the contract and plan data for the Medicare Part C
and D programs, which include Medicare Advantage, prescription drug plan
sponsors, cost plans, and some other related programs, like PACE and some
demonstrations.

If you are following on the slides, I’m going to move to slide 2.

In this response, I’m going to briefly touch on three points. First, I want
to provide a high-level description of our current process here at CMS for
enumerating entities that participate in MA and Part D. I also want to review a
few statistics to illustrate the extent to which the C and D programs depend on
these current enumerated entities. Finally, I want to touch on some potential
operational impacts on the C and D programs of adopting a new enumeration
system.

On slide 3, I have three definitions. Here in Parts C and D, all of our
business operations revolve around these three organizational entities: the
parent organization, the contracting entity, or what we call the contract, and
the plan benefit package, which also you may hear as “Plan” or even
“PBP.”

These are very technical definitions that I got from our contracting staff.
Most of our operations are around the contract and plan levels. The contracting
entity, or contract, is the legal entity that CMS has a contractual
relationship with to provide health and/or drug benefits to Medicare
beneficiaries. The plan benefit package is a set of benefits in a given service
area offered by one of these legal entities under contract to CMS. The parent
organization is an overall company that has a controlling interest in one or
more of these contracting entities that we have relationships with.

As I said, most CMS business operations are built upon the contract and plan
levels, but increasingly more operations are focusing on the parent
organization entity, specifically in the areas of plan oversight and
compliance.

On slide 4, there is an illustration of the relationships between parent
organization, contract, and plan. One parent organization may be affiliated
with one or more legal entities that hold contracts with Medicare C and D. One
contract may offer one or more benefit packages to Medicare beneficiaries.

As a reminder, CMS does not have a direct relationship with the parent
organization. Our relationship is with the legal entity under contract. I
believe that’s the blue boxes on the illustration.

As an example, Aetna, Incorporated, could be a parent organization. Let’s
take contract B. That may be Aetna, Incorporated PPO. Then the three benefit
packages offered by Aetna PPO are maybe Aetna PPO Gold, Aetna PPO Silver, and
Aetna PPO Bronze. Those are the actual packages that are marketed to
beneficiaries. Those are the entities in which beneficiaries are enrolled, and
those are the entities by which CMS calculates payment to go back to the
organization. The plan level has that detailed benefit package information, as
well as the payment rates. They are all defined at the plan level.

On slide 5, I want to talk a little bit about the enumeration method for
Parts C and D. All of the MA and Part D enumeration is performed by the health
plan management system here at CMS. The contract numbers and plan organization
numbers are generated during our annual MA/Part D application process, the time
of year when prospective organizations can submit applications to participate
in either or both programs. The plan IDs are generated during the annual plan
bidding process. Every year, both initial organizations and renewing
organizations have to submit those bids that define what benefit packages they
are going to be offering for the upcoming contract year.

Generally, the way CMS assigns contract numbers is, we assign a separate
contract number to each legal entity/contract plan type combination. In the
example here, legal entity A would get one contract number for its local PPO
offering, a separate contract number for its HMO offering, and yet a third
contract number for its standalone prescription drug plan offering.

CMS has been enumerating contracts since the inception of the managed-care
program many years ago. We have been enumerating at the plan level since 2000.

On slide 6, we have a chart that illustrates the enumeration schema as it is
today. This is actually not all of the possibilities, but it’s a sample. For a
local MA organization, for example, they are issued an H number. An H number
consists H alpha digit plus four numeric digits following. Under that H number,
the local MA organization can then establish plan IDs. The plan IDs, as you see
in the chart, are three numeric digits. At CMS, the unique plan identifier for
our systems consists of the combination of the contract number and the plan ID.
So H1234 plan 001 is a unique identifier for a benefit package. As you can see,
the plan ID itself has no meaning unless it’s joined to the contract number.

You may notice that parent organization is not represented in this chart.
That’s because we generally use the parent organization as a means to aggregate
contracts and plans for operational purposes and for analytical purposes. For
most day-to-day activities, we rely upon the contract number-plan combination.

On slide 7, there are some additional notes on our enumeration scheme. At
this point in time there is little intelligence left in the CMS identifiers.
The leading alpha digit provides some high-level sense of organization type. H
is for local MA; R is for regional MA; S numbers for prescription drug plans.
But even there you really need to go down to a deeper level at the contract
attributes to be able to see what precise organization types you are looking
at. I think there used to be some intelligence in the contract number. The
numerics used to correspond to geographic areas. But over time it has become
impossible to maintain that because of the number of plans we have and just the
changes in the program.

Parent organization number and the four numeric digits of the contract
number are all randomly generated by HPMS. The plan IDs are also issued by
HPMS, and they are issued sequentially, beginning with 001. As well, HPMS
contains a whole lot of data about these organizations at the contract and plan
levels. We have a significant number of descriptive attributes in the database.
Just some examples of those attributes are the legal entity names versus the
organization marketing names, the type of organization, the type of plan, the
service areas at the contract and plan level, EIN, NAIC codes, tax status,
parent organization, legal entity, address. Those types of things are all
collected in the database.

On slide 8 are some high-level statistics of utilization of these
identifiers. Currently in 2010, we have 289 parent organizations, 802
contracts, and over 6,000 plan benefit packages spanning the MA and Part D
programs. Looking back at 2009, there were approximately 29 million
beneficiaries enrolled in these programs using these identifiers. As well, CMS
paid out over $165 billion last year for these entities.

The last slide: Current CMS identifiers are integral to all of our business
operations for the MA and Part D programs. They are used to manage the entire
contracting process, including the submission and review of applications,
provider and pharmacy networks, plan formularies, plan bidding. Also they are
integral to the oversight process for MA and Part D, including marketing
submissions, tracking of beneficiary complaints, plan reporting of different
data, compliance efforts, as well as auditing. As well, these numbers are
integral to the beneficiary enrollment and plan payment operation.

Obviously, changes to this enumeration schema would impact not only our
business operations, which, as I said, are built around these three entities
that we just discussed, but also, obviously, CMS’s internal systems for MA and
Part D, as well as our downstream partners in other federal agencies and the
plans themselves that participate in the program.

That is all I have. Thank you for the opportunity to speak today.

DR. SUAREZ: Thank you so much, Lori, for this testimony.

We are going to continue going through our testimony. Again, we will have
time for questions at the end of these first four testifiers.

Margaret Weiker is next.

MS. WEIKER: I’m Margaret Weiker. I am the director of business exchange
services at Hewlett Packard Company. Today I am speaking, however, as chair of
the Insurance Subcommittee for ASC X12.

The national health plan ID is accommodated in all of the ASC X12
transactions mandated under HIPAA. Focusing on 5010, since that is the version
that will be mandated when the national health plan ID is implemented, at a
summary level, the national health plan ID occurs 30 times. Additionally, it is
referenced in situational rules or segments and data element notes another 19
times.

These instances all occur within the actual transaction themselves, and it
does not account for any use by any willing trading partner of a national
health plan ID within the transaction envelopes, as can be mutually agreed upon
between the sender and the receiver ID. If willing trading partners mutually
agree to use the national health plan ID in the envelope structure, it would
function solely as a trading partner ID which is used to route transactions.

Instances of the national health plan ID in the transactions that are an
inquiry and response pair appear in the sender and receiver entity loops to
identify a payer when the payer is one of the two entities. The data sent in
these specific data elements are often used for sorting or routing purposes,
whether by clearinghouses moving provider transactions to a payer or sometimes
by the receiving entity to route to internal work queues. The most frequent
numbers used today are NAIC numbers, EINs, BCBS plan code, and proprietary
numbers.

There are a few specific instances that I wish to highlight that are
important for the industry to evaluate how current implementations use the
data. If the national health plan ID is defined differently than is currently
used, the impact to payers, providers, and vendors, both clearinghouses and
software, will be significant.

In the eligibility response transaction, the 271, both the subscriber
benefit-related entity and the dependent benefit-related entity require the use
of the national health plan ID when the benefit-related entity is a payer. This
would occur when the benefit-related entity is a different payer than that
identified as the information source or when the information source is an
entity other than a payer.

In the claim transactions, the claim filing indicator is no longer allowed
once the national health plan ID is mandated. The claim filing indicator breaks
down to levels such as preferred provider organizations, health maintenance
organizations, Medicare Part D, Medicaid, et cetera. This data element is used
quite extensively today in front-end edit routines, as well as claims logic
processing within systems. If payers do not enumerate at the level to which
they expect the claim filing indicator data and enumerate at a less granular
level, it will impact not only payer implementations and processing logic, but
also provider and vendor implementations as well. The inability to use the
claim filing indicator also occurs when reporting other insurance for the
policyholder, which impacts coordination of benefits claims as well.

In the attachment that I sent, pages 2 through 7 contain additional
information about the actual X12 transactions. For each of the HIPAA-mandated
transactions, you will see a listing of the loop, the name of the loop, a
little bit of an explanation of what it is, and then, if there is a qualifier,
what that qualifier means, as well as any associated situational notes for that
data element or segment or value.

Page 6 in the attachment — when I was referring to the claim filing
indicator, lists all of the claim filing indicator values that are in the
current 5010 implementation guide. That way you can see the level of
enumeration.

I would like to thank the committee for allowing me to speak. X12 stands
ready to assist. Thank you.

DR. SUAREZ: Thank you, Margaret.

Randy Miller. I think Randy is on the phone.

MR. MILLER: I want to start by saying thank you very much for allowing me to
present.

The NMEH is the National Medicaid EDI Healthcare Workgroup. It’s a voluntary
organization that represents membership from all 50 of the states, EDI
professionals in those states working in the Medicaid program, as well as
vendors that support the Medicaid program.

The NMEH is not taking a specific stance on the long-term view of the NHPI.
The major concern that the NMEH has at this point is, frankly, the timeline for
the implementation of October 1, 2012. Medicaid programs today across the
various states utilize different means for communicating back and forth. Most
of our subrogation activities, which are subrogation activities that take place
on the back end, where we collect money back from other health insurers,
utilize the National Association of Insurance Commissioners code for health
plans, as well as the bank identification number and process control number in
the NCPDP transactions for pharmacy benefit management. The Medicaid programs
and the NMEH look at that as something that could be used as a national health
plan identifier, at least in the interim, for October of 2012, and would like
to put out there a suggestion of working together on something further out in
2014 or 2015 that would actually give the industry the time to adapt and do
something that would be significantly more meaningful.

Any one of the proposals this morning has merit. There are a lot of issues
that need to be discussed and addressed prior to being able to implement those
presentations. We believe that a date in the future would be more applicable to
be able to implement a more in-depth national health plan identifier.

With that, I want to say thank you very much for the time to present. We do
have a letter that’s written. I didn’t want to read the letter directly, in the
interest of time. I’m available for questions.

DR. SUAREZ: Thank you very much for that.

We are going to stop here and begin to take some questions from the members
of the committee and subcommittee to any of these four testimonies. Bill?

DR. SCANLON: I have a question for Lori. You mentioned that the numbers are
assigned as part of the annual bid process. I was wondering, for renewing
organizations, as they change their benefits, do they retain the numbers from
the prior year? If I have a gold, silver, and bronze plan in an area, will that
be retained so that beneficiaries who are continuing in their plans can
continue to use those same numbers?

MS. ROBINSON: Yes, that’s exactly how it works. There is some very detailed
guidance published for the MA and Part D plans about what constitutes a
renewing plan versus a new plan. Those rules are published. But it is up to the
organization to identify through a crosswalk that they submit with their bid
that plan 1 is continuing this year, plan 2 is terminated, and we’ve added plan
3. So, yes, if it’s a continuing plan, they will retain that ID in the next
year.

DR. SUAREZ: Any other questions?

I do have a couple of quick questions, one for Margaret with respect to the
standard. What’s the maximum capacity that the data element for the health plan
identifier has? Is it 30 characters?

MS. WEIKER: You mean the length of the data element?

DR. SUAREZ: Exactly. Do you recall?

MS. WEIKER: I think the largest would be 30.

DR. SUAREZ: And it doesn’t have any restrictions in terms of alpha or —

MS. WEIKER: It would be an alpha-numeric. It could be a combination. I don’t
think special characters would be allowed, but alpha or numeric or both.

DR. SUAREZ: Great.

This is a question for Lori. This is all part, of course, of the
terminology. The enumeration schema that is used in MA includes parent,
contract, and benefit package. I think you mentioned — or perhaps it was
inferred in the description — the benefit package could be noted as a plan
product, if you will, in the sense that a plan entity could have different
types of products — in the private-sector market, I suppose, not specifically
to MA, of course.

Two questions. One is, what happens when the parent and the contract are the
same — in other words, there is no distinction between the two? Is there a
number that is given to — how do you enumerate in that case?

MS. ROBINSON: We still do create a parent organization code, even if it is a
one-to-one relationship between that and the contract.

DR. SUAREZ: Okay. In the benefit package, would you say that it would be
parallel to what in the private-market sector would be a plan product?

MS. ROBINSON: I believe so. I know from working on some recent projects that
there is sort of a difference in the non-Medicare market between a product and
a plan. In Medicare there is a plan. You take the plan as it stands. It’s a
uniform plan that is being offered. The only thing that can be customized is
something called optional supplemental benefits. The plan may offer, if you pay
$25 more this month, you can have additional vision coverage or something.

But that is the benefit package that is offered to everyone. It’s the lowest
level of detail that we go. It seems to me that it’s probably equivalent, but
I’m not very familiar with the terms that they apply in the private market.

DR. SUAREZ: Okay. Maybe just one more, Lori. This is related to the
enumeration that you have established, which is certainly different than the
ISO standard type of enumeration that we have been hearing from other
testimony. You mentioned in your last slide that, of course, there would be a
significant impact in terms of the operation and information systems and others
if there was a change or a shift or a recommendation that takes us in the
direction of an ISO standard type number.

In the NPI world, for example, when the NPI came about, every health plan
had its own enumeration internally of providers, and everybody ended up having
to create these crosswalks between the NPI and their internal enumeration.
Progressively, in many cases, organizations started to replace that and started
to, natively, if you will, use the NPI internally. But, still, there is no
requirement, really, for organizations to use internally the NPI as their
internal enumeration schema.

What is your perspective about that? If there was a national health plan
identifier that was based on the ISO standard, what would be the implications
— I know there would be many, but some of the most critical
implications  for the MA programs and how much a crosswalk would
alleviate some of those.

MS. ROBINSON: It’s difficult for me to say. Obviously, whatever
implementation you guys come up with will have different implications for us.
But it’s certainly not an impossible thing to deal with. It would take some
time. There is the general complication that all of these systems are now in
the process of gearing up for health-care reform changes as well that are on
aggressive timelines. Obviously, we just would need a lot of lead time to be
able to assess what type of impact there would be on the systems, line up the
contractor resources that we would require, as well as funding, to get things
moving.

My biggest personal concern is with the plan ID. In our world, the
three-digit numeric ID is — the way we establish that ID, it’s integral in our
bidding process. It’s not something where the plan comes and says at the
beginning of the year, “We’re going to offer 10 benefit packages. We need
10 IDs.” Those IDs are generated as part of the bids. That, to me, is a
little bit of a concern. If this national plan identifier were to go down to
that level, to that granular benefit package level, that would require
significant changes in the way in which CMS manages the bidding process. That’s
probably the part that worries me, more than some of the rest of it.

DR. SUAREZ: Thank you for that.

DR. SCANLON: Could I follow up on that? I asked a question about the
continuity of the numbers. I’m wondering, even though, when the bidding process
begins, in some respects there is kind of an open slate in terms of what’s
going to emerge as the different plans that are going to be offered, if a plan
is truly a renewing plan and can retain its number, then is there a problem
that that is being identified in this unique national identifier and that only
a new number is created when there truly is a new plan?

MS. ROBINSON: It’s not so much the renewing plans, but it’s the new plans.
With the bidding process, it’s a process that goes on for about two months. It
begins the first week of April and ends the first week of June, and during that
whole time period we have MA and Part D organizations in HPMS reconfiguring
their plans, probably lots of different ways, until the bids are ultimately
due, that first Monday in June and they submit.

The part that concerns me is that even now, contracts could be creating new
plans as late as one hour before the bids are due. As I said, right now those
new numbers are generated during that process in the system. It’s not like they
are pre-requested and given to someone. They do it on the fly. So it’s not so
much the continuing plans, but it’s when new plans are being requested.

DR. SCANLON: I guess, though, this morning what we heard about was the issue
of how this information that is going to be in the identifier, even though it’s
not kind of card-coded — I’ll use that term — how it is going to be helpful
to both providers and beneficiaries. If we don’t get down to the plan level,
are we not sort of handicapping providers and beneficiaries?

MS. ROBINSON: I don’t disagree with you. I just wanted to make the point
that operationally that would be a change for us, a significant change.
Basically, we would need to reconfigure the business process to deal with the
fact that that plan ID was coming from a different place and not something that
could be generated necessarily on the fly right before someone is submitting
their annual bids. It’s an area that we would have to seriously look at and
figure out how to deal with.

DR. SUAREZ: All right. Thank you to our first group of testifiers.

We are going to go immediately to the second group. We will start with Greg.

We will be taking a break after the second group   or perhaps the
third group, to give a little more time. We’ll start with the second group.

MR. FISHER: My name is Greg Fisher, director of Interoperability and Data
Standards at UnitedHealth Group, on whose behalf I present these comments.

UnitedHealth Group offers a broad spectrum of health benefit programs
through UnitedHealthcare, Ovations and AmeriChoice, whom you might think of as
typical health plans, and also health services through Ingenix, OptumHealth and
Prescription Solutions. Through its family of businesses, UnitedHealth Group
serves 75 million people worldwide.

Thanks for the opportunity today to offer comments on the national health
plan identifier. Our comments will focus on key goals of the NHPI, as well as
practical considerations for implementation.

We believe the goal of the NHPI should be to reduce costs by further helping
to automate and streamline the electronic flow of data, from eligibility
through claim payment remittance, to enable higher levels of auto-adjudication
and auto-reconciliation by creating unique identifiers for entities that
perform payer functions in the healthcare continuum.

We believe the purpose of NHPI is to identify entities that perform these
payer functions of eligibility administration, claim pricing, plan
administration, benefit funding, claim payment and remittance advice. The first
priority is to enable trading partners to route transactions properly to and
from entities that perform these functions. This allows use of NHPI in
administrative transactions not only for routing, but other existing
identification functions in the HIPAA transactions, such as identification as a
secondary payer.

Secondly, the administrative transactions contain many more opportunities to
leverage the NHPI for additional identification. We believe there should be an
ongoing effort to utilize this valuable health plan identification in the
administrative transactions, particularly in the X12N 271 eligibility response
and 835 remittance advice, to accomplish the goal of additional automation and
simplification. It could be used in the transactions to identify plan
administrator, funding source, and other requirements, if and when the
transactions are modified to accommodate those business requirements. We agree
with presenters that have outlined other uses for the NHPI as an identifier in
other areas, such as ID cards and other exchanges of electronic data outside
the HIPAA transactions.

We recommend that all entities that perform the previously mentioned payer
functions should be able to obtain an NHPI. We recommend that insurance
companies, HMOs, TPAs, and PPOs who perform pricing functions should have
NHPIs. Likewise, employers should be allowed, but not required, to obtain NHPIs
for their self-funded, self-administered benefit plans. The pharmacy industry,
which currently successfully uses BIN numbers for identification and routing,
should not be required to get new numbers. They should either be exempted or
allowed to convert their BIN numbers into a standard 10-digit number with the
BIN number embedded.

We believe the process of enumeration should begin with a complete
one-for-one replacement of payer IDs with NHPIs. This will make the initial
conversion easier for vendors and third parties involved in routing
transactions. Note that insurance companies, TPAs, and PPOs already have payer
IDs that are used for routing today, so there should be no change in the total
number of IDs to begin with. Additional NHPIs may be added as needed by the
entities. Each entity may choose to have a single number, such as a TPA or PPO
often does, or may choose multiples, such as a large national health plan
company with multiple locations, products, or subsidiaries might.

In terms of structure, we support the proposals to use a format of the plan
ID that conforms to ISO. If that standard is selected, we request that existing
users of the Enumeron plan IDs, based on the same standard, be grandfathered in
to allow those who have already enumerated with that registry to keep their
numbers. We believe that initially allowing the existing numeric payer IDs to
appear intact as part of a new NHPI is productive in the short term for
conversion purposes. Obviously, there should be no long-term plan to embed code
sets in the numbers, but we believe that initially allowing the 4,000 or so
payer IDs that already exist to be converted to NHPIs should not be a problem.
Note that grandfathered Enumeron IDs would already have the current payer ID
embedded in them, in some cases.

Enumeration can support any number of one-time one-for-one conversions, due
to the flexibility of the check digit approach. Since a number can be inserted
in any position that makes the last digit conform to the ISO standard, it
allows current numbers, like payer ID, to be transferred intact, to ease
conversion for the industry.

We recommend that the NHPI be allowed to be used to identify entity and
product line, as others have testified, and to allow benefit plan enumeration,
such as employer self-funded plans, as desired. If benefit plan enumeration is
mandated, we strongly suggest that benefit plan NHPIs be enumerated separately
in the registry to enable a user to differentiate between benefit plan type and
entity/product type. Possible solutions might include the use a different
initial digit or sequence, or segregating in the registry with a clear
definition of benefit plan versus entity/product. Future uses in the
administrative transactions may require differentiation of entity versus
benefit plan IDs.

A central registry should include information on the name, parent company,
location, product line, type, routing information, as well as, perhaps, the old
payer ID. This could be expanded in the future to provide additional
information about contract and fee schedule arrangements, for instance, and
other data. To ease automation, there should be a query function built into the
repository that can return key information on demand.

Other business requirements: Contract holder, contracts, fee
schedules, funding source, plan administration, and similar requirements have
been identified by industry sources as key relationships that could be
clarified using NHPI. Since all those are administrative functions and should
be covered in the HIPAA administrative transactions, UHG believes those
requirements should be brought to the X12 and CORE committees and included as
soon as possible in designated standards. We believe that the following agenda
can be accomplished in order.

We will commit to participate in the operating rules committee to identify
where NHPI can currently be used in the X12N 5010 versions of 271 and 835 to
accommodate the identified business requirements, as appropriate to the
individual transactions. I would like to note that we would need immediate
business requirements for that, because 5010 has already been programmed into
most folks’ systems. Any changes to 5010 and the usage rules would need to be
done immediately. We would like to avoid companion-guide differences in the way
people implement NHPI from payer to payer and vendor to vendor.

Secondly, we will commit to participate in the X12N workgroups for the 6020
version of the administrative transactions, to include whatever cannot be
accommodated in 5010, within the current limitations of 6020. I point out again
that 6020 is being delivered and developed right now for publication in 2012.
Any changes need to be done to that in the next nine to 12 months.

We would also commit to participating in the groups to look at 6040, the
next version of the X12N transactions, to accommodate all the identified
business requirements for NHPI that have been identified.

Having said that the timeline is the key between 5010, 6020, and 6040
versions of transactions, there is a limited amount of time to get both
development funds and requirements and everything else together in order to
meet those deadlines. Currently folks are working on ICD-9 and 5010 programs.
Anything additional for NHPI would have to be included in the timeline and fit
in with already existing obligations.

The concerns we have: The implementation of NPI caused some difficulty to
payers due to the lack of differentiation between Type 1 and Type 2 NPIs. Payer
systems handle Type 1 and 2 very differently, and there is no easy way to
identify the types from inspection or automated transaction. If NHPI ends up
enumerating both entities and benefit plans, we suggest that a clear
distinction be made through separate enumeration or registry documentation.

If the Enumeron number is not grandfathered into NHPI, it could cause the
reissuance of over 30 million ID cards for us alone, at some expense. Normally
we only reissue ID cards every three to five years, on a regular cycle.

We recognize that the initial conversion of payer IDs to NHPI will not be
truly one-for-one in all cases. There are cases where two payers currently
claim the same payer ID, so that needs to be resolved, and there are
non-numeric payer IDs that would have to get numeric NHPIs.

However, we believe that this change will be beneficial in the long run, to
simplify the routing numbers and control them in a central repository with
consistent rules and procedures. We recognize that there could be impact to
vendors and third parties that need to accommodate changes to practice systems
and transaction processing. Any new requirements should be implemented with all
parties in mind. The key here is funding cycles and vendor lead times and the
level of complexity. The more complexity, the more lead time is necessary for
the funding cycle to be determined from both the payer and vendor community.

In conclusion, we are willing to invest in supporting the NHPI for the
ultimate automation of the administrative processes. We believe it is the right
thing to do, because transparency and simplification benefits everyone in the
long run. We fully commit to participating with the standards organizations and
rules committees to incorporate the industry business requirements for
administrative payer functions and accommodate them in the next versions of the
transactions, particularly in the 271 and 835. We believe those transactions
have tremendous potential to be reworked to accommodate many new requirements.
However, we recognize that this investment will return a benefit only if the
adoption of the transactions increases. We fervently hope this NHPI initiative
will be introduced in a manner that will not inhibit the growth of EDI, but
rather be structured so that all parties, including health plans and
health-care providers, can adopt this effectively and encourage long-term
adoption of the transactions.

We appreciate the opportunity to present our response today. Thank you.

DR. SUAREZ: Thanks so much, Greg.

John?

MR. KELLY: My name is John Kelly. I’m the director of eBusiness Architecture
for Harvard Pilgrim Health Care, with headquarters in Wellesley, Massachusetts.

Harvard Pilgrim offers health-care products and services to over 1 million
members in New England and throughout the United States. In addition, my
experience is informed by 10 years’ tenure as a board member of the New England
Healthcare EDI Network, an organization formed in anticipation of HIPAA and
specifically chartered to facilitate collaborative activity among payers and
providers, in the interest of increasing the quality and efficiency of the
health-care revenue cycle process.

In full disclosure, I’m also a member of the AHIP Operating Committee.

I want to thank the committee here for the opportunity today to react to
this morning’s presentations.

Today I’m speaking on behalf of America’s health insurance plans. In
general, AHIP and Harvard Pilgrim support the proposal detailed today by Jim
Daley of BlueCross BlueShield of South Carolina. Within the spirit, though, of
today’s NCVHS’s processes, my remarks are as a reactor, and I will therefore
respond to this morning’s proceedings in that capacity and within my role as
industry representative.

As a statement of principle, Harvard Pilgrim supports the concept that steps
need to be taken to simplify the submission and payment of claims, and steps
should be taken to ensure consistent identification of health-care entities
involved in the processing and payment of claims. In my opinion, the best way
to address this is by not adding additional complexity in the development of
this regulatory proposal.

What I have here is a graphic of what we have established within NEHEN over
the course of the last 10 years. The reason I display it is because it speaks
to the fact that HIPAA, as flawed a process as it may have been, was actually
quite forward-thinking in the sense that it was looking at health care and the
health-care revenue cycle as a business supply-chain integration process, and
the transactions were actually designed to work in a little dance between the
provider and the payer. As an example of how we have made that a success in New
England, 10 years ago when this started, we were a million-member health plan.
We were rejecting 30 percent of our claims for member-not-found, no
eligibility. We were doing about 100,000 transactions — eligibility
transactions primarily   by phone. Today, as a CORE I- and
II-certified health plan, on a base of a million members, we are doing 20
million eligibility checks a year. Actually, the run rate this year is about 24
million, on a base of a million members. Our rejection rate for claims is, on
average, between 1.6 and 1.8 percent. We have some providers that have fully
integrated this transaction by using standards, whose rejection rate is less
than .1 percent.

I say that because it’s not that we have a particular genius or anything up
there or that we spend a fortune on technology. I say that because of all the
things that were done 10 years ago with the 4010 — all that took was getting a
bunch of providers and payers to sit down together and agree on a standard.

So I want to make that point as I go on. What we are looking at in terms of
the national payer ID is an incremental movement to try to take what’s on the
shelf, take the transactions as they are, not think about or wait for what
happens down the road, but see what we can do with what we have.

The lessons learned from that exercise we did in Massachusetts and New
England with NEHEN: The key to this is collaboration, leveraging existing
transactions, and primarily integrating with the vendors in a
machine-understandable format. Those 20 million transactions I referenced are
because scheduling systems at hospitals and in providers’ offices are nightly
extracting their schedule for the next day, creating an eligibility request,
sending it to my machines. We process it, send it back that night, and they
upload those transactions into their machines. I think this is key as you
consider where we should be going with the national payer ID, in terms of not
just what it should look like or how it should be enumerated, but how it will
actually work when we think about doing machine-to-machine business. That’s
where the promise is, not just in making things a little bit simpler if we are
using file cabinets and paper.

Also along those lines, I want to echo the X12 comments made about the
various and specific roles that exist today in the transactions and that are
attributed to the various parties and the roles that those parties play,
whether it’s the payer or the billing agency or the intermediaries, in the
transactions, in how some might be served by the payer ID and others, by
different standard codes and identifiers. That is, if we are talking about
products or we are talking about fee schedules, putting all that in a payer ID
may not serve us in the long run. The model of HIPAA as it currently stands
took a decade to put together. Although I have certainly many things, in
retrospect, that might have been done differently, I just want to say that we
have been able to do quite a bit with what we have.

It’s also important to look for guidance in the original HIPAA definition of
the payer. To the degree that we don’t have to rewrite that definition, I think
we can avoid further time spent achieving consensus. If we establish the
original definition as a baseline, it will help to clear the path forward and
actually take us, I think, much more quickly toward answering the question
about granularity and what belongs in the ID and what doesn’t. Much of the
input and controversy that went into that definition I think is valuable to
save. In the interest of expediency, I think we should use what I would call
what the original framers gave us.

Many have cited the problems with the implementation of the 4010. Although
5010 has addressed many of these issues, I would argue that it was the
inconsistent and bare-bones implementation of the standards by the industry
that has caused most of the problems, and not limitations of those
transactions. We don’t need to wait for 6020. I think operating rules can
address the majority of, if not all, the issues identified, if they are applied
within the 5010 transaction. For example, product is and always has been
available as a discrete field within the 271 transaction, and the others as
well. Unfortunately, its use and definition was poorly defined. Consequently,
the practice-management systems have never incorporated product as a field in
their workflow. So they can’t do anything with it. They can’t tie anything to
it.

On the issue of granularity, with reference to a number of statements made
this morning, and with regard to all the possible sub-flavors of the national
payer ID, let me provide an analogy with the national provider ID
implementation. When that first came out, we, certainly, and most of the payers
I know had provider IDs that embedded location, fee schedules, which tax ID
they were with — all kinds of things. We even provided provider IDs to
providers so they could do their bookkeeping, if the doctor was working in one
office in the hospital rather than another in the hospital. Over time, what
happened? Any given provider might have 5 or 10 or 15 IDs, because every one
had all this other stuff embedded in it. Over time, again what happened was,
they stopped submitting the right ID. They had the IDs, but on the claims they
sent them to us, and then we had to figure out which one really applied. Then
we spent millions on systems to correct a problem that we created for ourselves
in response to provider demands.

Then, when we went to NPI, we spent millions and millions of dollars trying
to unravel all that embedded information, to be able to work with just the NPI,
the tax ID, and the taxonomy. So what took us millions to fix — a problem of
our own creation — had we had the foresight to keep it simple and use other
attributes within transactions to identify what a fee schedule us, what a
product is, what a location is, all of those things — if we had done that
originally, implementing the NPI would have been a piece of cake. It would have
been hundreds of thousands of dollars rather than millions of dollars because
we could have just built a simple translation table and a map that could have
converted over to our existing numbers.

I think that’s a good analogy when we look at the national payer ID. We
could really wrap ourselves around the axel if we try to solve too many
problems with that one ID number.

Specifically, the MA proposal references fee schedules. During the
question-and-answer session, though, the term “allowed amount CPT
code” was used. Those terms are not interchangeable. They are very, very
different. The assumption that they are the same leads to some significant
problems. Fee schedules are baseline lists of CPT codes and dollar amounts. But
in every contract I’ve seen — and that’s just in a fee schedule contract —
there are always plus and minus multipliers that are applied, based on specific
agreements, mutual agreements, between the services. Just telling someone a fee
schedule doesn’t necessarily tell you what the multiplier is with that specific
procedure at that specific location. So it gets a lot more complicated than
just saying we can post fee schedules.

Allowed amount, further, can take into account a number of factors like risk
arrangements, situation- and location-specific case rates, pay-for-performance
criteria, and carve-outs. If, for example, someone does a procedure in one
situation, they may pay it as a fee for service. If they do it as part of a
transplant procedure, it’s part of a carve-out that gets paid by somebody else.

So, prospectively, in a 271 transaction, it would be virtually impossible
for us to say in every case what fee schedule is going to be used until we
actually see the claim come in the door. That’s why some of the payers actually
are moving toward — and there is a big movement with the high-deductible
health plans to say, if you could send us kind of a pre-claim, we could process
it and have a payment estimator. That’s a different function. That’s a
different transaction. If that’s something that the industry demands, then we
should talk about that, as actually people already are deploying.

Consider also the complexity that ensues from an attempt to specify fee
schedule information within a health plan identifier. Many payers negotiate
fees separately with hospitals. Each of the fee schedules results in a separate
identifier. Even in a small state there could be 50 to 100 hospitals that
participate in one or more networks each. Taking the simple example, 50
hospitals, each participating in two networks, would result in 100 health plan
identifiers just for one health plan, just for one state. Additional
identifiers would be needed for the fee schedules associated with physicians
and group practices.

These fee schedules often change also whenever physicians change
affiliations, when groups merge, when negotiated rates change. Maintenance of
information embedded in a health plan identifier would have to be updated in
real time as claims are processed continually. We can’t just do it every night.

I also want to point out that embedding meaning in numbers is dangerous. I
agree with every issue identified, but I think the proposed fix will not really
solve the problem. Importantly, most, if not all, of the information needed to
address the problems cited here today is or could be available in real time by
promulgating robust operating rules for the 271, the 277, and the 835. The
current conundrum results, as I said before, from the fact that we just have
not implemented these transactions, loops, and codes in the ways that we could.

The other thing that seems to be not well understood with fee schedules is
that the benefits are not usually fixed at the time that the patient is seen,
because, based on situation, we choose the fee schedule at the time. It has
been said that providers have multiple connections with different networks. On
any given procedure, a certain network would apply. I would say that the
providers are the ones signing these contracts with these multiple networks. As
a health plan, as due diligence and to keep our premiums down for our employer
groups, we look and see if there is a contract out there that might apply at
the time we get the service. There is no way to keep every contract that every
provider has participated in up to date in any single repository for any plan.
So being able to say that we can know exactly what network, what contract is
going to apply at any given time — as long as providers sign multiple
contracts with multiple networks for the same services, that can’t be put on
us.

Finally, on granularity, with all due respect to my colleagues, I think the
wisdom of enumerating plan lines of business simply because of very complex
internal business processes on our part should be viewed with skepticism
relative to administrative simplification. At its heart, the national payer ID
conversation is a small part of a broader conversation on supply-chain
integration. It requires process redesign on the part of providers and payers,
so that we simplify our processes, so we don’t necessarily have to enumerate
hundreds of lines of business just so we can keep things straight.

I think the one thing not emphasized today is that we must address the
systems that providers use in their offices to conduct these transactions. Many
of these systems have not been updated in years and are not capable of
supporting any kind of robust provider ID. The systems are not read to
accommodate the processes needed to eliminate paper in the administration of an
office situation.

The last thing I would like to say is on the issue of “if it ain’t
broke, don’t fix it.” Grandfathering existing enumeration schemes, where
feasible and reasonable to meet goals of ease and speed and efficiency, makes
sense, but we need to beware the trap of assuming something is working relative
to the possibility of the future. If you mean claims are working because we can
get things from point A to point B and claims get paid, then that’s okay;
that’s working. But if you look at what could be a robust situation where you
have a well-constructed national payer ID that’s using machines and intelligent
Internet registry to get things from point A to point B, I think that would be
a much better situation, and you wouldn’t consider the present situation as
working.

I think, in conclusion, AHIP and Harvard Pilgrim wholeheartedly support the
efforts of this committee to achieve real improvements via the use of a
national payer ID. My own small hope, though, is that Harvard Pilgrim’s payer
ID doesn’t look like supercalifragilisticexpialidocious.

Thank you.

DR. SUAREZ: Thank you so much, John.

We have next Dan Powell.

MR. POWELL: Thanks to the committee for allowing the VA payer side to make
testimony here. My name is Dan Powell. I’m the assistant director for
operations at the VA Health Administration Center, or the HAC, in Denver,
Colorado.

HAC administers a variety of health benefit programs for the VA. Most of
these are veteran dependent programs — for instance, the civilian health and
medical program for the VA, or CHAMPVA — and one is veteran-centric — that
is, the foreign medical program.

HAC is aligned with the purchased-care operation of the Veterans Affairs
Chief Business Office, or the CBO. The CBO purchased-care operation serves as
the payer and/or provides administrative oversight for payment for all VA
health benefit programs for veterans and their dependents. That is, it pays for
the health services purchased by the VA in the commercial sector. It is
considered a covered entity per HIPAA.

Other programs under the purchased-care operation would include fee basis
and Project HERO, which are both programs for veterans.

I would like to briefly address the following six topics:

The format of the proposed identifier.

Accommodating uses across industries.

Enumeration guidance or strategy.

NHPI database design and functionality.

Connection to the health plan ID card.

Implementation timeline.

Transition issues.

Elimination of multiple health plan identifiers may be difficult for VA
payers to implement in the short term. VA would obviously have to modify core
application functionality, test, and implement the NHPI changes in a multiple
VA payer system.

Potentially there is less value add. Should format issues with the change to
the new identifier cause routing problems, claims would not be routed
correctly, and that would result in less processable claims, while increasing
the overall billable transaction volume to VA payers.

In addition, there is really kind of an ownership issue here. Historically,
VA health plan identifiers were assigned by a third party — for instance, the
automated clearinghouse or the PBM. To ensure claim routing, it’s clear now
that VA has to take ownership of their identifier and really operationalize its
use and enumeration. This is potentially true for a number of other covered
entities, particularly small or medium-size health plans.

However, I think VA payers need to focus on what the benefits of NHPI would
provide in the long term. A single unique ID number for one health plan will be
easier to track and less expensive to use in the long run. A fully considered
and carefully executed implementation of NHPI, which is what we have talked
about a lot all day long, could remedy existing routing problems, leading to
more value add for the VA payer.

In addition, we would see that the identification and tracking of secondary
payers would be streamlined, and it could facilitate automation of claims
generation to secondary payers and eliminate the need to drop the paper. For VA
payers, this would definitely translate to a higher EDI claim volume,
particularly since we are primarily a secondary payer, particularly on the
dependent side.

There are other benefits to be gained from the fact that the NHPI will be
standards-based. There would be better integration and interoperability across
a wide range of standards. We would see standard-based electronic transactions
— for instance, the International Committee for IT Standards 284 health
identification card. It’s also forward-thinking. Inasmuch as standards
anticipate future needs and build upon one another to meet those future needs,
a standards-based NHPI would do the same and reinforce that forward movement.

In addition, in terms of grandfathering, VA payers believe that schemas that
meet or exceed the standards adopted for NHPI should be allowed to grandfather
into the solution. For instance, that would be the 9-row that’s being used
presently by Enumeron.

We believe the NPI will need to accommodate uses across a variety of
industries. VA payers consider durable medical equipment to be a medical
benefit, as opposed to a pharmaceutical benefit. Currently we require DME
claims to be filed on a professional claim format, either electronically or on
paper. But potentially what that says is that we are asking our PBM to take
what may be submitted on an NCPDP format and convert it to an X12 format. A
standard that goes across those formats would be much more usable.

In addition, VA would like to move claims from a third-party liability, like
property and casualty, to the appropriate payer. Again, a common, uniform
standard would make that much easier.

While the list is not exhaustive, in some cases an alternative standard
identifier may need to be adopted for the following uses as part of the overall
plan — for instance, moving claims from payer to repricer or stop loss insurer
and moving claims from a payer to a health information exchange.

Regarding enumeration guidance and strategy, in terms of granularity, we may
need to analyze the various factors — i.e., a benefit structure, multiple
communication or processing sites, the need to separate groups or lines of
business — in each sector of the health-care industry to determine the best
level of granularity at which enumeration should occur. Clear guidelines,
including examples, on enumeration granularity should be provided by industry
groups and organizations — for instance, WEDI and NCPDP or X12. As a payer, VA
has a variety of programs, plans, and processing sites. It would be
advantageous to enumerate at a level of granularity that identifies these
elements separately, if it is determined that that is what is needed. However,
the database on which NHPI is built should be able to store and display the
necessary relationships between these various elements.

There is no need to overcomplicate or overuse the enumeration process. VA
payers should enumerate only to the degree absolutely necessary. Less may very
well be more in this case and will translate into a more streamlined and robust
— hence, usable — identification system.

That’s why we believe that research and carefully considered guidelines
should be a vital part of this process. VA as a payer would like guidance on
questions like the following: When is plan or group separation so difficult to
achieve within an organization’s boundaries that NHPI enumeration at that level
would be recommended?

VA payers feel strongly that research across a broad range of organizations
and industry sectors, robust discussion with adequate representation from all
groups, and consensus findings should lead to enumeration standards.

Finally, enumeration must be part of a well-managed NHPI system and
database.

In terms of database design and functionality, we would see that online
access would be quite important for ease of use and availability. It should
have a reasonable cost structure, which should be possible. Costs should be
spread out over the entire industry. The database should be secure. Speaking
from the VA’s standpoint and the issues we have undergone the last few years,
security has become quite an issue. Obviously, thorough authentication and
verification of user, controlled access, and using secure Internet technologies
would be very important.

We also think that there should be some access options for the database.
Both a Web-based access for searches and lookups and access to database
downloads would be important for authorized users.

In terms of consensus, database and system design that is maximally usable
for both enumeration and data retrieval will be critical. It will be vital that
the database recognize the appropriate entity relationships between primary and
secondary plans, if both are to be enumerated, and between NHPI and other
trading partner identifiers. The design will need to accommodate different plan
structures and their manifold relationship. VA payers see industry consensus on
sound database and system design as an essential precursor to implementation.

In regard to health ID cards, undoubtedly there will be some stiff upfront
costs, both in terms of time and money, to implement any requirements and
incorporate the NHPI in new cards throughout the industry. Adequate time to
plan, remedy systems, test, print, and distribute new cards needs to be
considered when setting dates for the use of the NHPI in ID cards. Required use
of the ID card may need to lag behind other mandated uses.

Benefits to the industry due to NHPI will probably not be fully realized
until NHPI is incorporated into the ID card and the industry starts to
effectively use the information in this vehicle. There will, however, be
significant long-term advantages that accrue, and it will facilitate the
information needed to reliably identify secondary payers, which will strengthen
COB efforts industry-wide.

Any new rules promulgated should make clear that the NHPI should be used for
claim routing and that the NHPI will always be printed on and available from
the health ID card. The rules should create a distinct requirement around
routing based upon NHPI information on the ID card. When the routing
information changes for any plan, payer, administrator, or entity, new ID cards
need to be issued from that entity to provide the new information associated
with the new NHPI.

Finally, in terms of timeline, we think sequencing would be pretty
important. To a few entities — although I think that’s growing fewer in number
— two years to implement the NHPI sounds like a long time, but when you stop
to think about 5010 and D.0 implementation, you realize that the bulk of the
next few years is definitely going to be spent on implementing 5010 and getting
ready for the ICD-10 code set. The industry should consider a sequenced or
phased approach and how each implementation sequence fits into the larger
regulatory or compliance framework. Phase I might require enumeration and a
fully functional system. Phase II might require a testing period. Phase III
might require use of the NHPI as the sole plan identifier in HIPAA named
transactions. Phase IV might require use of the NHPI in a health ID card.

Again, timing of each phase should be worked out in relation to the 5010/D.0
and ICD-10 mandated timeframes.

Required use of the NHPI in the health ID card probably should have a
different deadline than required use of the NHPI in HIPAA named transaction.

Finally, in terms of transition, we think that the industry should weigh
carefully the pros and cons of a dual-use transition — i.e., mixed-use of the
current identifiers with the NHPI. VA payers recommend dual use during the
testing phase, at a minimum, and consider dual use for other phases if needed.

Again, thank you very much for the opportunity to supply this testimony.

DR. SUAREZ: Thank you very much.

We have one more person, Barbara, from VA.

MS. MAYERICK: I’m Barbara Mayerick. I represent the Veterans Health
Administration provider side of the house. I’m the director of business
development and responsible for the EDI infrastructure for the provider side,
our decentralized health systems.

Thank you for the ability to come and make comments. I have a few.

Relative to the identifier, it will need to provide all the information that
is necessary to route the claim to the appropriate receiver. The plan
identifier needs to eliminate the separate payer identifiers for primary versus
secondary claim processing for the same payer.

With regard to the enumeration strategy, I was very glad to hear what John
had to say. We are, on the provider side, looking very much to keep things
simple. The enumeration strategy should be standard for the industry, and it
should occur at the health plan or payer level. If enumeration occurs at the
benefit plan level, it will increase the amount of administrative effort
required to maintain the association of the patient to the respective plan. VA
has very little capacity currently to do that kind of intelligence within its
system.

With respect to the administration, there should be a single administrator
of the plan ID who is responsible for the maintenance and the source of the
data. The plan ID information should be readily available to all registered
participants to obtain the source data to route transactions. Proactively, a
notification system is needed to communicate health plan changes to the
registered users.

With respect to enforcement, an enforcement strategy is needed if health
plans do not apply or publish their ID number. All IDs should be available to
all who have an appropriate business need to be registered on the enumeration
site.

With respect to the ID cards, the health plan ID cards will need to display
the plan ID. This requirement will result in additional timing for remediation
assistance, testing, generating, and the distribution of the new cards as well.

With respect to covered entities, the regulation will need to consider
covering or permitting entities outside of HIPAA, including workman’s
compensation and property and casualty plans. If the regulation is not applied
or allowed for those entities in terms of the plan ID and allowing them to get
them and be part of this whole process, we’ll need to look at an impact
assessment. Providers will then have dual processing, which is just harder for
us to maintain.

In terms of the timeframe, the two-year implementation timeline of October
2012 may not be realistic, given the HIPAA 5010 and D.0 requirements and our
current ICD-10 efforts under way.

Covered entities, we have seen with NPI, the provider ID, remediate their
system at various times. That impacts our ability to test and validate with our
trading partners or our indirect trading partners. So one plea also is to
support the end-to-end testing all the way to indirect trading partners. We are
currently seeing some health plans, at this late date, who have some level of
NPI in place, but not fully. It is problematic. It would help if that is taken
into account, and we can test end to end with our trading partners and indirect
trading partners.

We also suggest a cutoff for getting the health plan ID, so that the health
plans will have the ID well before the compliance date, which will allow for
the period of testing voluntarily across the industry, and the ability to test
and perhaps use dual- or mixed-use systems, as others have said, first, to sort
of do a level 1 implementation. Then the level 2 implementation will be,
finally, when we have proven that we can do it, to use solely the health plan
identifiers.

I agree also with some comments that were said earlier that we need to do an
industry requirements analysis. We need to look at the schema jointly. We need
to look at use cases and move forward collaboratively.

The bottom line for VHA as a health-care provider is that the more data, the
more information we must know about how a payer does business, and gather and
put that information together in order to process our claims, the more
administratively complex that is for us. So we are really looking for something
that is at the plan level, to simplify.

Thank you very much.

DR. SUAREZ: Thank you very much for the testimony.

We have now some time for Q&A from the committee. We’ll start with Judy.

DR. WARREN: The two VA people hit on something that has been bothering me,
and that’s 5010 and ICD-10. What kind of impact do you have on your IT teams if
we put this on top?

MS. MAYERICK: We have had a change in our organizational structure over the
last several years with regard to IT. Most of our IT is contracted. There is
the process of establishing a contract and bringing a contractor on board. So
we need to pristinely know our requirements in advance, go through the
contracting process, which is many, many months, and then get the folks on
board to do the development. Given what we are doing right now in preparation
for 5010/D.0 and ICD-10, it really would put quite a burden on.

MR. POWELL: And the payer side is very much the same. What you are really
talking about are two cycles of development, one on the business side to
develop the business requirements and one on the technical side to put an RFP
out for development on IT systems. You have two cycles that you have to deal
with. If you don’t get them lined up well, it’s a disaster.

DR. WARREN: Just so I understand what you just told me, if this is the same
amount of work that 5010 and ICD-10 are going to be, we have just doubled the
number of contracts you have to put out in order to get this done in the VA
system.

MR. POWELL: And potentially shortened the timeline.

MS. MAYERICK: In addition, it’s not only the contract, but then it’s the
finite resources on the business side that have to do the business requirements
in advance.

DR. WARREN: Right. Thank you.

DR. SUAREZ: I have a couple of questions, too, while others maybe think
about their questions.

The transition part — this is good that this particular group started to
address more specifically the transition period — actually, the transition
timeline is a little shorter than the two-year that has been referenced. In
reality, two years would be starting in October 2010, to have everything ready,
and then compliance would be in 2012. But I think it’s going to be a lot
shorter, given that the expectation is that the adopted rules would be
available July of next year for compliance in October of 2012. So in reality,
the transition plan, starting with the date the final rules get adopted —
let’s say it’s July 1 — will be only a year and three months, when you
think about it in those terms.

Given that transition period, I have three comments, I guess.

One is, there seems to be a need for some timeline to require the
enumeration to happen first. It’s sort of the sequence that we had in NPI. By
this date, every plan must have identified themselves, must have enumerated
themselves, obtained enumeration. Then the second phase would be the transition
between this date, which is the date the plans have enumerated, and October
2012, the transition and the testing and the dual use, which is an interesting
comment, I guess, to make, too. Then the third phase will be implementation in
terms of compliance, which starts October of 2012.

I just wanted to hear your reaction about that sequence and see if that is
consistent with how you would see things happening — for the four panelists.
Any reactions?

MR. FISHER: From the perspective of a commercial payer, I think I would add
one more to your list. You have to rules usage before you can do any
enumeration and then development. My concern would be that if the announcement
is made on what the rules are next August, in terms of the overall policy,
there still needs to be a period of time to say how each company is going to
take those rules in and determine if they are going to enumerate differently
than they are doing it today. Then that will drive the next series. So from the
perspective of a timeline, you are talking about announcement in July, rules
perhaps in November or December, decision on how to enumerate, first quarter of
2012, development in maybe the second quarter, testing in the third quarter,
and then come up — not likely.

The issue then is, you have all these separate activities, but to avoid
complexity and every one of having a different companion guide, the rules need
to be done after the policy is announced, and then enumeration starts.

DR. SUAREZ: Just one follow-up. Would you say the rules — what you refer
to.

MR. FISHER: The rules for 5010. It’s pretty clear —

DR. SUAREZ: The operating rules?

MR. FISHER: Yes. It’s pretty clear that not all the data in 5010 can handle
all the requirements being specified. For instance, in the 5010 271, there is a
qualifier that says PR for payer, and they also have one for primary payer,
secondary payer, and tertiary payer. What’s the difference between payer and
primary payer, secondary payer, tertiary payer? That needs to be written out:
This is how we are going to use the transaction with NHPI.

When you get right down to the transaction, you need to have rules saying,
here’s what we meant, five years ago when they built 5010; here’s what we meant
to do that. If there are things you can do with contract holder or funding
arrangement, they may be able to be done in the 271, but no one has looked at
it to say how you do enumeration. Depending on which way you enumerate, whether
it’s at the entity level or the product level or the benefit level, that
changes the definition of how you use it.

So I’m looking at it as a policy, then enumeration, then definition.

DR. SUAREZ: Great comment. Thank you.

DR. WARREN: Let me just follow up. When you are talking about rules, does
this also include the decision by the payer on how granular to request IDs for?

MR. FISHER: That’s correct. I would say the policy and then the rules would
determine the granularity.

MR. KELLY: This may be a bit of a self-serving response. It, to some degree,
depends on how complicated you make it. If you are trying to solve all the
problems that people want to solve, then there is a long time, not just to
implement and decide and determine the rules. In our world, half the time,
testing takes more time than development and deployment. Especially in more
complex, large organizations like Greg’s, you are testing with hundreds, maybe
thousands of people.

If, on the other hand, you are looking at the original HIPAA regulations,
which anticipated a field length that would accommodate the current format, and
if all you are saying is that wherever you use payer ID now, use this one
instead of that one — if you are not trying to solve all those other problems,
then I think you are looking at — if you could get that decision out quickly
and whatever operating rules needed to be established around the 5010 and its
use, and not require a whole lot of new fields in the 5010 with the operating
rules, then I think you are looking at — it’s hard to answer your question,
depending on which way you look at this.

DR. SUAREZ: Before the other questions come up, any other reactions?

(No response)

Let’s go down the table. Bill.

DR. SCANLON: It’s a question about granularity, which has come up a number
of times today. What CMS is doing with Medicare Advantage and the Part D plans
— I think you can easily see the connection between that and the program that
they are administering in terms of the structure of that program and the
accountability that’s needed.

The question I would have is, given that they are all going to be part of
this, too — as well, I think, the exchanges are going to be taking on some of
the similar kinds of functions in terms of accountability, and maybe even
insurance commissions will start to get more interested in that — is the
additional burden of going to that granular level that CMS has been using so
onerous compared to if we have a plan identifier that is at a higher level, and
people are going to start coming in and saying, “Now we want more
information”? CMS comes in and says, “We want encounter data that
doesn’t tell us just what a plan, according to the plan identifier, is doing,
but we want it done just the way it is today,” which is their plan
identifier, which is down to the product level.

I’m wondering about this tradeoff here, that if we allow this flexibility
and if we allow for higher levels of aggregation, whether that is going to be
an undoing of simplification later on, because we recognize the very important
ability to disaggregate to this product level.

I know some of you have had experience with Medicare, and so I’m
particularly interested in your comments.

MR. KELLY: I’m just going to say this sort of general level. All of us, I
think, are in the situation we are in now because we grew up with legacy
systems and we organically developed the stuff and the enumeration processes we
have over time, as we grew and we merged and we changed and the environment
changed. I would say that if you get all of us in a room and said, if we had to
do it all over again — if you look at this as kind of a data-modeling exercise
and say, these are all different attributes of this thing you are trying to
name — in any database modeler’s world, you would create a separate field, in
a rows-and-columns database, and say, if you want to specify an address, it
goes in this field; if you want to specify the first name, it goes in this
field; if you want to do the last name, it goes in this field. Everyone will
tell you that if you don’t do that, eventually you are going to pay the piper.

I’m in a system right now where we are fortunate enough that we are ripping
out our old system and putting in a whole new system. We are going through the
exercise across all enumeration, whether it’s members, whether it’s providers,
whether it’s internal staff, of basically saying, okay, we get a chance to do
this right this time. We are taking all of that stuff out of numbers and we are
modeling the data the way any other exercise would do it.

DR. SUAREZ: Karen?

MS. TRUDEL: Actually, this question is for you also, John. You did mention
that you thought that some more robust operating rules for the 271, 835, and
277 could solve many of the information gaps that were described this morning.
Could you talk about that in a little bit more detail?

MR. KELLY: Sure. For example — and this would be work on our part,
certainly, too — the 271 allows you to actually ask for a specific procedure
type or a specific location for a specific doctor. I think Tammy mentioned
earlier that a lot of this stuff is in our systems. We do have to adjudicate
the claims. So we know that. Getting it out of those systems is not always as
easy as it sounds. But if we knew that that was the model that we were supposed
to be approaching — again, we are putting in a new system, and we are
certainly anticipating use of the specific 271  we would be able to give
— right now, even with CORE II certification, with existing legacy systems, we
are supplying 71 different benefit data elements to coinsurance, the remaining
deductible, all of that stuff, and providers are finding that very useful
information. The fact that none of the systems can actually do anything with
it, other than that they can look at it on the screen, write it down on a
Post-It, and then turn around and key it in, that’s another problem.

But I think when you look at whether it’s product, whether it is responsible
party, whether it’s the group name — all of those fields exist in the 4010.
Self-insurance — we tried to put that in. We had to kind of kludge it. But in
the 5010, there would be a place to determine right away whether a person is
fully insured or self-insured.

We also encountered the issue with self-insurance that we are not sure
patients want us to divulge their employer’s name without their consent. I’m
not sure, when the contract is based, whether it’s fully insured or
self-insured, whether anybody needs to know exactly who the responsibility
fiduciary is, because the contract is with me, not with them.

I think there are a lot of things that operating rules could be used to
specify what information you need to make the system better and then find out
how the original framers of HIPAA intended for it to happen. That little loop
diagram, when you dive in there, is pretty robust.

DR. SUAREZ: Any other questions from anyone?

(No response)

I do want to ask another question. We might have to bring Margaret or
perhaps Gail Kocher in. This is a question about the transition and the
dual-use ability. In NPI, we had in the transaction — and this is a little bit
complex. Before December 31, 2011, we will still be under 4010. Starting
January 1, 2012, we will be in 5010. The question is, are the current versions
of the standards capable of carrying two payer identifiers in the same segment
and loop? I was looking at one of them, and it doesn’t look like that. That
will be a major factor in determining whether you can actually support a dual
use.

MS. WEIKER(?): In most instances I don’t think so. I would have to go in and
do an evaluation of every segment that had a payer ID associated with it. I do
know of one or two that allow an additional identifier in the same loop. But
there are only one or two of those, as I remember off the top of my head, that
would allow those. But for the most part, it’s one ID, one source, one
receiver, one payer. I can give you multiple other insurance types of things,
but it’s not to identify the same payer.

So, yes, that would be, I think, problematic.

DR. SUAREZ: Okay, thanks.

We are going to take a 10-minute break. It’s 3:20, so we will come back at
3:30 and we’ll continue with our panel. Thank you.

(Brief recess)

DR. SUAREZ: We are going to hear from our third panel of testifiers. We are
going to start with Annette.

Again, the same structure. We are going to hear from the panelists, the next
four, and then have a chance to ask questions after that. We will go through
the next three groups, basically. The last group is probably going to have five
instead of four, but we’ll manage it.

Annette?

MS. GABEL: Thank you, Walter.

My name is Annette Gabel. I am the executive director of industry standard
compliance at Medco Health Solutions.

I provided a FAQs sheet for what Medco Health Solutions is doing today, but
I am here today representing Medco, the prescription benefit manager, Medco,
the prescription drug plan for Medicare Part D, and two of our pharmacies,
Accredo, which is our specialty pharmacy, and Liberty, which is our diabetic
pharmacy.

I want to do some disclosures. I want to let you know that I sit on the
NCPDP Board of Directors. As you heard earlier, I chair the SNIP Committee for
NCPDP. I participated in the creation of the WEDI comments that you heard this
morning. I also participated in the creation of both the WEDI and the NCPDP
health-care ID implementation guides.

I want to thank you for the opportunity to come and present testimony today
on the national health plan ID.

What I did with my presentation — I’m going to make some reference to
NCPDP, not to duplicate the information that you heard this morning. When I was
asked to testify, to identify what the needs were for the industry on the
national health plan ID, I had a little bit of trouble because I couldn’t
really understand what the definition of health plan ID was. So in my testimony
I pulled from the HIPAA transaction standards what the definition of health
plan was. It’s in the testimony that I provided here. I’m not going to read it
again.

Obviously, as you have heard from the other presenters today, there are
probably a lot of opinions about what other reasons there would need to be for
creating a health plan ID. Medco has some of its own ideas. But what I first
want to point out is what we don’t want the plan ID to be, so I’m going to
start with that.

As you heard this morning during the NCPDP testimony, pharmacy has
successfully been using the BIN/INN and PCN for routing pharmacy claim
transactions. We process our claims in a real-time environment. When the
provider submits the claim using that information, they get a real-time
response back, and it gives them all the information that they need to provide
the individual standing at the counter waiting to get his prescription drug
what he is required to pay if there is a deductible involved. So there is a lot
of information that comes back in the real-time transaction standard.

I don’t know if that is some of the pain that the AMA deals with today,
because they are not processing real-time, so they are looking for a lot more
information up front. In the pharmacy side of the world, that information does
come back on the claim. So we have less need for that information in an
eligibility or benefit inquiry, because it’s part of the whole claim
transaction process. I just wanted to mention that.

The second part is that we do not believe that a plan ID should be required
on the prescription drug card. As I said this morning and I will reiterate, the
BIN/INN and PCN is all we need for routing. We don’t need the plan ID on the
drug card for routing purposes.

Medco follows the NCPDP Health Care Identification Card Pharmacy and
Combination IDs. This guide was updated last year to coincide with the WEDI
Health Identification Card Implementation Guide and now requires ealth a
complete 15-digit issuer ID be printed on the card. I pulled a section from the
NCPDP Health Care Identification Card Guide, just to explain what the purpose
of the card issuer ID was. There was a requirement by the INCITS standards that
the card issuer ID be on the card. Since NCPDP follows that guide, it was
necessary for us to create a default card issuer ID, and that ID was to be used
on all the pharmacy ID cards. So on behalf of the pharmacy industry, NCPDP had
been assigned a card issuer identifier — I put the number in here — that
had to be used on all pharmacy-only identification cards.

As we were talking through this when we were creating the WEDI Health ID
Card Implementation Guide, this issuer ID had absolutely no relevance to the
pharmacy industry. Although we fought very long and hard, we wound up getting
this default ID that was assigned by Enumeron. So while we found that there was
no need to have this ID, we were forced to have. As a result, Medco now prints
this default issuer ID on all of their prescription ID cards.

This creates some discussion with clients. When they come and say,
“Why, all of a sudden do we need this issuer ID? What’s the
relevance?” it’s kind of hard for me to explain why it’s relevant, because
it isn’t relevant. I have to point them back to the Health ID Card
Implementation Guide to reference that it’s a required data element on the
card.

Again, while we understand that this plan ID may have meaning for other
parts of the industry, as I said, it does not provide any additional benefit
when it comes to pharmacy claims processing.

We are suggesting that we review the requirement of plan ID on the
health-care ID card with the health-care industry to determine when it is
needed. I’m sure there will be situations where that plan ID will create
information so that it can be used for routing. But again, on the pharmacy
side, we have the routing information already on the ID card. That is essential
to us for pharmacy claims processing.

In the NCPDP ID Card Implementation Guide, it specifically states that for
pharmacy cards, the information — routing number, BIN/INN and PCN, when
needed, because PCN isn’t always needed — has to be present on the ID cards.
What I’m suggesting is, if you take this route, if the ID cards do become the
standard way to identify routing information, any time that routing information
changes, new ID cards must be issued. It has been Medco’s experience that if
you follow that process, it eliminates a lot of disruption when the patient
changes benefit administrators.

Now I go into what we think the plan ID should be used for.

As I explained earlier this morning in my NCPDP testimony, I described the
proprietary coding that exists today in the health-care industry. What I heard
from the two providers that I’m representing — and I went through that
Medicaid situation — that’s really the angst for them today, that when they
get the information back from the Medicaid agency, they don’t know who the
primary provider is. Although the insurance company may be a national plan and
it could just have one location for billing, they are finding that each state
has a different ID. When they go to the Medicaid agency, each Medicaid agency
has a different ID for that plan, even though there is only one location to
submit the transaction to.

Also as I mentioned this morning, a plan ID would help identify
reimbursement information. Again, from the provider’s side, what I heard was
that if a processor or a PBM is contracting with the provider, if they were
assigned a plan ID and that information could then be returned in the claim
response or in the pharmacy remittance standard, it would allow the provider to
manage their accounts receivable in a more automated fashion.

Medco has evaluated different benefit structures and can see the need for
plan IDs for benefit administrators when they are in a contract relationship
with a provider. Medco also believes that it may be necessary for the benefit
administrator to have multiple plan IDs when needed to identify a product line
or a product or a line of business. I think we heard that this morning as well
from some of the other testifiers.

We have identified above the need for insurance companies to have plan IDs
to help with coordination of benefits, but we don’t believe that an assignment
of plan IDs should be mandatory if there is not a business need for the entity
to be identified with a plan ID. We therefore suggest that before determining
the rule for enumerating a plan, all sectors of the health-care industry
provide examples of benefit structures. These should be used during the
analysis of determining who should receive a plan ID.

I just want to point out one example. If we went down to the benefit level
of identifying benefit structures, Medco has one client that has over 300,000
different benefit structures. So for that one client, you would have to create
300,000 plan IDs. I don’t think that’s where we want to be.

As far as the NPI, Medco believes there were a number of lessons learned
from the NPI and from the subsequent enumeration process. One lesson that we
did learn was that we didn’t think enough thought was given to how to create
the provider structures that existed before the rules were defined. As a
result, there was much confusion — and I think there still is confusion out
there — about who is eligible for an NPI and whether a provider could be
assigned more than one NPI. This initially impacted providers who required an
NPI for their specialty pharmacy business and a different NPI for their
mail-service pharmacy business. As suggested earlier, it is imperative we
review the needs of the health care before we create an enumeration strategy.
This will create a clear, well-defined process, and that should be outlined for
the entities — I mentioned this this morning — so that the entities who are
responsible for supplying and maintaining the national plan ID have a
responsibility to keep that information up to date.

Medco acts as a prescription drug plan for Medicare Part D and also
administers benefits for clients who provide Medicare Part D beneficiaries with
primary and secondary coverage. Therefore, due to the impact to these
beneficiaries and the remainder of the patients that Medco provides benefit
administration for, we cannot recommend an alternative to the BIN/IIN-PCN
routing.

Just for a few examples, the BIN/IIN and PCN are required for routing drug
claims, and for Medicare Part D, are used specifically in real-time
eligibility, financial information reporting, and information-reporting
transactions. The eligibility inquiry supplies providers with the beneficiary’s
coverage information, including COB information. When they do this query — so
when they send this transaction in — they get back the necessary routing
information in that inquiry. They use that to send the claims on to the primary
and secondary payers.

The FIR, which is the financial information reporting, and the
information-reporting transaction also use the routing information to enable
exchanges between processors and payers required to maintain accurate financial
balances for Medicare Part D beneficiaries. This information is so important to
the Medicare Part D benefit program that as of January 1, 2012, CMS has issued
a requirement that each individual, when they go into the pharmacy, if the
pharmacy submits a claim and the payer can identify that that individual is a
Medicare Part D beneficiary, and the BIN or PCN that is associated with that
Med-D plan is not submitted on the claim, we are to reject the transaction back
to the pharmacy. That’s how important it is for this benefit.

NCPDP put out a statement on the impact of any alternatives to the current
routing methodology, and Medco supports that information.

In closing, I just want to say that it is important — based on our past
experience with HIPAA regulations, if we create standards and they are not
adhered to, there will be more confusion and less administrative
simplification. While other rules have imposed penalties for noncompliance, it
is not a common practice for entities to report their trading partners. We have
seen that in the past. If it’s possible for CMS to audit to verify compliance,
maybe that would help solve some of the problems that we see today. Also having
some discussions with some of the Medicaid agencies, I have found that when
they have money, when they are being provided money to do something, whether
it’s to update a database or to move to the HIPAA transaction standards, they
seem to get into compliance a lot more quickly when they have the funding
necessary to do that. So if there is any way to provide incentives, I think
that would be very helpful.

In closing, I just want to say that I appreciate the opportunity. I would be
happy to answer any additional questions that you may have. As you move
forward, I would be more than happy to assist with any additional input you
need, as you go through and analyze the plan ID enumeration. Thank you.

DR. SUAREZ: Thank you very much, Annette.

Larrie?

MR. DAWKINS: Co-chairs and members of the subcommittee, the Medical Group
Management Association is pleased to submit our testimony on the issue of the
health plan identifier. My name is Larrie Dawkins. I am the chief compliance
officer of Wake Forest University Health Sciences of Wake Forest University in
Winston-Salem, North Carolina.

A little background on MGMA. It was formed in 1926. Our membership is
21,500. We lead some 13,700 organizations, which have about 270,000 physicians
in practice. The core purpose of MGMA is to improve the effectiveness of
medical group practice and the knowledge and skills of the individuals who
manage and lead them.

In my testimony today, I would like to focus my attention on what MGMA has
learned from a member survey which we have done some research for, reactions to
the key proposals, and offer a series of recommendations to assist NCVHS in its
determination on this important issue.

This is an excellent opportunity to streamline an important part of the
claim revenue cycle, defined in medical group practice as the cycle from
registration of the patient to actually having the account paid for. Currently
there is considerable ambiguity in the term “health plan.” Without
knowing which entity performs each role in the revenue cycle, physician
practices experience difficulties in processing transactions, reconciling
claims, posting payments. This adds to patients’ dissatisfaction and confusion.
Practices also face needless complexity when plans offer many different
individual insurance products that have different fee schedules and different
benefit schedules. In addition, health plan A may sign a rental agreement with
health plan B to administer a particular benefit, such as vision. In some cases
the practice may have a contract with A, but not with B. Yet they receive a
remittance from B. This irregularity can challenge the practice seeking to
identify the correct plan product during this stage of the revenue cycle to
determine if they are being paid correctly.

As outlined by AMA this morning, it is clear that the different entities
play multiple roles in the revenue cycle. These entities include those that
fund the claim, receive the claim, administer the claim, and contract directly
with the practice. We support the creation of separate identifying numbers for
each of these entities.

In an effort to leverage the expertise of our members on this administrative
process, MGMA initiated a survey with our Legislative and Executive Advocacy
Response Network, done in June and July of this year. More than 440 practices
participated, representing 17,000 physicians. The survey covered
multispecialty, single-specialty, small and large groups.

When asked if the health plan identifier should identify specific entities
in the revenue cycle, practice administrators responded, definitely. Ninety
point nine percent agreed or strongly agreed that the entity that funds the
claim — for example, the health plan, employer plan, or government health plan
— should have a unique health plan identifier. Eighty-four percent agreed or
strongly agreed that entities that receive the claim — for example, primary
payer, secondary payer, tertiary payer — should have a unique plan identifier.
Eighty-six percent of the entities that administer the claim, such as health
plans, pharmacy benefits, or other third-party administrators, should have a
unique health plan identifier. Eighty-six percent believe that contracts with
the practice should be identified with a unique health plan identifier.

Not in the testimony, but to answer the question that AMA deferred to MGMA
earlier, we contacted MGMA over lunchtime and found out that the data that MGMA
has shows that approximately 15 percent of the information provided at the time
the patient is seen does not have enough information to act on. This is
estimated to turn into about $800 million per year worth of extra work in each
practice. If you multiply that by 10, you start to get real government money of
$8.8 billion.

A key concern for practices has been that in some cases the remittance is
sent by a health plan insurance product that practices do not have a contract
with. How prevalent is this? Almost 14 percent of our respondents stated that
this occurs more than 25 percent of the time. Some 30 percent say it happens
from 11 to 25 percent of the time. Only 3 percent state that they never receive
a remittance from a plan insurance product that they do not have a contract
with. Suggesting that this problem is not improving, fully one-third of the
respondents stated that over the last year the number of electronic and paper
remittance coming from health plan insurance products that the practice did not
have a contract with increased, 60 percent said it stayed the same, and 6
percent stated that it had decreased.

What is the impact on the practice receiving remittances from entities that
they do not have a contract with? Sixty-four percent of the survey respondents
stated that this issue requires additional time to process and post the
remittance, 63 percent stated that it requires additional staff time to
identify the health plan insurance product, and 47 percent indicated that it
requires additional staff time to contact the health plan on the remittance.
Just 15 percent stated they are not having a problem.

Not surprisingly, 89 percent of the survey respondents stated that they find
it very helpful or extremely helpful to have the health plan product identified
on the remittance. Just .2, less than 1 percent, indicated that they would find
it only helpful. Similarly, 96 percent of respondents stated that they would
find it very helpful or extremely helpful for the specific health plan
insurance product to be accurately identified when receiving patient insurance
eligibility verification. Ninety-five percent of the respondents indicated that
it would be very helpful or extremely helpful for specific health plan
insurance products to be accurately identified when settling
coordination-of-benefit claims.

Let me turn to the issue of the impact of the health plan identifier on
standard machine-readable cards.

The university health plan identifier can add additional utility to the
patient ID card. The identifier can facilitate the ability of the card to be
swiped at the time of service to initiate an electronic eligibility
transaction. For the purposes of the patient ID card, however, the health plan
identifier does not need to identify down to the health plan product level. A
number of health plans have already issued swipe cards to their customers, and
the health plan identifier included on those cards simply routes the card to
the correct health plan. From there, as we understand it, the health plan
utilizes additional information to identify the appropriateness of the
transaction.

When asked how helpful it would be for the health plan identifier to be
embedded in a machine-readable health insurance identification card to assist
in identifying in near real time all covered services for a patient, 88 percent
responding to our survey stated very helpful or extremely helpful. Only 2
percent felt it would not be.

There is a debate regarding the numeric composition of the health plan
number. We assert that there is considerable utility to having the health plan
identifier mirror the composition of the national provider identifier. Survey
respondents, when asked if the health plan identifier should mirror the current
NPI and be all numeric, 10 digits, to simplify the claims process and online
accessibility of health plan identifier numbers, 76 percent stated they agreed
or strongly agreed. Only 4 percent disagreed.

Although the NPI does not itself contain any intelligence, there is some
value to having a health plan identifier contain some basic intelligence. For
example, similar to credit cards, the first digits identify the issuing bank.
The health plan identifier could identify the health plan itself.

Our research supports the AMA proposal and confirms the need for significant
health plan identifier granularity on the back end of the transaction. This
granularity, however, should not be mandated on the front end. It is common for
patients to come to a practice without a health plan card or generally to not
have their health plan identifier number. If a granular product would be
required at that stage of the process, it would prevent the practice from
conducting a patient eligibility verification transaction.

Is there precedent for adopting a granular approach to this type of
activity? We believe that the approach that CMS used in NPI is an example of
this granularity.

After having said that, the MGMA has a number of recommendations that we
would like to address on this critical issue.

First, the health plan identifier is long overdue, and we urge that NCVHS
include in its recommendations to the Secretary that development and
implementation of the health plan identifier be expedited.

Second, in developing its recommendation to the Secretary, we urge the NCVHS
to strongly consider the administrative simplification opportunities
facilitated by the granular health plan identifier. Practice workflows will be
greatly improved by identifying each entity that is responsible for funding,
receiving, and administering the claim, as well as entities contracting with
the provider.

Third, in order to avoid workflow problems when patients do not have access
to the specific health plan identifier at the time of service, identifier
granularity should not be required for providers to initiate a patient
insurance eligibility transaction.

Fourth, in an effort to keep the health plan identifier numbering system
consistent and facilitate an easy industry transition, we recommend that the
composition of the number be the same as the NPI.

Finally, NCVHS should consider recommending or exploring the inclusion of a
minimal level of intelligence in the number, similar to what banks have done on
consumer credit cards.

In conclusion, MGMA strongly supports the development and use of granular
health plan identifiers. Identifying all the entities involved in the entire
reve3nue an claims cycle will significantly streamline administrative processes
for physician practices. Should health plans be required only to enumerate at
the broadest level, a tremendous opportunity to reduce unnecessary
administrative burden and expense on providers and improve patient satisfaction
will be missed.

We appreciate the committee’s interest in this topic. Thank you for inviting
us to present our views.

DR. SUAREZ: Thank you very much, Larrie.

We are going to go to Jim Whicker.

MR. WHICKER: Thank you very much. My name is Jim Whicker. I’m principal
technology consultant for health IT strategy and policy within Kaiser
Permanente, and until recently, was employed with Intermountain Healthcare as
the director of EDI within the Revenue Cycle Organization.

I should also note that I’m a past-chair of WEDI and participated in WEDI’s
development of the testimony that has been presented today.

However, today I’m representing the American Association of Healthcare
Administrative Management as their national EDI liaison. AAHAM is a provider
organization of individuals involved mostly on the business side of hospitals
and clinics. The following testimony is offered on behalf of AAHAM and does not
represent the positions of either my current employer or that of my previous
employer.

That all said, I have submitted my documented information. It’s online for
all of you. Rather than try to repeat everything that I think we have heard
several times today, I would like to just make a few comments and emphasize a
few things.

First, our recommendation is that we do allow every health plan that is
identified as a health plan within the HIPAA rules to obtain, and be required
to obtain, an NHPI, or a national health plan identifier. The recommendation
would also be to allow those organizations that have been mentioned several
times that are not covered under HIPAA — workers’ compensation, auto
insurance, and property and casualty — to obtain one as well. From a provider
perspective, there is really no difference whether it’s property and casualty
or a traditional health plan as identified by HIPAA in the business work, and
it would be helpful if they had a standard identifier, the same as others.

A second recommendation would be to then allow payers to enroll the
additional entities or subparts to obtain an NHPI when it met a business need
to do so. In addition, allowing other related entities, such as repricers,
TPAs, and so on, to enroll in and obtain a national health plan identifier.

There are several reasons for that. Those, again, are documented in the
written file that was submitted and is available online. But one of the key
things that we want to point out is that while allowing for a more granular
identifier than just for routing, we do believe we need to be just as cautious
on the other side and not get too detailed in identifier assignment and
overwhelm the industry with too many identifiers at too great a detail. I think
Annette mentioned that earlier today. If we are considering down to the benefit
level that would identify 300,000 different benefits, that’s way too granular,
way too much for the industry to take on.

However, in the recommendation from AAHAM to allow for the granularity down
to the line-of-business level, there is a real specific and what I would
consider valid need for that, from a provider perspective, that deals with the
traditional indemnity type of insurance. This isn’t in the testimony per se,
but we do talk about, when you look at a health ID card or when you are dealing
with a patient who shows up — the example I like to give is when I look at
Blue Cross of Utah, from my previous employment situation. The patient walks in
and says, “I have Blue Cross.” If we take that at face value and
query Blue Cross, I’ll get a response back that, yes, the patient has Blue
Cross. However, there are multiple plans or multiple entities within Blue Cross
that that patient could be enrolled with. If the patient is enrolled with a
line of business that that provider is not contracted with and still proceeds
to treat the patient and take care of the MRI and so on, there is a good chance
that that provider is not going to get paid for that service. In fact, often
that payment would go directly to the patient, rather than to the provider.

So knowing that relationship between the health plan and the patient, when
the patient shows up to receive services, is critical.

In my previous employment, I spent many years dealing with the HIPAA
transactions and trying to determine ways that, as a provider, we could develop
the return on investment that the transactions promised us. Those benefits come
in the 271 transaction, and knowing not only what the benefit is, what the
copay is, what the deductible is, and so on, but what entity that is that I’m
really dealing with in the health plan environment, and that same information
coming back in the 835 when a payment comes in to ensure that I got paid
appropriately. Knowing that it’s not just traditional Blue Cross, but the HMO
or the PPO that I may or may not be contracted with, is critical in knowing how
to deal with that patient up front.

Of course, if it’s an emergency type of situation or active labor, you are
not going to say to the patient, “You have to go home.” You are going
to treat the patient. But knowing whether or not the patient is enrolled in a
plan that I’m not contracted with — at that point, we can work with the
patient, and if appropriate, direct them to the provider site where they would
get full benefit for their services if they were to go elsewhere.

The key also is to know — if you deal with an entity that you are not
contracted with or that requires certain activity on behalf of the provider,
you need to know that up front when you are admitting a patient, if you have a
requirement notification. One of the state Medicaid agencies that bordered the
state of Utah had 14 different HMOs. Each one had different rules about
notifications, referrals, and so on. It’s real critical to know not just that
they had Medicaid for that state, but which one of the various HMOs within that
Medicaid entity I was dealing with as a provider.

There is another important note to remember when considering the need for
line-of-business indication within a 271 transaction. The HIPAA transaction has
an indicator for in or of network. The yes/no indication does not reference if
the provider is in or out of network. It only indicates if the benefits quoted
in the 271 are for an in- or out-of-network provider. That’s a significant in
between the usage of that data element. It’s important for the provider to know
what that network is that the provider is dealing with.

Within the Utah Health Information Network, we developed a standard that
said in the 271 and in the 835, the payer was required to give us the text in
the EB segment of the plan name. That works well until somebody in marketing
changes the name of the plan, and all of a sudden my mapping no longer works.
So having a standard identifier that I can refer to and check the database if
it’s not in my internal database would be very helpful in that.

Lastly — then I’ll let you move on and hear from other folks — the last
thing that I just want to mention in my written testimony is that we recommend
that the identifier follow national and international standards, be consistent
with current enumeration of providers, and be consistent with the next version
of the HIPAA transactions to be implemented in 2012. We recommend that the
groups responsible for development of standards, implementation guides,
instructions, white papers, and operating rules work together to ensure that a
clear understanding exists of what is expected with transactions in production
today, and appropriate enhancements are made in the next round of updates,
regardless of the final form that the identifier takes.

Thank you for this opportunity.

DR. SUAREZ: Thank you, Jim, for that testimony.

Finally, we will hear in this section from Laurie Darst from Mayo.

MS. DARST: Thank you.

I’m Laurie Darst. I’m the senior HIPAA and external relations coordinator at
Mayo Clinic. Just to note that I also participated in the WEDI development of
the national health plan identifier, participated in the sub-workgroup, and I’m
also on the WEDI Board of Directors.

I want to speak first to the ever-changing environment and the need for a
tool. Over the past decades, there have been substantial changes in the
health-care environment, including the proliferation of different types of
health-care products and benefit plans. We have also seen new relationships
form between health plans, third-party administrators, and rental network
preferred provider organizations. Trying to stay abreast of these ever-changing
relationships and new benefit plans is a challenge, not only for the provider
organizations, but for our patients also.

Given this evolving environment, we feel that the adoption of the health
plan ID is an opportunity to address some of these business challenges. To
solely consider the plan ID for the purpose of routing transactions would be a
missed opportunity to reduce ambiguity and increase efficiencies.

How can the plan ID help providers? The plan ID can help mitigate some of
the challenges by facilitating the identification of specific health plan
information, such as product line, network information, and self-funded plans
so the expectation of the health plan-provider relationship can be handled
appropriate at the time of patient registration using the HIPAA eligibility
transaction.

What’s currently missing? Our findings indicate that the information
currently reported in the eligibility transaction only reflects the
relationship between the patient or the subscriber and the health plan. It does
not provide information specific to the health plan and provider relationship.
Subsequently, network and contract information specific to the provider
initiating the eligibility transaction is not communicated.

Currently there is a field in the eligibility transaction to indicate in-
and out-of-network information. However, this simply reflects general coverage
information for the patient/subscriber, not specific information based on the
provider’s relationship. There is also a situational or optional free-form text
field to indicate product-line name. The challenge providers encounter in
trying to use this data field is, one, it’s optional, so it’s not always
reported; two, if reported, health plans may reference a product name
differently than the provider, subsequently creating some confusion; and three,
if reported, free-form text does not allow for any type of automation.

I want to talk a little bit about variances, kind of adding on to what Jim
talked about previously.

Many times a provider will have a contractual relationship with a given
health plan, but the contractual relationship is only with select product
lines. For example, if we have Blue Cross/Blue Shield in Minnesota, besides
their traditional Blue Cross/Blue Shield, they have Blue Plus, they have the
federal employees, they have Medicare Advantage, and they have about three
different PPO products. Most providers today would probably contract with four
of these, not all of these. So it’s critical for us to know which PPO network
— it’s different than benefit plans, and I think it’s going to be important
for us to get our terminology straight. As we talked throughout the day, we are
all referring to product lines and benefit plans a little differently. I think
we need a common terminology. We are not talking about thousands, like Annette
was referring to. We are talking about a few — help our patients and help the
providers.

In addition to the contract and network issues, there may be variances in
prior authorization and precertification requirements, based on those different
product lines within a specific payer. Enumerating by the product line and
network information would also allow us to do more precise prior authorization
and certification reporting.

The opportunity for efficiency: Providers need discrete plan ID enumeration
in the eligibility transaction which would allow them to automate their
registration systems by linking the plan ID from the eligibility inquiry to
their contract database. This would allow providers to proactively communicate
out-of-network financial information to patients before the services are
provided, reducing confusion and frustration for the patients. This level of
granularity would also reduce phone calls for all parties involved — between
providers and health plans, patients and providers, and patients and health
plans.

I just want to skip down to another important benefit. The health plan would
be returned in the remittance transaction. This would provide an efficient way
for providers to track reimbursement by their different contracts and also
provide a mechanism to do accurate analytics.

So in conclusion, enumerating the plan ID provides an opportunity to address
some of the complexities and challenges facing providers and their patients
today. The burden placed on providers and patients to try to deal with
determining appropriate financial responsibility would be reduced if specific
plan information was communicated at the onset of the patient encounter. This
is an opportunity to have the plan ID go beyond just functioning as a routing
number. Instead, it’s an opportunity to further administrative simplification
by eliminating ambiguity.

I would like to thank you for this opportunity to testify today.

DR. SUAREZ: Thanks, Laurie, for that testimony.

We have now an opportunity to ask some questions. Do any of the members of
the committee have questions? Karen?

MS. TRUDEL: I’m interested in getting a sense of what requirements would be
placed on the vendor community in order to be able to update their
practice-management software, in order to be able to make use of this
additional information. Are we talking about something that is a huge job? It
sounds to me as though a lot of these functions don’t exist today.

MR. WHICKER: I can respond, from my previous life as a provider, outside of
Kaiser, and not as a vendor myself, but knowing how our internal registration
and receivable system worked at my previous employer. The databases were
already set up. That’s how we track health plans today. We would have codes
that identified the major category of payer — UnitedHealthcare, for example —
and then we would have those critical pieces identified within that
organization that we needed to know, based on expectations, reimbursement rules
that we had with them. So the infrastructure, from my perspective, was already
there. It would be a matter of modifying, updating the databases with different
numbers.

MR. DAWKINS: I would agree with that. Most systems have a file already that
contains the insurance information. They are identified by number. So it would
be adding something to that file, potentially, as another field, which is not a
big change. It may already be there in some systems. But a lot of people
already have dictionaries that contain this information to begin with.

MS. DARST(?): I would just add to that that today it’s pretty much a lookup.
Using Jim’s example of UnitedHealthcare, our front-end people know that we have
contracts. We have to go out and take a look in the database: Is this one of
those scenarios? It’s moving from a manual process into a more automated
process.

MR. WHICKER: The key to that, though, is making sure that what my
registration staff thought they gathered at the time of registration matches
with what comes in on the eligibility, matches with what the payer identifies
their relationship with that patient is. That’s a mapping exercise that we do
today. It’s just a matter of how we do that and how clearly that’s identified.

MR. DAWKINS: And I believe a lot of us would tell you that we spend a lot of
time copying, photocopying, Xeroxing, scanning ID cards today, because we want
to be sure, when we have a problem, that we can go back and look and see what
the patient actually presented, and whether we got it wrong or it’s wrong on
the planned end.

DR. SUAREZ: Jim?

DR. SORACE(?): I was just curious. The number 300,000 came up. I would just
like a little more information. What level of granularity are we actually
talking about — thumbnail sketches of how that was calculated, maybe.

MS. GABEL: When you look at that level of granularity, it could be a
difference in drug benefit coverage. It could be that the plan has a different
structure for the coverage. They might exclude or include drugs that other
plans don’t. It could be that they have a closed formulary versus an open
formulary, an incentive formulary. It could be a difference in copay. Some
groups could have deductibles; other may not have deductibles. It’s really
getting down to the benefit level that the individual has.

DR. SORACE: And why 300,000 and not 30 million or 300?

MS. GABEL: For that particular client, they only have 300,000 different
variations of benefits for the groups that they insure. I imagine if you were
looking to go down to the benefit level and you had individual benefits at a
card holder level, then it would be in the millions.

DR. SORACE: But ultimately the system has to resolve that level of
complexity to handle the —

MS. GABEL: When you are talking about billing, I don’t see that as
information that you need to bill. If you are submitting a transaction, you are
going to get the information back on the transaction. I’m talking about
real-time environment here. You really don’t need to know   you
don’t need to know on the pharmacy side. You don’t need to know that I have a
$10 copay. When you submit your claim, I’m going to respond back to you and
tell you that that individual has a $10 copay, or they have a $100 deductible
that has to be met before that $10 copay comes into play, or the drug is not
covered, or they have a closed formulary. I’m going to respond back to that
real-time transaction, giving you all the information you need to complete the
dispensing of the drug and collect the money from the patient that’s required.

MR. WHICKER: A good-quality 271 transaction can supply that benefit-level
information as needed — differences in copays and deductibles and so on.

DR. SUAREZ: Other questions?

(No response)

I do have two. The first one is — I think a point, Laurie, that you made is
a very good one. During the break someone brought it up to me, too. It’s the
terminology issue. Of course, we have different terms. We have talked about
product line and product type and benefit packages and things like that. But
one term that has been used and has created some confusion, at least in my mind
somewhat, is the word “routing.” We keep saying this should be used
for routing purposes. It should be exclusively or primarily set to facilitate
routing.

Earlier during the day we heard that for routing there is technically the
aspect of the envelope in a transaction that allows the routing, if you will,
of the transaction. Then there is the more operational, practical aspect of
routing, which is, who do I send this to, in terms of the provider wondering
which payer this should go to.

I wanted to hear your expectation and understanding of what we are referring
to when we say routing is the primary reason why a health plan ID could be
useful — not the only one, but at least one of the primary ones. Is it routing
in terms of the identification of where to send the payment or the claim
transaction or the eligibility inquiry, or is it routing from a more technical
perspective of the envelope part?

MR. WHICKER: I’ll throw my two cents’ worth out on that. You mentioned the
two key components that I see in the routing world, the enveloping, which is
just getting the data from point A to point B — in my experience, at least in
the last several years, I don’t see a real big issue with that. We generally do
a pretty good job in the industry of getting claims from point A to point B,
from an enveloping perspective. Within the envelope of identifying the health
plan, again I think we have done a pretty good job of using what’s out in the
industry today — refer to the NAIC number or however you want to refer to it
— Aetna 60054, if you want to know the internal routing number there. But I
think in the industry we have done a pretty good job.

That’s why, when I look at the pharmacy industry, I would hate to see us
break what they have going on with the ability to route pharmacy transactions.

What I was referring to earlier in my discussion on the question that Karen
asked is that, at least from what I’ve seen in my discussions with most
providers, they have identified those different pieces of a payer in their own
internal databases, and how they identify those from an electronic perspective
that is repeating the 60054 for Aetna multiple times in the database. I know
all of these go to Aetna.

Identifying the subparts within the national health plan ID to identify PPO
1 versus PPO 2, and how Laurie mentioned it, to know whether this is the
traditional plan Blue Cross or the PPO 1 or the Medicare Advantage for Blue
Cross, that’s where that additional sub-element or line of business becomes
important. In today’s world, we don’t identify those in a routing perspective;
they all go to Blue Cross. When I get my transaction back from an eligibility
or from an 835, it’s really helpful. I think it becomes a barrier to a lot of
providers in the indemnity world to be able to implement an 835, because they
don’t know who actually paid that claim, and they are not able to really say —
unless you look at a physical, hard-copy claim with a logo that says Medicare
Advantage or PPO 1 or PPO 2, to really know who paid that.

If a payer sees a benefit of implementing that additional level of
granularity, it could assist in the automation of those transactions.

MR. DAWKINS: Walter, I would say, too, I think we have gotten much better at
knowing where to send it. The problem is that when we send it to a Blue Cross
or United or whoever, we don’t know clearly whether they are acting as their
product or they are acting as an ASO supporting an employer. The benefits may
be different there. The routing is all going to the same place, but the benefit
and what we should have asked the patient to pay for or should have gotten a
waiver to say they were going to be responsible or gotten a prior authorization
may be different. We understand, for instance, the United product. We know
what’s available there. But as each ASO can put things in and take things out,
those are the things that are very difficult for the front end to be able to
look at. That’s why we are talking about trying to get down to a granularity
where we can see that, so we can go look it up and say, okay, this patient is
in this ASO; what is it that is excluded that might be done at this visit that
we need to do something special about?

That all requires rework when it doesn’t happen, and sometimes you don’t get
paid.

DR. SUAREZ: Thank you.

I had a second question, but I’ll reserve it for later. I think we are going
to move on. Any other questions from the committee members?

(No response)

Thank you very much.

We are going to continue to our next panel. I think we are going to start
with George.

MR. ARGES: Thank you. I’m George Arges. I’m the senior director of the
Health Data Management Group at the American Hospital Association. On behalf of
our nearly 5,000 member hospitals, health systems, and other health-care
organizations and our 40,000 individual members, the American Hospital
Association appreciates the opportunity to discuss the adoption of the national
health plan identifier.

As others have mentioned, today’s hospitals face uncertainty in being able
to accurately identify the health plan responsible for processing the claim.
But the establishment of a viable process that not only issues, but also allows
for easy verification of a national health plan identifier is long overdue.
Today the lack of a national health plan identifier and the associated national
registry of national health plan IDs makes it difficult for hospitals to
accurately determine a patient’s eligibility for health benefits. This is
especially true when the patient presents without an insurance enrollment card.
It is therefore very important to move forward with the adoption of the health
plan identifier, along with a readily accessible registry that would allow the
provider to easily locate the patient’s health plan and corresponding national
health plan identifier.

The national health plan identifier registry should contain additional
information about the health plan, the type of insurance product, linkage to
the patient’s group or policy number, as well as links where one can obtain
more details about the insurance product and its benefits.

To keep the national health plan identifier and the national health plan
identifier registry current, a core set of business rules is needed on who
should get an national health plan identifier, the information that will be
contained in the registry, along with the registry, the frequency of updates,
and other search functions to allow for national health plan identifier
retrieval or validation.

From our perspective, it is important that there be a linkage of the
national health plan identifier along with the group or policy number. Ideally,
these elements should be present on all enrollment cards. Any entity assigned
the responsibility of handling and processing the claim should have a national
health plan identifier. Every group or policy number representing the specific
benefit plan of the subscriber should have a corresponding national health plan
identifier assigned for processing the claim.

With these core elements, the provider should be able to determine where the
claim should be sent and the parent or umbrella health plan ultimately
responsible, whether it’s a government or commercial plan, for the particular
group or individual covered benefit package.

The process for issuance of the national health plan identifier should begin
with the development of a registry that contains additional detailed
information about the category of insurance product, whether it’s HMO, PPO, fee
for service, et cetera; the name of the entity responsible for the issuance of
insurance coverage, whether it’s the health plan, the employer plan, the
government plan, and the national health plan identifier as well; the entity
assigned to administer the product and their national health plan identifier;
those processing the claim; and a group or policy number issued by the
responsible insurance plan.

Hospitals are interested in being able to correctly route the claim to the
appropriate entity quickly and easily, and to verify benefits based on the
group or individual policy number. The registry and the information contained
therein is the key to making this work. Each entity identified as the
administering agent is assigned a national health plan identifier and
categorized within the registry with the assigned routing number. Included in
this registry should be another lookup feature that would allow the provider to
find the group or policy numbers under which the subscriber is enrolled. The
registry must include information such as the name and address, mailing or
electronic communication addresses, for submitting the claim. It should also
include the parent organization’s name and national health plan identifier that
is responsible for the issuance of the group or policy benefit.

The AHA supports the approach that was outlined in the AMA paper,
particularly since it outlines many of the critical components needed by
providers. The illustration that the AMA had of the file cabinet provides a
picture of the many items and functions that will likely reside in the
registry, all of which are tied to the health plan identifier. These items must
be correctly managed and organized as part of the registry, along with lookup
features.

The previous CMS paper from March of 1998 also provided a good start in
identifying who should receive a national health plan identifier. But missing
are other types of plans, such as property and casualty insurance carriers,
workers’ compensation programs, and health saving account administrators. These
other types should also obtain a national health plan identifier. The CMS paper
indicated development of a national health identifier using nine digits, with
the ninth acting as a check digit. Since that time, others have suggested
following the ISO standard, which is 10 digits. We would support the 10-digit
length — basically, the ISO standard — for the national health plan
identifier, both of which can be accommodated in the electronic transaction
standard, as well as the paper forms.

The AHA thanks you for the opportunity to comment today. We’ll be happy to
answer any questions that you may have later on.

DR. SUAREZ: Thanks, George.

Given the time that we have, we are going to continue straight through the
remaining testimony and then reserve the last several minutes for questions to
anyone of the remaining testifiers.

We also want to acknowledge that we have received written testimony from a
number of organizations. They will be included in the deliberations of the
subcommittee and in the recommendations. We have received that, and we want to
acknowledge that.

Next is going to be Jerry.

MR. DIFFLEY: Dr. Warren, Dr. Suarez, members of the subcommittee, thank you
for this opportunity to testify today on behalf of the American Clinical
Laboratory Association, which represents national, regional, and local
laboratories.

My name is Jerry Diffley. I’m corporate director of patient compliance and
billing compliance for Quest Diagnostics.

I appreciate your interest in developing a unique health plan identifier for
HIPAA standard transactions. Because clinical laboratories are HIPAA-covered
entities and regularly exchange both clinical and claims data with health
plans, ACLA is taking this opportunity to testify today.

I would like to focus my testimony on the patient experience when they
obtain clinical laboratory services and the pressing need to create a unique
identifier and the necessity for appropriate sequencing of the implementation.

Clinical laboratories, like other health-care providers, submit claim data
to health-care clearinghouses and/or directly to health plans in order to get
reimbursed for the services they provide to patients. However, unlike other
providers, clinical laboratories also receive orders and payer information from
electronic medical record systems. Due to the absence of a unique health plan
identifier, laboratories often get incorrect and/or outdated billing
information from the physicians’ EMR systems. Physicians typically map their
own internal insurances and insurance codes to the appropriate clearinghouse
identifier that corresponds to the different payers in their respective plans.
When the physician submits payer information directly to a clinical laboratory
via its EMR system, the laboratory must create unique mapping for that
physician and each physician with whom it does business in order to properly
submit the laboratory claim to the payer.

When a physician adds a new payer to its EMR or practice-management system,
there is not a corresponding mapping to the laboratory’s internal insurance
code. A lab must then invest time and resources to attempt to properly identify
the correct payer. Failure to properly identify the new payer and manually map
the corresponding proprietary insurance code has a devastating impact on the
patient experience, since more than likely the patient is not identified
correctly with their insurance plan and is billed by the clinical laboratory.
The burden is then shifted to the patient to communicate the correct
information to the lab so that the lab can correctly bill the claim.

Adds, deletes, and changes to either the physician’s EMR system or the
laboratory system create havoc, resulting in patient dissatisfaction and manual
rework by all concerned.

The bottom line is that this is, at best, a resource-intensive process,
prone to breakdowns, that could be dramatically improved with the development
and use of standard unique identifiers.

Congress saw that this area was ripe for the use of standard identifiers and
had this insight when they mandated the promulgation of the final rule to
establish this unique health plan identifier in the act.

As mentioned, the development of a unique health plan identifier for HIPAA
standard transactions is very important to the clinical laboratory industry.
ACLA recommends a unique identifier that not only identifies the payer, but
also includes within the identifier something that further enumerates the plan
within the payer.

Once developed, the implementation of the standard needs to be carefully
coordinated. As members of the subcommittee are well aware, there are a number
of upcoming changes providers are preparing for, including the transition to
the ICD-10 and the conversion from the 4010 to 5010 transaction standard.
Allowing providers ample time to implement these programmatic changes, and not
doing so concurrently, will be essential to the success of a new unique health
plan identifier.

Thank you for allowing me the opportunity to testify today. I hope I made up
some time for you.

DR. SUAREZ: You did, and we appreciate that.

We’re going to continue. I think the next testimony that we have is Ellen
Cannon.

Just in the interest of time, if we can ask you to focus, perhaps, on the
key highlights of the recommendations and findings of your testimony, we
appreciate that.

MS. CANNON: Thank you for inviting me and telling me to be brief. I have
trouble with that, but I’ll try to be brief.

I’m here today because somebody recommended that I speak, based on my
experience with the NPI, the national provider identifier. In 2004, I entered
the MMIS unit of West Virginia Medicaid. Because the national provider
identifier was then unknown territory, my boss pointed me toward that work. I
volunteered as a workgroup chairman for the national provider identifier.

What I found out was that there are a lot of different aspects to the health
industry. Down at Medicaid, it’s all about pharmacy claims. If we can keep the
people in their medicine, we can keep them out of hospital, so everybody is all
for pharmacy claims. When I did my research, I found that the pharmacy industry
is well served by their current process. West Virginia Medicaid would like to
see that continue. I think all the Medicaids would.

At Medicaid agencies, we have subrogation contractors who have successfully
developed individualized mapping systems to help us obtain the coverage from
other health plans that our clients are supported by, and we can’t afford to
lose that.

The approach to the national health plan identifier should be global versus
specific. The primary use would be for coordination of benefits within
Medicaid, or subrogation. We would not want to replace the pharmacy claims. We
can see a parallel between major insurance companies and the plans, with
varying health coverage and health plan companies and Medicaid agencies.
Recently, West Virginia Medicaid has changed their plans. They have a huge
market for HMOs. We are finally able to support two HMOs. We have one regular
Medicaid plan. We used to have three Medicaid plans, but now we have just one
again. But we will continue to have to support that type of activity.

When we did the national provider identifier, much of the work was done by
industry volunteers. Those industry volunteers are the glitterati of the HIPAA
world that I see here today. I am so glad to see that you’re still here.
(Laughter)

What you will find in Medicaid systems is that the states volunteered their
workers. They spent a lot of time getting local codes transferred to standard
codes. We found that there should be edits on the input of information for
provider identifiers. I would hope that the plan identifiers would have edits
as well. We managed to get a national provider identifier for West Virginia
Medicaid. It was not a good thing. Somehow we need to be able to certify that
these entities that are signing up for national health plan identifiers are
indeed health plans.

Medicaid agencies are struggling. The news that I got before I came here was
that Pennsylvania has taken drastic actions in response to increased Medicaid
costs. California and Ohio have already decreased the days of operation of
their state government. Many states — not just California and Ohio and
Pennsylvania — are having budget problems, and they are cutting staff. I am
blessed to work for West Virginia. For once in our lives, somebody did some
planning, and as long as the mines don’t go completely down, we are in good
shape, and I won’t be laid off. But that’s not true of many of the Medicaid
agencies. Many of the states have laid off employees. I don’t know if it got to
the Medicaid agencies.

I think the lady that spoke before from Medco had the right idea. If you
give Medicaid agencies money to implement a thing, they will do it. Perhaps we
could hire some of the California people who are only working four days a week,
who were really critical in our NPI implementation, and helpful. Maybe we could
do something with that.

There are current enumeration projects that are in place. They are going to
speak. But I recommend them.

I thank you.

DR. SUAREZ: Thank you very much, Ellen.

We’re going to go to Susanne Powell.

MS. POWELL: Good afternoon. My name is Susanne Powell, and I’m director of
government affairs with Emdeon. Emdeon greatly appreciates the opportunity to
share these comments with the committee today. I certainly acknowledge the late
hour of the day, so I’ll try to move through these comments as quickly as
possible.

First, I think we would like to spend just a little bit of time talking
about how payer IDs are currently used in the system today. There has been some
discussion of that already, but there are a couple of points we want to
highlight — one in particular that hasn’t come up today.

One area in particular that we would like to bring to your attention is the
concept of provider enrollment. How are providers actually enrolled with their
particular payers? As we think about that, the question that comes to mind, as
we think about the level of delineation, the level of granularity that is going
to be required — if we have to go down to the contract level, or even down to
the level of a fee schedule, will the providers have to enroll with each
individual or will there be some type of blanket enrollment process?

We think that’s a question to think about as you move forward and think
about the use of the NHPI. Again, in the current enrollment process, the payer
ID is used to accomplish that.

Another thing that’s important to point out is that payer IDs today are also
used in reporting. They are very important in that. For example, when the payer
returns a 277CA to us as the intermediary, the reports are sorted and then
delivered, based on the payer ID. The expectation would be that the industry
needs to tie these enumerations together. If not, how would that impact the
payer and the provider?

Finally, the payer ID also has an impact on remittance advice and payment.
We have touched on this a bit earlier in some of the other comments. If the
numbering system is based on group or contract or funding level, it could
increase the number of payments and remittances advice that have to go to the
provider, which could have some impact on efficiency. For example, if payer XYZ
enumerated 3,000 NHPIs, would the provider get one check or 3,000 checks from
the payer?

In the written testimony that we submitted to you, we put together an
illustration, Figure 1.1, which just tries to show all the current touch points
for the payer ID today. We just urge you to take a look at that and think about
how the payer ID is used today and what the relationship of that will be to the
NHPI, as we define it going forward.

We do want to go on the record as saying that we strongly support the
standardization of a payer ID and the concept of the development of a national
health plan identifier. There has been a lot of good discussion today about the
benefits of that. A couple of other benefits that we would point out would be
streamlining the maintenance of payer identification information, facilitating
more effective routing for claims, coordination of benefits, as well as helping
manage situations where we have merged or acquired entities.

We know from the discussion today that there is some variation in opinion on
the level of granularity that we want to look at in terms of development of the
NHPI. We certainly acknowledge that. In general, as an intermediary — we
will not repeat all of the reasons; those are all provided in the testimony —
in general, our recommendation would be that we think about starting out with a
less granular approach and work to keep enumeration at a higher level, leading
up to the 2012 deadline, just given that short time period, which is written
into the law. But what we think would be important to think about is some type
of phased approach that might begin by adopting the existing payer ID and
moving to allow for more granularity and additional phases later on, which I
know a couple of the other representatives have suggested today.

If we do take a higher level of enumeration, we need to think about all of
the needs that are expressed — and very well expressed — by the provider
community about the various pieces of information they need at the time that
the patient encounter begins. We believe that in order for them to get the
information they need, but at the same time to accommodate the challenges
associated with implementing a more granular approach by 2012, an alternate
solution that could maybe lead to consensus is to look specifically at the
eligibility transaction and begin to look at making enhancements to that.

As a specific example, if we think about the current standard, we know that
the contract number as one of the elements, as well as the group number, is not
required in the standard today. If those were to be required and if we were to
look at other enhancements to that eligibility transaction, combined with a
phased approach to the enumeration process, we might have a chance of doing a
better job of meeting the needs of more stakeholders within the timeframe that
we have to deal with under the law today.

Finally, there are just a few other considerations that I want to mention
before we close. One has been mentioned repeatedly by all of the stakeholders
today. That’s the continued concern about trying to implement this enumeration
system in the midst of the 5010 and ICD-10 implementation. It’s going to take
an enormous amount of resources for all the stakeholders. We need to think
about that as we develop and assess the level of complexity of the system that
we are going to be designing.

I want to reemphasize the question about provider enrollment. As we think
the approach taken for the NHPI, we just need to think about how we would
approach provider enrollment and whether there is an opportunity to do a
blanket enrollment as part of that process.

A third piece of payer edits. I don’t believe that has been discussed. Payer
edits today are driven also by the existing payer IDs. If a payer requires
their member ID to be 11 numerals, for example, we would enforce that either at
the desktop level or at the clearinghouse level. That’s all based on payer ID.
The question we just want to put on the table is, what impact will an NHPI have
on payer edits that are currently driven by the payer ID? Just a thing to think
about.

A fourth item, which actually goes back to a question that was asked earlier
by the committee, really deals with vendor interoperability. The question was
asked, what impact will it have on vendors, having to make a change to
accommodate an NHPI that has more digits than the current payer ID does today?
The fact is, Emdeon connects with over 600 channel partners. Many of those are
practice-management systems. A lot of those practice-management systems are
configured with five-digit codes. When you look at trying to make that
transition to a larger number, there is going to be a development implication
on that. It’s just important to note, and that might be an area that the
committee might want to explore in a little more detail when you have the
opportunity.

Also I just want to emphasize, related to networks — this has been raised
before — we need to think about specifically how managed-care network rentals
are going to be handled. Is there going to be one NHPI per network or will
there be one per network per payer? There are a lot of implications there.
Again, think about the networks.

In closing, I think what we would really like to leave with is just the
notion that we look for what is the most practical approach that can fulfill
the must-have needs of the broadest range of stakeholders, really trying to
keep in mind the intent of administrative simplification, and without
significantly increasing cost. We hope that perhaps a combined approach,
starting with a slightly higher level of enumeration, with the opportunity for
phasing, and then a serious look at the eligibility transaction enhancements
could be a good solution.

Thank you for your time. We appreciate it.

DR. SUAREZ: Thank you very much. Excellent.

We have John Quinn.

MR. QUINN: Members of the NCVHS, many of you know me; some of you don’t. My
name is John Quinn. I’m CTO of Health Level Seven International, and on behalf
of HL7, I would like to thank you for the opportunity to submit our remarks
regarding the upcoming regulations on national health plan identifiers.

HL7 International is the global authority on standards for interoperability
of health information technology, with members in over 55 countries and formal
affiliates in 35, with the U.S. obviously being the first.

HL7’s vision is to create the best and most widely used standards in health
care. As an SDO in the U.S., we collaborate closely with our fellow HIT SDOs
and have liaisons to those SDOs, as well as other industry organizations, as we
believe collaboration is extremely important. As we have always encouraged
others in collaboration, we will also vigorously support that requirement when
it comes to national health plan identifiers.

HL7 has reviewed and, in general, supports the positions of X12 and WEDI, as
they have been presented here earlier today. These position papers were shared
with us within the last week or so and we had time to review them. In the
meantime, since I wrote this, I have also had a chance to review NUCC, and we
strongly agree with their position as well.

We are making no formal statement about other presentations today, either
because I didn’t have a chance to read them before I got up here or their
recommendations fall largely out of the areas of technology where I would have
a particular opinion. When it comes to business rules of how to run payer
organizations, I’m not going to propose myself as any sort of expert. When it
comes to how we have to encode that information or how it’s traditionally coded
and used in IT systems, then I will take that position.

HL7’s customers, for the most part, are provider organizations, the HIT
vendors that supply those organizations, governments that participate in the
support and delivery of health care in the U.S. and other countries, and
organizations that support any of the areas I just described — for instance,
consultants, manufacturers of IT infrastructures, et cetera. Also — and please
make no mistake about this — all countries have health insurance. I know in
the U.S. we tend to think — because we are quite different in how we approach
it — that they don’t have the same needs and we don’t find exactly the same
types of demands being made on HL7 as the U.S. industry does. They use that
insurance to track the delivery of health care through mechanisms that closely
resemble our use of health plans and health claims.

HL7 standards are used to support this activity in many countries, with the
U.S. being clearly our largest market.

Health plan information is usually gathered by providers in an IT
application at a point of patient contact — for example, admissions,
registrations, et cetera — and then used for claims and billing purposes and
communicated to other IT applications, both within the source provider
organization and external to it. HL7 is almost universally used for the purpose
of supporting the provider IT application that collects and first communicates
this information. This is true in IT applications that support providers,
ranging from individual physician practices to very large, integrated delivery
networks and large government-owned and operated health-delivery systems. It is
possible or even likely that a new regulation for health plan IDs may require
changes to existing provider IT applications which could include screens,
workflow, and data elements collected, stored, displayed, and processed by
those applications. So it’s more than just the messages that are being
communicated.

Provider IT applications that collect and use health plan information
support workflows, processes — I’m going into a little more detail here —
business scheduling, registration, preadmission, et cetera. In small ambulatory
settings this occurs on a single practice-management application that has an
included billing component and does not appreciably involve HL7. So, for the
most part, from HL7’s perspective, we don’t tend to see a lot of interfaces for
small group practices and individual physician practices, because the billing
is done on the same system as the registration and scheduling.

In any environment that is large enough to include a separate billing and/or
financial reporting environment, HL7 is likely to be involved in the
communication of patient demographic, charge, and payer information to an
external billing application and also, possibly, an external financial
reporting system. If these assumptions are accepted, then it is safe to assume
that we are potentially looking at tens of thousands of existing interfaces
that could be impacted by this change. I’m not trying to be an alarmist; I’m
just saying that that’s the way the numbers work out. Many of these interfaces
have been sitting quite comfortably for at least 10 or 15 years as well.

The adoption and use of these existing HL7 interfaces began to occur as one
of the first, if not the very first, set of interfaces that were adopted in the
industry going back to HL7’s inception in 1987. As a co-founder of HL7, I did
work at that time for a vendor organization that was involved in HL7 for
specifically these purposes of needing to adopt standard patient demographic
and charge capture interfaces. Since this adoption was early in HL7’s life and
since the adoption was widespread, most, if not all, of these interfaces are
based on a family of HL7 version 2.X — that is, versions 2.1 to 2.6, 2.1 being
the first that was reasonably implemented. Please remember that it makes
little, if any, financial or technical sense to modify and upgrade an existing
working interface to any new version of HL7, whether it be 2.X+1 or version 3.
So it is safe to assume that all of these interfaces in the U.S. are, in fact,
HL7 2.X-based. That’s not true of the clinical stuff that was announced for
meaningful use last week, but it is true for these types of transactions.

I’m not going to go into the details, but there is an example in the written
handout of exactly what information is available to be moved that describes
insurance plans in HL7 version 2, including the data types.

Please note that, while text subcomponents are supported within the data
type, this construction primarily supports and external coding identifier where
the details of the health plan and guarantor and related benefit plan are
contained in an external code set database. In other words, the trend for years
has been going away from meaningful identifiers, going to meaningless
identifiers that access a database, so that you can update the meaning without
having to reissue the identifiers. This is a worldwide problem, not just a U.S.
issue.

It is also important to mention that HL7 has widely adopted the use of ISO
object identifiers, or, as we refer to them, OIDs. HL7 is also a registration
body to ISO for OIDs that are created by HL7 itself and its users. For
instance, when my company, who actually makes me available to HL7, was working
on an HIN prototype project, they were using version 3, and so all of the data
elements that they were accepting and using they were registering as OIDs.

An important concept of HL7 in the use of OIDs for vocabularies and in the
use of standards is that identifiers are best when they have no meaning in
themselves. That is, all meaning is contained in an external database which can
be updated without reissuing identifiers. Of course, the base assumption is
that we are using IT systems when we collect and use identifiers. But, after
all, is not that what this is all about, and we are trying to get away from
paper? So, yes, it does require the use of a computer, but that’s — my
feeling, I guess — what we are here talking about.

The current adoption of health plan ID information with HL7 outside the U.S.
— I was asked to give you some information on, specifically, Canada. So we did
a little research. It’s pretty easy. I have a couple of Canadian board members.

Shortly after the HIPAA laws were passed in 1996, I, as chair of the HL7
Technical Steering Committee, was asked to initiate a project in the HL7
financial management chapter — that is, Chapter 6, for those of you who have
any familiarity with version 2. Two events had occurred in the previous two
years that seemed to make this an unusual request. I was sort of floored by it.
One, HIPAA had just been passed, and it seemed like any HL7 claims
transactions — to do this would be impossible, since the then-recent law
specifically named X12, NCPDP, and ADA as the author of these transactions.
Number two, a year or two before the HIPAA law was put into law, HL7 had, in
the spirit of collaboration with X12, decided to kill, effectively, the efforts
within HL7 to create claims transactions, because X12 was already doing that
and was well established with the payer industry. So we decided not to
independently pursue it with claims transactions that would be sent to a payer,
and left that for X12N.

When I gave these reasons for HL7’s lack of interest to the petitioners, I
was informed that the request was coming — in perfect English, I might add —
from Canada, Australia, and New Zealand — possibly was a language that I
didn’t understand; I would have not assumed it was coming from somebody in the
United States — and that those countries, and later the Netherlands and
others, did not use X12 in their countries and wanted claims transactions that
were of similar syntax and technology as HL7, which was already widely used
within their provider organizations. So HL7 proceeded to develop claims
transactions — they kind of got a stamp on them, “Not for use in the
U.S” — in, first, version 2.X — I can’t remember the exact version at
the time; I guess I could research it — and, later, HL7 version 3. They are
intended to be used in realms outside of the United States.

My contact with our Canadian HL7 board member, Michael van Kampen, has
informed me that outside of a few nonstandard proprietary implementations,
Canada is now using an HL7 version 3 claims message. So for those who say
version 3 isn’t adopted anywhere, I guess that’s — whatever. I’m going to
state who last said that publicly.

A previous conversation that I had with a chief architect of Canada Health
Infoway, Ron Parker, also informed me that he had conducted a recent study and
found that X12 is not use by the Canadian health system.

If you want a bigger version that you can actually read, there’s a big
restrictive message information model that Canada is using attached to this
handout. You can see what data elements and what relationships between data
elements they are using. Admittedly, claims in the use of payer plans outside
of the U.S. tend to be more of a reporting and an enabling nature, as opposed
to the decisions that are made as to whether or not you pay for the patient’s
services. I’m not trying to be glib here. There is certainly much more
complexity in what we do in the U.S. with this. But there are a lot of other
examples out there right now, too.

Thank you.

DR. SUAREZ: Thanks so much, John.

Tim McMullen.

 

MR. MCMULLEN: Thank you. Good afternoon, everybody. My name is Tim McMullen,
and I am the executive director of the Cooperative Exchange.

Understanding that my testimony comes between you and Happy Hour, I will
keep this brief.

First of all, I want to thank NCVHS and CMS for holding these important
hearings and inviting the Cooperative Exchange to participate.

The Cooperative Exchange is the recognized resource and representative of
the clearinghouse industry for the media, governmental bodies, and other
outside interested parties. Our missions as an association for the
clearinghouse industry is to provide open access for organizations to promote
electronic transactions for the health-care industry by ensuring optimal
quality, value, and functionality, which is accomplished through enhanced
connectivity, quality service, and education of the health-care industry.

Last year our membership connected with over 300,000 submitting providers,
with over 5,200 payer connections, processing nearly 600 million claims
transactions, with a value of nearly $1 trillion.

I want to make it very clear that we support the concept of the national
health plan identifier, with a lot of the characteristics that have already
been expressed through the testimony earlier today, such as that it’s easily
obtainable, easily accessible for any entity that needs to use it, has
associated information that is easily updatable by the health plans, provides
the ability for providers and other entities to verify benefits, provides a
tracking mechanism back through the claim submission, claim status, and
reconciliation process, and, probably most importantly, that the format is
ANSI-compliant.

As clearinghouses, we attempt to do for our customers whatever is needed to
implement national standards. The number needs to be consistent for each payer,
with a sub-identifier attached to indicate the health plan, which would create
the need to eliminate crosswalks. Earlier today we spoke a little bit about
using the EIN, and the Cooperative Exchange could support using the EIN as a
viable starting point, provided the payers agree to use this number.

The two points that I really want to get across today: It would be of value
to our industry and ultimately reduce costs to not only have the organization
that is ultimately responsible for assuring the risk for paying the health-care
costs identified, but also any entity that processes or adjudicates health-care
transactions, such as property and casualty, which has been mentioned many
times today, or, for instance, a TPA, should be identified either through a
plan ID or a plan ID database that provides this information. All of the
functions of a health plan — administering the claims, contracting — should
have a health plan identifier if done by separate companies.

The other value would be if the NHPI provided format intelligence on where
to go to submit an eligibility transaction. This information would be included
in the NHPI database. I know that we talked about looking at who would be
willing to serve on some sort of committee on that database, and certainly the
Cooperative Exchange and its members are willing to do that. Of course, having
the eligibility information would reduce costs during the process of
enrollment, more clarity of the plan the patient is enrolling in.

Ideally, the way to reduce costs, from our perspective, would be a clear
indication on the insurance card, or whatever cared we have talked about, that
that patient presents to the provider of what health plan they are enrolled in,
because that’s actually where the problem starts. The card could have an
identifier so that the provider knows the payer and the plan, and can determine
eligibility from the identifier. It would make our systems far more efficient,
by starting at the front end. When the claim is generated, that number has
already been captured. It will make the process more efficient. It will get
adjudicated more cleanly. You could check on claim status. Reporting is
enhanced, including accurate reconciliation remits, and it would reduce the
rejection rate.

We applaud the discussion today and the opportunity to submit our
perspective. Thank you very much.

DR. SUAREZ: Thank you.

Gail, you’re next.

MS. KOCHER: Members of the subcommittee, I’m Gail Kocher. I’m director
within the Inter-Plan Programs at the Blue Cross and Blue Shield Association. I
do currently serve on the WEDI Board of Directors. This afternoon I am here,
however, as I was a co-chair of the National Provider Identifier Outreach
Initiative that WEDI held during the NPI implementation. We would like to talk
about — very quickly, I promise — our experience during that timeframe.

There are details about how NPIOI, as you will often hear it referred to,
was formed. Through a series of events and industry requests, WEDI stepped
forward and set up this outreach initiative to focus on education and
collaboration.

We had several goals to establish that framework. Key among them were:

To create standard and consistent messages on the national provider
identifier.

To serve as a coordinating body for the deployment of NPI-related
education and outreach initiatives that were implemented at national, regional,
and local levels.

To empower industry collaboration by engaging key industry stakeholders to
participate in and contribute to the programs and deliverables that supported
those outreach and awareness strategies.

To collect and disseminate readiness assessment information.

We have highlighted within the submitted written testimony a series of
activities and products that were issued over the three years of the NPIOI
existence, key of which, I believe, was the establishment of the industry forum
format, which WEDI continues to use actively today for 5010 and ICD-10. I do
believe, given the feedback and the attendance that we have seen at the two
held so far this year, that that definitely continues to serve a significant
value to the industry in terms of outreach and education.

We did an awful lot of audio casts that ranged from specific issue topics or
just general entry-level 101 topics.

Fifteen white papers were published over the three-year timeframe. We did do
several collaborations, some specifically with CMS and also with my current
organization.

In conclusion, what we found and the things that we felt were key out of the
NPIOI experience are:

Education and outreach is critical for all stakeholders.

Education and outreach must begin upon adoption of and ongoing throughout
the entire implementation of the national health plan ID.

Outreach and education messaging must be consistent industry-wide.

Stakeholders must communicate and work collaboratively throughout the
implementation process.

WEDI looks forward to partnering with the Department of Health and Human
Services, especially with the staff of the Office of E-Health Standards and
Services, as well as the industry as a whole, to facilitate a successful
transition to the use of the national health plan identifier.

Members of the subcommittee, thank you very much for the opportunity to
testify this afternoon.

DR. SUAREZ: Thanks so much, Gail.

Lastly, we have Sheila Frank, the Public Health Consortium.

MS. FRANK: I am definitely the person keeping you from Happy Hour.

I think half the people in the room know me in my former life as a voting
member of HL7, X12, NUBC, NUCC. I was one of the early members of the Public
Health Data Standards Consortium. I had a long career at CMS, where I helped
draft some of the original HIPAA regulations.

I have been retired for a while, and my only activity in the industry now is
as a member of the Public Health Data Standards Consortium, which is a national
nonprofit, membership-based organization whose goal is to empower the
health-care and public health communities with health information technology
standards to improve individual and community health.

The Consortium is committed to bringing a common voice from the public
health community to national standardization efforts. As a result, public
health now has active representation at X12, HL7, the National Uniform Billing
Committee, the National Uniform Claims Committee. We believe it’s very
important to be part of the process of creating data standards for today’s
health transactions.

The purposes of health data systems range from providing support for
clinical care to assessing the quality of that care and assessing the health
status of populations at the state and national level over time. The aim of
these systems is to inform sound health policy. I think that’s one of the
business problems that we need to identify that were discussed today. One of
the purposes that the plan ID can serve is to help with assessing health care
and health programs and health plans, and what models work best.

Early on, we identified a need to find a standard for categorizing the
different payer types for health transactions. None of the existing ones quite
worked. So we created a Code Committee to create the source-of-payment
typology. This standard was developed with cross-industry cooperation and is
maintained by, as I said, a Code Committee within the Public Health Data
Standards Consortium. It has been incorporated into HL7 as an OID, X12, and the
Uniform Bill standards. Even more significant is the fact that this typology is
currently being implemented into several state public health reporting systems
and is under consideration by national cancer registries and other entities.

The code set is posted on our website, along with the user guide and a white
paper on some of the implementations to date. The website URL is
www.phdsc.org. Changes to the code set are
made annually in October. Any industry representative may make recommendations
for changes and modifications via our website.

This is how it all fits in.

We believe that, just as the national provider ID has a provider taxonomy to
differentiate provider types, the national health plan ID should have a
codified typology for use in differentiating plans. This opportunity shouldn’t
be missed, as it would facilitate other requirements of recent legislation,
such as quality and cost measurement. Collection of these data during plan
enumeration and their availability to users of the plan ID registry would allow
researchers to answer questions raised by health reform.

I had a bunch of examples I was going to cite, but in the interest of time,
I just want to say that outcome studies done by payer typology — what kinds of
payment models we are using — can be very useful in the future to meet a whole
host of goals that are set forth in recent legislation and policy.

In closing, the Consortium would like to recommend that the
source-of-payment typology be named as the standard vocabulary associated with
the national health plan identifier for categorizing payer types, probably
within those types of plan IDs that are product lines. We were talking about
routing and line of business and product lines. I think this fits more in
product lines. But again, we ought to sit down and come up with some national
definitions of all these terms before we say what it is exactly.

We think this really has a place. We have a unique opportunity for a
comprehensive categorization of all U.S. payer product lines during the
enumeration process. We shouldn’t reinvent the wheel. We already have this code
set and a maintenance process in place. The typology is recognized by
standards-development organizations and committees, as I stated before. It is
part of the UB-04 standard. There is an existing consortium which approves
additions, deletions, changes, through a transparent, public code-maintenance
process.

It goes without saying that our committee would be pleased to amend the
typology as required by health reform changes to payment models, such as health
exchanges, and, of course, correct any omissions in the current code set.

I want to thank you for this opportunity to testify.

DR. SUAREZ: Thanks so much.

We do have a few minutes for questions from the committee. Justine?

DR. CARR: I just wanted to follow up on something that Jerry Diffley said.
You mentioned that there are some unique issues brought up by EHRs or EMRs with
regard to lab testing. Is that something we are going to see more of? Is it
going to affect other areas?

MR. DIFFLEY: From the standpoint that if a physician is able in his own EMR
to name the health plan with whatever he or she chooses — and then it has to
map to a clearinghouse and then the clearinghouse has to map to the laboratory
— yes, I think we will see more of it as EMRs proliferate.

DR. SUAREZ: That was one of the very important elements in your testimony, I
think, the connection between the provider submitting an order for a lab, and
then included in it is the information on the payer, and the opportunity that
we have with this unique plan identifier to allow the lab to consistently bill
the same payer that the provider is billing. I think that’s just a unique
element.

MR. DIFFLEY: And it’s huge for the laboratory industry. It really is — as
well as the patient, because ultimately the patient is the one that will
benefit.

DR. SUAREZ: Thank you.

Other questions from the committee?

PARTICIPANT: I have one. I can’t remember who talked about it. It has to do
with the patient cards with the identifiers on them. Somebody mentioned that
these cards are periodically sent out to the patients, about once every three
years or so, with updates on them. Somebody else said it would be really
expensive to have this stuff put on cards because it costs a lot of money to
reissue 3 million cards or something like that.

Would there be any downside if the cards were reissued over this two- to
three-year cycle, when they are normally done, instead of having the cards
mandated to have this ID on them immediately?

PARTICIPANT: Just put it on when they are renewed?

PARTICIPANT: Yes, put it on when they are renewed.

PARTICIPANT: A longer implementation.

PARTICIPANT: Talk to Steve Jobs. There’s an app for that, I’m sure.
(Laughter)

PARTICIPANT: That would be probably the easiest solution. Then you could
make whatever changes.

PARTICIPANT: If you can do it with an airline boarding pass, you can do it
with your health card.

DR. SUAREZ: Let me throw the $800,000 question, I guess.

The biggest question — well, there are several big questions, but the
biggest question in my mind, I think  – is, whereas with the NPI there was
a clear sense that there was an eligible set of providers that could obtain a
number — there were individual providers and they were required to obtain one
and then there were provider organizations, and there was eligibility to obtain
the number, but there was no specific requirement to enumerate to this level or
that level — with the plan identifier, I think we have heard during the day
that there is certainly the expectation that we define clearly who is eligible
to obtain a number and what components are also eligible to obtain additional
numbers within a health plan. But I heard different levels of “we
must” or “these numbers must” or “these entities must”
obtain the number.

For example, the legal health plan entity or the health plan organization
must obtain a number more than — well, they are eligible, but at some point
someone has to say, these groups must obtain a number. Going down into another
level was the line of business, going into this plan has a Medicare, this plan
has a Medicaid, and this plan has a PPO. There is where we start to see some
perspectives recommending that you must at least enumerate at this level and
some others that it should be a flexible option. You are eligible to obtain a
number there, but you are not required. Then going down into even further
granularity, we begin to lose some of the — you must obtain a number for fee
schedules or for — there are some recommendations for that.

That’s where the real question is: To what level do we begin to find the
right balance to say this is the minimum that needs to be required to obtain a
plan identifier, and beyond that the granularity becomes more optional?

My question is, where would you put that level — this is the minimum that
you require to obtain a health plan identifier, the minimum granular number?

MR. ARGES: I think it was mentioned before. It would be helpful to really
develop a business model first in terms of what the essential components are
that are needed and lay out how that might work. Then, once you do that, the
rest kind of falls in place.

DR. SUAREZ: You say a business model, George. You mean to define the various
options and —

MR. ARGES: All the components that would be necessary. What would be the
front-end piece? What would be the database piece, and then the maintenance
process and the flow. It’s the entire process.

DR. SUAREZ: Other perspectives from anyone else on the panel?

PARTICIPANT: This is for John. In the RMM(?) that you showed us in your
testimony, could it accommodate a health plan identifier that was ISO-compliant
with nine digits, plus one digit for check digit?

MR. QUINN: That would be easy. We were just having this conversation before
I walked up here. The kind of information that is encoded in OIDs is who the
issuing authority is and how you find it from ISO’s perspective. We don’t have
any real length limitations, at least not in any context of what we have spoken
of. If you started talking about wanting more than 50 or something, or 30 or
something like that, I would be concerned.

PARTICIPANT: That’s what I thought. You were into, like, a 64-bit number or
something.

MR. QUINN: It doesn’t even get stored that way. I’m not worried about the
number of bits of memory. The number of terabytes on a disk after — yes.

DR. SUAREZ: Any other questions from the committee?

(No response)

Okay, I think we are ready to wrap up. First of all, I again want to thank
everyone that provided testimony, both in person here and in written form. I
think this has been one of the richest discussions about this specific topic,
and it has been very valuable. We really appreciate your feedback.

We will be now, of course, turning into the discussions Wednesday and begin
our deliberations as a committee. We do expect to have some work around the
recommendations hopefully by the September timeframe, when the committee will
be meeting. We certainly look forward to continuing to work with you all on
this. If at any time when we are deliberating we have a question, I’m sure we
will be coming to you to clarify.

We’ll start tomorrow at 8:30.

(Whereupon, the meeting was adjourned, to reconvene at 8:30 a.m., the
following day.)