Capital Hilton
16th and K Streets, NW
Washington, D.C. 20036
Major Topic: Perspectives on Security Issues in Implemention of Administrative Simplification Provisions of PL 104-191
MR. SCANLON: First we will have a little bit of discussion about terminology and follow up on our work plan discussion. Then we will dig right in to the data content, to the extent that we will have materials today, which will primarily focus in on the NUCC and NUBC report.
DR. COHN: Good morning, everyone. I wish I could say after a couple of days that the jet lag got better in the early morning from the time change, but it doesn't always.
I had brought up the issue yesterday about the conference being put on. I just wanted to elicit some feedback, really just thoughts from the committee in relationship to the conference. Obviously, the committee has a long history of interest and activities in the area of codes, classifications, nomenclatures and terminology.
Terminology is the term I typically use as the umbrella term that includes all of that.
The committee, as we begin to move into our responsibilities, both in terms of the overall code set responsibilities, as well as the issues around data content for the electronic medical record, the issue of these code sets will become more important.
Now, I think as you all know at the last meeting of the NCVHS, there was some brief discussion around a national terminology conference that is being held in November. The lead group on it is the CPRI, but also includes some sponsorship by the American Nursing Association. Truthfully, without the information in front of me, I will stop listing other lead organizations' names, but there is a variety of groups involved. I think there was interest in the last meeting for there to be some involvement for the NCVHS, or at the very least, assuring that topics were being addressed that would be of value to furthering along HIPAA, our needs in the area of codes, terminologies, classifications and nomenclatures.
Now, I think the question I had for everyone is just your thoughts about, if a group of experts in this area were to be addressing some focused topics, what might we think might be of value to us as a major public advisory committee, in terms of getting some input on. I think this is going to be a wonderful opportunity to get some additional information.
This is a wonderful first discussion point of the morning, isn't it? Certainly the procedure coding system is one. Kathleen, do you have any comments about that?
MS. COLTIN: No, I would agree that that is number one.
DR. COHN: That's number one.
MR. BLAIR: I couldn't hear the articulation. What is number one?
DR. COHN: The procedure coding system issue. I think we have reached some agreement that we need to move forward on a comprehensive approach to procedure coding, but have really not spelled out the details at this point.
Are there other issues that the committee would think would be of some significance or value? Well, I will talk to many of you individually. I suspect that we can pull some things out in private sessions.
I guess I should ask the audience also, before we finish, do any of you have any particular comments, questions or any input that you think would be valuable in this area from basically a national expert panel, or a conference on this? Okay.
MS. GREENBERG: Something might arise from our discussion. How many people who are here are actually planning to attend the conference?
MR. SCANLON: What is the date?
DR. COHN: It is the 12th through the 14th of November.
MS. GREENBERG: Wasn't it only two days, though?
DR. COHN: It is a half day, full day and another half day.
MS. GREENBERG: I guess the agenda is pretty much being firmed up now, right? When we all wake up, we should get back to Simon.
DR. COHN: Please. Thank you.
DR. LUMPKIN: Those are the same days as the International Congress on Performance Measurement and Improvement of Health Care.
MS. GREENBERG: Where is that?
DR. LUMPKIN: On my pilot. Probably the same location.
The next item on our agenda, which is a small item, has to do with data content. I'm wired because I am going to go to the blackboard as we go through and take some notes, so for those of you who want to know why I'm not speaking into the microphone, it is because I am actually wired for sound.
We have a task before us that is almost impossible to do as it appears, much as a lot of our K2 assignment was when we first started. There is an old African saying about how you eat an elephant, and the answer is that you eat an elephant one bite at a time. So despite the fact that we know there is a matrix in preparation that the contractor is preparing, and we will have that for our next meeting, the thought was perhaps we would start off with some of the materials from NUCC and NUBC, probably starting off with the NUCC document, which we have all had, and to walk our way through it.
There are some key issues which Kathryn has raised that we need to address. Conceptually, as part of our exchange of information, the concept is that what we want to move towards is some sort of uniformity. To the extent that you have a document which makes some data elements required and other data elements not required, you begin to move away from that uniformity.
So I would suggest that we begin to look at the document that we all have, the NUCC document, and that we try to accomplish perhaps two tasks today. The first is to do a comparison of those items and see whether or not
we are comfortable, to the extent that this recommendation meets our core data set and how they address it. There is some discussion on that on page 7. Items are referenced within the document that are on the core data set. Part 7 on page 10.
Then to go through the individual data elements, with particular attention to those items which we think may be important, that were determined to be required, that we think we may or may not have agreement with, and those items are listed as being optional, which again we may or may not have agreement with, and perhaps get a little feel for this process. Let's do it for awhile and then go back and re-evaluate whether or not we think this is a reasonable way to try to approach this elephant.
Does that seem to be an approach that is -- Kathy, do you have any beginning comments?
MS. COLTIN: No, I think that's fine. I think that each of the data elements listed in the NUCC has a list underneath it of how it maps to other data sets, to the 837, to the NSF, and also to the NCVHS core data set. So you know that if an element that is present on the NUCC data set is also in the core data elements data set, it will be so marked. What is a little more difficult is to identify elements that are in the core data set that are not in the NUCC data set. That you may want to consider, in terms of their appropriateness. There isn't that reverse map, so that will be a little trickier to try to address.
DR. LUMPKIN: One of the overarching issues that will come out through this discussion is, to what extent should this document, which is a report on an encounter, reflect those items that may be somewhere else, such as in an enrollment form. I think rather than trying to discuss that issue as we get to data element, maybe we might want to start off on that first, at a conceptual level, and proceed to the document.
MS. GREENBERG: I think you're right. That is one generic issue. I think that was why we need to know what is in the enrollment and eligibility transaction. Now, my understanding is, it is quite minimal. There seems to be kind of a void that needs to be filled. That is, there are elements that were recommended by the committee and were not recommended for collection at every encounter, and maybe don't even make sense to collect it at every encounter. But preliminary discussions with the eligibility and enrollment people, who are looking at it on that team, also they question whether they are appropriate for that transaction. They certainly are not currently in that transaction, is my understanding, although I have yet to actually see what elements are in the eligibility and enrollment transaction.
So they fall between the cracks. I think sometimes a creative response to that is needed. I know certainly -- well, they were considered critical elements by the committee, but also I know by certainly people in CDC and other parts of the department.
So I don't have a solution to it, but it is kind of betwixt and between when it comes to these kinds of transactions. In fact, some of them -- I remember, we had a discussion that -- I remember Kathy explaining that some of them would not actually be collected at the time of enrollment or eligibility by the employer, but might be collected at the first encounter or in the first interaction of the health plan with the individual. Is there something then that can be updated to bring those in, or how does that get into the data set?
I think certainly the states have had the experience where it has been very difficult to get information of that type to link with the encounter data. So it is a problem.
DR. BRAITHWAITE: I think we have to be very aware in this discussion, which I think is a very important one, that the industry is still in a difficult transition, from a time when only the insured was recorded anywhere, nothing about the people who were covered under that policy were recorded, and it was all done on paper. The industry depended totally on the information that came on the paper claim form to do any processing whatsoever about those individuals, even though logically now we think about the computerized record in a relational sense, of having information on an individual being something you got from the individual, and then information about the encounter you got from the provider.
So we are in this transition where much of the industry is still dependent on gathering a lot of the enrollment information from the provider, because they just don't have it. We might want to think about the ideal, that is, information about the individual coming from the insurer at some point in the future, and information about the encounter coming from the provider solely, but recognize that those are going to overlap for a number of years.
DR. LUMPKIN: The other issue, and perhaps others may help me with this, we are looking at the components of the NUCC that will be included in 837, is that correct?
MS. COLTIN: Well, I think we need to look at all the components of the NUCC, because if they are not accommodated by the 837 and we believe that they are important, then we need to make a recommendation that they be added to the 837.
DR. LUMPKIN: Let me rephrase my question, because I think that is a different issue. Part of the responsibility of the NUCC, as I understand it, is to look at an encounter form, whether it be paper or electronic. Our responsibility is in the electronic arena. The issues of a document on paper versus an electronically submitted claim are different.
Let's take an example. In my wife's office, when a patient comes in, in her system they record the name, address and demographic information. It goes in the system. There is no burden of reporting that with an electronic transmission, because that is automatically transferred by the system when the general electronic billing form is created.
If on the other hand she were working in a paper office, that would mean that those lines would have to be filled out every single time, and that is a burden. So because we are still working in both an electronic and a paper environment, a single document that covers both will have certain limitations that we may not necessarily feel restricted to if all we are talking about is the electronic transmission. Simon?
DR. COHN: John, I actually agree with what you are saying. I was thinking initially that you were moving off on a different tangent, but it is really very pertinent to this.
I think we get in some trouble when we try to connect too tightly data content and work floor issues. I think that is really what we are beginning to get into right now as well. We know we want this data element, but do we collect it during an enrollment process or do we collect it as a part of a claims process? How and where are we collecting it?
I'm not sure that we need to hear how that may happen from real experts in the field about how all this may happen. Maybe it is our primary responsibility to really assure that the right data is being collected, and then say to them, how are you going to do this?
I guess that would be the approach I would take, rather than trying to figure out under which environment. But I am also persuaded that in the guise of administrative simplification, you're right, you don't want people to have to do four things over and over again.
MS. GREENBERG: I don't really disagree with what you're saying, but actually, I think the committee's purview or certainly recommendations that the committee has made in the past, could cover -- no matter how the data are collected. The committee was involved with the NUBC a number of years ago, when a lot of that was still paper. But on the other hand, I think the electronic transactions probably offer -- and the fact that you are not totally restricted by paper probably offers more opportunities rather than fewer. But in the context of the administrative simplification, it is true that the electronic is the focus. But I think again, concurring with what Simon is saying, the issue is what data really should be collected and how feasible is it in the various ways that data are now collected.
DR. LUMPKIN: I think one of the important things that we need to bear in mind is the magnitude of what we'll be discussing. I don't know the full numbers, but I know that there are somewhere in the neighborhood of 100 million emergency department visits a year. I don't know how many other out-patient visits there are estimated. Do you know, Bob?
MR. MOORE: The best estimate I have on the total number of claims that we use is like 4.6 billion, which incudes admissions and all services of all types for all payors. So you're looking -- I guess a good round number would be five billion transactions.
MS. GREENBERG: For Medicare?
DR. LUMPKIN: That is the guesstimate for the total?
MR. MOORE: That's for everything, because we are talking about for everything, I thought. We're not just talking about Medicare. Medicare is a lot less.
DR. LUMPKIN: So one of the things -- and I'm going to write it up here, every one of these things that we put in here, we're not putting one in, we're putting five billion a year. So it becomes not insignificant when we take that perspective. Somebody has got to do that five billion times.
DR. COHN: But having said that, John, just to take the other side of this, the committee should not really care whether to get that information, it has to be entered multiple times and the person is changing insurance companies, or if you are in an integrated managed care organization, it was entered once and that is it and it never has to be entered again, right?
DR. LUMPKIN: Right.
DR. COHN: We should try to collect it once.
DR. LUMPKIN: That's right, we should try to collect it once. So to the extent that our task is not only to standardize but also to simplify, it is just a lesson I learned very early on when I was trying to do research in the emergency department and wondered why no one ever filled out my forms. It is because each data element should be considered like a drop of gold, because it really is worth a lot of effort to fill them out.
MS. COLTIN: But John, if we are talking about standards for an electronic environment, then shouldn't we be assessing the reporting burden in that environment, as opposed to in a paper environment?
DR. LUMPKIN: Exactly, I agree.
MS. COLTIN: And if the burden is much less because some of these things can get entered once, then we should consider that.
MR. ARGUS: I think all of you have some interesting points here. I think the key focus in my opinion is defining, number one, the data components that make up a particular transaction first and foremost, worry about process redesign as you move forward beyond defining the data components.
But whether it is paper or electronic, there is somebody keying something in at some point in time. The challenge is to balance the electronic in the future in terms of not being enticed or falling into a pattern of creating more data just for the sake of data, because data is costly to collect, whether it is paper or electronic. It is just that it is easier in terms of transmission to move it forward.
So I think the key thing here is, if you look at the NUCC or the NUBC data elements, define the universe of data elements first, and say, does this in fact make up and can describe the series of key events that may take place within the particular transaction, without getting into the process of who enters it and when they enter it. I think that comes later.
DR. LUMPKIN: George, you are with?
MR. ARGUS: The American Hospital Association and the chairman of the National Uniform Billing Committee.
DR. LUMPKIN: Thank you.
MR. MAYS: Yes, I'd like to make a comment, and it goes to the difference. There is actually a fundamental difference --
DR. LUMPKIN: Can I ask you --
MR. MAYS: Yes, I'm Bob Mays from the Health Care Financing Administration.
DR. LUMPKIN: We probably should have done introductions before we got started. Are we connected to the Internet? Because there are some 10 or 15 or maybe 100 or 2,000 people out there. It may be better if we identify ourselves, even those of us on the committee, before we speak.
MR. MAYS: Bob Mays, Health Care Financing Administration. I believe that there is actually a fundamental difference between collecting the data in different media, whether it is paper or electronic. The main difference, which you alluded to, Dr. Lumpkin, is that in the electronic world, one can link data much more efficiently.
So I think that we have to be careful about examining each transaction as if it stood alone and by itself, because that is not the case. There are actually a constellation of transactions.
We have already heard Miss Greenberg talk about the fact that -- should it be in the encounter or enrollment, or should it be over in the claims side. That is I think a very relevant way of looking at it. In the electronic arena, if you have a constellation of interconnected or potentially -- as long as those transactions can in fact be linked to one another, it only has to appear in one of those transactions. You don't want to say, we're going to define 16 elements in every single one of these transactions when in fact you could link the transactions using only one or two of the elements.
So I would propose that that be kept in mind, and not that the transactions be examined solely as stand-alone individual transactions, which in the paper world they would much more likely have to be looked at in that way.
DR. LUMPKIN: Maybe if we can take a quick break to do the introductions. When we started the meeting, the Internet connection wasn't online, so I think we'll do the introductions and introduce the audience, and then go back.
I'm John Lumpkin. I am director of the Illinois Department of Public Health and chair of the work group.
MR. SCANLON: I'm Jim Scanlon from the U.S. Department of Health and Human Services and the executive staff director of the National Committee.
MS. GREENBERG: I'm Marjorie Greenberg from the National Center for Health Statistics and executive secretary to the committee.
DR. COHN: I'm Dr. Simon Cohn. I'm the CIS coordinator of Kaiser Permanente and a member of the committee.
MR. MOORE: I'm Bob Moore from HCFA. I am the liaison to the committee.
MS. COLTIN: I'm Kathy Coltin, director of external affairs and measurement system development at Harvard Pilgrim Health Care in Boston.
DR. GELLMAN: I'm Bob Gellman. I'm a privacy and information policy consultant in Washington and a member of the committee.
DR. VAN AMBURG: I'm George van Amburg. I'm a health researcher from Michigan Public Health Institute and a member of the committee.
MS. BALL: Judy Ball from HHS, and on staff to the subcommittee.
DR. LUMPKIN: And we have Jeff Blair, who had to step away from the table for a few minutes, from IBM and also a member of the committee, and Bill Braithewaite, who is our chief of staff or something like that to this work group.
(Whereupon, there followed introductions from the audience.)
DR. LUMPKIN: Thank you. I think where we were headed in this discussion, and it really is a little bit different than where we were starting, but I think it is important to get this out of the way, we really need to talk about some conceptual issues, and Bob Mays raised that. We have to recognize that each of these transactions don't stand alone. They really are part of a cluster of transactions with data elements that we are dealing with.
So perhaps at this point, we may want to spend a little bit of time in discussing to what extent do we expect there to be overlap with data elements from one transaction to another, of non-essential -- name we need, but address and perhaps as a good example would be the location of the employment of the parent, which one would expect would be on an enrollment form; would we expect to see that kind of information on a transaction form. Let's take that as a straw man or straw person, in whether or not that kind of issue as an example of our vision, do we see the information on the transaction to point to information that is elsewhere through the universal identifier, or do we expect that information to be repeated in the electronic environment. Or am I completely off base? Jim?
MR. SCANLON: Maybe start with the easier items. Typically, the information that is of interest on the encounter form or the claims form that may be also on an enrollment form would be certain kinds of demographic items, I would guess: age, sex, race, potentially address and location, things like that.
There are related person descriptors and family descriptors that might be of interest as well. The issue though is, when one in fact can link enrollment and encounter data electronically, then there is this interaction between what needs to be on the encounter form versus -- and collected at each encounter, versus what can simply be linked.
But I think we are dealing with a hybrid situation, where the enrollment process takes place, there may be records somewhere, paper or computer, but the link doesn't necessarily take place, so that the complete enrollment record with the demographic information isn't necessarily available all the time.
But I think it is more demographic kinds of items that probably are in this area of, are claims more appropriate for enrollment information. That is I think where the difficult area comes in. Do you collect these at each encounter? Do you collect them once and then link them? Or is it a hybrid situation, where you really don't know? You say, these are the items that are of interest. These are the items that are of interest for each encounter and leave it up to the functionality about where it is collected.
Beyond demographic, I"m not sure there are -- there are some administrative, as you indicated, John, where it is necessary simply to carry out the insurance transaction, to coordinate benefits or whatever. But I think it is the demographic items that are probably the most important.
MR. MOORE: I don't think you can leave it up just to the chance encounter that it is going to be collected. This is something we heard yesterday, that the industry is saying, tell us what you want and give us some of the base rules. So if we are going to come up with a series of data elements that are going to be required for multiple purposes -- and I think one of the things that the committee discussed early on was that the billing is getting beyond just for payment purposes. It is being used for quality assurance, it has been used for looking at access to care, a whole bunch of issues, as we get more involved into managed care and so forth. So we need to be aware of what is happening elsewhere, like with NCQA, how they are evaluating managed care, what information is available.
I think that is one of the points that Kathy is raising, since she comes from a managed care plan. Just how are we going to go about organizing the data that is required to do health care in this country, and what is a strategic point that we can try to pull that together? Maybe we can get a lot of comments and so forth.
One of the things that we are doing as part of the standardization effort for the transactions is, we are trying to wrestle with the definitions. One of the things that we learned yesterday in security, and the day before, is that not everything is clearly defined, that there are a lot of ambiguity, if you will, about what we mean by encryption or whatever.
So as we go through all of these transactions, right now I think we are looking at -- and I didn't make a copy for everyone, I only have one copy, but we're going to have this on a website, but we are looking at probably 5,000 data elements, different data elements in the transactions that we are looking at. That is not counting anything that might be embedded in some attachment.
What I did to date for the committee is put together -- and I had it printed out last night. It was on my chair when I got home about seven. I have the definitions that we have wrestled with so far for the NUCC and NSF, which is part of the NUCC effort, and then the UB-92. Those we are looking at as we move over to the 837, but it gives you at least where we are to date.
Then this other will be available to you. It will solve some of Marjorie's problems. This is an alphabetized listing of all the elements. It tells you where that element appears in what transaction, and what location, and eventually -- Bob, you can chime in here any time. When I start to get incompetent, you need to help me.
MS. COLTIN: If you look at the NUCC data set, there are 19 data elements devoted to insured information and another 19 elements devoted to other insured information. In theory, if you had the unique identifier of the insured, the unique identifier of the other insured and the payor I.D. for each one of those, you should be able to link that to the enrollment data at that payor for each one of those individuals, and pull in every one of these other data elements.
So to spend 38 data elements in every encounter or bill, if we are talking about burden, it seems to me those aren't the data elements that I would like to see the effort expended on, if in fact they could be easily obtained through linkage to a standardized enrollment transaction, and the data elements contained in that.
I would much rather see us add data elements if we are going to, or argue for the retention of data elements that have to do with some of the activities that occurred at the visit, at the encounter, than all of this insured information that could theoretically be obtained from the enrollment transaction.
DR. LUMPKIN: So we are talking about roughly 150 billion communications of data elements, which if they go across the Internet will be encrypted and then decrypted with a significant hit on performance of two or three times if it goes through a clearinghouse.
DR. COHN: Let me just make sure I understand, Kathy. Are these required data elements or are these optional?
MS. COLTIN: Many of them are. Many of them are either required or conditional on the variable value of a required element.
DR. COHN: I can't speak for the NUCC document. I know in some of the other documents, a lot of these things seem to be insurer specific data elements that are put in invariably.
MS. COLTIN: They begin on page 15 in the NUCC document, so you can see the kinds of things that I am talking about. But some of them have to do with simple things like the patient's name and their date of birth.
Now, part of the concern -- and I was a party to putting a lot of these in here -- is the insecurity of wanting to check to make sure, what if it doesn't link? What do we do then? We've got to have this other information as a backup.
So there is a lot of information that is in here because of worry that those sorts of linkages will not necessarily occur perfectly, because it is not a perfect world. If they don't, you need to fall back on certain information.
But part of my concern is, if that information resides in a provider's office, in their file, and for some reason it doesn't link, you have that information. Now, if it is a keystroke to have that automatically appear on a form, then fine, send it, but I'm not sure it has to be required.
DR. LUMPKIN: But it needs to be encrypted and decrypted 158 million times.
MR. MOORE: One of the problems with what Kathy is proposing is that in order to do what she is saying, we have to have all those identifiers done, established, the data sources. Then like HCFA is talking about the NPI, we then have to have that data source on all the providers with that standardized information that is needed by everyone available 24 hours a day, seven days a week, so people can look it up and get that information when they need it. That is one of the things we had proposed for that one.
The same with the payor. Then when you get into the unique identifier, we've got all the issues that -- what are the demographics that are to be associated with that identifier for a person, and then where is that repository on those people, how do you pull all that together.
MS. COLTIN: I think we have to be careful that we are talking about standards that need to be adhered to within two years of the date that the regulation is issued. Hopefully, all that will be in place by then.
What needs to happen in between may need to require more of these elements. But is that our job in this committee, to say what do we need to collect today, given that we don't have an NPI or we don't have a payer ID or we don't have the unique person ID? Or is our job to say, let's presume that all of those things are in place, because we are going to develop the mechanisms to put them there, and then given that they are in place by two years from now, what should this transaction look like.
MR. BLAIR: I don't know if I am making this suggest because I'm paranoid or because I understand the marketplace, but it may be some of both.
My inclination would be to assume that there is a significant minority of the marketplace out there that is evolving or going through transitions or shifting from one integrated health system to another, one health plan to another. There is just going to be enough circumstances where the linkages may not be there. At least, maybe for the first iteration, when we go out there, that intentional redundancy is a protective measure.
It probably will take some time for us to gather the information to really determine whether we can eliminate that redundancy and how quickly. So that is the inclination that I have, is to keep the redundancy for the first iteration.
MS. GREENBERG: I probably agree with you, but that is the issue that always comes up about race and ethnicity. You really don't want to collect it at every encounter in a situation when people put different things down at different encounters and different things are collected based on observation and self reporting, and you don't know what to do with it.
But this has been a real problem for uses that are made of the encounter information beyond strictly reimbursement. I know in the case of some of the HEDIS measures such as low birth weight or whatever, it is a problem that data are not available.
I also wanted to follow up on what Jim said. I think you are right; most of these elements are demographic or sociodemographic or economic, but there are also a few elements that the committee has recommended in the past and that actually other people in the department have recommended, although isn't part of the committee's recommendations, that are more in the area of risk factors, such as the general health status question.
I know CDC felt strongly that one of the elements should be smoking behavior. Again, you don't exactly see these being collected by an employer. On the other hand, you don't want to collect them every time. That is where they could really add a lot of robustness to the information you would have on an encounter linked with an enrollment.
So I think that is an area that really needs development. It is not being considered on either the enrollment or the encounter side of this.
MR. SCANLON: I just want to take a step back. In terms of the framework we are working in, what ultimately will occur with content as well as transaction standards will occur in what will be viewed as a regulatory framework, in which there is an extensive baseline of activity as jeff indicated now. There are five million claims, some of them paper, some of them electronic enrollment and everything else.
At any rate, what new standards are adopted, there will be benefit-cost considerations in terms of what the baseline is and what the trajectory is. I think what Kathleen was describing was the intermediate vision, and I suppose the clinical data standards are a further vision of how this framework could operate.
But as a practical matter, there is a tremendous baseline of activity that we are building on, and each additional data item will have to be viewed at least when HHS proposes these things, they will have to be viewed in a regulatory framework of benefit-cost.
So it is not a research situation, where items can be added or modified more or less at the researcher's discretion. It is a situation where there is a tremendous benefit-cost calculus involved as well.
MR. WILSON: Hi, Wayne Wilson. I would like to argue for some consideration of a minimum set of demographic information. It is not always the case that patients show up for an encounter with the correct set of unique identifiers. So you have to go through some sort of demographic information to resolve to a unique identifier.
That is one of the things that NPI designed that we struggled with, what exactly is that minimum set of information. Thank you.
DR. COHN: If I could make a follow-up comment, I was just going to comment that until we get the unique identifier handled, it is unknown whether the solution to that is a single number or a mapping. So probably that needs to be kept under consideration in this discussion.
MS. NARSCISSI: Jean Narscissi, AMA. You have to keep in mind that the NUCC data set was built on current business transactions, whether they are in an electronic format or paper format. So your wish list may not be included in there right now, because that is not how business is done currently. Just keep in mind, it is a baseline, and it will just grow from there.
DR. LUMPKIN: And this is not our last cut at this. Certainly I think we are making a decision for today, in that any vision of the future of any of these standards -- and we are going to discuss this when we talk about implementation and version control -- will have to involve a process to update these data sets.
Now, as we look at the issue on page 15 of the insured, -- do you have --
MR. MAYS: Just a quick comment. Bob Mays from Health Care Financing Administration. With the release of the full report, it will be very easy for you to determine which specific elements are appearing multiple times. You may in fact then want to really at least prioritize. If you see an element that seems to show up in eery single transaction, you would want to look to that element first to see does it really have to be in every transaction, and then on down the line. If there are elements that only show up in two or three, that is less of an issue than if they show up in all ten, for instance.
DR. COHN: I have a question for Bob. Is not one of the big issues in all of this going to be to make sure that all of the data elements are defined the same way, and the applicable values are the same?
MR. MAYS: That is true. It is not a single level thing, though. There is concept and then there is conduct, what we are calling conditionality. So we certainly want to be sure that the concept of, for instance, sex -- that is a pretty straightforward one, you think -- is the same across.
However, there are some conditional instances for sex. Normally you think of it as male, female or unable to determine or not available. However, when you are talking about prenatal care, for instance, indeterminate is in fact a legitimate conceptual or conditional value that you might give to sex. It is not the same as I don't know, but --
DR. LUMPKIN: Is that prenatal or post natal?
MR. MAYS: You're right, we have to be sure that we are consistent across, but there are different levels of consistency. So we certainly want to have conceptual consistency across for all the data elements, but then we do have to address specific context issues, where it may be not, is it appropriate, yes or no, but is it appropriate within some other permutation of it.
DR. LUMPKIN: As we look at the items on page 15, which are the demographic information not of a patient but of the insured party, I think that gets to the heart of it.
First of all, let's walk through a situation, an individual provider who may be related to multiple groups, a couple of person office. That information is going to be current there, because if someone walks in the office, one of the first things they ask is, has anything about your insurance changed, has anything about the employment changed. Many of them have signs that say that the patient is responsible for their bill. If you don't know where the person lives or works, and that changes and the bill comes back, you are not covered, then the patients themselves are going to get the bill.
So that information is collected somewhere. So the issue becomes not whether or not it is collected, but whether or not it is now either electronically or manually transcribed onto the encounter form in every encounter, and encrypted and decrypted multiple times through the clearinghouse.
So conceptually, we are talking about this and many other elements which -- I think the issue not becomes whether or not it is asked, sex or all these other demographic elements by and large are done at the first encounter, and after that at subsequent encounters are not collected or verified, because the assumption is those don't change. Those that do change generally as part of the entrance into that system, there is some question.
Now, in the larger managed care ones, there is some check of the fact that they are still enrolled, and if they are still enrolled, they get provided care, but then it becomes an encounter and not a billing form. Those encounters again, whether or not this information is really useful.
So the question becomes, do we think in our conceptual model this should be part of an encounter form, or whether or not it should be part of the -- which we don't have in front of us, but the verification of enrollment and confirmation of enrollment documents.
That was a question. It was not rhetorical.
MS. COLTIN: I think the point was made that we are in a transition phase. I think what has us a little bit stuck is that what you may require during a transition phase may be broader than what you may require ultimately when all of the mechanisms are in place to accurately link these files.
So yes, there is information that would be collected at the provider's office or at the hospital admitting office or wherever. You might down the line not want to send all that information in the transaction. The question is, during the transition phase, do you need to send some of it for verification purposes, to make sure you've got the right person, the right facility, the right payor, whatever.
I don't know how we want to deal with that here, whether we want to deal with what you send or what you put down as a required element during the transition phase and make that our recommendation, or do we want to look at what we think ultimately the transaction should look like two years from now, when it actually becomes enforced, and make that our recommendation.
So that is a question that I am putting out.
MR. BLAIR: Maybe there is no way for us to avoid at least thinking through form design and systems design in order to figure out how to do this. Maybe if we specify, these are the data elements that the end user requires, like for example the payor requires, and indicate that there are certain sections where the provider or the patient may or may not need to provide that information if that information is available through other sources.
For example, they might be going into a clinician or physician that has a patient management system where automatically, all the demographic information and insurance information just pops up on the screen and all they do is, they fill in the additional encounter information, and that is just fine, that information is there for the payor when it is sent, or maybe the clearinghouse can search the rest of the demographic information, or the payor themselves may have that information.
So there is probably a lot of different ways that it could occur. Maybe we could just preface certain sections just simply to indicate that we don't -- we are not saying that all this information has to be filled in at the provider's office. It is just that somehow, this information is required by the payor or the health plan. It can come from different sources in different ways.
DR. LUMPKIN: If I could just follow up, I think that as I am listening to your comments, it strikes me that part of the limitations is that we are talking about a batch mode transaction. If we were dealing with an interactive transaction, at the point you begin the first part of that, the requirement to download the non-matchable information would be readily apparent. When the new systems are hand shaking, that determination could be made.
But I do think we have to recognize that we are dealing with a batch mode system that spits out the whole record. Then the receiving end gets the whole record, and then has to do whatever they do to determine whether or not they can fill in those data elements, which then requires another transaction, so you know the data elements cannot be linked.
So there is some additional burden that is placed on both the sender and the receiver, if those items can't be linked.
DR. BRAITHWAITE: At the risk of being redundant, George Argus' suggestion I think was a good one, which is to look at this in light of the information that is needed by the recipient of the information for their processing, and let the process re-engineering that will occur over the next few years in light of what you just said to occur without us having to worry too much about it at this level.
DR. LUMPKIN: Sounds like we are roughly on the same page, which is page 15.
MS. COLTIN: What that argues for is that what is in here now in terms of what is listed as required really is I think what the payors said they need at least during the transition phase. Their needs may change when this is completely implemented. So I think that is consistent.
MR. MOORE: That is the same approach that we are taking. We are spending a lot of time talking about the claim, because it has so much information that everyone wants. One of the things that we have heard in doing other transactions, like the remittance advice, is exactly what Bill and George said.
What we have heard from the community is that a lot of times, payors are given back remittances advices that really don't meet the providers' needs. They get it, but they can't do what they need to do with it, that is, close out their receivables, because it doesn't have enough information about the transaction.
So what we are trying to do is take a view that -- does it meet the receiver's needs for the reason it was intended, that is, to enroll a person in a plan from an employer to get eligibility back to a provider for coverage, all the things that those nine or ten transactions were required.
Right now, a lot of people -- once you get past the claim and then you get into the remittance, the claim is -- we estimate if we are electronic that the claim might be 65 percent electronic out there today, at best. When you get into the remittance, it is like 15 or 20 percent, 30 percent? You get into the other transactions, they are not all electronic, and in many cases the provider doesn't get it. It is a phone call, it is an oral message that is moved back and forth.
MS. GREENBERG: I'd just like to add one thing. In the committees that we are working with, they prefer to view claim and encounter as being equivalent.
DR. LUMPKIN: Just let me check, because that would be my assumption. Is it correct to assume that we as a committee feel that claim and encounter are the same?
DR. COHN: Are you referring to the X-12 standard and the documentation?
MS. GREENBERG: The data content of an encounter would be equivalent, the way the people in the industry are currently --
DR. COHN: Which people and which standards? If you are looking at it from a payor standpoint, that might be true. If it is from a provider standpoint, there may be some distinctions.
MS. GREENBERG: Well, we had HMOs even say that they would just as soon have the charges. We are writing data conditions that we hope will support identical implementations. We bought that up, and the HMOs that were present in the room, there wasn't very many, said they even want the charges.
So almost everywhere in this work, claim and encounter are treated as identical transactions.
DR. COHN: The reason I was looking a little funny is that I remember efforts by X-12 over the last couple of years to really define the encounter. They have had a hard time doing it, because X-12 is a wonderfully expert organization that is obviously heavily insurance oriented. I think we are just aware of that.
MS. GREENBERG: Well, X-12 came up with an identical --
DR. COHN: No, they are the ones who had problems trying to figure out how the encounter really needed to be fleshed out. I think effectively, you are saying for the first go-round and probably for the immediate future, that certainly everything gets sent on the same --
MS. GREENBERG: Or tell us how to define the differences.
DR. COHN: Yes, or add things to really create the encounter information that may be needed in the future.
MS. COLTIN: What Bob is saying is accurate from my understanding, at least, through discussions that we had at the NUCC. We were trying to consider the needs in both a capitated environment and a fee for service environment.
To me, a lot of the differences really come into play at the level of the code sets, not so much at the level of the data elements. For instance, when you look at a procedure code being used for a fee for service payment, the tendency is to want to roll it up into the most bundled code or payment. When you are looking at procedures for the purpose of -- under a capitated system, the tendency is to want to see it unbundled, so that you can look at what was actually done for the patient at the visit.
So you have situations now where you have health plans actually paying providers to code immunizations with zero charges, just to get the codes, so that they can monitor immunization rates, because they have been bundled into a single well-child code historically for a bundled payment purpose. But now, under capitation, where your interest is more to look at what services were delivered and you want to know about all those individual immunizations, you are actually having to pay to get them to write the codes in with a zero charge. That is how ridiculous it is getting.
So those I think are more where the differences come into play between claim and encounter, more so than the data elements themselves.
MR. BLAIR: Could I add my preferences along the same lines? I know the debates that occurred with the Computer-Based Patient Record Institute when we were doing our concept models also agonized over terminology quite a bit. Is it an encounter, is it an episode, is it a visit, does that make a difference.
As we start heading down the path more and more towards our mission three years from now of recommending legislation for computer-based patient record systems, I think that if we assume that a claim is the same as an encounter, we may have to unlink that a year or two from now.
DR. LUMPKIN: I'm almost afraid to summarize. I think that where we are at is that we believe that what we are working on is an electronic version of a form, not the paper version, but an electronic version, that should be used for both a report of an encounter for a claim as well as a report of an encounter in a capitated system.
We are working on a document, given the current environment, where the assumption is that we cannot guarantee that other supporting transaction forms are easily linked into that. So therefore, we are working in an environment where there will be some redundancy that may not exist in a future environment in two or three years, when these systems become more automated.
Is that a fair statement of where we have gotten to this morning? So based upon those assumptions, maybe now we can try walking through this one document, which I think will give us some insight, because what we will receive later will be the matrix. We will want at a subsequent meeting to go through that matrix, but I think if we have a feel of at least what it is like going through one document, it will give us a lot more insight in walking through that matrix and understanding where is it that we ultimately want to go, and the kinds of issues that will arise.
So if we are all on the same page, let's make that page 15.
I'll just refresh everyone's memory that these are coded by NUCC for being R for required, required if applicable. An example of that would be the middle initial, which my parents don't have middle initials, so it wouldn't be applicable. But they were fortunate enough to give me one because they felt tired of having to write down no middle initial, NRUC, which is not required under contract and NR which is not required.
Page 15 includes insured last name, first name, middle initial and insured generation. In other words, the second, junior. I wasn't sure if that was like in the country, whether you go on the mother's side or the father's side.
But anyway, page 16. These would be the insured address. These are required except for where required if available, if applicable. This would be the address demographics of the insured.
I'm just going to walk through. Stop me if we get to something that we need to talk about. This follows up on page 17 with the insured country, insured date of birth, and then required only if under contract would be insured sex or gender, probably.
Are we all comfortable with that being the gender only if under contract?
Then we go to --
DR. BRAITHWAITE: It might be worth bringing up the philosophical point about contracts. We did make a statement several months ago about the desire for the conditions to be defined outside of the payor to which the information was being sent, if at all possible, at least move toward that. A provider can create an electronic transaction and send it off and not have to worry about which payor it is going to.
Right now, as you know, when providers fill out their electronic forms, they use a lot of paper to figure out what to put in each field because it is different for every payor. Required under contract implies that the payor gets to say what the information is that is being sent to them.
Wherever possible, we ought to limit what the contract dictates that the provider sent.
DR. LUMPKIN: So this raises the issue of, should there be any NRUCs at all; either it is required or it is not enquired.
MS. COLTIN: Correct.
DR. LUMPKIN: Should we allow individual plans to add additional data elements. Is there anyone who is supportive of allowing individual plans to add administration data elements to the uniform transaction? I don't see any support, so what do we do about the sex of the insured? Is it in or is it out?
Do you have our core data set? I would be very surprised if sex is not in there.
MS. COLTIN: It's gender.
(Simultaneous discussion.)
DR. LUMPKIN: I'm kind of confused, because --
MS. COLTIN: I think this is only in here as a verification variable for linkage. Now, if in fact we do come up with a unique person ID that is dependent on a constellation of other personal variables, there may be a reason for including sex among that constellation of variables. If so, then it should be a required element.
MS. NARSCISSI: I just want you to notice that element number 52 is the patient's sex, and that is required. If you had taken any time to look at the 0.9 version, we had listed the patient elements first, and the insured was second. But because of how current business is being transacted, and because the 837 is built this way, the insured information moved to the front of the document.
But Kathy is right; if it is a necessary item, in NUCC, you can certainly discuss it.
DR. LUMPKIN: Thumbs up or down? Up, required? Anybody disagree with that? Everybody said thumbs up.
MR. ARGUS: Can I add a comment? Actually, on the UB-92 data set, the insured sex is not a part of our data set, nor is the insured's birth date, which is the other item right above that.
But it gets back into the philosophical argument you had just before, in terms of where some of the data will reside. We used to have insured sex under UB-82, the previous version. We dropped it on the basis that this should be part of the enrollment file that the payor has.
Clearly, what you define as a data set here is something that tells all the various parties involved in maintaining a portion of the transaction set, these are the data elements that your internal systems have to be capable of dealing with.
So keep that in mind as you go through this, and keep in mind the ultimate end game that you want to see later on down the road.
DR. BRAITHWAITE: Is that an indication that we have moved far enough along the pathway to uniquely identifying insured, that we don't need to collect all this information on them anymore, or is that only true for the in-patient environment.
MR. MOORE: It is not just the in-patient environment he is talking about, because the UB-92 covers out-patient, ambulatory, home health, skilled nursing, physical therapy, everything that is organization, right, George? So you are looking at a lot of different kinds of providers that UB-92 covers.
The NUCC covers the solo practitioner and the physician and the supplier, mainly.
MR. BLAIR: What we are trying to do is get rid of elements when we can, when the transition has gotten far enough along to enable that. If the UV-92 indicates to us, and people are using that today, this information is not required out there in the --
MR. MOORE: This is a payor community, remember that we are giving this to. So if the payers have decided they don't need it for all of that other environment and working with George, that maybe we can say that the payers can use those same files, that they didn't need it for the other, with the physician-supplier side.
MS. COLTIN: My argument for making it required is the uncertainty of the unique identifier. If in fact the unique identifier may require this, and we don't put it in the data set, it closes off the option to use it as part of a unique identifier.
So if we knew for certain that this was not going to be part of a unique identifier, it seems to me there is enough other information about the insured to link the record, if in fact the unique number doesn't match in and of itself.
So if that were the only consideration for file linkage, I wouldn't say it should be required. I think it is more the point Simon brought up, that we have not yet resolved what the unique identifier is going to be. If that unique identifier is going to incorporate the sex of the person, then the data set has to capture that.
So are we ready to make that decision today? I don't know, but that was my basis for a thumbs-up.
DR. BRAITHWAITE: That makes the decision very easy then, because we are going to require the unique identifier. If an element of the unique identifier is the gender of the insured, then it is included. But we don't have to include it as a separate item if it is not enquired by the payor communities.
So the only question I have is, we have heard from the NUBC that it is not required by a majority, or for a large portion of the payor community, so we need to hear from the NUCC about why they have continued to include it.
MS. COLTIN: They didn't. They had it in NRUC. I think there were some payors that indicated they would like to have it, which is why it is in NRUC as opposed to NR.
MR. MAYS: That is exactly the point I was going to make. If it is in NRUC, it obviously is not felt by the total community as being something required. So that already says no, it doesn't matter, because the majority of players already feel that they have other ways of getting that information if they need to have it.
DR. LUMPKIN: Are there any -- in our core data set, since you I think are the keeper of our copy for this meeting, are there any specific data elements related to the insured?
MS. COLTIN: No.
MS. GREENBERG: It is just the relationship of the patient to the insured. That is the only one.
DR. LUMPKIN: Okay. So having now heard that discussion, and just thinking about the unique identifier, some of the discussion that we are having today I think points out some of the weaknesses of the master-patient index, which is the number of data elements that you need to have to try to uniquely identify somebody, can create some problems in trying to do that uniquely, and not having a number that can be transmitted.
So I don't know what the final decision is going to be, but I think that perhaps we should see that -- obviously, if we come up with an NPI, all of the transaction sets are going to have to be reviewed in light of that identifier. I suspect that we should not make a decision based upon a yet to be identified unique identifier.
DR. COHN: I feel very persuaded by Dr. Braithewaite's comments that we should probably hold some of these questions around NPIs or unique identifiers for that discussion, and not require them in these data sets, pending the uncertainties of all of that. But obviously, reserve the right to put them back in if we need to.
DR. LUMPKIN: Do we want to reconsider the gender of the insured?
DR. COHN: Yes.
DR. LUMPKIN: How many people want to see gender of the insured in now? I see no positive signs. So is it a safe assumption that we are all agreed that it will be not in NRUC, but O-U-T?
MS. NARSCISSI: In the previous version, we listed all the NRs, just so there is a placeholder down the road. We will know which funds were discussed. We eliminated a lot in this version.
DR. LUMPKIN: Insured ID number, insured group number, inapplicable. Insured authorized person's signature or indicator, policy number or FECA. What is that? Does anybody know what FECA is? Inter-plan name or program name? Then the next, when applicable, then insured retirement date, which is in NRUC. Do we want to see that in or out? Anybody want to see that in?
MS. GREENBERG: The other insurers are always looking for somebody else to pay. If you as (word lost) relatively recently, there would be a possibility.
MR. MAYS: One of the things tho keep in mind, and I think it even came up with Marjorie's point about the public health uses of some of this data, we're saying right now, the recipient of this is just the payor. But this claims information, counter information, is used by a wide variety of groups and users.
Although conceptually, getting rid of some of these things makes a lot of sense, it may in fact have some pretty significant impact for individual or group of individual users of this data that we are just not aware of.
Some of this is fairly straightforward, but when we get several pages in and look at some of these NURCs, it is going to be -- I think even the people around the table will say, wait a minute, I need that to do my thing.
MS. COLTIN: I think when we get to the patient information, it becomes more of a consideration.
DR. COHN: I'm a little confused about whether this is really an NRUC or an RIA, only because of a comment at the bottom which says, required if applicable. I need some guidance from either Kathy or -- it doesn't make a whole lot of sense to me that you would have NRUC under the comment, required if applicable.
MS. GREENBERG: It looks like if you have RIA, it must be entered if applicable, and in NRUC, required if applicable. I don't understand the distinction.
MS. COLTIN: The applicability may be the payor requiring it.
DR. LUMPKIN: So this would ban NRUC IA, which means that it is not required unless under contract if applicable. Anybody want to keep this one, given all that we have said? We have pretty much agreed that we don't like under contract, because that gets us away from the uniform.
MS. COLTIN: I think that is fair.
DR. LUMPKIN: So it is out? Okay.
MS. BALL: It is interesting that you raise this. Reading the usage notes, the element on the top of this page, insured or authorized person's signature, indicates in the usage note that this is more like NRUC than an RIA.
MS. COLTIN: I have a question. Bobby, maybe you remember this, because I don't. Data element number 16, would that become the payor ID?
DR. LUMPKIN: Sixteen, which is the insured policy or FECA number, which we don't know what it is.
MS. COLTIN: I'm trying to figure out where payor ID would actually be captured here, if not at that data element. If that is payor ID, then fine. If not, we may need a data element for payor ID.
MS. GREENBERG: I know they have linked it with the patient's expected source of payment, and I know the discussion around that element was that with an appropriate payor ID you would be able to collect that.
MS. COLTIN: You think that will be payor ID?
MS. GREENBERG: I don't know.
DR. LUMPKIN: So really, number 16, insured policy or FECA number and insured plan name or program -- that is NRUC, which is the payor ID. So it appears to be internally redundant.
MS. NARSCISSI: No, the insured policy number, FECA, I think that has to do with black lung or whatever. No, the policy number is linked to the insured. It is not the payor, specific. In today's environment, on a typical card, a member card, you could have policy number, group number, plan number, patient ID number. So that is how that got into the data set.
MS. COLTIN: This is a further breakdown, that the payor wants beyond a broad payor rate.
DR. LUMPKIN: Was the thought though -- and you have to help us on the latest iteration of the payor ID. I know some of the initial thinking was that each product would have a separate ID number. Is that still the case?
MR. MAYS: That is still under a lot of discussion. I think at the moment, the leaning is towards aggregating it up a little higher than actually breaking it down to specific product. It would really be more organizational level.
MS. GREENBERG: I think here are real limitations to that, but --
MR. MAYS: To which approach?
MS. GREENBERG: To the latter, to this aggregate.
MR. MAYS: Well, yes, that is why there is still a lot of discussion.
DR. COHN: Speaking of that, is there going to be an update at the next NCVHS meeting on the payor ID?
MR. MAYS: Well, I think that if we looked at the list developed yesterday, that that was on the list. The idea was that the team would present detailed -- sort of like the provider ID presentation.
DR. LUMPKIN: So given that, we believe that both the policy number and the plan and program name need to be in.
So that takes us down to the insured's employer or school name.
DR. BRAITHWAITE: On item 15, the signature, the HIPAA regulations call for us to define a standard for an electronic signature which will replace the need for a written signature in an electronic transaction. Is this one of those places? This is not the patient's signature, as I understand it; it is the insured's signature, which assigns the benefits to the provider.
DR. LUMPKIN: No, actually, this looks like it is probably a binary indicator, that indicates whether or not there is a signed authorization in the file. So I would suspect that even in the environment of an electronic signature, whether or not the insured has signed authorization is going to be a lot cheaper to send in binary form than trying to send a copy of that signature, which would be a much larger file.
So I can't imagine that -- I think the electronic signature really is more for the provider's signature, which requires verification, more so than the patient signature, would be my understanding.
DR. BRAITHWAITE: I think you are probably right, but I bring it up because this is one of those cases where in an electronic transaction previously, it was impossible to send the enrollment signature of the authorized person. So they demanded that the signature be there on paper somewhere, and this just says that it is there. Now it is possible to actually send the signature. The question is whether or not the payors are going to want the actual signature as opposed to just an indicator that it is somewhere. I don't think it is appropriate to have to send the signature, but I just bring it up, because that is a possibility.
MS. BALL: But is it appropriate for this to vary by payor?
MS. NARSCISSI: I think this crosses over into some of the requirements that are within a state that you are required to keep within your office, within the record. So whether they would want an actual signature being sent to them, if it is possible in their system to do that, or else is it mandatory that they keep it in a file in these kinds of issues?
DR. LUMPKIN: Anybody want to -- we've got a little placeholder in there, so why don't we leave that, unless someone really strongly objects to leaving it as a required if applicable, okay?
Down to insured's employer or school name. Then we have a whole set on page 19 of information on other insured.
MS. GREENBERG: Would employer or school name -- well, employer, would that be picked up under the employer ID, if there were an employer ID? Would you put the ID there rather than the name?
MR. SCANLON: Ultimately.
MR. MOORE: Ultimately, because every employer would have an ID, and you wouldn't have to then record the text.
DR. LUMPKIN: I would agree. I wonder if in the initial couple of years of implementation, if a patient shows up at a physician's office or a dentist's office or whatever, that they are going to know their employer's ID number.
MS. GREENBERG: No, I was just wondering if that is the same thing.
DR. LUMPKIN: But I think that ultimately, that ought to be collapsed. We probably can collapse the first 19 data fields into two or three, with the employer ID, the unique identifier for the insured, and a number or some information on the plan. It probably would be collapsed significantly in the near future.
I think we can skip to -- yes.
MR. BLAIR: Do we want to say anything at the time this becomes available that if there are providers and payers that come up with agreements where they have information systems that in fact enable them to collapse that, that that would be perfectly sufficient, that we are not requiring all of these data elements, if they have a more efficient way of accomplishing the same purpose, so that we are in fact encouraging the evolution and adoption of payor identifiers and employer identifiers?
DR. LUMPKIN: My personal response to that would be that it would create multiple forms. The allowance of a contractual multiple form, which is contrary to the concept of simplification. I think if we are going to go that way, we should go with all of them, because the individual provider now has a system, and has to figure out which payor it is before they know which pieces of information to put in that particular form. That may create some problems when they have multiple payors they have to deal with. I don't know how other members of the committee feel on that.
MS. COLTIN: I agree. I think we just need to revisit this, and perhaps redefine which elements are required after all of these other data elements and identifiers have been implemented.
DR. LUMPKIN: Which is probably in about three years. So they have been required and they have been enforced and have been implemented, and we can see the impact.
MS. COLTIN: On the other insured, shouldn't we treat the two data elements that we changed for insureds in the same way, so that it would be data element 31 on page 21, to make it not required, the other insured sex, and then data element 37 on page 22, which is the retirement?
DR. LUMPKIN: That's correct. Since they are all the same, I just figure we can ski that, because we would just apply the previous actions.
This is now the section entitled patient information. Last name, first name, middle initial, generation designation, address. These are all RIAs, and I'm not sure why they are RIAs as opposed to R's.
MS. NARSCISSI: The reason they are RIAs is, they must be entered if the patient is not the insured.
DR. LUMPKIN: Is that what that says there? It is time for a break. Shall we take ten minutes?
(Brief recess.)
DR. LUMPKIN: From here, what I would like to do is continue as we have been going. Somewhere about 11:30, I'd like to do a status check of what we have learned and the conclusions that we would like to come to in relationship to this document.
Obviously, it is not our intent, nor will we go through item by item everything in the 5000 list. But certainly, the issues that we are describing I think will give us a better foundation for all of us when we do get those lists, to look at them at home and then bring some issues to our next committee meeting, to actually focus in on discussion.
Okay, patient information. All these items, as many of you should be aware, are RIA, because if the insured is the patient, then we don't need to fill those in.
We have last name, first name, middle initial, generation designation, address, city, state or province, zip or postal code. Is that the 11-digit? Patient country. What if they are in-patient? Birthday, weight. Weight is NRUC. That is a very heavy discussion. Do we leave that ought to be in or out?
MS. GREENBERG: Is this the weight of any patient, or is it primarily -- is it related to the birth weight of the newborn?
DR. REDDING: It is only for Medicare. To the beset of our knowledge, it is required only for Medicare and EPO claims.
MS. COLTIN: EPO is what?
MR. MOORE: That is for dialysis, where they are getting EPO. It is there for end-stage renal disease patients. EPO is a drug that they are getting to help with the dialysis.
MS. GREENBERG: And they want to know the weight of the patient? So what about birth weight of newborn, which was --
DR. LUMPKIN: Our core data set says for newborn that the birth weight should be part of that.
MS. GREENBERG: Is that collected anywhere else?
MS. COLTIN: I think that should be on the UB-92.
MR. ARGUS: Birth weight for newborns is not a UB-92 data element. I know we have discussed it in terms of adding it as a value code with paper, weight amount recorded. But there is no actual reporting. The only thing we recognize is that there are certain series of diagnoses codes that identify premature births and a range of birth weights.
DR. VAN AMBURG: Is not weight birth part of the uniform birth certificate?
MS. GREENBERG: Sure.
MS. COLTIN: And actually, some states, I know Massachusetts being one of them, require it on the discharge abstracts that the hospital submits to the states.
DR. VAN AMBURG: Other states do not.
DR. LUMPKIN: I'm just not sure why, if in fact it is collected in an identifiable fashion on the birth certificate, and this is why we would want to make that part of the claim form.
MS. GREENBERG: That is assuming that you can link with the birth certificate, which is even a bigger assumption than that you can link with an enrollment form. A lot bigger assumption.
DR. VAN AMBURG: I think that is the issue. Some states have successfully linked some private provider data with the birth certificate for looking at these measures. Other states have been unable to accomplish that.
DR. LUMPKIN: So this is related to a HEDIS measure? Is that the concern?
MS. COLTIN: It is used for the low birth weight measure. We can also try to get this from the ICD-9 codes, but unfortunately, often they are not coded. So by having a specific data element, it would force that to be coded on a newborn claim.
There are like the New York State (word lost) I believe requires the weight also. I'm pretty sure it does.
DR. VAN AMBURG: There are some states that do require it. They may have a state assigned value code to report the birth weight.
DR. BRAITHWAITE: We should note that birth weight is included on the in-patient claim, and what we are reviewing here is the data elements for out-patient claims specifically.
MR. ARGUS: It is not on the national data set. There are some state variations that do allow for the reporting of it within the claim work of the data set. But it is not part of the national.
DR. BRAITHWAITE: In any case, a birth weight would be unlikely to be reported on an out-patient claim.
MR. ARGUS: Well, home delivery would be an out-patient event. A birthing center would probably be an out-patient center, because I suspect most of the -- I don't suspect there is a certification process for birthing centers.
MR. MOORE: This is the professional claim? Would a midwife or a physician or somebody be reporting that? Rather than having it reported by the facility, is it better to be reported by the individual who delivered the baby or whatever, as part of that set? The only place it would be reported is on the in-patient claim, more than likely, in George's world? Right, George?
DR. VAN AMBURG: Correct.
MR. MOORE: That would be under the mother's, though, that in-patient, would it not?
DR. VAN AMBURG: On the mother's claim, correct.
MS. GREENBERG: It wouldn't be a separate claim for the newborn?
MR. ARGUS: No, and that is something that we probably need to look at, in terms of being able to distinguish who we are tracing and what we are reporting on.
MS. GREENBERG: Is it only a separate claim if the newborn has to stay longer than the mother? Or even then, is it on the mother's claim?
MR. ARGUS: Only if the newborn comes back and is admitted.
MS. GREENBERG: And they get billed for all those additional expenses of a newborn.
DR. BRAITHWAITE: This is one of those places where the information about the patient and the information for billing purposes gets confusing.
DR. LUMPKIN: Well, to the extent though that we have agreed that these are encounter forms and not just billing forms, and to the extent that the performance of the managed care plan is related to information about the child who is delivered as one of the performance measures, it seems to me that that becomes more than just a public health interest. I think in the public health community, we have access to a way to monitor birth weights, through the birth certificate.
MS. COLTIN: True, but it depends on whether you can link that with aspects of the discharge, although there is a lot more on the birth certificate, a lot more than there is on the discharge.
MS. COLTIN: We have not been able to get access to any individually identifiable data from state birth certificate files.
DR. BRAITHWAITE: We have laws about that.
MS. COLTIN: So if a plan or any payor needs this information, I don't think we can rely on linkage to state birth certificate files to get it. We have to have another way to get it.
MS. JAKES: (Comments off mike) doing linkage of birth certificates and plan data. I was actually just looking at the first data from the first runs yesterday, and it was not a pretty picture.
DR. COHN: These are as far as I can tell two different data elements, talking about under number 50. One of them is a birth weight of newborn, which to me is very clearly RIA. Indeed, if it hasn't been captured anywhere else, this is definitely an RIA.
On the other hand, the other one, which is the Medicare rates on initial EPO claims is to me a whole different kettle of fish. I'm not even sure of how to categorize them. I am well aware of how it is done, but I am just trying to think of how -- it doesn't seem to me to be the same element, or maybe it is the same element, but under two different prescriptions. This is the first time we have looked at something that is quite so different under the same rubric.
DR. LUMPKIN: What is the magnitude of new EPO patients?
MS. GREENBERG: The number of people on dialysis is small in Medicare, but I don't know the number offhand.
MR. MOORE: EPO is a very expensive drug in that arena. If you were saying -- on the five billion transactions we get, there are probably 150,000 Medicare people. We have 93 percent or so of the people getting dialysis that are all Medicare enrolled.
DR. LUMPKIN: I know we only have about a thousand folks who are on Medicare in Illinois on dialysis, because we pay a part of that bill. So I am just wondering whether or not this is something that could be in the attachment.
MR. MAYS: It is about 135,000 nationally.
MR. MOORE: As of '95, the dialysis patients are about 200,000.
DR. BRAITHWAITE: This is normally something that would appear in an attachment, because it is a requirement of a payor for additional clinical information to back up a claim.
DR. LUMPKIN: Right, and it is something which is not even on every transaction. It is just on the initial EPO claim. So what I am hearing then is that there is a reason to have a patient weight for a newborn, and then maybe that might be the new name for this.
MS. COLTIN: I'm not sure there is agreement on whether there is a need for it in the NUCC data set. I think there may be more agreement that there is a need for it in the UB-92 data set. But people did bring up the issue of births that occur outside of hospitals. If in fact the source of information for those births is the NUCC, then the argument goes the other way, to say, put it in the NUCC and don't put it in the UB-92. You don't need it in both data sets.
DR. COHN: Well, actually I disagree.
MS. GREENBERG: I disagree, too.
MS. COLTIN: Why would you need it in both?
DR. COHN: Well, if it is done in the hospital, then it is --
MS. GREENBERG: You are also assuming a linkage there of a physician claim with the hospital claim, which doesn't always happen.
MR. MOORE: But you don't get a claim on the baby in the hospital unless there are some extenuating circumstances.
MS. COLTIN: It is going to be on the mother's claim, and then you've got the problem of trying to link mother's claim to a baby record. Here at least, --
MS. GREENBERG: What if the baby has a diagnosis other than being a newborn? How is that handled?
MS. NARSCISSI: I just want to make a comment. In the patient weight element, it was designed to be generally used for EPO or birth weight of a patient. If you think it is necessary in those situations where the baby is born outside of the hospital, that could be handled in a comment. You can see there is nothing on that element which you could say must be entered if applicable, or if the patient is born outside of the hospital situation.
DR. LUMPKIN: We could move that to the attachment. If the baby is born outside a hospital, if it is a home delivery, then the plans that want that information would require it as part of the attachment. It just says HCFA would for the initial EPO treatment.
MR. MOORE: Right now, EPO is part of the claim.
DR. COHN: John, I think we are getting into a discussion on principles right now that is a very important discussion, and we should just stop for a second and begin to think about where does a condition have to be or how specific do those elements have to be to be in an attachment as opposed to the main claim, because up to now, everything has been -- every payor has tried to use the billing forms to their own devices by just redefining a data element. We see that for example with dialysis patients, and we see more of that as we go along here, talking about newborns.
I don't have the answer to that, but I think this is the question that we are coming up to. It certainly becomes a very clean thing if we start saying, no, that is not part of the main activity. It becomes part of a yet to be defined additional piece. But we need to make sure that that doesn't also cause problems down the line for anybody.
DR. LUMPKIN: The magnitude which we are talking about now, this data item on patient weight, seems to be two populations. One are those who are beginning EPO, which are a subset of the 200,000 on dialysis. It is just the initial EPO claim. So once you have got it, that is not it. So we really are not talking about 200,000, we are talking about a subset of that.
The second group that would be related to this would be those patients who are having a non-hospital based delivery, which is a small subset of the four or five million births that we have in the country.
MS. COLTIN: Why make the distinction about where the baby is born, if in fact this data set cuts across all delivery settings, and knowing that the birth weight is not in the UB-92 data set? Why not just put it into this data set, because you would pick it up for babies born in hospitals as well as babies born outside of hospitals?
MS. GREENBERG: There isn't a separate claim, you are saying, for newborns? The newborns don't count as an encounter, apparently, in the UB-92 world. On the one hand, I can understand the burden, since the vast majority of newborns are normal birth, et cetera, and come with their mom and go with their mom. It still does raise insureds about how you collect the information about newborns particularly who have a lot of complicating conditions. I'm a little confused about that.
But isn't it also the case that the physician claim or what we are talking about here, this NUCC claim or encounter, it wouldn't be a separate one for the newborn?
MS. NARSCISSI: This claim wasn't even discussed in being used for a newborn, this data set right now. So I don't know how current business is done.
MS. COLTIN: If the pediatrician sees the baby in the hospital, you're going to get the bill.
DR. LUMPKIN: But the issue is that the concerns that are being monitored to performances to prenatal care and the events leading up prior to the delivery of the child, you want to link this bit of information with that, not with the child. If you now have a separate child one, then you somewhere have to link that mom's record with the kid's record in order to be able to pull that information in.
So this really is quite pertinent, to be on the person doing the delivery's encounter. If we are conceptualizing that this encounter would be the professional billing for that delivery in the hospital, it would be appropriate here.
MR. ARGUS: I would say the only thing I would caution you on is if you have it on the professional claim as well as on the institutional claim, you are likely to probably get two different results for the same event. I would use one over the other, and make that the preferred method.
DR. LUMPKIN: We have spent quite a bit of time on this particular one, and I think it has highlighted a number of issues that will be involved in decision making related to items. This is obviously not an item that affects every single patient.
If in fact we see this as a major source of information in relationship to the management of deliveries, and I can't remember how many deliveries there are nationally, but I think there are somewhere around four million, just judging from how many we have in Illinois, four million deliveries, so we are talking about four million entries in this particular item, out of the five billion. Does that rise to the level of importance that we want to see in here? That is the decision we have to make.
DR. COHN: John, I would make a couple of comments. Number one is, I think a level of four or five million is a level that deserves that we pay attention to it. This is not 500 people a year.
The other point that I would make is that issues of perinatal data gathering, which is really what we are talking about, are extraordinary complex. The question I was beginning to ask had to do with if you have twins, and if you capture it on the mother. Once again, this gets to be -- I'm not giving you an answer. What I am saying is that it is extraordinarily complex. There has been a tremendous amount of thought as well as expertise that exists in this area. Indeed, if we are having trouble, rather than trying to decide it at this point, this gets reflected as an issue, and we need to query the tremendous amount of expertise that exists in the country around all of this.
DR. LUMPKIN: That is an excellent point.
MS. COLTIN: I also think the whole issue of ability to link birth certificates with discharge or encounter forms is one that goes maybe beyond this discussion here, but it certainly doesn't go beyond the committee's interests.
DR. LUMPKIN: It falls into the vital records system, and many states have a level of confidentiality associated with them that has been a much higher test than even medical records. So I sign birth certificates all the time that only have one parent's name on here. Do you want someone to have the option of looking on your birth certificate and finding that out?
So I think that there are some issues related to linking that are quite significant in that area. It is more than just a mechanical one.
PARTICIPANT: I would agree that the linkages are very important, specifically because even though for a newborn, you may not generate a claim, a medical record is generated for those newborns in a hospital facility. They are given a medical record number. In some instances, they are also given a pseudo social security number or unique identifier for some subsequent follow-ups, which will then have to be linked with anything that happened on the claim for which the mother had her normal newborn listed as part of that entry.
So you have another set of linkages that also have to be considered when you are trying to link all of these records together again.
DR. LUMPKIN: So we are going to put this one on the table. We are going to move on. But I think we need to mark this in our minds, because this is an issue that we need to revisit. The multiple births issues becomes a problem. I think that this seems to establish a threshold that four million seems to be a significant number, worthy of inclusion right now. We don't know how low that threshold goes, but at least we are toying with one.
But I think the specifics on this one needs to be revisited with some additional thought.
MS. COLTIN: John, I agree with you. I did seem to hear some consensus that it is a data element that we do want.
DR. LUMPKIN: Yes.
MS. COLTIN: The question of how to get it is what is on the table, I think, is that correct?
DR. LUMPKIN: That is correct. We think it is a significant data element. We ought to put it in our core data set. Oh, it is.
The next one is date of death of a patient, gender, and then patient ID number, which is NRUC. I suspect we would -- now, the next item after patient ID number, which is NRUC, is patient account number, which is an identification number assigned by the provider to the patient. Then the next one is the patient Medicaid ID number.
So I suspect we may want to -- I don't know if we want to do that on this version, but certainly ultimately we would want to collapse all three of those into the unique patient ID.
MS. COLTIN: I don't know why this one is in NRUC. It seems to me it should be RIA, if it is different from the insured, that it must be entered.
MS. NARSCISSI: I think the reason that it is NRUC is because in the current business generally, a lot of plans use the same number as the insured. Maybe there would be like a check digit at the end, but a lot of them are assigned the same number.
DR. COHN: I just didn't hear what you said.
MS. NARSCISSI: In today's world, a lot of the patient numbers may be the same as the insured's ID number, in the way business is done today.
MS. COLTIN: For the 75 percent of commercially enrolled people who are in managed care, that is generally not true. I think there is a large enough volume of patients who have unique numbers that this should be all right.
DR. LUMPKIN: So we think this should be in if applicable?
DR. COHN: This should be what if what?
DR. LUMPKIN: If applicable. In other words, if the person has a number, this should be it. And if they don't have a number, then it is not applicable.
MS. GREENBERG: This account number is something different.
DR. LUMPKIN: My question about 55, because we are looking at these three as a cluster, which his Medicaid ID number, if we are looking at the ability to have variable length fields, is there any reason why that could not be accommodated under either a patient ID number or account number?
DR. REDDING: The patient account number is the provider's in-house number, which is returned to the provider on a remittance advice for their use. Medicaid is a payor of last resort, and frequently there are other payors.
MS. COLTIN: Until we have a unique person ID, every party to the claim has their own ID for the patient right now.
DR. LUMPKIN: So is three enough? Because you can have the parent source, you can have the father, the mother, the guardian and the provider's ID number and then the Medicaid number, particularly for children who may be in custody of the state. So that would be five. This is another multiple issue. Maybe we can ask the NUCC what they thought about that.
Was there any thought about some of these fields that may in fact have multiple entries?
MS. NARSCISSI: Definitely. In fact, the patient Medicaid ID number isn't used for Medicaid, it is used for Medicare. So there was quite a discussion on, if a unique identifier was available, that would eliminate a number of these. But since that isn't today, they wanted to leave those in there, to leave a placeholder.
DR. LUMPKIN: No, actually, my question goes to the fact that we have probably identified five or more potential numbers that could be put in those three locations.
MS. NARSCISSI: And they are. They are there. There is the insured ID, the other insured ID, the --
DR. LUMPKIN: But what do you do if you have five?
MS. NARSCISSI: If they are necessary for every claim?
DR. LUMPKIN: No. I'm sitting here, and I am at Hospital XYZ and I am scratching my head because I've got these five numbers, which Medicaid wants to see, because they want to know who else potentially could be tapped to pay for this bill, but I have only got places to put three numbers in. What do I do?
MR. ARGUS: I can explain how we do it on the UB-92. Basically, we try to link certain components, primarily with the insured information. That may mean identifying who the insured is, who the health plan is with that particular insured, and we allow up to six in the electronic world to identify different insureds and health plans related to that insured party.
So you could easily have different patient identifiers for each of the insureds, depending on who the health plan is.
MS. NARSCISSI: This, again remember, is the data content, and how that will be sent electronically. If you choose the 837 there is an unlimited amount of times that you can send this data element.
DR. LUMPKIN: So that is also the answer on multiple births. Thank you.
So it seems that our druthers would be to have both the patient ID number and the patient Medicaid ID number as NIAs instead of NRUCs?
MS. COLTIN: RIAs.
DR. LUMPKIN: Yes, RIAs, required if applicable.
DR. BRAITHWAITE: Well, from the X-12 perspective, what you are really talking about is a unique patient identifier, if and when we in fact get a unique patient identifier, a patient account number, which is unique to the provider that is sending in the claim, and then a repeating field, which is an identifying number used by a payor, which is a repeating set that is an identification of the payor and identification of the number that is used by that payor.
In this case, we have a specific one identified, which is Medicaid. You could also have a number used by Aetna, a number used by Medicaid, a number used by Medicare, et cetera, et cetera.
DR. LUMPKIN: So those two could be collapsed into one, with the understanding that it could be repeating in an X-12 transaction.
DR. BRAITHWAITE: Right.
MS. GREENBERG: Is the vision that with a unique identifier, then everyone would use that and you wouldn't need all these different numbers?
DR. BRAITHWAITE: Exactly.
DR. LUMPKIN: Can we move on? Number 56 is authorized signature or indicator, required patient relationship to insured required, also part of our NCVHS, isn't it? I just am questioning because it is not listed. There it is, okay.
Homebound indicator, which is NRUC, an indicator that the patient is homebound.
PARTICIPANT: Homebound is one of those words that really needs defining. Congress has asked for a report on the definition of homebound for next year for Medicare purposes. That is a tricky one.
DR. LUMPKIN: So this is a Medicare issue. In or out?
DR. COHN: I think it is part of the attachment.
MR. ARGUS: I'll put my two cents in here, in terms of how the institution or provider community handles some of these unusual circumstances. Rather than use it as an attachment, what we try to do is identify certain events or situations, and try to codify them, and then categorize them into blocks where they can be codified and put into general types of categories of pieces of information that are significant.
For instance, condition codes, occurrence codes or value codes are just codification of events. Some of them are just stand-alone events with a code. You could have a code that says they are homebound, an indicator or another code for accident related or another code for some other situation.
Then you have certain codes that are date specific. A date is required because an event and a date occurred at a particular time, and you may report that. Or you may have another code that has a particular value, be it monetary, weight, or some other quantitative measure that needs to be associated.
The purpose of that is to reduce attachments and to reduce the constant rebuilding of the electronic architecture. So you are building basically blocks of slots to handle certain pieces of information that may be needed at some point in time, and allowing the committee itself to evaluate the need to codify it and then add it as part of the data set.
Having said that, this is one that could be easily accommodated with some sort of codification.
MR. MOORE: How is this different from the place of service? The place of service on a claim for a person who was homebound will be home, would it not? That would be an indication that the service was rendered in the home. If they were homebound, they couldn't go out of the home to get the service.
DR. LUMPKIN: Well, no, home delivery would be a home delivery, but the person would not necessarily be homebound.
MS. GREENBERG: That is where the definition of homebound is really iffy.
DR. LUMPKIN: Home dialysis would not be necessarily on a homebound person.
MR. MOORE: Correct. Withdraw it.
MS. GREENBERG: This is very specific, though. It must be entered if an independent lab renders an EKG tracing or obtains a specimen from a homebound or institutionalized patient.
DR. LUMPKIN: Is there anybody here representing an independent lab? Okay, it is out.
MR. MOORE: I don't think the lab industry put it in. I think I did.
MS. GREENBERG: The only thing I would say is that George raises an interesting point. I guess there is a conceptual difference of how some of this type of element would be collected on the UB-92 versus the 1500. I do think we are going to be struggling between trying to simplify why we standardize as much as possible, but maybe having to use a little wiggle room in some cases.
I guess that is what your approach does. It just is --
MR. ARGUS: Right, and I think in this situation, it just may mean that the patient could not go to the lab or have the EKG done at the typical site, and he had a van or somebody come to their home and performed the test. There may be some additional information just to let someone know that there was a trip made to provide that test or service.
DR. LUMPKIN: In the UB-92, I think it is still true in the UB-92, there is some fields that are left open?
MR. ARGUS: Yes.
DR. LUMPKIN: Is that the same thing with the NUCC? Are there some, let's throw them in for people who want to use them?
MR. ARGUS: Let me clarify that, though. We design things to be open, and we did assign some states the opportunity to assign those. But it is not to be decided upon willy-nilly by any payor or any other individual who may want to use them.
Some others are reserved for national assignment in the event that we felt there was a particular need to open it up and add some additional knowledge to the data set.
MS. NARSCISSI: And for the NUCC data set, no, this would have to be adopted by all. If it is a required element, it doesn't matter if it is Medicare or Medicaid or commercial.
MS. COLTIN: I think George's suggestion about the indicators could apply to the three elements, 58, 59 and 60. They could actually be handled --
DR. LUMPKIN: Okay, 58 is the homebound indicator, 59 is patient condition related to employment indicator, and 60 is patient condition related to auto crash indicator.
MS. COLTIN: All of these are yes-no indicators, as I understand it. If you simply had a field called indicator, and instead of having it as a yes-no, you had a code set for these, including a code value that says none, because the negative is important, which is why the next two are required, it might be possible to handle it that way.
You have to think it through, some of the pertinent negatives.
DR. LUMPKIN: I think we should think about perhaps the options, not necessarily deciding it here, collapsing those three into one, having a code for patient condition, allowing certain values of that code set to describe either homebound, whether or not there is some relationship to employment, and whether or not it is the result of a motor vehicle crash.
DR. VAN AMBURG: These are not mutually exclusive. You can have an employer in an auto accident. So it is not going to be simple.
MS. COLTIN: You would have to be able to handle multiple --
DR. LUMPKIN: Right, but you could solve that by the coding scheme, which would allow a code to exist that would include a motor vehicle crash related to employment, or you could do it by the fact that these fields in the 837 can be repeated. So you can have repeating fields that may have two different codes. So either one would resolve it that way.
I have to apologize. After serving for five years on the advisory committee for the Centers for Injury Prevention and Control, we are trained not to use the word accident. So I have this trouble, and why I always stumble over that word. Automobile crash is really the more appropriate term, because if you put a six-pack of beer into a kid behind a car wheel in the middle of the night and he runs into something, that is not an accident.
But anyway, commercial aside.
MS. GREENBERG: If you were properly using external cause of injury codes, you would know that the condition was related to some type of automobile crash, and you would know more than that from a proper use of the codes.
DR. LUMPKIN: Actually, ICD-9 uses the word accident, too. Do we have E codes in here?
MS. GREENBERG: It is, so that was a victory. Actually, the victory at the NUBC has now transferred over to the NUCC.
DR. LUMPKIN: So if we have got E codes, then we don't need these.
MS. GREENBERG: There obviously isn't enough comfort level that the E codes are being recorded, I guess.
MS. COLTIN: Yes, I think that is a problem. This is used often for a different purpose. This is a flag that the payor uses to go after other insurance --
DR. LUMPKIN: So we can flag these as potentially redundant after we see the implementation of the E code?
MR. ARGUS: Flag is a good word, only because most third party payors do not work with the E codes. So that may mean a fundamental shift in how they handle these events, in that they will have to build logic into whatever internal systems that they have to work with E codes.
DR. LUMPKIN: The next item is patient type of residence, which is an NRUC, enter if government payor requires or if contract requires. This is a part of the core data set.
MS. GREENBERG: Right. Here is a situation too where -- and I guess we have agreed, we are just looking at elements, we can't look at -- we are not looking at code sets, but I would suspect that the code set recommended by the committee is considerably more extensive and different than the code set used here, for better or for worse.
DR. LUMPKIN: In or out? Actually, it is in, unless we choose to change the recommendations of the entire committee for the core data set. So it should be RIA.
MS. GREENBERG: When would it be applicable?
DR. LUMPKIN: Undomiciled? There is a code for undomiciled.
MS. GREENBERG: I think we discussed -- yes, there is a code for homeless.
DR. LUMPKIN: So it would be required.
MS. GREENBERG: Yes, there is a homeless.
DR. LUMPKIN: Okay, that's in.
MS. GREENBERG: Are we making that an R?
DR. LUMPKIN: R. Marital status of the patient, functional code status, which is another core data set.
MS. GREENBERG: But what is this?
DR. LUMPKIN: This is a code to specify the patient's functional status.
MS. GREENBERG: Thank you, John, that helps. This is a placeholder? Okay, that is what the committee asked for, a placeholder, so it is there.
DR. LUMPKIN: So if we have asked for a placeholder, --
MS. GREENBERG: You got it.
DR. LUMPKIN: -- we've got it. But how can we say it is required?
MR. MOORE: You have to tell us what it means and how to define it.
MS. GREENBERG: I don't think it should be contractual, probably. It is more an issue of when there is agreement on the appropriate way to collect it.
DR. LUMPKIN: So it would be an RIA, and right now it is not applicable.
MR. MOORE: Well, right now we don't know what to tell the provider, how to determine when to put it in and what to code it with.
DR. COHN: I think we are under some responsibility if we are going to start sticking things in here, to be very specific, define them, identify the code set. We just can't say, this is a nice idea that we are going to therefore foist off onto the entire American population.
Now, this may be something that we -- either we have to come relatively rapidly, not in this session, but get closure on what this really means and where it is applicable, or else we need to say, this is a good idea for a future improvement in this data set.
DR. LUMPKIN: Right, because it requires at least five billion bytes to put it in and never have it filled out.
MS. GREENBERG: I think this relates to another issue, which is that a number of the elements, the committee saw the importance of them, but also saw they weren't ready for -- there wasn't agreement on code structure or whatever, and recommended to the Data Council that further evaluation or research or something -- that these be undertaken as elements that are important to collect, but we don't have agreement on the way to collect them.
I don't think any -- those recommendations I think are still in the report, or they haven't gone anywhere. They have gone to the Data Council, but they haven't been acted on in any way. I think you want to think about that.
MR. MOORE: I think the way to collect them is not as much -- because we know how to collect them. We couldn't define it sufficiently so that person would know what to collect when it occurred. So that is the bigger issue. If you could tell me what it is, we could collect it on the claim when the service is rendered. But the public health or whatever, we can't define what it is, sufficiently.
DR. LUMPKIN: So we are going to move it from an NRUC to TBD, to be determined?
MS. GREENBERG: Let me ask both of you a question about this. I know when the committee was working on the core data elements report, there was a sense that it was important to have placeholders, even though you weren't ready for it, because then you would have a place to put things. Then I have gotten more recently contrary advice or thoughts on this, given that you are dealing with electronic -- or something like the X-12 transaction, that you really don't need placeholders. Once you know how you want to define it, it can be added or something. I don't know what the situation is.
MS. COLTIN: I think this is one of those examples of the difference between the content and the envelope that we are talking about. My understanding of what we were told is that we needed to make sure that the envelope could carry the message, once we decided what the message was.
So maybe what we are saying here is that the 837 needs to have a field for this, but these data sets maybe don't need to have something defined yet, because we haven't determined the content. These are for purposes of content and for saying what you must actually fill out.
When we do determine that, we can add it to the data set, and the transaction set will have the capability to carry it.
So part of that was actually based on an assumption that you would not have an opportunity to modify the transaction set that often, or that it might be long lag periods between when the transaction set got updated. So if you wanted something, you should have it put in.
DR. COHN: This is actually an item for the terminology conference, and I will seek some guidance from them to see if we can bring it back to the committee, on this one. But you don't put in data elements without identifying what you stick into it.
I think we are looking towards a future where things are going to be moving a little quicker than they are now. We have lots of places where we can stick functional status, claims attachments, other, other. If we can identify what the values are, we are pretty silly to stick it into a claims form as a major piece of it. But that is my opinion.
MS. NARSCISSI: I just wanted to say that the reason functional status is in here is that it is specifically a placeholder for NCVHS. There have been a number of discussions on who uses it, what is the definition and nobody knew, and it just stayed in there, because it was felt that it was necessary.
Then regarding the comment with the envelope and the content, as far as for instance an 837, if you got into the detail of how this was mapped to the 837, a lot of the places that it fits into the 837 aren't specific even for a specific data element name. It would fit in there maybe in what is called a ref segment.
So you have to really keep n mind that those things are separate, and a lot of the elements that maybe in the future you want to use, you may not have to add it as a specific element. There is probably a way to pass that information electronically.
MR. ARGUS: I just want to remind everyone, too, that although the messaging standard does have a cost in terms of implementing for electronic, the data content really defines the internal application systems that help support the messaging standard.
From our institutional provider perspective, that is where the bulk of the costs are in developing the routines to collect information, store that information, and then pass it on.
So if you are looking at the universe of elements, be clear about it, and recognize that any blip in adding to it or changing it is a costly venture. If it is something that can be codified, it is less costly. But if it is a distinct item and you want it kept distinctly reported, then it becomes a cost of your venture.
DR. COHN: Let me hear that one again. You are saying that we should put it in, even though we don't know what it is as a placeholder? So that you have a place in it in your databases? Is that what you are saying? Or are you saying that the real issues are having to do with how you collect this, and without knowing what the code set is, it probably doesn't make much sense --
MR. ARGUS: First of all, I'm not quite clear as to exactly what this is. But if it is something that can be codified and we already have an architecture internally that can add codes, then it is not going to be a costly item. If it is something that requires a distinct place within your internal application systems, unique, then you are going to have to redesign those internal application systems to record it.
In other words, if I am looking at functional status code as a code that is a specific condition that I report on, I've got condition codes I can use and put it in there.
MR. MOORE: If I recall the discussion when the committee had this two years ago, whatever, there were like five levels, like good health, fair, poor --
MS. GREENBERG: That is health status.
MS. GREENBERG: This is functional status. I think your suggestion of this being an issue for the terminology conference is very good. There are classification systems currently, such as the ICIDH. There is the ADLs, IADLs. The committee felt that this might be something you would collect on enrollment and then annually or something, or if it were a rehabilitation, you would have to do it every time, so there were a lot of issues that were resolved, but it is increasingly a critical issue.
DR. COHN: George, the reason I was responding to you the way I was had to do more with the belief that this is going to be an evolving data set, and that the claims transaction is going to be evolving. I want to make sure everybody understands that you create your systems from the year 2000, 2001, but that doesn't mean that that is going to be all the data elements that are ever going to be asked for.
MR. ARGUS: And I recognize that. I know, for instance, the UB has evolved, but has remained fairly much intact in terms of having 86 distinct items of data. But we constantly add data components for reporting within the 86 data items.
What we try to do is build an architecture that allows for flexibility in terms of the changing nature of health care, to report unique circumstances or events or situations, and then add it through some level of codes.
DR. COHN: I guess I would just comment that I recognize that there has been a history of performance based limited -- you talk about 86 items. Part of the reason why there are a certain number of items has to do with the amount of space on the form. So when we redefine what that space is, there are various architectural views.
MR. ARGUS: Yes, but that wasn't the driving factor behind the 86 items. Actually, we had more items with the UB-82. What we did is, take some of the items out and codify them, rather than keep them as distinct items. Blood deductible we felt could be handled with a value code and the amount, units of blood furnished code and the amount, that type of approach.
DR. COHN: I don't want to take more time from the committee, but this will be an item for the terminology conference. We will try to come back and re-discuss it. I think it is a very important issue as an example of an area that we want to make some progress in.
DR. LUMPKIN: The next item is patient tribe.
DR. REDDING: Patient tribe and patient residency code. The Indian Health Service assures me they cannot pay without that data. I took them at their word.
MR. MAYS: This is Bob Mays, who used to be assigned to the Indian Health Service. Contract services are paid by specific individual service units. A tribal member may actually -- if you are for instance in Arizona, you may actually receive care at any number of different service units that would be billed in their budget. So that is why they have it structured.
You can probably -- I would think that the patient health record number would be equivalent to the patient ID number. The patient residency code, the piece that is missing is county. Actually, there are other instances in Medicare where county actually would be a very interesting piece.
DR. REDDING: Whose county? The patient's county?
MR. MAYS: Yes, this is the resident of the county.
MS. NARSCISSI: The residency code should take care of the county or the state.
MR. MAYS: Right, but I'm saying, if you had county -- you have patient state and patient city in your address information here. If you had county, then you could build this residency code as well.
DR. BRAITHWAITE: It doesn't say city, it says community.
MS. NARSCISSI: Community. It must be their own unique --
MR. MAYS: No, no, it is not. It is based on recognized communities within the reservation. But they are usually towns or communities that are identified to the world. It is not some made-up name.
DR. BRAITHWAITE: And tribe is essentially a subset, a sub-category, of race.
MR. MAYS: Yes, that's right.
DR. LUMPKIN: But we don't have race in there.
DR. REDDING: There are 512 tribes currently on the IHS website.
DR. BRAITHWAITE: But there are about a thousand tribes altogether, if you include state recognized tribes as well as federally recognized tribes.
DR. REDDING: Well, for IHS they have 512 codes as of the last time I spoke with them, which was only a few weeks ago.
DR. COHN: Is this a claim issue or is this an enrollment issue?
MR. MAYS: It is a claims issue, because this is -- as I was saying, these are contract services for IHS, that IHS is paying. So they at a facility can't provide a particular service, or decided not to. They contract out with other providers, and then the bill comes to them to pay those providers.
MR. ARGUS: How is it different from Medicaid with their beneficiaries in the Medicare HC number?
DR. REDDING: It is pretty different.
MR. ARGUS: Other than the number itself, but isn't the number the driving factor in linking it to --
MR. MAYS: No, it is not. That is what I was saying. I can be a Navaho and be treated pretty routinely at two or three different reservations. My wife might be Apache, so I could go down just a few miles down the road and be treated in that. I would have different health record numbers in each of those places. In fact, because of the way they pay their bills, the Navaho facilities would be billed if that is who referred you.
MR. ARGUS: But if I am a Navaho and I am part of the Indian Health Service, and I am given a card, that card is going to have --
MR. MAYS: No, that is not how it works. Each facility gives you a --
MR. ARGUS: Change the system.
MR. MAYS: Yes, well, I'm explaining to you why they -- I am agreeing with Bobby. That is why they say it is needed to be worked. I'm just saying, in the future it can be possible to work around it.
MR. MOORE: But is this an issue where we have the government, just like the Blues or Medicare? We are going to have to change some of our rules, and the Indian Health Service may have to change some of the rules they have, like how they identify -- like George was saying, that was what George was getting to, that maybe where we are accommodating the form just to accommodate the Indian Health Service, maybe they need to change their enrollment system so they can properly recognize the tribe, the county, et cetera, for these purposes.
MR. ARGUS: Right, fall into a common pattern that other third party payors have.
DR. LUMPKIN: Now, what this raises to my mind is a similar question. I assume there was some discussion about race?
DR. REDDING: No. For the Indian Health Service?
DR. LUMPKIN: No, for the -- did I miss it? Is it anywhere in here, in a descriptor of the patients? We have gender.
MS. GREENBERG: Yes. It is kind of amazing that you are going to collect tribe, but not anything on race.
DR. REDDING: The reason for the tribe has to do with payment, not for demographics.
MR. SCANLON: Actually, it is getting more complicated, with self determination. It is not the Indian Health Service that will determine these issues. It will be each tribe. They can determine how each person is enrolled.
MS. COLTIN: Can each tribe get a payor ID?
MR. MAYS: It is not the tribe that is paying. It is the federal government.
DR. LUMPKIN: Well, no, but the federal government could get a separate payor ID for each tribe.
MR. MAYS: It is not based on -- they would have to do very major changes in how they -- I'm not arguing that they shouldn't do it. I'm just saying that the way it is structured, it would require complete restructuring of how they pay for health care.
DR. LUMPKIN: Anybody want to keep it in?
DR. REDDING: The Indian Health Service does.
DR. LUMPKIN: Anybody here from the Indian Health Service?
MR. MAYS: I would argue that you put in county somewhere then, because there are actually other people that are interested in county as part of an address.
DR. LUMPKIN: Yes, state government, county payors, particularly Cook County, which provides indigent care.
MR. MAYS: The rest of it, they could work around.
MS. NARSCISSI: I think you could add county to number 63. That would be a code list, anyway. That is patient type of residence.
MR. MOORE: I think this is going to be another one of those things that you can recommend that we take it out, but we probably leave it in until we can get the Indian Health Service to change their system, so that we can get this payment done properly.
DR. LUMPKIN: My only response is, if it is going to be in, it needs to be in as an RIA. Obviously, it wouldn't be applicable to the vast majority of the -- but unless there is an understanding that for those who are providers of services for the Indian Health Service, that they may be in that class of providers who will have two different forms, one for their patients who are Indian Health Service patients or not. That is what RUC means, that for each RUC item there is now another variation of this particular document.
DR. REDDING: In documenting the standards, we are working very, very hard to make sure that every data element is connected to an instruction that tells you exactly when and how it must be used.
Quite frankly, I suspect -- and don't know -- that if we get to the end of that effort, and there are data elements that are not defined, they will have to be removed.
MR. MOORE: When you say not defined, no one comes up and owns them, and says, I am the reason I wanted that, and I can tell you why I wanted it?
DR. REDDING: We are working with a lot of committees on defining what all these things are and under what circumstances they must be used. At least frankly in the case of the Indian Health Service, I think it is pretty clear, it is not a difficult condition for somebody to understand and use. That is the goal.
DR. LUMPKIN: Right. My only comment is that it is either in or out for everybody.
DR. REDDING: Now you are telling the Indian Health Service that they have to spend a couple of years changing their systems before they can use the standard.
DR. LUMPKIN: But following in on Bob's comment, that even if we say it is out, it is going to be in, then in that conditional case, it would need to be in as an RIA, not as an NRUC. That was really the point I was trying to make.
DR. REDDING: And that is a good point. It is an important point.
DR. COHN: Are you beginning to get to the point where there is no such thing as an NRUC? By definition, every NRUC is really an RIA?
MS. GREENBERG: Or an NR.
MS. COLTIN: Yes, some of them we are making R, some of them we are making NR.
DR. LUMPKIN: But I think this may be a case where it may be acceptable to leave this as NRUC. The only thing is, as you think about multiple forms just generating, every NRUC generates two versions of the form, and it becomes multiple. The second NRUC now means that there are potentially four versions of this form, depending upon the contracts.
But that doesn't mean that there are no NRUCs that are acceptable. I think that is what this issue maybe bringing to us, that there may be some acceptable NRUCs.
MR. MAYS: But why would you say that the Indian Health Service is entitled to its own specific contractual arrangements, when you are saying that no one else is?
DR. LUMPKIN: Historical precedent.
MR. ARGUS: I think you ought to be very, very clear. I think you are muddying the waters a little bit by allowing this. I think it is better to play with the transition period, but make it very clear what the end goal should be for everybody to start aligning towards.
If you allow some wiggle room, people will take it. We are left with no better system. The idea here is to make it very, very clear what we are transitioning to, and if they need more time to make those changes, then perhaps give them a little bit of that time. Make it very, very clear, under no circumstances will they in the end be held in a different light.
DR. COHN: John, I actually agree with you, but I was also going to say that we need to be very careful, especially when the appropriate people aren't in the room, without the appropriate level of information, to be making judgments. There need to be concerns raised, there needs to be additional information gathered, either by us or by the people involved with the implementation teams, so that we can really identify the issue on this one specifically.
I think the question is, are there other solutions. I think what we are all hearing is that the Indian Health Service needs tribe information. I have no objection to that. It just seems to me to be the wrong place -- tribe seems to be something that probably doesn't change on a very frequent basis, and there seems like there ought to be other ways to get it, but we need to understand better if there are alternatives, to what is going to help the migration. Just telling them, no, this doesn't work I don't think gets -- we wouldn't do that with any of the major constituencies.
DR. LUMPKIN: And we are talking about a substantial population. I think we need to have more discussion to determine whether it is either in, out or even potentially NRUC. What I think we have learned from this particular discussion is that there may -- and I'm not saying this is the particular one, but I don't think we should be black and white in saying there should be no NRUCs. There may be in fact be some justification for an NRUC in this document. We need to have more discussions about it to determine whether it is either in, out or even potentially NRUC.
What I think we have learned from this particular discussion is that there may -- and I'm not saying this is the particular one, but I don't think we should be black and white in saying that there should be no NRUCs. There may in fact be some justification for an NRUC in this document.
I would like to perhaps -- yes, sir.
DR. BRAITHWAITE: I didn't want this to be used as an NRUC, because we have pretty much said that the patient residency code is the county of residence, and part of the address of the patient, and we can deal with the patient's tribe, although in one perspective it is a subset of race. In this case, it is not being used that way. It is being used as a contract number or a group number for a particular payor. We ought to address it that way, or get IHS to address it that way. The health record number for the Indian Health Service is in fact the unique identifier which we are dealing with in that way.
So we have a migration plan, at least an obvious one, for each of these elements into the new world, and we ought to make sure and check it out with the IHS that they can accommodate that. But it doesn't seem to me to be difficult. No issues have come up here that would not allow that migration to be easily accommodated by IHS, as long as they are aware that it is going to happen.
DR. LUMPKIN: I don't think there is any disagreement. What comes to my mind as this issue is brought up is why we did not include -- or why race is not included in the encounter form.
MS. COLTIN: I think it was because we thought that would be collected at enrollment, that it didn't need to be captured at every encounter, that it was a one-time thing.
DR. LUMPKIN: Is that on the enrollment?
MS. COLTIN: We don't know.
MS. GREENBERG: That is the $60,000 or $60 million question.
DR. LUMPKIN: So let's put that as an issue that we need to come back to, that we need to remember to check.
MS. GREENBERG: I'm almost sure it isn't, but it seems someone should know.
DR. LUMPKIN: Right, because it certainly is an important variable for care. There have been numerous studies that have been published, showing that there are variations in levels of care, even within the same source of payment by race.
MS. COLTIN: There is another reason. This is a form filled out by the provider. The enrollment form is filled out by the patient. So we felt that race was something that should be reported by the patient, as self report.
MS. BALL: Just one thing I would point out is, if you are really interested in race for risk adjustment purposes or for variation studies, you are talking about a system with enrollment where you are only going to have race on insured people. That leaves a giant hole.
MS. COLTIN: Well, that is a good point.
DR. REDDING: I would also like to add that if you put race on the claim, you will in your database eventually have many races for each individual. In addition to that, there are states where it is illegal to collect race data in that fashion. That is true, because Dartmouth says it is against the law. I forget what state Dartmouth -- Vermont?
MS. COLTIN: New Hampshire.
MR. ARGUS: As I understand, too, isn't there some movement within Congress to add some new category in terms of the census tracking on race, adding a new multiracial category?
MS. GREENBERG: Well, the recommendations are that -- they are out now for public comment, but you can check all that apply, but multiracial was not recommended as a category.
MS. NARSCISSI: And you have to keep in mind that this data set and the enrollment transaction data are designed just for people with coverage to be reported that way. So you wouldn't collect those that aren't covered in these types of transactions.
MS. GREENBERG: If an encounter is the same as -- if we are saying that it is also an encounter, then --
DR. LUMPKIN: But I think we need to understand that while that is true, this becomes a standard for an individual provider and the data that they collect in their internal system. So the uninsured patient who may show up at a hospital emergency department and so forth would tend to have the same enrollment form, even if they have no insurance.
My watch, which is admittedly a little bit fast, says it is 11:30.
MS. GREENBERG: It is 11:30.
DR. LUMPKIN: At this point, we were going to have a status check.
We have spent a good portion of the morning, in fact, almost all of the morning, going through -- and I think we have made it through a number of points in the document. But I think that there are some fundamental issues which this discussion has led us to.
First, I don't think it would be our intent to go through this entire document today, and to make a decision on every data element. But I think we have established certain approaches to looking at data elements and understanding what is the size of the population involved, the fact that we want to minimize or completely eliminate all those variabilities in the form that may lead to proliferation of different entities within the standard.
We also believe that some of the things we are recommending are transitional, particularly as a system is in place where we require evaluation in three years, when we actually can substitute much of this demographic information with the unique identifier or unique provider ID and so forth. So I think there are many other areas where we would come to very similar conclusions.
It seems to me that there is a much larger issue that the committee needs to address, probably for recommendation for the full committee. It has less to do with the individual items in the content that we have discussed and more to do with the process of future discussions.
Who owns this data content? If we are in fact as a committee going to go through each data element and each one of the various transactional standards and hold ourselves out to being the owners of this data, I think that we are far exceeding our capability, much less perhaps our charge. Perhaps we need to think about for discussion, maybe some preliminary discussion here, but at our next meeting, more or less the process about going through this, whether or not we see there being bodies like the NUCC and NUBC, who would then make these recommendations with some cursory review by us, or some other kind of process.
So that is really what I wanted to toss up for discussion at this point in our agenda. If there is some agreement -- or other items that we may want to summarize for this meeting.
DR. COHN: I was going to agree with you, that I think it does bring up that issue now. First of all, just to try to close off this particular discussion, I think this has been very valuable, despite when we started this, I was absolutely certain that this was an absolute waste of time.
I think it has been very useful in terms of identifying principles. I guess knowing the group that did this, I would certainly hope that maybe they could come back and revisit themselves the data element, and come back with some recommendations on how some of these NRUCs and other things might be best handled. That would be very useful for the committee.
Now, on your second point, which is probably the more germane, which is this issue of ownership evolving the data set, how all of this happens, I think that there are a lot of interested parties in this one. I think it might be very useful to certainly before the committee comes to any conclusion, to begin to hear from some of those interested parties on what they think structures ought to be for that. That would be very useful for the subcommittee to hear in terms of any recommendations it might have on that.
I think many of the standards groups, certainly the NUCC, NUBC, all that, all I think need to be heard in relationship to that issue.
DR. LUMPKIN: I don't have the list anymore, but we do have some items that we have identified for a fall hearing.
MS. GREENBERG: We have a winter hearing.
DR. LUMPKIN: Okay. That would be much better than a fall hearing, anyway.
MS. GREENBERG: I don't think we actually have a fall hearing.
MR. BLAIR: If we are going to have a fall hearing, this is just questioning, about the October time frame, I expect to at least have drafts of the templates that we would be using for the clinical inventory of standards. I would really like to be able to work together with the terminology task force, which is in November.
I'm not sure how this will all pull together, but when I was speaking to Michael Fitzmaurice, we were thinking in terms of templates for clinical message format standards, clinical vocabularies or terminologies, and then clinical data sets or models in those general categories.
MS. GREENBERG: Would you repeat that?
MR. BLAIR: Sure. We were trying to think how do we wind up putting together categories for these things. So the first one is maybe the easiest one, which is clinical message format standards, as opposed to the financial and administrative ones that we have done to date. The second one would be a category which we might call either terminology or vocabularies, clinical vocabularies, clinical terminologies. Then the third one would be, for lack of a better phrasing, clinical data sets or clinical models.
I am only mentioning it because I would like to be able to make sure that whatever I do, it is consistent with the rest of the work efforts and plans.
DR. COHN: On this assignment, I just was curious. Is this under the heading of HHS activity, AHCPR, HISB? Which hat?
MR. BLAIR: Probably under ANSE/HISB. Michael Fitzmaurice had asked if I would follow up the initiative we did on the inventory standards that we delivered last year, and that we go ahead and both come forward with a clinical inventory of standards. That was in our last ANSE/HISB meeting. I agreed, but I indicated I wouldn't be able to start it really until September, October time frame.
So he agreed that that would be okay. So I am just mentioning it so that we are all working as much in concert.
MR. MOORE: Would they be things like what HCFA has put out, like the minimum data set for a nursing home? Would that be put into your inventory, or the one that we proposed for the home health, the OASIS, that created a lot of furor here?
MR. BLAIR: I really haven't looked into these things, so I haven't even made a first cut of everything that should be in each of these. So I'll be soliciting as well all the data sets that should be included.
The last time we went through the process, we were kind of rushed. But we made the initial templates, we distributed them as widely as we could. Then we got people that wound up saying, make these changes, add these additions to them.
So yes, I don't have -- I have no limitation in my mind at this stage as to what would be the appropriate data sets. I would like to be able to work with you to decide what would be the most useful and valuable ones.
DR. COHN: I think your idea is a very good one. I think that we need to make sure -- and I think the place where NCVHS can be really valuable for this is making sure that it is meeting the need, that we have this focused in a way where the results come out in a way that would be useful and helpful to HIPAA activities. I think that is probably what you are asking for, just like I was around the terminology conference, coming up with things that would actually be useful to moving all of these things forward.
It is probably a topic of conversation of some kind during the fall, which I think is what you are also describing.
MR. BLAIR: I will not be here for the September meeting.
DR. COHN: Okay, after that.
MR. BLAIR: I might try to individually speak to as many of you as I can during the next few weeks to get your ideas and thoughts, so that I get started in October with as much input as possible.
MR. SCANLON: It seems though, Jeff, that you are taking this up at the request of one of our agencies, is that right? At the request of HHS, it sounds like.
MR. BLAIR: Yes.
MR. SCANLON: And maybe some sort of framework or a table of contents or some sort of an approach could be given, in terms of what would be most useful to the national committee and HHS.
MR. BLAIR: Absolutely. I would love to have as much input as to what you would like.
MS. GREENBERG: On the work plan, I think the earliest hearing was the winter for attachments, which actually follows on to this. But clearly, we are not going to get -- even if we decide to stay until five, we probably wouldn't get through this whole document. And this is only one of them.
I do think though that this work group should have some recommendation or plan or whatever to consider the core data elements that were recommended as to -- they were a finite number, and a number of them are already included. I think it would actually be pretty easy to identify the ones that are not included at all, even as an element. In fact, I think both George and Jean have done that.
So I think there should be some kind of recommendation back to the full subcommittee and for that matter, probably the full committee, about at this stage, whether they are going to be looked at now or will be put aside and go forward with what these two organizations have, or what.
DR. LUMPKIN: I think the matrix that we will get should allow us to look at where the core data elements are or are not.
MS. GREENBERG: I could tell you right now, for that matter, I don't think we need the matrix. But -- well, no, I could tell you about the ones that aren't on the encounter form. I can't tell you about the enrollment, although I am almost positive that most of them aren't there. But I have yet to see what is there.
DR. LUMPKIN: So what we need is a listing of those core data elements. We need to evaluate those. We need to look at the core data elements that would fit under here as NRUCs. We need to as a committee make some evaluation of whether or not -- as we did with functional status code, that if we don't have something to put there, then while it is important to raise the issue, it is probably not reasonable for us to suggest that it be sitting there in a form.
MR. MAYS: The core data elements are in the master data dictionary. So when that report is out, they will be listed.
MS. GREENBERG: I know they are.
MR. MAYS: As well as cross referencing as to where they show up.
DR. LUMPKIN: I think as we discussed, that would be part of our discussion at the next meeting.
MR. SCANLON: Related to that, though, John, what we have been doing this morning is setting criteria for why is something in and why is something out. If we can be more explicit about what are the criteria that determine whether something is in or out or transitional or RA or whatever, then I think for everyone's benefit, that would be useful, an explicit set of criteria.
DR. LUMPKIN: Is there a member of the committee who would like to volunteer to make a cut at that, based upon this discussion?
MR. SCANLON: Well, a place to start is the criteria that were used for the UHDDS and the ambulatory care data set. I know they have been included. When does an item meet the criteria of use, general utility and measurement, precision and other things. That could be a start.
MR. ARGUS: Can I add a little commentary here?
DR. LUMPKIN: I thought you were volunteering.
MR. ARGUS: No. I'd be happy to help. But fundamentally, I do agree, process is very important. I think that at some point in time, a decision is going to have to be made about not required under contract type of situations.
I think if process is important, then I think just coming out and saying that those items that are currently identified as NRUC from the NUCC perspective, we need to go through the process of determining whether they have value or don't have value and are accepted as a first step.
But by and large, you are saying that they are going to be taken off the table as a recommendation as far as the core data elements, is a first step. Then letting them make the case to bring it before the group.
I know from an NUBC perspective, we are holding a meeting next week, inviting many of the state billing committees, the state associations, to come with their state use codes, because we are on a fact-finding mission just as you are, to determine how some of the unique data reporting requirements may exist within the states, and then trying to determine whether there is a need to add them to the national data set as part of the UB.
So from our perspective, we are just doing an inventory right now of what the states are doing. The process is very important, and we are willing to help.
I also think -- and I have talked to Marjorie and to others within her organization about our NUBC looking to expand the membership to include a liaison role or a representative from her group to be on our committee, to help provide some insight in terms of the process.
So I think the dialogue needs to continue, and I think fundamentally, if you just lay out some basic baseline criteria and keep it within a framework for process that gets you to where you want to go, I think that would be very, very helpful.
DR. LUMPKIN: Is there maybe someone on staff who could help us?
DR. COHN: With your request?
DR. LUMPKIN: Yes. I think we have pulled some things out of here. For instance, I think we would want to recommend to the full committee on data content that the documents be -- that something like NRUC is not something that we want to see, that there needs to be -- the data fields either need to be in or out, or some criteria in which a very limited set may be in that position.
I think that we would need to look at issues related to -- I think there is a difference between an NRUC and a state variation. If I live in Illinois, I'm going to do it the same way, no matter who the provider is, as opposed to trying to figure out for different providers.
So there are some of those differences that we may want to tease out, and actually come to some decisions, and have those approved by the full committee.
DR. COHN: Obviously, we are having process discussions now. First of all, I think that there were a number of very important principles that we discussed, so I think some of those can be pulled out of the minutes of this morning, and probably e-mailed around to have us all add them, critique them or whatever as part of that.
I do however think that we are right in the middle of that process. I think that there probably needs to be some more looking at this document, both to look at the document, but also to -- because I think we will be beginning to uncover other principles. I'm not sure if we are quite ready to create the full set of principles. There may be some empiric effort, work, that needs to go into it to uncover more principles, though I think we can begin to add them by an e-mail conversation between now and September, then to be re-discussed by the group.
DR. LUMPKIN: I am actually just looking for a straw man type document for us to look at, because there are other things that when we look at the matrix, we will want to discuss, to what extent do we want to see -- how much variability and definition will we find acceptable from one transaction set to another.
MS. COLTIN: I think there has been a fair amount of discussion around some of the elements that are required, that in fact they are not all equal. Some of them are elements that we feel will always be required, or at least for the foreseeable future, and some which we are saying would be required during a transitional period, after which they might no longer be required.
Even with that second group, there are some that could be accommodated potentially now, but we want to allow a transition for that to occur, like some of the Indian Health Service type things, and others that really couldn't be accommodated now, unless payor ID is implemented, or unique person IDs. Do you know what I mean?
DR. LUMPKIN: Yes.
MS. COLTIN: So it seems to me that among our principles for how we designated things, we would need to differentiate in those required elements those that are only required because we are in a transitional period.
DR. COHN: I would think that pulling this stuff out from the minutes would be a very useful type of activity. It is not my responsibility to assign staff, obviously.
MS. GREENBERG: I think the executive secretary and the executive staff director, we'll put it that way, can find a way probably to at least bring together what we talked about today, what the criteria have generally been for the uniform data sets and core data sets, and we have pulled those out in the past. Then also look at the criteria -- I know the NUCC had explicit criteria in your report, and you did as well, is that the case?
MR. ARGUS: We basically did. We have nothing in terms of under contract. We just don't recommend it.
MS. GREENBERG: Well, we can talk with you. I think obviously we can work together on it. As George said, the whole process is evolving, and this is something the department is clearly looking at as well, what kind of representation there should be on the NUCC and NUBC, if they have the bulk of the responsibility for defining content, and then what kind of appeal process or process the national committee might have.
I think all that isn't going to be resolved by September, but I think we can get some of this down in a very basic way.
DR. COHN: And I think some of the things you were just talking about probably are really the focus on the information gathering and once again, some recommendations. I'm not sure in my own mind that there has been a firm decision -- in fact, I know there is no decision on exactly how this content should all evolve.
MS. GREENBERG: I think there isn't even a firm decision on how it should be determined right now, although there certainly are strong leanings.
MR. MOORE: Come October, we have promised that we will have a reg, and that reg will cover all nine transactions, not the claims attachment. An addendum to each of those regs will be a list of the data elements that are found within that transaction set. We are on a hot path to pursue that effort.
Also, we are creating a website that will be with Washington Publishing, that anyone can go and look at, that will say, here is the transaction set, here is how to do it, which will be hundreds of pages, and within that will be a data set that will tell you what the name, the location, the definition, under what conditions. This is all 5,000 data elements. We are working like a bunch of little ants getting ready for the winter.
DR. COHN: I appreciate your time frame, but since you to date can't even give us that, it is not our reluctance to review that or provide input. It is the fact that you literally have not gotten it done. I find myself in a funny position of hearing you telling us how much in a hurry we all need to be.
MR. MOORE: I didn't tell you we're in a hurry. I'm just saying I'm in a hurry, and I don't have it done yet. I'm just saying that I can't give it to you in that fashion. We have both Jean and George here from the NUBC and NUCC, and they only represent one of those transaction sets. That is the claim. All the other transaction sets we don't have a content representative to have done the detailed work that you see here in this NUCC set, because it wasn't done out there in the X-12 industry, where we have the transaction set.
DR. LUMPKIN: But I think our role of our committee is to provide advice in that process. I think that from the members of the implementation team who are here, I think the direction that we are going should be relatively clear in some items, and some other items where we are kind of fuzzy on.
But this is an iterative process. We are rushing to October, but I don't think we should delude ourselves that the perfect should be the enemy of the good. We will make significant progress by implementing the transaction sets and the code sets by creating some standardization and simplification.
But our job will not be done when those regs are printed and when they are adopted. We are going to need to refine those. Because of the time frames of HIPAA, we know that there are many things that we would have liked to have much more detailed input on. It is just not feasible.
But we certainly intend to continue that partnership beyond next March or May, whenever that deadline is, to refine these data sets, so that the next iteration will be even better. We are going to be talking about that with version control, even with the transaction sets. We have a tremendous amount of work to do on the attachments and the CPR.
All this I think will begin to move us closer and closer, as we get to a closer approximation of what we think will be the best possible.
MR. SCANLON: That is why the process that is being set out and has already been started is so important, because it is a continuous process. It is not the issue of some regulation and everyone goes home. That is probably the beginning of the process.
DR. COHN: Leaping way back in the conversation, do we want to think about some sort of a hearing to talk about how this is going to happen? Obviously, right now everybody is pushing to get these initial things in. But the question is, and I think it is going to be very important that we get some recommendations about alliance models for how this is going to evolve, what sort of ownership and how that all plays out.
DR. LUMPKIN: And I think we need to -- my suggestion would be that I just don't see, given all the work that is going to be done between now and October, I just don't see us really being able to pull something into October. After October, we are playing in a different time frame. The pressure is off in that regard.
So I think we need to probably re-evaluate this in the September time scale. I think we do need to have hearings, but it may be that after the proposed rules are out, that hearing may be more meaningful.
MS. GREENBERG: I think what fits in with this whole idea of the next set of hearings may be starting the discussion of the attachments. I think that could be combined. There also will be real issues about certain things, whether they should just should be parts of attachments and how much -- and that whole process, too.
So you could get a process to do more thinking about and get some input through hearings on a process which would apply to the transactions as well as the attachments. I think that would probably fit.
DR. LUMPKIN: I think we have a plan.
DR. COHN: And John, we are asking for additional feedback from you.
MS. NARSCISSI: I would just like to add, too, on this data set, it is the baseline version. And because we mapped it to whatever current version is available to date, the 837, that could change next week or the week after, because it is not in a final format. So that means that there are some elements that are not mapped to the 837, just because it wasn't clear on where they would fit into the 837. It can accommodate them, but they weren't sure how they should be carried.
If they want to add a couple more pieces to the 837, that means the page numbers could change. So this version, 1.0, may be 1.1 in a couple of weeks. I just wanted to make you aware of that. It also is available electronically in the NUCC website, NUCC.org, or on the AMA website.
DR. LUMPKIN: Are there any final comments before we adjourn until next month?
MS. GREENBERG: This subcommittee could benefit from more than the three hours that are being planned. Do you really want to think in terms of -- other than that?
DR. LUMPKIN: I think we need to plan to work into the evening, as much as I hate to say that.
MS. GREENBERG: We need to let people know, staff and members.
DR. LUMPKIN: Yes. I think we should schedule more than three hours. The usual one is, we start in the afternoon and then we -- of the first day.
MS. GREENBERG: I guess we are going to be in a hotel, so we need to get a room and maybe break for dinner.
DR. LUMPKIN: Right, get a room, break for dinner and then come back.
MS. GREENBERG: Resume.
DR. LUMPKIN: Yes.
MS. GREENBERG: The San Francisco style, work morning, noon and night.
DR. LUMPKIN: Yes. If there are no final comments, I would like to thank everyone. I think it has been a tough but productive couple of days. Thank you.
(Whereupon, the meeting was concluded at 12:00 p.m.)