[UNEDITED TRANSCRIPT]
Unique Health Identifiers
DR. MOORE: It is 1:30. We need to get moving. We have four more teams for presentations. This afternoon we will be doing the identifier team, followed by I believe the enrollment and transactions, personal enrolling, eligibility, et cetera. Then follow that by the coding, medical coding, and then followed up at the end will be the security team.
I have Mary Emerson, who is working on the national provider identifier, Fay Broseker on her left, who is working on the payer I.D. Karen, who is working on the implementation of the provider identifier, and the regs that -- Karen Trudell, excuse me, and Susan Abernathy from the CDC.
Susan is going to lead off this session, again talking about the identifiers for individuals. So, Susan?
DR. ABERNATHY: Our team was charged with recommending standard unique health identifiers. There were four identifiers to be named: the individual, which I'll talk about, the employer, health plan and health care provider that the others from the team will discuss.
Within the work of the individual identifier group, right now we are nearing the end of the process of analyzing the proposals that were given to us from the inventory that Bob Moore mentioned this morning, from the American National Standards Institute. They had done an inventory of all of the different proposals for all of these transactions, all the standards that existed, showing where the gaps were in the standards.
As we do that, we are using the criteria that were put together by the American Society for Testing and Materials, which is a standard that was developed by a standards development organization. If you will remember from this morning's presentations, this legislation has an emphasis in using standards that have been developed by a consensus process, as that one was.
They issued a guide for properties of a universal health care identifier. That guide has 30 criteria for identifiers in it. We have taken each of the proposals and gone through, applied those criteria to them and done an assessment of those.
We are also trying to stay in touch with the Social Security Administration, with their efforts to come up with some recommendations to Congress about the social security number. Their report to Congress is due -- I believe it is August 22, it is coming up soon. We also have been talking with the Postal Service about work they are doing that might have some connection to a health care identifier.
We wanted to give you an idea of what we have accomplished so far in the talks that we have had as a team and the evaluations we have done. We think that we are at the stage where we can begin to eliminate consideration of some of the items that were on the ANSE inventory. We think that we can eliminate considering the unenhanced, unverified social security number. We think that we can also eliminate the group of proposals that you would categorize as biometric. Those would be things like fingerprints, retinal scans, those kinds of readers of physical characteristics of the individual.
We also think that we can eliminate the proposal for an identifier based on an existing medical record number, plus the practitioner prefix.
The ones that we are still then considering as a team would be the enhanced social security number. We are looking at the proposal put forth by the Computer-Based Patient Record Institute that involves a check digit being added to the number, and a method of encrypting the number, and changes in the Social Security Administration itself to resolve some of the problems with the use of that number.
There are also several proposals based on personal immutable properties. Those would be things like date of birth, mother's maiden name, place of birth. There are several proposals that have combinations of those.
Then within that ASTM guide that we talked about, there is actually a proposal for an identifier that is used to show how you would apply the criteria, but we are actually looking at that identifier proposal as something for us to consider, too.
We are also looking at supporting technologies for an identifier, such as a master patient index system identified within the ANSE inventory as a directory service. We are also looking at different characteristics of public and private key encryption. That was also in the inventory.
Among the issues that we are having to consider as a team -- and I wanted to talk to you about the issues, because we are now at the most difficult point of implementation, where I think we have eliminated the easy things, and now we are really starting the struggle to come up with something that we would feel comfortable recommending.
Among those are the risks and limitations of the social security number as a health identifier, the fact that there are duplicate numbers out there, and that one person can get more than one number if they need to.
There is also the problem that in some of the proposals that we have been considering, there is a proposal for a number, but there is no discussion of an infrastructure would be needed to maintain that. So we are having to try to consider something that is a partial proposal, since it doesn't address those things.
We also are having to consider the adequacy of current technology for some of the ideas we have heard, like the master patient index and the public-private key encryption.
Then we are also very sensitive to the acceptance by the public of any kind of a national master patient index, or for that matter, even a national health identifier. We have about 20 people on our team, and we represent a large cross-section ourselves of citizens, and also we come from a number of federal agencies. So we have a wide range of opinions of our own, and interest in this identifier that we bring to the project that we have.
As we consider what our recommendation will be, one of the problems that we have to look at is how can we positively link that individual to the identifier. What is to say that one person has an identifier, someone else doesn't take that identifier and get health care in their name? We also are considering how could we come up with a method to prevent a duplicate identifier being issued to someone.
Then there is the issue of, are we really trying to help the process of computerized patient records by being able to link to previous records and come up with a longitudinal health care record for someone, or are we trying to be sure that we insure the right to anonymous care, if that is what the patient wants? So it is a struggle; those are almost opposing things that you are trying to do. So which side of that should our work fall on?
Then as we consider these, some of them seem like really good ideas. Yet, as we look at the cost to the American public, we can't really in good faith recommend that we try something like that on a national scale.
Then we have to look at the fact that there is probably -- because there is an opposing wish to be able to identify the person positively with another wish by some to not be able to, probably whatever we decide to recommend is going to meet with some controversy. So we are trying to be sensitive to that, too.
Before we go on to the next identifier, are there questions from the audience about the individual?
DR. TRACY: Sue, when will you publish your recommendation?
DR. ABERNATHY: That is a good question, when would we publish our recommendation. Our team actually is a little behind the other teams. We got started later. We first met as a team in March. We are trying to meet the same deadlines that were put up here earlier for the 18 months with standards, which would mean our first draft would have to be done very quickly.
Any other questions? Then I would like to introduce Mary Emerson.
DR. EMERSON: Hello. I am Mary Emerson. I am the other co-chair along with Susan Abernathy of the unique health identifiers implementation team. I am going to talk to you about the other three identifiers that our team has been considering. Those are the identifier for employers, the identifier for health plans and the identifier for health care providers.
I'm going to stop after each identifier so that you can ask questions on that particular one. But because our time may be limited, if you have a lot of questions, you may not be able to have us answer them all this afternoon, so I would like to give you my phone number and e-mail address, so if you have questions that aren't answered now, you can direct them to me later. My phone number is area code 410/786-7065, and the e-mail address is memerson @ hcfa.gov.
I will start out with the employer identifier. The current activities of the team are that we have been coordinating with the team that is developing the transactions that we think will use an employer identifier. These are enrollment and disenrollment in a health plan, first report of injury -- that would be used for workman's compensation -- and health care premium payments.
The current thinking of the team is that we would recommend the employer identification number that is issued by the Internal Revenue Service to be used in those transactions.
Three issues have been raised relating to the use of the EIN in these health transactions. The first is that the EIN isn't unique to the employer, that is, many employers have more than one EIN. So the question this brings up is, would this be a problem for health transactions. So far, our feedback is that it would not, and that the EIN that is used on the employee's W2 form would be the appropriate one to use in transactions relating to that employee.
The second issue raised is that some sole proprietors, that is, sole proprietors who have no employees, some of them do not have an EIN. The question this brings up then is, would they need to obtain an EIN to use in health transactions that they issue on their own behalf. Or alternatively, would they use their social security number in those transactions?
The answer to either of those questions probably brings up the third question I've got on the list here: would the use of the EIN in the health transactions require any sort of legislation or regulatory change.
With that, I would like to open the floor for questions that you may have on the employer identifier. But actually, in this case what I am hoping is that the employer identifier is not very controversial. Maybe you will even give me answers to my questions. But do you have questions on the employer identifier before we move on to the other identifiers? Please come to the mike.
DR. ZUBELDIA: One of the issues is that sole proprietors do not have an EIN. Would those very small entities be subject to HIPAA? If they don't even have an EIN, if it is a single individual, would they be required to do electronic transactions? Would we be required to deal with them under the law?
DR. EMERSON: I'm not sure of the answer to that. I think that we can say that if they want to submit electronic transactions, they would have to do it in the standard format.
Now, I know that the law is definite about providers, health plans and so forth using the standard transactions for electronic communication. But I don't think it directly addresses when employers have to use -- whether they have to use electronic transactions or not. I would think that it would not require them to use electronic transactions. Bob, would you like to address that?
DR. MOORE: In the enrollment and disenrollment and premium payment, we had expected that employers if they were going to use electronic transactions, would be using the standard transactions. The question of whether a sole proprietor, if he is an accountant or a lawyer and that is his whole business, would he be required? I don't know.
DR. EMERSON: Bob, I think your voice is not catching the mike there.
DR. MOORE: I'm sorry. If it just an individual who is in business as a sole proprietor, as I stated up there, I don't know how he would be required to do an EIN, just to sign up for health care with some plan. I would imagine he would be paying his premiums by check or some other way, like many of us do already. So in this case, he would do it on paper, I would think, which is not out of the ordinary for that level of volume and for those kinds of transactions. We were looking at mainly for -- it would be to enroll or disenroll in the plan where there might be some group.
Does anyone have an answer that they could help with that? The State Farm people here, do you have -- or any other insurer, Frank from the Blues? If I were a sole proprietor and I wanted to enroll with some group, and I am the only one, I would probably do it on paper.
Frank is with Blue Cross and Blue Shield Association.
DR. POKORNY: Yes, I am with Blue Cross and Blue Shield Association. In response to your question, I don't know if there is one answer. In most cases, if it is an individual, the sole proprietor would not be under a group contract. I think the purpose of the EIN would reflect group employment situations with several individuals that are covered under one contract. So I don't know if it applies here.
One wrinkle is if it is an affinity group, such as a professional association that could offer coverage to its groups members. That just came to me right now, and I would have to explore that one. I don't know what the answer would be.
DR. MOORE: How would that group be identified in submitting all the people that are enrolled in a plan? Or would all the people submit their enrollment in that particular plan individually, but using that affiliation?
DR. POKORNY: I don't know if there is one way in which that is done. I think both options are viable, but I don't know enough to really answer the question fully.
DR. MOORE: Okay. But it is one that we need to investigate a little more and explore further. Thanks.
DR. EMERSON: Thanks to both of you. I'll move on now to the identifier for health plans.
The team expects to propose that the payer I.D. that has been under development at the Health Care Financing Administration be proposed as the identifier for health plans. Payer I.D. is a nine-position numeric identifier. It includes one check digit. There is no intelligence in the number itself, and it has the capacity to enumerate 100 million health plans.
This would include the various entities that are listed as health plans in the law. It includes group health plans, federal programs like Medicare, VA, CHAMPAS and so forth, Medicaid programs, and we would also propose to give payer I.D.s to those employers that offer funded and unfunded health benefits, so that when they are acting in the role of a payer, they would use their payer I.D. in those transactions.
I want to contrast that to the employer I.D., where when an employer is acting in the role of a general employer, they would use the employer I.D. which we are suggesting, the EIN, in those transactions.
Just to go over a few of the payer I.D. system features, first of all, it is a registry of the business information about the entity that is enumerated, in this case the health plan. It is an electronic phone book of the entity names and their payer I.Ds, and it is a database of the information that is necessary to route electronic transactions such as claims electronically.
With that one issue that has remained controversial about the payer I.D., that is, the level at which enumeration should take place. Should it be at a high level, the level of the health plan, or should it be at a detailed level, where you might even be enumerating a policy under the plan, or something of that sort?
I would like to turn the mike over to Faye Broseker now. Faye is the regulation team leader for the payer I.D. effort, and Faye is going to entertain your questions about the payer I.D.
DR. BROSEKER: Hi. Are there any questions?
PARTICIPANT: You say the issue is high level versus detailed enumeration. I would be curious to know what the thinking is amongst the implementation team about which way to go, and if a direction has been considered, how would that affect the actual enumeration?
DR. BROSEKER: Currently right now, what we are proposing for the regulation process is that the health plan will act as the gateway to get the transaction to the front door, and then if they have any internal business addresses, then let them route it to the appropriate one. That is the current way we are going right now.
DR. ROBINSON: Hi, I have a couple of questions. The first one is, are carriers responsible for maintaining the registry, and if they are not, how do we keep it in sync with new parities that might be on incoming claims but not yet on the carrier's copy of the registry?
DR. BROSEKER: If the individual or the entity has a payer I.D., they themselves will be responsible for keeping all the data related to them current in the registry.
DR. ROBINSON: And when are the carriers then going to receive copies of the registry and their supplemental insurer files?
DR. BROSEKER: We are looking for February of '98.
DR. ROBINSON: Okay, thanks.
DR. BROSEKER: The registry is going to be updated on a quarterly basis. That is about it. Every couple of months you will be getting a new update to the registry.
PARTICIPANT: I just had a couple of questions, I guess. I presume that this will also provide a payer I.D. to third party administrators or plan administrators that do work on behalf of groups?
DR. BROSEKER: That is correct.
PARTICIPANT: And is there going to be guidance as to telling an employer when they have to have their own payer I.D. and use that? Because there are some that use insurance carriers as administrators, there are others who may be doing some arrangements that are self funded or not self funded. I am just curious: is there some guidance to the employer to know when they have to have a payer I.D. and use that?
DR. BROSEKER: Actually, in addition to developing the regulation, we are also developing guidelines on that line. It also applies to providers as well as payers, because providers could also be a plan, like an HMO. So we want to make sure that everybody understands their role and when they have to use their numbers.
PARTICIPANT: The reason I ask that is, I can see confusion, particularly from employers with multiple health plans, some self funded, some not, in trying to determine when they need to use this and when not to, and obviously also for the provider, trying to figure out when they have to fill that information in for an employer, when they may see two employees come in, and they will have to try to figure out who is the payer in that particular case.
DR. BROSEKER: Yes, we agree. That is a good point.
PARTICIPANT: I just had a follow-up to what you just said about the registry's update on a quarterly basis. If the carriers are to maintain that, but we are only getting new updates every quarter, then I'm not quite sure, if new claims are coming in that need to have new payer I.D., how is that -- they come in on a daily basis, so I'm not quite sure how that is going to be --
DR. BROSEKER: You are talking about Medicare carriers?
PARTICIPANT: Yes.
DR. BROSEKER: They will have access to the payer I.D. registry on a daily basis. You can go in at any time to update your own records. The industry at large will be getting -- if they want a download of that registry copy, they will be getting a quarterly update, so it is a little different. You can have online access, or you can have a copy of the registry. But if you do have a payer I.D., then you can go in at any time to update your own information.
PARTICIPANT: Will medi-gap providers be able to have a default number then?
DR. BROSEKER: At one time we thought we were going to distinguish medi-gap from the rest of the industry. But as it is now, they are going to be considered just like every other insurer out there.
What we are looking to propose is a number that the individual health plan will let us know, is there a default address, that if they want all their claims to be sent to one specific place, they can let us know that, and that will become their default.
DR. POKORNY: You mentioned in response to my first question, you see the health plan acting as the gateway. Does that mean that a health plan as enumerated in the legislation would have one unique identifier, that the concept of the two-digit suffix, which was bandied about many, many months ago, has been set aside?
DR. BROSEKER: Yes. We got some comments from industry, saying that the suffix caused them confusion. So now we are concentrating on the fact that a legal entity will be assigned a payer I.D. That is the full nine-digit payer I.D., will identify that entity.
DR. POKORNY: And only one payer I.D. per legal entity?
DR. BROSEKER: That is correct.
DR. POKORNY: Thank you.
PARTICIPANT: I just had a follow-up to something you said a minute ago about a plan being able to assign a default number. In our case, we have a number of carriers doing business in different states under similar names, and we are planning to use a specific number for all of those plans and then internally sort out the claims. Would we be able to do that under what you just said? Could we assign one default number for all of the companies --
DR. BROSEKER: That's correct.
PARTICIPANT: -- and then the providers would send everything, and then we take care of it.
DR. BROSEKER: That will be your option, yes.
DR. BUCCAFURNO: I have a question to the committee as a whole, not necessarily to the health plan identifier. Perhaps you want to ask if there are any more health plan identifier questions before I go ahead?
DR. BROSEKER: That's okay, go ahead.
DR. BUCCAFURNO: I am from a company called NorTel, Northern Telecom. This question goes to some of the issues you had up earlier about whether a national master patient index was feasible.
My company has been doing national database infrastructures for the telecom industry for a number of years. We see a number of similarities between the technologies that we have been using and the technologies that you will need to implement your national patient identifier infrastructure.
My question was whether you were interested in learning more -- or using my company in an advisory capacity, just to talk further about what the infrastructure might look like.
DR. ABERNATHY: Our team has received some information from your company. As I recall, it was in the form of overheads for some presentation, and we didn't hear the presentation that went with the slides. So I'm sure that our information is not complete, but we do have a way to contact you on that.
DR. BUCCAFURNO: What I sent you was basically a conversation starter, just to give you an idea of the kinds of things we are thinking of. Certainly, information about how this would work would be very detailed and very complex, and probably require a number of subsequent conversations and meetings going forward. If you are interested, contact me.
DR. ABERNATHY: Thank you. It does give me a good opportunity to ask for help from anybody in the audience. It is a difficult process and a difficult recommendation to make.
What I didn't say, if I can take one more minute, in the time that I was up here was that we probably will end up recommending a combination of the best of the recommendations that we have seen. That would be my guess. If there is someone who has spent some time on this and has a recommendation that we haven't seen, we would like to have your input into the process.
Mary gave you her phone number and e-mail, and she would forward anything on to me about the individual identifier, I'm sure.
DR. EMERSON: I'd like to first ask if there are any more questions about the payer I.D. Is that what yours is about?
DR. ZUBELDIA: Yes. Faye, I want to make sure I understood correctly. The proposal that was on the table before was to assign payer I.Ds to large payers in groups of 100 at a time. Has that been killed?
DR. BROSEKER: Yes.
DR. ZUBELDIA: There was also another proposal that was discussed, about having the payers request a specific payer I.D. number that would be maybe similar to the number they are currently using today, and instead of reassigning a random number to the payer, letting the payer select what number they want. Is that possible?
DR. BROSEKER: I think you are referring to -- one of the terms was called vanity numbers?
DR. ZUBELDIA: Yes.
DR. BROSEKER: We looked at that, and currently we are going to propose that we do not want to introduce intelligence into the number. But we welcome your comments when the proposal goes out there.
Are there any other questions about payer I.D.? Thank you.
DR. EMERSON: The last identifier that our team is considering is the identifier for every health care provider. We expect to propose that the national provider identifier that has been under development at the Health Care Financing Administration be used as the provider identifier.
The NPI is an eight-position, alpha-numeric identifier. Like the payer I.D., there is no intelligence in the identifier itself. It has the capacity to enumerate more than 20 billion providers.
Some of the system features that you may be interested in are that we will have data validation software as part of our system. We will have an interchange with the Social Security Administration, where we will be able to send them the SSNs and names of providers that have been reported for NPIs, and they will validate that the name and SSN match what is on their files. We will also have address standardization and validation software as part of the system.
The heart of the system, if you will, is a search and match algorithm that will attempt to prevent assignment of duplicate NPIs to providers. The system has a national database and it will have a query and report generation feature as part of that.
We have three issues that have remained controversial about the national provider identifier, and I would like to go over those briefly right now. The first involves the enumeration of providers on a national scale. We are using the term enumerator to describe the entity that would interact directly with our system, in order to obtain NPIs for providers. So the question really is, what kinds of entities will be the enumerators with the national provider system.
There have been several proposals. I want to mention that what we plan to do is to list these proposals in our notice of proposed rulemaking, and ask for your comment and your vote on what you think would work the best.
I'll go over them briefly right now. First would be that the various federal programs that currently enumerate providers would be enumerators, and would obtain NPIs for their providers, and that the Medicaid state agencies would also be enumerators, and would obtain NPIs for their providers.
We recognize there are many providers that don't deal with either a federal program or a Medicaid program, and so in order to allow them a way to obtain NPIs, we could also establish a registry, and those providers could go to the registry to obtain their NPIs.
Another possibility that has been proposed to us is that the governor of each state would designate a state agency to be the funnelling point for the providers in that state. That way, the state could choose an entity that would work best for it. It could be a Medicaid agency, it could be the state professional licensing boards, or whatever would work best for the state.
A combination of those types of enumerators might also be used. So again, we will be putting forth some options in the notice of proposed rulemaking and asking for your comments on those.
The second issue that has remained controversial about the NPI is whether the system should contain the practice addresses of individual providers, like doctors and other practitioners. Some people have felt that the system should really only contain a mailing address for those providers. Others have felt that every practice address of the provider should be listed in the system.
The issues there really revolve around the difficult and expense perhaps of maintaining the data on those practice addresses. We have learned that they are fairly volatile; providers move around a lot. Should we be trying to keep them up to date in the central system?
Another question has been, if we do collect those practice addresses, should we assign a location code as a pointer to each practice address for the provider? Again, as with the enumeration options, we will be putting forward several options here in the notice of proposed rulemaking and asking for your comments on them. One of the options does contain practice addresses and location codes, one of them does not, and we would like to know your thoughts.
The last issue that has remained controversial is whether the system should contain the Department of Health and Human Services Office of Inspector General sanction information about the providers. Some folks there have felt that this was important information to have in the national file, because it helps plans and other health programs make a wise decision about which providers to enroll in the program.
Others have felt that the focus of the national provider system should be kept strictly on uniquely enumerating the provider, and that we should not bring in other supporting functions like those that might support enrollment of a provider.
So these are some of the issues that we are dealing with. I would like to mention that for both the payer I.D. and the national provider identifier, there is quite a lot of information on the HCFA website, www.hcfa.gov. If you go to the link for initiatives, you can get information on both the payer I.D. and the national provider identifier. The NPI information has just recently been updated and it includes discussions of these issues and the options that you will also see in the notice of proposed rulemaking.
I would like to introduce now Karen Trudell. Karen is the regulation team leader for the national provider identifier effort, and she will take your questions on the NPI.
DR. TRUDELL: Are there any questions on the NPI?
PARTICIPANT: One obvious question I have is, will a group practice be able to get an NPI as the group name, or will each individual provider within the group have to have its own NPI?
DR. TRUDELL: Group practices will be enumerated as entities in and of themselves, and individuals who practice in the groups would also have NPIs as individual practitioners. The system will link the two together.
PARTICIPANT: Okay, because obviously, that is a clear opportunity for HHS debarred providers to hide behind a group in many instances, not to mention the many other ways that they circumvent the system. Are these things being addressed?
DR. TRUDELL: Groups and individuals will be linked within the system.
DR. TRACY: Could you please provide an operational definition of the term provider, and indicate to me which allied health professionals you anticipate being categorized within this term?
DR. TRUDELL: That is an excellent question. It is one that we thought was going to be very easy from the beginning, and it became more problematic as time went by. What we mean by a provider is either an individual or group or an organization that provides health care services or supplies to patients. We expected that in the beginning, this is going to be primarily used by providers who are involved in the electronic transactions that are specified in the HIPAA legislation.
However, over time it appears that we need to take into account the fact that other allied health care professionals, registered nurses, other therapists who perhaps don't often bill directly for their services or engage in the other transactions may either begin to do so in the future or that there would be another reason for them to have a unique identifier, perhaps that would be associated with a computerized patient record in the future.
So we expect that initially, we are going to target enumerating the providers who engage in these transactions, and keep the door open in the future to enumerate any other health care providers. The definition in the regulation is very broad. We haven't left very many practitioners out.
DR. EMERY: Jack Emery with the AMA. I'm just looking for some assurances that the underlying data that is used to help assign a number is information that will be kept in house, not available generally to the public. We have very strong concerns about fraud and abuse of provider numbers by inappropriate people, or data that is contained in the provider files. Will we get that assurance?
DR. TRUDELL: Yes. There is again a line that we are having to define in terms of making certain amounts of data available to the health care industry in general, so that the provider identifier is usable in electronic commerce. There is also data that we expect we will need in order to make a reliable match, demographic data, social security number, date of birth and that type of information is not necessary to maintain electronic commerce and the utility of the NPI, and it would be preserved under the privacy act and kept separate.
The regulation actually delimits two different sets of data elements, and says which ones will be available to the general public and the industry at large, and which ones will be maintained in HCFA's internal file.
DR. POKORNY: How will entities that are integrated as both health plans and providers be enumerated?
DR. TRUDELL: As health plans and as providers.
DR. POKORNY: Separate numbers?
DR. TRUDELL: This is -- yes. This is a situation where it depends more on the function than the entity itself. An HMO could be a provider, it could also function as a plan if it has to handle out of area claims. A hospital obviously is a provider, but it is also an employer. So a lot of these definitions are going to have to be very carefully worked out also across all of the transactions. I think that was one of the things that was mentioned this morning as an issue.
DR. ZUBELDIA: Do you see the provider I.D. being used as the submitter I.D. for electronic transactions?
DR. TRUDELL: As a submitter I.D.?
DR. ZUBELDIA: Yes.
DR. TRUDELL: In terms of who submits a claim and who gets the payment?
DR. ZUBELDIA: In terms of sending the claim, yes, or sending any of the transactions, separate from who is performing the medical service. If that is the case, will service bureaus, for instance, have provider I.Ds?
DR. TRUDELL: In some cases, the entity who submits the claim is not the same person as the one who performed the service. If you have a group practice, who submits the claim? And the payment goes to the physician? Each of those would have a provider I.D., so it definitely has a connotation over and above who actually performed the care.
PARTICIPANT: How about billing services and automated claims clearinghouses? Under the various identifiers, would they be assigned any specific types of identifiers?
DR. TRUDELL: No, unless they are payers. Clearinghouses? No, I'm sorry.
DR. RENSHAW: If the provider is the submitter, would they have separate numbers, one for the physician part of it and one for the electronic submission, or one provider I.D. would cover both identifying a provider and the electronic submission?
DR. TRUDELL: Right. One of the challenges we have had is to try to structure this number and the process so that various payers can use the number in whatever ways their own business processes require.
PARTICIPANT: Addressing that issue, I'm not sure I'm clear on that, because there are many doctors who use a billing service that is serving many, many different providers in many, many different locations. Ultimately, especially if it is a managed care plan, certain providers are under the plan and certain providers would be non-participating providers.
It would seem to me that any claim would have to come in with two fields, a field for the provider and a field for where this remittance is going to go to.
DR. TRUDELL: But it might have the same identifier in both fields.
PARTICIPANT: But there has to be the facility t have two separate numbers on the same claim, correct?
DR. TRUDELL: Yes, that's correct. But we view that as a question that has got more to do with the use of the number and the standard encounter or claim form than how we are going to issue the identifiers.
PARTICIPANT: There's a lot more issues to that, because certain providers are licensed to perform certain functions, and other providers are not also. So there are many, many issues related to that, and there has to be the facility for the provider who is doing the service to be on that claim, as well as wherever you want that payment to go to.
DR. TRUDELL: Yes.
DR. TRACY: A comment rather than a question. I think this goes to my earlier question of the definition of a provider. I think there really ought to be two distinctly different concepts here that may require different terms. The legal entity responsible for the care and maybe the recipient of reimbursement from the individual who actually provides the care. It certainly appears as if the two concepts are intertwined in a single term here.
DR. TRUDELL: Yes, that's true. I suppose the only thing I can do is to suggest that as you look at the definitions the way they are in the notice of proposed rulemaking, if there is something that we have missed or if there is something that is going to make it difficult to do business, we need to know about that.
Mary tells me the provider definitions are on the website.
DR. DONATH: It appears that a payer's claim systems in a provider's master file would have to provide enhanced assistance to include many data elements, such as the old number as well as the new number, the stop and start dates. Will you be issuing guidelines as to what other data elements will have to be maintained, any flags or anything along with the unique I.D. number?
DR. TRUDELL: By health plans?
DR. DONATH: For payers. Claims will still be coming in to old healths as well as new numbers. There has to be a stop and start date. So there has to be other fields in the system beside what claim systems have now for providers, which is an additional cost. They have to enhance the systems when they design it.
I was just wondering, will you be giving any guidelines as to what other additional information other than the new number that would have to be maintained.
DR. TRUDELL: There will be guidelines that we will be providing to the Medicare carriers as to how they can implement. We have heard from some of our own carriers and FIs that they would just like to switch over on one day. Others have told us that they would rather do it gradually.
The data elements that we will be making available as I said are noted in the regulation. Some of the data actually points back to old numbers. So if you have existing provider numbers, you would be able to use that data to crosswalk back to them.
DR. MOORE: The last question really was an implementation issue, as Karen tried to address. We have been made acutely aware when we proposed that we would go out and do this first, and enumerate all the Medicare providers, how that might have the potential to cause a lot of grief in the whole community. If we implement it to a provider, what would be the national provider identifier, leaving all the other payers to use their own, and it would cause the providers to try to make a rush to make all the other payers change it.
But it has nothing to do with how we enumerate providers. Once we get them all enumerated, then we have to sit down with you all and decide how is the best approach to do this. Would it be feasible for us to say, on January 1 of the year 2000 we are going to have all providers use a new number? Are we all comfortable with that? I don't know if I am. I don't think the providers would be, too much.
But this is something we have to work out as an implementation issue. Whenever you do anything on this grand of a scale, with this many parties and payers, we are estimating that there are over four million providers and over four million payers, when you count all the ERISA plans and everyone else that is in there. So we are looking at eight million payers in this game, and how do you get everyone to coordinate it and implement something without causing grief to those who haven't done it, or those who are going to do it, can we do it at one time. Those are things we have to work out. No matter how we enumerate providers, we still have that issue to address.
DR. TRUDELL: Thanks, Bob. Are there any other questions? Four minutes to spare. Thank you.
Enrollment and Eligibility
DR. MOORE: Thank you. We have the enrollment and eligibility implementation team to go over the other five transactions that we didn't cover before lunch. After we do this presentation we will take a short break again of ten minutes, and then proceed with the medical code sets and the security.
MR. MOORE: Thank you. The person to do this is David Clark with HCFA, who is the chair -- or right now, to be co-chair of that particular team.
DR. CLARK: Thank you, Bob. Good afternoon, everyone. What I would like to go over is just to share with you the charge of the team, talk a little bit about some of the recommendations or the thinking as it presently exists within the group. I would also like to walk through each of the transactions, share with you a little bit about the status and some of the issues that we are looking at.
Before I begin, I would like to just talk about the team a little bit. As Bob said, it is a group effort, and we have really struggled to make sure that the spin is understood within the community, that it is not a HCFA effort in terms of developing these standards, that there really is a very broad effort within the federal government to bring about and develop these standards.
On the eligibility and enrollment team, I have Deborah Bills with HCFA, who has been assisting me and acting as a co-chair up until the last couple of weeks. The Department of Defense identified Steven McMilly as a co-chair to be assisting with the rest of this project.
In addition to Steven, Duane Goodenow is on the team from the Department of Defense. We also have representation from the Office of Personnel Management, the Veterans Administration, and then a somewhat unique arrangement with the Department of Labor and OSHA, Bureau of Labor Statistics, as well as its Office of Workman's Compensation programs.
I understand that Jean was in the audience and so was Judy, and I believe Duane is here as well. I would like for them to just stand up, please, if they are available. They seem to have gotten away from us.
Let me start with the charge of the group. Basically, we are responsible for five of the 11 transactions that were named in the legislation. That would include the enrollment transaction for checking and testing the enrollment of various individuals in a health plan, the eligibility requirements in terms of the services that they are eligible to receive. We are also responsible for the first report of injury, which is really not a health standard, and we'll talk about that a little bit. It is outside of the scope of the health delivery system. We are also responsible for health premium payments. Then the last one, referral certification and authorization for specialty services that are received within a plan.
In terms of the recommendations, where we are at this point, for the enrollment transaction, we are looking at the ANSE X12.834, the version 3070. For the first report of injury, it is the X12.148. For premium and billing payment, we are looking at the ANSE X12. It says 811 and 820, although at this point our efforts are really focusing on the payment side of the transaction, which would be the 820.
For health care services review, we are looking at the ANSE X12.278. Then the last one for eligibility, the ANSE X12.270-271.
Under enrollment, the current implementation guide covers all forms of benefits. It is narrower in scope for the health care specific guide. In terms of policies, what we are looking at is whether or not -- how we will incorporate the whole issue of race and ethnicity into the standard. There are some providers and plans that would like to see a fairly broad bucket, if you will, an ability to identify the race and ethnicity of the different members within the plans.
There is a great deal of variation across the country in terms of out West, looking at a little bit more specific information requirements. At this point, we are very anxious to see the OMB directive 15 in the Federal Register. I believe that is soon to be published, which will give us some guidance in terms of how to approach this particular issue.
Also, there is the whole question of performance measures and outcomes research, and how is that to be addressed, or even if it is covered by HIPAA, in regards to the HETUS data or even data from the Foundation for Accountability.
With the 834, basically we have a good draft of an implementation guide that is ready. We have identified the changes on the federal side. We expect to have a data dictionary ready, as well as drafting some of the industry requirements.
Our target date is August 25 to have the data dictionary completed. Looking at the interim meeting for ANSE in mid-August, we may be able to have additional and more specific information about the transaction and how it will appear in the regulation.
The first report of injury is rather unique, and really outside of the purview of the health system. It is more of the insurance industry, in terms of reporting workman's compensation claims, something that HCFA has relatively little or no experience with. We have been working with the Department of Labor through its Office of Workman's Compensation programs. That is Bureau of Labor Statistics, which is also interested in some of the data that comes out of this transaction, as well as OSHA.
There is no current implementation guide available. There was a draft guide that is being worked on in a tutorial. I believe it is a version 3040 that we are working with the chairs of the ANSE work group on, in terms of looking at how this transaction can be used within the HIPAA requirements, and whether or not it would meet the requirements for the Department of Labor, as well as states in terms of reporting workman's compensation issues.
As I indicated, it is not a health specific transaction. It is outside of HHS purview. I mentioned the groups that are working on this with us.
Some of the policy issues, how can we expand this or should we expand it to include allowing physicians to make a first report, as opposed to coming from the employers or through the state. Again, given our lack of experience with this particular transaction, we may need to engage the private sector workman's compensation community to assist us a little bit in looking at this particular transaction.
There is another area that we are looking at with the 148, which involves the Food and Drug Administration. Evidently they have a reporting requirement for devices which they are in the process of developing standards for as well. I am in communication with Mr. Haffman over at the FDA, to see whether or not these particular transactions and the standards and the data elements that we are looking at under the 148 can and will include what he is trying to do for the devices, in terms of reporting injury through the different devices.
We are looking at that. Our expectation just from a preliminary conversation was that that material really is much broader in scope than what we are looking at in 148 for the first report of injury, and will in all likelihood continue down two separate and different paths.
In terms of premium billing and payment, it is used in the industry as an ANSE finance function, much broader than the health care opportunities for use within the health industry for premium payments, either through our side in HCFA, through the federal government for making payments to the states or different providers.
There is no implementation guide available for that, so it is something that we are going to have to build ourselves. Our expectation is that the HIPAA transactions or the HIPAA use would not be very complicated. It would be much smaller in scope than what is currently in the 820 or the 811 on the billing side.
In terms of health care services review, there are multiple implementation guides that are available. I mentioned most of limited of any actual use for us. I mentioned the use of the 278 in terms of the standard that we would be looking at, making a recommendation through the Secretary. We understand that there is a pilot project underway within Blue Cross/Blue Shield, taking a look at the 278. We are very interested in the results of that activity.
It is one that we are not really focusing a lot of energy on at this point. There may be a late deliverable for this one after the February '98 date, sometime mid or late spring.
In terms of eligibility with the ANSE 270-271, right now we are near completing the mapping of the government data element requirements for this particular transaction. All the necessary components are in place to produce the regulation. We have identified some 161 data elements in the 270, approximately 327 elements in the 271. Most of these are optional elements, fortunately. We continue to develop and make the final process for the data dictionary for the various data elements.
We have made a decision that we are not doing interactive eligibility transactions within the 270-271.
In terms of the data dictionary, it will include the listing of names, definitions, transactions and locations. It will be organized by individual transaction. It will not include the codes for the values nor the implementation instructions. We are looking toward the implementation guides to carry that information.
I just want to wrap up by saying a little bit about the regulation itself, because that ultimately is the end game for us in terms of each of these transactions that we have been working on. We are looking at basically pulling information together into one regulation with a preamble, which will cover the background information, in terms of how the particular standard was identified and selected. We will also explain that the standard data organizations will continue their processes for maintaining the standard. We hope to explain how the modifications process would be carried out, the change control forms.
We will also include in the preamble some information -- or hope to include information concerning the evaluation guide, the criteria that we used to select the different standards. There of course will be the impact analysis that we have, which we are pulling together the data right now in terms of the cost of implementing these various standards.
There is a huge debate internally, just in terms of whether or not we will be looking at electronic comments on the regulation as it comes out in terms of an electronic rulemaking process.
There will be addenda for each of the transactions which will include a cross reference for each transaction to the following: the ANSE requirements, the standard itself, as well as the implementation guide. We will also have in the addenda for each transaction the data dictionary, which we hope to identify and label a definition and whether or not that particular element is required or optional.
That concludes the materials that we are looking at for the enrollment team, in terms of the five transactions that we are looking at. We hope to be in place with most of the information that you will need to give us feedback on what we have done by the ANSE meeting in August.
Thank you. Are there any questions or feedback for us?
DR. OWENS: Just a comment on all three implementation guides that you mentioned, the premium billing and payment and the first report of injury and illness. Those are all being worked on and are anticipated being done at the August meeting of X12.
DR. CLARK: Yes. The question was whether or not the implementation guides that we are working on internally within the work group, the 148, the premium payment, which is the 820, and the 834 are all being worked on internally. The answer is yes, and they will be available at the ANSE meeting in August.
DR. ROBINSON: On your last slide on the 834, on the enrollment, you talked about one of the outstanding issues being performance measurement and outcome results, or something along those lines. What are you envisioning including there? I didn't quite catch what was meant by that line in the slide.
DR. CLARK: The question was raised concerning one of the slides on the 834, where we were raising the issue of what are the HIPAA requirements with respect to some of the outcomes research activities. There, what we are looking at is like with HETUS data. Now that the plans are required to submit HETUS data to HCFA, is that something that ought to be included under the HIPAA requirements, and are there standards or data elements that we would need to include under HIPAA for collecting that information.
That was just one, and it is more an internal debate within the work group, in terms of how broad the scope of HIPAA would cover.
DR. ROBINSON: I just don't see that transaction being the place for that kind of information, since it is coming from the employer in the first place. So they wouldn't know that information relative to the health plan.
My second question is, just because I don't know what it is, what is the OMB Directive 15?
DR. CLARK: The question is regarding the OMB Directive 15. What that is, is a federal regulation that requires for an internal reporting of race and ethnicity, based on specifically defined categories for race and ethnicity. A lot of controversy around it in terms of even whether or not the federal government should be collecting race and ethnicity data, how do we want to include that into the standards, whether or not it will be used. It is along that line.
DR. ZUBELDIA: I have two questions about eligibility. Have you looked at having minimum and maximum data requirements for eligibility, so a payer cannot be asking for basically everything on an eligibility inquiry? Then answering with a yes-no answer, but actually giving some extensive data in the answer. Have you looked at that, like we discussed about maximum data requirements for a claim?
DR. CLARK: No, we haven't, not within the group. I can certainly take that back within the team. I think the -- is that in regards to the huge number of elements in the 271, where we are looking at some 271 elements with roughly about 50 of them being required elements?
DR. ZUBELDIA: Well, it has both sides. The 271 response can say the patient is covered or is not covered, and stop there. Or it can give additional coverage information. On the other hand, on the inquiry, you can be asking for a lot of information, basically all of the eligibility information, and then you will turn around and say, yes, it is covered or it is not covered. You can use it in many different ways. I think that beyond saying this is the transaction itself, you need to standardize how it is doing to be used.
The other question that I have on -- I forgot about it. I'll come back.
PARTICIPANT: I also have a question regarding eligibility. I come from Massachusetts, where both the Bushiell plan and the state Medicaid uses magnetic card read swipe boxes, which are both proprietary to each organization. Under the law, if you are picking the 834 transaction, would those boxes have to be changed to accept the ANSE transaction, and if so, why are you using the 270 non-interactive as opposed to the ICEBER, which would be a reduced set?
DR. CLARK: I don't have the answer for that right now. I would like to capture the question specifically, and can respond to you at a later time. John, was there any comments that you would make on that?
DR. ST. GEORGE: Well, if we follow the same statements that have been made about the federal law, then yes, they would have to change those to use the transactions as specified by the federal law, just as we talked about with the claims.
In terms of the interactive, our group wasn't involved in the team's decision with that, but not everybody supports interactive transactions. But the 270-271 support, what is called fast batch, which means you can make an inquiry and get an immediate response, is just not a true interactive response. It is a single batch in, single batch back. Kepa knows all about interactive.
DR. ZUBELDIA: Well, no, but this has refreshed my memory, and it also goes with the interactive issue. I thought you mentioned that the interactive eligibility was being left out of HIPAA. So if they are doing an interactive eligibility, they don't have to do the 270 and 271.
My question that I forgot before was, if they are using batch eligibility, even if it is fast batch with 270-271, is there a required maximum response time? Or can I send an eligibility inquiry today and the payer will answer back a week later, or three days later, like is the case today with some payers?
DR. CLARK: The question is, will the standard include a required maximum response time to an inquiry on the 270 transaction. At this point, we haven't made a decision on that. Is there a recommendation in terms of what that time frame might be?
DR. ZUBELDIA: My recommendation would be about 10 to 15 seconds.
DR. CLARK: Okay.
PARTICIPANT: I'm chair of the ANSE Z15.2 committee. We have been working with the insurance industry, the Office of Workers Compensation programs and the Department of Labor's BLS, almost the same groups, all the state workman's compensation commissioners. But our focus was on the coding mechanism and simplifying and standardizing the coding, so that we could better prevent and deal with workplace injuries and illnesses.
I just want to make sure I am invited to your August meeting, so I can try to coordinate the efforts on the ANSE Z16.2 and Z16 committees, and all the X12's, and try to petition ANSE to help you do this in a way that will benefit the working professionals, and try to do it in a way in which we can prevent workplace injuries throughout this country.
So I'll see you after the meeting, and I hope I can get invited to your August meeting.
DR. CLARK: Yes, thank you. Any other questions or comments? Thank you.
DR. MOORE: It is 10 of three. If anyone wants to do jumping jacks to get warm -- by the way, take 15 minutes. That will give us until five after three, and the medical coding and classification team will lead off with that session.
Coding and Classification
DR. MOORE: It is time again. I think we can finish this before five. There was a question asked during the break about the meeting that is coming up in August that was referenced at the last presentation. That meeting is an ANSE X12 meeting that is taking place in Rochester on the 10th through the 14th of August. That is the meeting where these implementation guides will be discussed and further refined. So those of you who are interested in implementation guides should go to that meeting.
As this implementation effort, we are not holding a special meeting on implementation guides. The only other meeting that we have referenced in this session that is taking place in August is one that is being held by the National Committee on Vital and Health Statistics that Dr. Detmer referred to earlier, and I think that is the 5th and the 6th.
The next team for a presentation is the one on coding and classification. This is the medical coding and classification, not all the other codes that might be necessary in some of these transactions.
We have three people who have been co-chairing this effort: Betsy Humphreys from the National Library of Medicine, Pat Brooks from the Health Care Financing Administration, and Donna Pickett from the National Center for Health Statistics. I think Betsy is going to be making the presentation, and I'm sure that we will have a lot of questions when that is over. Thank you. If we can speed it along, we will be out of here early.
DR. HUMPHREYS: As Bob said, this is the coding and classification implementation team. Just to remind ourselves about what we are talking about here, we are talking about codes and classifications for diseases, injuries, impairments or other health problems, or as we might say, whatever is wrong with the patient, the causes of these conditions, which are represented in some of the administrative transactions, such as first report of injury and so forth, and actions taken to prevent, diagnose, treat or manage these conditions, aka procedures, and also we are including obviously the substances, read drugs, and others, equipment and supplies used in the procedures for diagnosing and treating the conditions. So these are the major areas that are covered by this team.
In setting up the charge for this team, the department has looked at this team as one that obviously has immediate responsibilities for the initial administrative standards, but because of the large number of vocabulary issues that relate to the longer term agenda of providing recommendations under Kennedy-Kassebaum to the Congress related to electronic medical records, this team has some responsibilities that relate to that as well.
Our first, and the one that we have been focusing on to date, given the timetables here, is to identify and select the standards for codes and classification for the administrative transactions that are covered by the act, and to insure that there are appropriate mechanisms for distribution and maintenance for the selected standards.
We also see as a longer term effort recommending the set of health vocabularies that are useful for full electronic health records, and looking at the issues related to appropriate mechanisms for distribution and maintenance of those. Then we see also as a responsibility that the department should have to insure that there is some sort of a reasonable map between the more granular vocabularies that will in the future be used in the full patient record, and the administrative codes and classifications which we assume will continue to be necessary for statistical and administrative purposes.
However, having said that, that is the whole charge. But now what we are going to focus on is the first part of it, which is what we have been working on up to date, which is the selection of the initial standards for administrative transactions.
You will not be too surprised by these recommendations. Let me tell you where they came from. There was a combination of inputs here, including the input from ANSE in terms of the inventory of existing standards, information that was known to many of us within the department who have a long history with the various codes and classification systems for other projects, and then primarily we took advantage of, and actually assisted in planning and setting up questions and so forth for the National Committee on Vital and Health Statistics hearings on this particular topic, codes and classifications, which was held April 15 and 16.
So in essence, what we are recommending is based largely on what we heard during those hearings. The overview is that everyone said that for the year 2000, it would be -- I don't want to say everyone, but the great preponderance of testimony said that for the year 2000, we could not deviate from the status quo of what is generally used in health care transactions now. The recommendations therefore for the initial standards follow that.
That means for the diseases, injuries, et cetera, we are dealing with ICD-9CM. As you can imagine, one of the big issues that was addressed at the hearing was whether we should recommend for the year 2000 9CM or 10CM. After evaluating all the testimony that was received on this point, although there were some proponents of moving ahead to 10CM, there were in essence a larger body of opinion that ICD-10CM could not be reasonably implemented by the year 2000, and that therefore we should go with 9CM as the initial standard.
In terms of procedures, we are again with the status quo. THErefore, although there was a great amount of testimony in favor of moving to an integrated single procedure framework or system, where there was a closer relationship at least between any different levels of systems that were needed for different purposes, everyone was pretty well unanimously telling us that for the year 2000 we had to stick with what was in use now, which is ICD-9CM, the third volume, CPT for physician controlled procedures and out-patient procedures, CDT for dental procedures, and HCPCS, which is the HCFA common procedure coding system, which as those of you who use it know, encompasses CPT and CDT.
For drugs, for most administrative transactions, we are dealing with HCPCS. It has a relatively coarse level of granularity for drug coding, and for pharmacy transactions, where the choice is the NDC code, the national drug code. When we get to the device area, again we are dealing with HCPCS.
So we are not talking about revolutionary change for the year 2000, but when we go out with our statements about the year 2000, there will also be some additional warnings and issues and heads-up that life will not remain o the status quo forever.
One of the main issues that came up in the hearings is that we will be mandating or proposing the use of the official implementation guides. In general, most of these systems that I mentioned have official implementation guides, but there is uneven implementation of them, that is, they have to be followed perhaps for certain sets of transactions that come to HCFA, but then people may or may not rely on the same implementation guides in other environments, and people say that this is a problem, so there will -- of course, since we are dealing with national standards, there is going to be an implementation guide that will cover everything.
I think we heard in very strong terms that whether a particular recipient is willing to pay for a particular item at a particular level of specificity, if the code that is sent to them is at least valid and part of the code set, the claim should not be rejected totally, that is, not be able to be processed if it has official codes in it. So there was a lot of discussion about that.
I think we feel very strongly that there is major likelihood of changes in some of these standards in the year 2001 and beyond. One major example here is that it is highly likely that it will time to move to ICD-10CM in the year 2001, and there is also a strong move to have something done on the procedures side. We also have ICD-10 procedure coding system, a new system that HCFA has sponsored the development of, which is in testing.
Let me just say to you that as part of the process of determining what happens after the year 2000, we are going to be very interested in input and testing and test data and reaction, both to the version of ICD-10CM, which will be released for testing in November, and you will be able to find information about this on the NCHS Web page, and ICD-10 PCS is already available for testing, and the information about that is obtainable from the HCFA Web page.
Those of you who are interested in looking at the underlying relational files for the PCS system, which the National Library of Medicine is also interested in, those are not available yet, but they will be available shortly, and when they are available, that information will also be announced via the HCFA Web page.
If you anticipate, as we all do, that there will be changes in the year 2001 and beyond, then everyone who processes these administrative transactions had better start their plans now, because we can guarantee that at some point in the year 2001 or shortly thereafter, you will get codes for these things that are longer than the five digits that are currently being used.
So in terms of other implementation issues, we heard a lot about concern about the openness of the update process for privately owned and maintained systems, and of course, there are a few maintained here in what we are recommending. There were concerns about what would be cost to use restrictions for these systems. There have also been concerns, not so much expressed at the hearings, but we have heard them from the informatics community via other routes, that they are concerned that all of the standards be available in electronic formats that are suitable for the full range of users.
Let me just translate this a bit. Some of the electronic formats that are available for some of these systems may be useful for the individual who is looking up codes and selecting them. They may not be quite as friendly for the people who are building them into large systems, because they are not fully specified database versions of the things that are easier for people that are dealing with large systems.
So having made what we think is the correct initial selection based on all the input, we are now going to be looking at any of the issues that I have mentioned here: what exactly is the situation now with the systems that are have recommenced, and what if any changes have to be negotiated or discussed with the privately maintained systems between now and the year 2000 when these become national standards.
I think that is what I have to say. So we are all available here for questions.
DR. OWENS: I have two questions. The first is relative to supplies. You had it in your earlier slide, but you had no standard listed. Do you have a standard in mind for the supplies?
DR. HUMPHREYS: The alpha numeric HCPCS -- and I'm sorry, we should have expanded this to say devices and supplies. Those of you who are familiar with the system know that this is at a certain level of granularity. I think that in the future, we may want a more granular system, and there is discussion about that.
But again, these initial -- for example, there has been discussion about moving forward to various types of product codes, and in the case of the device area to more granular device systems such as the universal medical device nomenclature and so forth. But again, what we were strongly hearing from the people was that they would not be ready for a move to these systems in the year 2000.
DR. OWENS: Then the second question is relative to the drugs. You had mentioned you recommended NDC. There are three different formulas within the NDC as far as a numbering format. Then there is a fourth that is used by a lot of systems. Are you recommending the three different levels, or the fourth, that is actually an 11-digit NDC that is used by systems? Or do you have a preference?
DR. HUMPHREYS: I think that we have heard that we want to use NDC codes for pharmacy transactions, but we really have to get down to the specifics of that. So any specific input that you have on that issue, we would be delighted to have it.
DR. OWENS: From a systems standpoint, both the major databases and pharmacy actually add a leading zero in either the fourth, the first, the middle or the end section of the number, making it a constant 11-position field.
DR. HUMPHREYS: I think that -- we have heard your comment. We will look at that.
DR. ROBINSON: I have a question regarding the procedure codes. You said get ready for it, it is going to be greater than five digits on the procedure code.
DR. HUMPHREYS: I just said in general on the codes. I would expect it to happen in the procedure coding system as we move ahead. But for example, the version of -- I believe I'm correct that the version of ICD-10CM that is going out for testing -- granted, NCHS may receive comment on this issue -- also have six-digit codes.
I think that the major message here -- and if we were to move to NDC codes across the board for drugs, which many people feel is the way to go in the future, as the gentleman just said, whichever version we use here, we are using something that is much longer than a five-digit code. So I would anticipate that this would probably be true for procedures, and certainly the PCS system that is available for evaluation has a seven-digit code. But it is a general comment. I think people should be thinking about the fact that we are going beyond the point in electronic transactions where they can count on from year to year that we will never change the length of a code.
DR. ROBINSON: Then if it is just a general comment, you probably won't be able to answer my question, which was going to be, have you taken into consideration if you are going to be crosswalking the current five-digit procedure codes to a new number?
Also, the other part of that question is, what is the maximum length that you are thinking?
DR. HUMPHREYS: Let me answer the first question, because we did heard a lot of testimony on that issue. Most everybody believes that to the extent that it is possible to have a reasonable crosswalk between what becomes a new administrative or statistical code for procedures and what was an old one, that such a crosswalk will definitely have to be created.
In some cases, if you change the semantics and the basis of the system to a certain extent, you can't get a perfect one. But something will have to be done, because we will continue to be concerned obviously in terms of health services research and quality and whatever, to be able to compare from year to year. So something like that will have to be done.
Then the issue is, will there be a clean change, so that anyone could guarantee that on January 1, they would receive no data under the old system. Highly unlikely.
In terms of the maximum length of a code, I won't touch that one now.
DR. ZUBELDIA: To what extend are you going to regulate implementation issues? Let me give you some examples. For instance, some payers want providers to use surgery codes for anesthesiology, because it gives them better detail on what the service was. Some payers will not take punctuation in the ICD-9. They only hold five positions, and you have to drop the period. Most payers will not accept E codes in the ICD-9. Some payers will accept three-digit codes when there is a five-digit code available, but they will still accept a three-digit code.
All of these are implementation issues. Are we going to have regulation on this, some sort of standardization on the implementation itself, or just the codes?
Then, after you answer that, I have another one.
DR. HUMPHREYS: I think that what we have heard from the people testifying to the NCVHS is, the desire is to have a standard implementation guide as we have for the other standards, and have that apply across the board, which is what I meant when I said before, that just saying, hey, we are going with the status quo, maybe it won't be exactly the status quo if you had chosen certain options to deal with this in your particular environment.
So I think that there is going to be a lot of discussion on that issue. But I believe the intent here across the board is to have an implementation guide and say, everyone is implementing these standards in these ways. If they are not, then we don't have a standard, do we?
DR. ZUBELDIA: Then will Medicaid programs be allowed to just pay the fine and continue creating their own codes? They are paying with our tax dollars.
DR. HUMPHREYS: Would somebody from HCFA like to respond to that? I guess my feeling is, the law has certain fines, and I don't know whether allowing people to pay the fine is exactly the way to say it.
DR. MOORE: Are we talking about Medicare or Medicaid? Medicare will pay the fine probably, if we don't do it.
On the Medicaid side, there is a burning interest back at the office about, are we going to make funding available to the states to do this. That has been the issue from the states.
One of the things that was mentioned earlier about this, some people have said, this is going to take a great deal of resources, I'm going to have to completely revamp my system in order to implement these transactions. I don't believe that. We already process these transactions in many ways. It is going to require more standardization of the transactions as they come into the system. We are going to have to -- and I think HCFA is guilty of this -- do less customized programming, if you will, where we have more opportunity for failure, and work with translators, work with the tools that are being developed in the industry.
These standards, X12 and others, are being used for manufacturing, for ordering supplies, for doing a whole lot of business that is already moving in an electronic way. One of the things that we are going to have to do here, and this incudes the state agencies and Medicaid, and I know I don't have the authority to speak for governors, but they are going to have to start complying and seeing what they are going to have to do as well.
DR. ZUBELDIA: Bob, the reason for the question is that some Medicaid programs say that to comply with state specific requirements, some legislation in their state, they have to issue new codes that are not HCPCS codes. They are required in their state only.
DR. MOORE: This is the issue that I think was mentioned by Betsy, where some states are saying that the level of specificity that is contained in the HCPCS is not sufficient for their needs. They want a greater level of specificity because of pricing and other things of that nature.
Choosing the HCPCS does not address that issue. Where HCPCS has a -- for a catheter it is a general code, and it can have multiple types of catheters, and there are different prices, and the state wants to narrow that pricing mechanism, so they are pricing more equitably. That is going to be an open issue that I don't think we can address.
The only way that we can do that is to open HCPCS up for more codes. And if that is the case, then we may -- if we select this as a standard, that may be the burden that HCFA has to pick up and add to it that says, we will do a better job more timely of doing this to meet the needs of the other payers in the states, in order to make this a standard code. Otherwise, I don't see how we can make that call.
DR. BROOKS: I'll just mention one point. They are attempting over the past couple of years to increase user friendliness with the alpha numeric HCPCS process, and bring more codes in and do that quicker. They are not perfect, either. But I think that is a long-range goal that we have to work on, is a better coding system, not before the year 2000, to get more specificity for everybody.
DR. EISENBERG: Betsy, Barry Eisenberg from the AMA. I have two questions also, if I could. Yo really emphasized the idea of the status quo versus what might take place after the year 2000, 2001 and so on. Stating that I think is going to create a lot of interest and some anxiety amongst a number of people.
Is it your intention at this point or in the NPRM to lay out your thinking about the timetable and process that you are going to use to address those longer-term issues?
DR. HUMPHREYS: We have a couple of issues here, in terms of what happens in 2001 and beyond. We have the two major codes and classification system efforts within the department that have not been fully reviewed and tested by the field, which are ICD-10CM and the PCS system.
The current timetable calls for us to have had a fair amount of testing and response from the field on both of those systems by about March of next year. I think I've got that about right. So that is going to give us some additional data on which to work.
There is a strong interest as expressed -- perhaps that was mentioned this morning; I came in in the middle of Don Detmer's presentation. The NCHS has made their recommendations to the department, and they have strongly suggested that the department should set in motion a procedure, a process for coming up with quote, a more unified procedure system for implementation. I believe the dates they indicated in their recommendation was like in the year 2002 or 2003. That of course is the NCVHS recommendation. The department has to take their recommendations pretty seriously, in terms of looking at those issues.
So we feel that once we get out the NPRM that relates to the year 2000, that is one thing which is a big thing to do, but we have these other issues to address, in terms of what is going on.
One of the things that I should mention is that there will definitely be additional hearings as we had said in April on the longer term issue of what we see as being required as a full vocabulary that is needed for the full patient record, which also relates to this whole issue of an integrated procedure coding system and everything else. Those opportunities, meetings related to that, are being in essence scheduled now, but are likely to come up in the fall, in the November time frame. They will be heavily advertised, so people will have an opportunity to provide input on those issues as well.
I don't know if I have answered your question. We have to get this done and out. Having identified that we can't make some of these changes by the year 2000, then we have to immediately get on how do we set in motion the procedure to deal with them. But we will definitely be using as one set of information to help us grapple with these issues the information that comes to us from the field on the testing of ICD-10CM and ICD-10PCS.
DR. EISENBERG: Thank you. My second question is related, but goes also to timing. That has to do with the slide just previous to this, where you enumerated a number of concerns. I think you really did a very fair job of enumerating the concerns which have been brought out in the NCVHS hearings.
I take it from the comments that you made that these are also a group of issues which are going to be addressed in terms of the 2001 and beyond issues.
DR. HUMPHREYS: I think they certainly are going to be involved in 2001 and beyond. But in this particular case, we also have to look at -- we have to do an assessment of what is the reality of the situation for the year 2000, because there are systems in use now, and they are distributed under reasonable -- what are considered reasonable conditions related to HCFA's requirements and so forth. The issue is, are those also reasonable if we now are imposing this as a national standard on every type of situation for every type of transaction.
So we are going to be looking at these things. I don't know the answer to that question, you understand, but it is something that has come up as an issue even for the designation of quote the status quo as official standards for the year 2000.
DR. EISENBERG: Thank you very much.
PARTICIPANT: Hi. Do you foresee HCFA reviewing new codes more frequently during the year? For example, at our company, we are having problems rejecting particular the HCPCS codes without a description on electronic claims. I wasn't sure with new drugs and devices coming on the market after the review process to accept new codes, it would be more frequent during the year.
DR. BROOKS: That is one of the things our committee is supposed to work on for implementation. For the short term, no, there are no planned changes, just because that is what industry expects in the systems. It works better to change them once a year. But I think our group will be discussing, is this the best mechanism, or do we need to do it more frequently or less frequently.
DR. HUMPHREYS: These issues were expressed to us as they are enumerated here. People were more concerned about these issues as they related to the privately maintained systems. But I'll tell you that internally, we have also looked at those that are currently maintained by the federal government; are we also in a position to distribute these and to -- we need to look at the procedures across the board, not just for the privately maintained systems. But we have to make sure that we have got something reasonable in place for all of the systems.
Any other questions? If not, thank you.
Security Standards
DR. MOORE: The next and last team is on security. To present that is John Parmigiani and his co-chair, who are headed down the aisle. John is from HCFA and Dennis Steinauer is from NIST. Dennis, John?
DR. PARMIGIANI: Good afternoon. I just wanted to say that our team represents a very broad spectrum of government. We have people from SSA and the department, VA, what have you. Many of them are present here today.
We have also experienced tremendous support and input from various groups and standards development organizations. After we make our presentation shortly, Dennis will be doing that, we'll be glad to answer any questions, not just the two of us, but a number of people that are out in the audience that are on the team. So hopefully we will be able to leave you today with some feeling that we know where we are going and we know what we are doing.
Dennis?
DR. STEINAUER: I don't know whether the rest of you have discovered the online broadcast of this, but I was -- this morning I was wanting to check the up-to-date schedule for the presentations. So I went into the Web page and discovered that they are -- they got a real audio broadcast going on at the same time. So I was able to literally sit at my desk, finish a couple of things on the presentation, get a couple of other things done, and hopefully not miss too much of the previous discussion. I thought it was very handy to be able to do that. I suppose the next appendectomy that I have to have is going to be real broadcast, too, so I'll get to listen to my screams.
Anyway, let me make sure I've got this set up here. What we have been charged to do through the act of course is in general terms to provide some modicum of security or to provide some standards that should provide a modicum of security for health care information in general, specifically for the systems that handle health care information and for the specific transactions, the electronic transactions that are used in the exchange of health care information and the handling of health care activities or health care delivery activities.
Then one of the other aspects of the act is to address the issue of what was called in the act electronic signatures, and I'll get back to this in a little bit, because at least where I come from, we don't talk about electronic signatures, we talk about digital signatures as a very specific technical term, and an awful lot of people probably put together in the same basket that signature that you write on the little pad down at the container store or Sears or one of those places with digital signatures, and those ar not the same thing at all. You probably should worry just about as much when you fill out one of those things.
But anyway, that is generally what our charge is. Now, what we have established as basic objectives in our activities are to first of all, try to develop what amounts to a common framework that can be used by health care providers and other players, if you will, in the whole health care arena, with respect to providing a common level or a consistent level of security that meets the requirements that may be established through the specific privacy requirements, other security requirements.
In a moment I'll define a little bit more what I mean by security. I don't mean just trying to keep private things private.
There has been a considerable amount of work that has been done over the years, and just recently actually, in providing good framework or structure that folks can use when they are trying to establish a security program for an organization or for an entire activity.
The National Research Council of course put out a report recently on the protection of health care information, and it providers a discussion of making sure that there is a consistent security framework before you run out and say, let's encrypt everything, or let's put everything behind nicely locked doors. That is the typical approach that we tend to take in providing security, rather than in looking at the overall picture and trying to provide security that makes sense in the context of what you are trying to protect and what it is you have at risk.
Also, the Office of Management and Budget for several years has provided federal government agencies with a basic structure or framework for security programs. They have recently updated that guidance to reflect a little better current technology and current network advances that have certainly affected how we look at and are concerned about security.
I have been in this area for about 30 years now. I think we spent the first 20 to 25 of it trying to get somebody interested. Now all of a sudden, all you have to do is watch TV, watch CNN, see what has happened recently, see the IDM or the other ads that spend as much time trying to point out that they indeed are trying to make things safer to conduct business and other activities, whether it is on the Internet or using information technology in general.
What we are going to try to do in this process -- as I'll point out in a minute also -- is to try to make use to the maximum extent possible existing work that has been done to existing standards or guidance that has been provided. For everyone's presence of mind, to try to identify those security processes that ought to comprise a baseline for virtually all activity that is undertaken.
One of the things that has caused managers and other folks a lot of problems in the past is spending an awful lot of time analyzing, what do I need to do, how do I need to protect this, and sometimes going through very involved risk analysis processes, which indeed are -- technically, that is the right way to do it, but sometimes you can spend so much time and effort trying to analyze it, as opposed to just doing it. There are certain activities that probably come into what the lawyers call the prudent man concept, or the prudent person concept now, that comprise a baseline. You ought to be doing these sorts of things irrespective of any long drawn-out discussion of how valuable is that information, blah, blah, blah.
Indeed, the recent revision of the Office of Management and Budget circular that I have got cited here has actually taken that into account. In the first go-round with their guidance to agencies, they said, first decide what is sensitive and what is not sensitive, and then protect that stuff that is sensitive.
You can imagine what everybody did. They said, that is not sensitive, that is not sensitive, that is not sensitive, and therefore I really don't have anything I need to do. Government folks I'm afraid in general have a habit of saying, this is all public information, therefore it is not sensitive.
Well, that is patently untrue. If it is valuable enough for us to be spending taxpayer resources, if you will, taxpayer dollars to build these systems and operate them, there is some value in them, presumably. If there isn't, the issue is not a security issue, it is something else.
So anyway, to make a short story long, as my grandpa used to say, we want to try to provide some basic baseline standards or guidance.
Then the last thing is one that we have thrown on our list here, is to try to be technology neutral in the process, not to try to wire specific security requirements to any technology that maybe just exists today or is one kind of technology. That is the wrong way to go about this, because the basic technology we are trying to protect is changing on a regular basis, so we sure as heck don't want to be having our security mechanisms based on some given technology.
We have tried to make sure we have defined carefully what the scope of our work is and what we are trying to do, so that we are not trying to secure the entire world or all information that is handled electronically or otherwise.
Originally, if one reads the act, one might see that what we should be doing is just looking at those nine defined transactions and defining the security requirements for that. Well, even if we were doing that, we feel that there would be relatively little difference in security requirements for those given transactions. Indeed, the types of security standards or guidance that we helped to put forward would apply to any types of health care information. So we certainly have a broader scope than just looking at nine little transactions.
The act also says that it is important that there be consideration made with regard to the technical capability of various recordkeeping systems, the costs that are involved to implement any security standards or guidance that is recommended, other issues such as how long is it going to take to train people and personnel issues, all those things you can see on that list.
The primary rationale, I am assuming, and I don't have a legislative history of the act, but I am assuming that the concern there is the so-called small operator not be put out of business because some onerous security requirements are levied.
I think the approach that we are taking on this is not going to have that problem at all. What it does say, and I think it rightfully says, is that there should be a concern about having security mechanisms or protective mechanisms that are commensurate with the risks that you are facing.
Now, it ends up that in many cases, the determination of what needs to be protected and at least generally how much it needs to be protected is not a security issue. It is a policy issue up front. As I am going to point out with the next item in another slide, it is very important to distinguish between security and privacy. We are not addressing the privacy issues, we are not trying to establish what the privacy requirements might be for health care information. In fact, that to some extent has already been done, and there are folks that are directly involved in the policy and other related activities. There is a separate work group for that.
What security does is provide the mechanisms for implementing and enforcing whatever policy decisions have been made. I want to draw that distinction, and not get pulled into a privacy discussion, because only in a couple of areas is there a legitimate argument that certain security requirements have privacy implications. I'll get to that in a moment here.
Now, as I pointed out, we probably need to draw the distinction between privacy, which involves among other things a requirement of confidentiality in certain cases. But anyone who has read the privacy act or even partially understands the concepts and the discussions that have gone on for almost three decades now with respect to privacy, many aspects of privacy are making sure that information that is recorded about you for one reason or another, you have a certain amount of control over.
That is not just an issue of keeping it secret or keeping it confidential. You want to make sure it is correct, you want to have the ability to challenge it, all of those things. So those are all part of the privacy problem. It is a policy, it is a legal issue, it is not fundamentally a technical issue, although our technology has certainly affected how much we become concerned about privacy.
Confidentiality as I mentioned is one of the elements, and security is the set of mechanisms that allow us to insure or protect confidentiality, and these two other equally or normally equally important aspects of information and systems, integrity probably being the one that ought to be listed first. If we are not concerned about the integrity of data that we are maintaining or using in the decision making process, I've got to ask, what is it that we are concerned about.
That is not a privacy issue fundamental, except for your right to make sure yourself that data about you are correct.
Then another aspect of security that often gets addressed in other issues of reliability is making sure that a system that is supposed to provide some sort of a service or a process is available to do that. It can't be arbitrarily or accidentally disconnected.
So we look at the whole security picture as addressing all of those issues. We also -- again, in trying to define specific standards or guidance, it is important to not just say we need security. You really need to break it down into some way that allows you to look at more specific controls.
The traditional way, or the way that we have found to be most useful at least with respect to information technology is to make sure that there are mechanisms that enable us to identify the various players, the people, the users and the information or the systems to which they are gaining access, to have some sort of a mechanism that allows you to authenticate, in other words, prove that that user, who is probably off at the end of a wire someplace, really is who he or she claims to be, the authentication mechanism being the one that seems to be one of the major problems in large distributed networks.
You can't and often never see the individuals that are involved, and therefore, if you are going to be making business decisions or any other kind of access decisions based on, this is Joe Smith, you need some kind of authentication mechanism to verify that identity. And we have technology of course that enables us to do that reasonably well now if we choose to use it.
The third mechanism is one that allows us to in essence set rules, who should have access to what, and in some cases, what should have access to what. In other words, what system might have access to what other system and what functions. So that is a technical mechanism that is crucial in this whole process.
Then the specific mechanisms that allow you to enforce the access controls and enforce the identification. Then given that we often have to go back and determine what did happen for a lot of different reasons -- sometimes, when something goes wrong, you go back and try to reconstruct events or reconstruct information. Sometimes it is because something illicit went on, and you need to go back and find out what happened, for legal purposes or even law enforcement purposes. So there is an additional need for an audit mechanism or an audit trail recording mechanism, and then ways of handling that.
So those are the basic technical mechanisms that we tend to build security systems on.
Now, let me briefly tell you where our work group stands, in terms of what we have accomplished to date and where we are trying to take this whole thing. We have gone through a process of developing glossaries of key definitions, and we have made extensive use of work that has been done by others. In fact, wherever possible we attempt to identify other work first so that we are not trying to re-invent the wheel. We don't have time to re-invent the wheel, even if we had an inclination to do that.
We have established a website specifically for our working group, for the sharing of information, and then also for the bubbling up of information into the overall HIPAA website that is generally maintained.
Then probably the key thing that we have done is to try to make sure in this process of seeing what has been done, what people are doing and what standards people either are already using or want to use. We have spent a fair amount of time in outreach efforts, talking ASTM, AFEHCT, ANSE, et cetera; we've got several of those listed up there.
Also, we have had ASTM and CPRI come forward and suggest that some of the work that they have done over the last years and some recent work that they are doing could be part of a joint effort to try to identify and establish certain technical standards that could be used.
I think this is important from two standpoints, the fist one of avoiding re-inventing a wheel we don't have time to do, but more importantly, these are part of the voluntary standards community that comprises the folks who are out there recognizing the value of having standards that can be used for interoperability, for general cost effective operation. These are standards that folks have agreed to use.
So this is the way that certainly we at NIST have always attempted to use in trying to establish standards, rather than writing our own. I think the same thing applies in this activity.
I just saw a little note that I made on my copy of the slide. I want to back up one slide here just very briefly. I identified these five different mechanisms which are fundamentally technical mechanisms or primarily technical mechanisms, that comprise overall a security package. But it is critical to recognize that the overall security structure or framework has to include administrative procedures, in some cases physical controls, particularly in the area of access control. You often have physical control, even in the authentication mechanisms. Then there are a number of technical controls, so that was a point that didn't show up on the slide that I wanted to make sure that we discussed.
A couple of other things that we have done is in talking to the groups that I mentioned before, we have identified a few others that have activities going on, even if we haven't had the opportunity yet to spend time specifically with folks. There is a lot of material that is out there at this point, and it is very helpful.
Several of the organizations of the members of the working group have been involved in this area for some time. I am the deputy director of the computer security division at NIST, and we have for 30 years been issuing specific technical standards and management guidance in this area, so there is a lot of stuff that is available that we are going to be using.
What we are focusing on right now is what we have called, for want of a better term, a preliminary requirements analysis. That is basically, what is it that we need in that framework that I mentioned a couple of minutes ago.
The requirements analysis has as its underlying requirement something that allows interoperability when we are talking about electronic transactions. It is no good if we have one security mechanism or any other kind of information exchange mechanism that someone else can't use, and therefore just plug into, and interoperate, as we like to say in Dilbertland. So the interoperability issue is an important one.
Then in addition to that, we are concerned about consistency. In other words, one can apply or use lots of different types of technologies, but you are going to get inconsistent results and inconsistent levels of protection if you don't spend some time looking at the consistency issue.
The key activity right now is focusing on building what we can call a basic security model, in other words, something that allow us to identify the parts of what are existing in information technology systems that are handling any kind of information, but in particular health care information. We have built an initial matrix, what might be called a protection profile, but basically it is a matrix that identifies existing or available standards or guidance for protecting information.
We are generally looking at two classes or two states of information. For simplicity, we are calling it information when it is at risk, in other words, it is sitting on a disk someplace, it is sitting in backup material, and also perhaps sitting in hard copy form. That is essentially data at risk.
Then we also have the concern that most people identify with a computer security concern, data in motion, in other words, when it is being sent over networks or otherwise what we might call unprotected channels.
Out of this, we hope to develop those baseline standards that we were talking about, that I have mentioned several times. If you are going to use an identification mechanism in certain environments, it ought to be something stronger than reusable passwords, as an example. In other cases, that may still be an acceptable mechanism. But we don't want to get going on reusable passwords; I get on a soapbox quite often about that.
Anyway, we do recognize that there are a number of other working groups that are a part of the entire HIPAA effort. There is only a limited amount of opportunity to make sure that we aren't stepping on the toes or vice versa of one of our other working groups. So one of our ongoing efforts is to try to make sure that we aren't going off toward Joneses when everybody else is going the other way. So that is a constant challenge in this process.
A couple of the issues that we have to deal with. We don't want to be technology dependent or technology specific. We want to try to be neutral in that area. One of the ways you avoid that is by not getting too specific or too detailed in the requirements.
Now, of course the danger of that is, if you don't have things at a reasonable level of specificity, then people say, what is it I am really supposed to do? There is a certain mind set that says, tell me exactly what to do, I'll do that, and everybody will be happy.
Well, I can almost assure you that that isn't what is going to come out of this process. We all get paid reasonable salaries to analyze things and make decisions. It might be nice if someone could lay out a cookbook and that baseline set of standards that I was talking about would provide everything that one needs to do.
People that are looking for that are going to be disappointed, because there is no way in the world that we can do that without having everybody scream properly, tell me what needs to be done, don't tell me how to do it. I think if we are successful in trying to identify what needs to be done and avoiding saying do it exactly this way, then we will be quite happy and I think most other folks will be happy as well.
Ten as I also indicated earlier, because the act specifically cites some requirements or some analyses that says, don't make these things onerous, particularly for the small folks -- and I think if they are onerous for the small folks, they are also going to be onerous for the big ones as well, so that is one of the concerns that we have.
Then one of the other issues that we are still wrestling with is trying to keep separated and identify the technical requirements as opposed to the legal and other requirements in separating electronic signatures from digital signatures.
Just briefly, a digital signature of course is a very specific technical mechanism that is used to bind an originator of information to the information itself. You might think of it as a combination of checks to make sure the data are correct and also a wax seal that only I can put on that, and you can verify that it came from me.
So you get two things out of digital signatures: you get a verification of the integrity of the information itself, and you bind it to an originator. That is getting very simplistic in the process, but that is the essence of it.
The value of digital signatures and other types of encryption technology is, it means that we have an opportunity for a much higher level of security than we have in any kind of existing hard copy, manual process. As many of you know, one of the difficulties that individual states are having right now is to get their laws changed, so that things that require a pen and ink signature no longer will require that, as long as you have an adequate technical substitute for it. That is really what a digital signature is.
All of this has fundamentally nothing to do with scratching your signature on a little pad, so that that can be digitized and stored along with some information. One can use digital signatures to make sure that that was indeed the signature when it went in. But anyway, we are getting lost in some of the details there, but you can see some of the problems that we have.
I think that is about where I want to end this. I'm sure there are probably some questions. Well, maybe there aren't, maybe we have answered everything. But that is where we are going right now. We are on the same general timetable that everybody else is. In other words, it is way ahead of enough time to get everything done. One of the things that we have to face is the fact that both as the information technology that we are using is constantly changing and getting better and faster and cheaper; the security mechanisms that we are attaching to them are rapidly becoming more routinized, so that we will see them part and parcel of systems, and we won't even be thinking about them, I hope.
PARTICIPANT: By your discussion of digital signatures for electronic signatures, is the direction of thinking on the team that you would require digital signatures? And if so, are you looking to specify for what transactions, or in general?
DR. STEINAUER: The question, for those of you that are listening to this on real audio, -- since one of the things I learned sitting at my desk was, I couldn't hear any of the questions, I could only hear the answers, was, are we looking to specify what types of data or what types of transactions will actually require digital signatures.
I'm not sure what the answer to that is at this point. What we want to do at least initially is say, if a digital signature is required, here is a technical standard or a family of technical standards that will provide a digital signature that is trustable for whatever purposes.
That can be a very highly technically involved process. That is one of the areas where these kinds of technical standards can be very valuable. The next step then of course is to determine in which cases, what type of information is a digital signature needed.
I would argue that in the vast majority of cases, since what you are providing with a digital signature is simply a way of knowing that the information in a transaction is correct, and if that transaction is one that perhaps could be very fraud prone, then it is going to be in the best interest of either the government, if the government is paying for those transactions, or on the part of other payers who want to make sure that transactions have come in only through authorized sources, to actually apply a digital signature, or other mechanisms to make sure the data are correct.
You already do that. You have a lot of mechanisms, everything from -- back when we used to double punch every transaction in order to catch errors. That kind of thing is very expensive to do or might be very expensive to do, but if the types of efforts that it prevents justify it, then you do it.
Digital signatures are the same way. Now, one of the advantages was that this technology is getting rapidly easier and cheaper to use. The industry itself through a number of initiatives in the financial industry, among others, and in the network industry in general, are rapidly coming to closure or coming to agreement on basic standards for doing this. When all of that happens and comes together, all of a sudden that technology is going to be so simple and so cheap to use, you would rather do that than just send in a transaction without a digital signature on it.
DR. ZUBELDIA: I'm a little confused about the scope of the security work group.
DR. STEINAUER: You're not the only one. We have spent a lot of time on that. But go ahead.
DR. ZUBELDIA: You mentioned that this is for the defined transactions only.
DR. STEINAUER: For a reasonable amount of our initial discussion, we thought that was what the act said, and that we were to only look at those defined transactions. If you remember on that slide or noticed on that slide, I said defined transactions, comma, but dot, dot, dot. Our basic conclusion was some time ago that the kinds of security mechanisms that need to be applied are going to be needed, and they will apply for any type of transaction. So we are probably not going to spend much time at all looking and trying to analyze what is different from a security standpoint in those transactions.
DR. ZUBELDIA: From the list of entities that are involved in your group, I saw --
DR. STEINAUER: Entities as in organizations?
DR. ZUBELDIA: Organizations, yes. I didn't see X12 as one of the entities.
DR. STEINAUER: I did list ANSE and of course ANSE is the accrediting body for X12 and others.
DR. ZUBELDIA: X12 already has all the security mechanisms to secure the defied transactions. So it looks to me like what you are actually securing here is everything but the defined transactions, because the defined transactions already have a security mechanism through X12.
DR. STEINAUER: That is probably a fair statement, given that what we are concerned with is any kind of -- technically, we may be concerned beyond just the electronic exchange of information, but that is where we have something specific to say.
Basically, I think you're right. Those defined transactions are simply specific cases of more generalized EDI transactions.
DR. ZUBELDIA: One concern that I have is that you are taking into account the needs of the small provider and rural providers. I would like for you to take into account the needs of the large clearinghouses and switches, for instance, because if we have to do digital signatures and encryption with certificates on every transaction that we get, getting two and a half million transactions a day, there is not enough seconds in a day to do that. We have to move to Mars or something.
DR. STEINAUER: Yes, we have had some discussions, and that has been pointed out. I would like to think we would have recognized that anyway. That is why I went through a convoluted answer to the first question: are we going to require digital signatures on al types of transactions.
I don't think so at all. I don't think we have either the need nor probably even really the authority to say, you've got to sign everything. In most cases, the decision of what specific mechanisms are to be used will be determined by who the parties are that are exchanging the information.
Now, to the extent that in some cases, the government is one of those parties, it may be appropriate for the government to say, you send me transactions for ten million dollars, and I want the damn things digitally signed. But in general, signing all individual transactions is not an implicit requirement in any of this, as far as we see.
PARTICIPANT: Kepa, in line with your question, this is why we have added this interoperability. Our concern is that we are providing a broad array of solutions that can be chosen from by various players in the marketplace. The important thing though is that there be connectivity with these solutions.
So we are not trying to say -- we're not just catering to large or small or whatever. We are trying to come up with something that is going to meet everybody's needs, at the same time be appropriate for the level of protection.
Closing Remarks
DR. MOORE: Thanks, John, Dennis. Our intent today was to let everyone be aware of where we are, what we are thinking, any progress that we have made since we have last spoken to you, either collectively or in smaller groups. I hope that we have done that today.
I would like to thank Betsy Humphreys for getting NIH to let us have this facility. I would like to thank you all for coming. If you have questions, most all of us can be reached through e-mail, or you have the two bulletin boards that I showed, the websites, both for the Data Council and for the NCVHS, for information.
As we progress with these standards, we will be putting information out there on the Data Council site. As the NCVHS has hearings, the transcripts of those hearings will be on the NCVHS website.
We will be at the X12 meeting in August. There will be other meetings. I ask you to send in comments to us. You can address them to the Secretary. You can address them to the administrator of HCFA or other ones that you deal with, whether it is OPM, et cetera. I would encourage you to do so.
Also, I would encourage you to read the implementation guides as they are developed. We will be going with the X12 transactions for everything, as you saw, except for the pharmacy claim, retail pharmacy. That is the direction we are going. We felt, even though there were other suggestions, in order to meet the mandate for a single standard, and that is where we are trying to go, we felt we had to go with something that had to have the backing of the industry in general, as well as the participation of many individuals in all parts of the industry.
Thank you for coming. Have a safe trip home.
(Whereupon, the meeting was concluded at 4:20 p.m.)