[This Transcipt is Unedited]
ADMINISTRATION SIMPLIFICATION UNDER THE
PATIENT PROTECTION AND AFFORDABLE CARE ACT
NATIONAL HEALTH PLAN IDENTIFIER AND
OPERATING RULES FOR ELIGIBILITY AND CLAIMS STATUS
Hamilton Crowne Plaza Almas Building
1315 K Street, NW
Washington, D.C.
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, communitybased and locally operated Blue Cross and Blue Shield companies that collectively provide health-care coverage for nearly 100 million –- oneinthree –- 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 statelevel 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 10digit 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.)
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.)