Hubert H. Humphrey Building
200 Independence Avenue, S.W.
Washington,
D.C.
TABLE OF CONTENTS
Page
K2 Workgroup Discussion 1
ANSI HISB Inventory of Standards 25
Panel on ANSI SDOs 31
Jean Narcisi, ADA 31
Ed Hammond, Health Level 7 45
Daniel Staniec, NCPDP 58
Lee Barrett, ASC X12N 67
Gary Beatty 79
Panel on ANSI SDOs (continued)
Phong Xuan Ngo, X3L8 101
Richard Peters, ASTM, ANSI HSB 105
P R O C E E D I N G S (8:13 AM)
DR. LUMPKIN: This is the time for the work group to kind of synthesize what we heard and sort of put ourselves in a frame of mind for the next panel, and just a little bit of discussion here.
I know we spent some time last night talking about upcoming meetings, and that was in some ways a summary of yesterday's session, but perhaps with our brains functioning a little bit better this morning, given the large amount of information we have to assimilate, we may want to raise some specific issues that we want to address.
Certainly the issue of certain coding sets came u yesterday. We heard a fair bit about the 837 standard and issues related to the implementation guide, and we have, also, heard over a period of time a fair amount about the NCPDP and the overlap between 837.
So, given that, are there some thoughts or issues that any members of the work group want to --
DR. IEZZONI: Yes, John, I think we need to be really clear about what we are doing because I confess that I still get quite confused.
We have this kind of staged responsibility over the next 4 years, ending up with electronic medical records, but right now our responsibility is very limited and restricted, and we heard from Bob Moore that we have to give him recommendations by June or July on this very limited specific area, and you know, I think that we don't want to forget that down the road we need to deal with electronic medical records and attachments and other things, but I think to be able to meet our responsibilities we need to be very focused and very targeted about how we spend our time talking over the next few months.
It is kind of frustrating to people like me because it means that the clinical data is not going to be as much on the table as I would like it to be, but I still feel that we are getting a little bit muddled in what we should be focusing on right now, and you know bringing in things that we are going to have to deal with later but maybe not having the discussion that we need to meet our immediate responsibilities.
Do other people feel that way?
DR. STARFIELD: I certainly feel that way. I think now is the time for us to get very specific about the questions that are of high priority, and I think we have to split them into purely billing and clinical because there is a tension within the Committee itself about interests in this but yet we have to do both. They are not the same. There is overlap, but most of the standards we are talking about are really billing standards, not standards, and I think we just need to develop ourselves a list of whatever it is, 10, 20 specific things that we think are of highest priority and assign responsibility to a member of the Committee to organize, you know, to answer the question.
MS. COLTIN: I agree, but I just don't want us to think about these as billing standards because I tried to make the point yesterday that in today's environment with capitation they are serving many other purposes besides billing, and in fact, they are not being used for billing in a lot of managed care organizations.
DR. IEZZONI: So, Kathy, what is the single word or short word that we would use to describe this because I agree we shouldn't use the word "billing"? Should we say, "Encounter"?
DR. STARFIELD: Transactions.
MS. COLTIN: I think they are administrative transactions. I think it is fine to call them administrative, but I would not limit it.
DR. STARFIELD: As you know, I don't even make a distinction between administrative and clinical, either, but when we are talking about most of the standards that are out there, most of them don't have much to do with clinical stuff.
DR. LUMPKIN: Except you get into diagnosis and treatment, and that is pretty clinical.
DR. STARFIELD: But procedures aren't really clinical.
DR. LUMPKIN: Oh, I disagree, I think that there is a tremendous body of research that is being done on the implications of clinical treatment and procedures and the utility of those treatments and procedures, and most of that is being done off of transactional data.
DR. IEZZONI: Our problem is definitions. I suspect that you, John and Barbara do not disagree. I think each of you need to define what you mean by clinical, and once you define that, I suspect that there will be some agreement.
DR. STARFIELD: What I mean by clinical is for clinical use. Okay, procedures most of the standards we have there are coded because of payment, not because of clinical use. So, by clinical I mean clinical use.
DR. LUMPKIN: But there are two definitional bases then, and one is the essence of what it is, and the second is how is it being used. You can use a tire for a swing, and you can use a tire to drive your car, and one might call one a recreational item, and another might call it a utility portion of a vehicle, but it is still in another nomenclature a tire and in both uses, and I think that that may be the syntax difficulty that we are having here is that you know, whether we define it as a use or we define it as what it is itself in its essence.
DR. STARFIELD: I think that is really helpful, actually, what you just said because it clarifies for me that most of the standards that are out there are not for clinical use.
DR. LUMPKIN: And I think my biggest concern is --
MS. GREENBERG: That is certainly not true about HL7.
DR. LUMPKIN: Right, but I think my biggest concern is I am not as concerned about how we are going to get to what we are going to decide in June. My concept is that we have got these implementation teams that are working internally in HHS, that we have interfaces with those internal teams. Those internal teams are not because of the various rules and standards and all that other stuff able to bounce things off the public.
We, on the other hand, can interface with those teams, and we can bounce our impressions of what they are doing off of the public. So, we have a way of really looking at what they are doing in a different way.
My expectation is that since we are required to comment on what they come up with before it is implemented that they will have to try to have their implementation schedule somewhat in line with what we are going to be doing at our June meeting.
So, we have the opportunity of taking what is going on with the implementation teams, bouncing it off the general public and making some decision, and I think while much of this is complex, a lot of this is kind of really obvious, the choices that we will end up with in June. You know, we are going to be looking at SNOMED(?) and CPT4 and those kinds of codings and ICD9, and we know that today, and we know that it is not going to be any different in June.
A lot of the data that we need to make those decisions are going to be there. We need to listen to people. That is one of the differences in what we hope to accomplish.
My biggest concern is while the decisions may be fairly obvious, the right decision may not be, and the implications of this for the clinical are what I think we are all concerned about.
So, are we going to be making choices in June that will have adverse impact upon the CPR and other clinical uses of this data that we think are very important? I think from the public health viewpoint the use of this data for surveillance purposes and epidemiology and all of us think about for the management of patients, and so, I think the issue we have to grapple with is how we make sure that we are not shutting future doors by decisions that we are going to be making in June. I see you are puzzled.
DR. IEZZONI: No, it is not I am puzzled. I think that what we are talking about in June is so limited that it seems to me that it is unlikely to close doors irrevocably about where we might be heading with the CPR down the road because I do think the way that the decisions have been laid out for the administrative transactions, they are very narrow.
I think one of the frustrations that I have been feeling, and I pushed a little bit at the last set of hearings was whether we want to expand those administrative transaction data sets just a little bit to add more information that can begin to address some of the needs that the first panel yesterday expressed.
You know, we talked at the last meeting about adding for the hospital data set a code or a little flag about whether a diagnosis was present on admission or occurred after admission.
Barbara is very interested in level of certainty about outpatient diagnoses. I guess that is something that I feel we haven't really had a chance to talk about and could be extremely controversial for the field, that we might want to add a few things to the standard administrative transaction set, but I don't see any of that as closing doors for where the CPR is going, you know, 4 years hence.
MR. MAYES: If I could just share some of the thoughts that we in the implementation teams have been talking about because it is right to this point, one of the things that we were thinking about doing was perhaps explicitly coming up with a phased approach.
It has come out from a lot of the panels that that is a concern they have, and it is, also, a concern of ours because a number of us share this concern that we don't pick something in June that has far-reaching implications as we move towards standardizing clinical data, as well, and so, we thought that code sets is a good example, because there are some very de facto standards. I mean ICD9 CPT, it is going to be a real battle if you decide in June that you are not going to use those anymore, whereas they may not really be the best choice as you move towards the broader patient record, computer-based patient record, and perhaps if we were able to explicitly lay out, you know, that we recognize for practical purposes and for the purposes of the specific administrative transactions talked about in the legislation that there are some current de facto standards which for economic reasons it is perhaps not worth trying to change overnight, and the pharmacy is a good example. They are not going to be the only ones when it comes out. There are going to be others who really want their standard, and yet, if we explicitly state that we have thought through a plan that, you know, just because we picked ICD9 now does not mean that it is going to remain ICD9 or ICD10 from now until forever with simply iterations and versions of that code set but that it is really because of the necessity to phase towards a broader application that that is the kind of step we are going to take.
So, that might be one approach that we wish to consider, and I really hope that the members of this work group are very actively liaisoning with the implementation teams because I think, Dr. Lumpkin, you really hit it right on the head as to how we would hope to work synergistically in this process.
We have got the staff that are going to plow through the ANSI standard inventory and do a lot of the footwork that I think you are concerned about, Dr. Iezzoni, and how you are going to get it done between now and June, and yet we need to have a link to the broader world to be sure that we don't send signals that we are just in the back room figuring out what Medicare wants.
MS. GREENBERG: In a way I am reluctant to raise the "C" word, but the core data elements that were the focus of this Committee and in many ways have been the uniform data sets, they basically are administrative data sets, and yet, many people felt that, you know, there was value for them, many people on the Committee.
So, I think this dichotomy that you are drawing isn't exactly real because some of the things that you were mentioning, Lisa, about the possibility of adding, they were recommended or were considered at least in the context.
DR. IEZZONI: I know, back in 1992.
MS. GREENBERG: And I think there you weren't really dealing with the clinical record. You were pretty much dealing with what a state hospital discharge data system would get, usually gets it from a UB92; ambulatory surgery data comes from 1500. So, I think that the lines aren't quite as drawn.
I think it is true that the ANSI, certainly the X12 standards have primarily been driven by claims and billing issues, and because it is in an insurance rubric and that is what its focus was, but HL7, ASTM, I mean a number of them actually, probably, you know, of the standards activities are in the clinical area.
So, again, I don't think that you can say that the standards work has all been related to billing.
DR. IEZZONI: I don't think anybody is suggesting that, Marjorie. I think what we are talking about is what we need to do for June.
MS. GREENBERG: But I am just suggesting that you have that opportunity to revisit some of the things that have been recommended in the past.
DR. SCANLON: Again, I think what you heard from the panels, and I think the approach that the Department is taking is that the June product, the first set of standards are more or less a platform upon which some of the needs for the electronic standards could be built.
In other words, if you decide what the unique identifier is for patients and the national provider ID and payor, that supports the infrastructure for the clinical data as well.
In addition, this is not seen as sort of we issue the standards and walk away. This is seen as a framework for updating and adding and potentially adding items to the standards, and there will be a standard for encounter data, and the core data set, for example, is being given to all of the work groups instead of considering additional items, but what will happen in June is not the end. This first wave of standards is really sort of the platform upon which the rest can be built.
We clearly don't want to have in the set of standards initially promulgated anything that forecloses anything we can foresee in terms of technology or flexibility. We clearly wouldn't want to have a standard that basically eliminates one whole direction for the clinical area as well.
DR. LUMPKIN: Let me perhaps share with you my bias because I agree with everything that has been said, and we do have to take along perspective. My concern is, and it is based upon some of my past experience; I started out doing my clinical research in emergency medicine at the University of Chicago, and one of the hard lessons I learned in trying to capture data in the emergency department is that every single field is like pure gold, and at some point, you know, just by saying that it would be nice to know just one more piece of data, you end up with a form that no one fills out because of what is going on in the emergency department.
As states and as a state in Illinois, when you look at some of the systems that we have to complete for federal data it is clear that somebody somewhere in the federal bureaucracy was just saying, "You know, it might be interesting to know that," and cost implications to us as a state in trying to just get something that has no clear use are really quite significant.
So, I say that because I think that if we are looking towards a computerized patient record as where we are going, once we get there, once we get the computerized patient record, then cost to the provider of care, you know, the end user of this system is relatively cheap, but until we get to that point the cost of each additional data element is going to be very expensive, and that has to do with the cost of medical care. You know, we think about a billion transactions.
One field times a billion transactions is a tremendous amount of stuff. So, my druthers is while I agree and the researcher in me, the epidemiologist in me, you know, the surveillance guy in me who says, "Yes, I want to know as much as I can, but I think that we have to recognize that there are some associated costs," and so, it is not that I am opposed to it. I just need to get the feeling that whenever we say that we want to add just one or two clinical things that it is really worth the tremendous cost because that is what really is going to be the outcome of adding additional things to a record that really has a function, and while we don't agree with it, I mean I kind of, you know, I hearken back, and maybe I mentioned this before but when I was in Egypt and I was viewing an emergency department in Luxor which is right across from the Valley of the Kings, and I was looking at their emergency department, and they said that they saw 26,000 patients in an area that is about the size of these tables, and I asked them how they did that. I couldn't believe it. I said, "Can I see your medical records?" They said, "Medical records? If we had medical records, we couldn't see that many patients," and that is the trade-off. Every time we add data, the ability to see and to provide clinical care is going to be impacted, and so, that is my bias, and I am not saying that that is going to mean that we don't do what is being suggested. I am just suggesting that we really fully understand what we are doing when we begin to add in additional items.
MS. GREENBERG: On this topic I just wanted to mention, and I was talking to Bob Mayes about this, we have volunteers from the work group for four of the implementation teams, but actually the two that in some ways are the most focused on content we don't have anyone, and that is for the claims and for the eligibility and enrollment.
So, I think it would be good if the Committee could --
DR.LUMPKIN: Can you give us the five and who is on --
MS. GREENBERG: Okay, according to my notes Simon signed up for infrastructure. I think he confirmed that last night. Kathleen Frawley signed up for systems security. Lisa and Simon signed up for coding and classification. You signed up for identifiers. We need someone for claims and someone for eligibility, and then I think Bob will see to it that the people are contacted and told when the conference calls or whatever are and participate as available. I don't know whether Clem is interested as well. It could be someone on the Subcommittee as opposed to the work group, but those are the two really content rich ones.
DR. BRAITHWAITE: I would think that someone like Kathryn would be excellent for particularly the counter side of the claims team which is going to be maybe the most controversial one of them all.
MS. GREENBERG: I was thinking the same thing. So, that is claims and counter one.
MS. COLTIN: I was thinking, too.
(Laughter.)
DR. STARFIELD: How important is it, do you think to have someone for eligibility?
MS. GREENBERG: I don't know what the opportunities are there. It is the only place you are going to get any of the --
DR. BRAITHWAITE: Let me make a suggestion that the controversial aspect of enrollment might revolve around the ways you describe the demographics.
MS. GREENBERG: That is what I was saying. It is the only one where you are not going to get that on the claim.
DR. BRAITHWAITE: Race, ethnicity codes, for example.
DR. STARFIELD: Maybe somebody from the other, there is another subcommittee?
MS. GREENBERG: Actually maybe someone from populations at risk might --
DR. LUMPKIN: It is almost like creating a vital record. Do we know anybody who has that sort of expertise? Let us look around the table.
DR. STARFIELD: I don't know whether Tom would do it or not. George volunteered, also? Okay.
MR. VAN AMBURG: You are very persuasive.
MS. GREENBERG: Being a point person we don't expect you to come in for all the weekly meetings. Okay, good.
DR. STARFIELD: What is the mechanism of coordination of these people with the --
MR. MAYES: For those of you who don't know, I am Bob Mayes. I am the co-chair of the infrastructure cross-cutting team, cross-cutting issues team. Most of the teams are meeting weekly, and the infrastructure and cross-cutting team actually coordinates the activities of the other five teams, the ones that really do the work. We handle such issues right now, for instance we have two high-priority issues. One is to come up with a standard set of evaluation criteria that can be applied across all of the standards, and that came out, I think in yesterday's discussion, the need for that. So, this would be the criteria that each team would use to justify why they chose one standard or another.
The other priority issue at the moment is to develop a template of the regulatory process. Since these standards ultimately have to be issued as regulations that is a very lengthy process, and we are hoping by standardizing the process and coming up with boiler plate language that we might be able to convince some of the parties involved in the process to look favorably on speeding it up a little bit.
So, those are the two cross-cutting issues. We have the chairs or representatives from all the other teams come to our weekly meeting on the infrastructure team. They are to be sharing a weekly activity progress report, and I think I have got them submitting it to me. So, I will be compiling that into a single weekly report which I will be happy to share with all of the work group members here on the Committee as to sort of what the issues are for each team, what they have accomplished and what sort of outside communications they envision for the next short period of time.
I should mention a third effort that the infrastructure team is doing, and that is we are creating a master data dictionary, and what we have done is we started out with the nine data sets that HCFA actually uses for Medicare, and we sort of put them all together, and we are trying to identify where there are like elements and try to rationalize the definitions of those, and as we move towards examination of the ANSI HISB inventory and begin to narrow down at least likely candidates for each of the standards we will, also, include all of the data elements in that particular standard in this master data dictionary, and that is to ensure consistency so that, for instance, race, ethnicity, if it appears in more than one standard is defined in a consistent manner.
As part of that we are, also, folding in the NCVHS core data set as Marjorie mentioned. Should there be issues that arise between implementation teams, for instance over how a particular element is defined, these would be brought to the infrastructure coordinating team for discussion and hopefully consensus resolution. If not, we would then elevate them to the data council or NCVHS for further discussion and resolution.
So, that is a quick overview of how we are trying to coordinate the activity from the HHS side.
DR. STARFIELD: What are the nine? You said that there were nine.
MR. MAYES: I can give you an overview, but I don't have the sets in front of me.
DR. STARFIELD: What are some of them?
MR. MOORE: One would be UB92, the 1500, what we have for eligibility with plans and those things.
MR. MAYES: Surprisingly enough we don't actually work off a master data dictionary in Medicare. I am sure that that comes as a revelation, but we haven't actually internally ever done that to my knowledge. So, this is a good starting point for us.
MR. MOORE: When we started doing this, Barbara, we were looking around. I talked with people at X12 about their dictionary and one of the things that we did was take what we had in house because a lot of the data elements are the same or we feel they are going to be the same regardless of where you get these transactions from. There may be other data that other people use since they are looking at national standards, but at least we had something to start with, and we can start identifying where it exists so that we can give off something to each of the teams when they look at the transactions.
MR. MAYES: And we have a contract set up to help us do that.
MS. GREENBERG: Actually the work that we did with the core data elements did a lot of it, didn't it, that contract?
MR. MAYES: The number of elements that we are looking at beyond the core data element is probably ten-fold.
MS. GREENBERG: No, no, the report that we had from the contract had a lot more than the data set.
MR. MOORE: But he used the HCFA 1500, the UB92, the X12.
MR. MAYES: All the same things that we have now.
MR. MOORE: In order to pull all this together. There must have been 12 different data sets that they used in order to make the comparison.
MS. GREENBERG: Bob, if you don't have a copy of that compendium report we should get it to you.
MR. MAYES: Yes, definitely. That would be very useful, just to be sure that we are not reduplicating efforts
DR. LUMPKIN: A question about the scope, states in implementing many of these kinds of issues, also, deal with welfare and AFDC, and look at eligibility. I know we are trying to do this in Illinois. We are trying to put together an information system that handles both Medicaid, as well as welfare eligibility. Are you looking at those quasi-medical WICK(?) eligibility, AFDC and so forth?
MR. MAYES: We do have members on the teams from the Medicaid Bureau and HCFA, and we have already had some comments from states that have come through that channel.
They have not yet gotten to the point. I think it will actually begin more this week once we have got the ANSI HISB, but that is a very important point and one that I think we need to stress to those groups that they need to look at the fact it is not only with the welfare-type programs, but I think it came up in the last set of hearings from the insurance industry that there are, you know we have to be aware that there is this kind of claims activity that takes place when you have a fire in your house, when you have an automobile accident, and we would certainly want to, I think, be sure that we took a look at the elements. This sort of goes along do we want to add one or two, but it would be kind of counterproductive to sort of not be able to be usable by such a huge segment of the health care industry.
DR. LUMPKIN: And, also, to the extent that we come across some standardization for gender it wouldn't make sense that one arm of HHS may use gender this way and another one would then say, "Now, we don't care what they did; you have still got to use it that way."
MR. MAYES: And this is the effort behind the master dictionary concept, and we, I can only, well, actually Bob can speak for HCFA, but certainly in the HCFA program, and I know we want to make sure this is seen as HHS and not HCFA, but since we do have major programs within HCFA that people identify with this process, we have committed ourselves internally and have had a number of discussions internally that we will be committed to making sure that Medicaid does not use a different set than Medicare, and I cannot speak for the rest of the agency or the rest of the Department, but that would certainly be our departmental position or something we would push.
DR. BRAITHWAITE: Council has specifically put out a philosophy that says that all Department agencies will follow these standards.
DR. LUMPKIN: And have Veterans Affairs and Ag been invited?
MR. MAYES: We have a number of people from the VA on our implementation teams. We, also, are getting a number of representatives from CHAMPUS, and we are pushing DoD Health Affairs, also, to join. So, we are trying to broaden our groups beyond HHS and with some success.
VA has been very interested. They have probably put 20 people or more on the different implementation teams.
MR. MOORE: John, on the welfare side we have of course on the Data Council welfare agencies represented. I don't know that we have anyone from the welfare side on our steering group or on the implementation teams. Maybe we could see if they would like to send someone, just so they understand what is going on in the area.
DR. LUMPKIN: I don't think I would be proposing piggybacking anything upon the transactions but just for consistency across --
MR. MOORE: Yes.
DR. LUMPKIN: Thank you. Other issues?
Shall we take a little break?
(Brief recess.)
DR. LUMPKIN: Let us get started. We have a slight change to the agenda. I think one of the messages that we as a Committee and I am sure HHS would like to get across is that since the passage of HIPAA there is a train that has left the station, and that train is in high speed, and it is on its way to its destination, and that this process is for real, that there are decisions that are going to be made. We don't expect there to be any significant roadblocks along the way, and so, we appreciate the various comments, but, also, we recognize that it is important for as many players as possible to weigh in with more than just general direction, and that is part of what we were trying to get to yesterday, but specifics as to which of the various standards that are out there work or don't work or where the problems are or what the recommendations were. So, Kepa, do you have a statement to read?
So, we are going to start off with that and then move to the panel.
DR. ZUBELDIA: Mr. Chairman, and members of the Subcommittee thank you for the opportunity to offer additional testimony today.
After yesterday's presentations the clearinghouses and VANS(?) members of AFFECT(?) would like to make a clear and unambiguous statement. We recommend that the Secretary adopt the NCPDP claim for pharmacy use and adopt the ASC extra standards for all other transactions. We recommend that the Secretary endorses and recommends that payors use commercial off-the-shelf EDI translator products and discourages the use of one-time custom translation programs.
These two recommendations we see as an investment in the future that will result in an increased use of health care EDI.
Thank you for this additional opportunity.
DR. LUMPKIN: Thank you. If you could perhaps give us a written copy of that, that would be useful.
DR. BRAITHWAITE: Or an electronic copy would be even more useful.
DR. LUMPKIN: And if, for instance, that group would like to submit any background material or supporting documentation on that recommendation, that would, also, be helpful.
Thank you.
We will now go on. I told you that there was a change to the agenda, but I didn't tell you that it was a very small, short change to the agenda.
Okay, the first item, Jeff Blair from ANSI HISB Inventory of Standards, and the document that is going to be discussed will be on the Web page or is already?
MR. BLAIR: Is not yet.
DR. LUMPKIN: Is not yet but will soon be. Thank you.
MR. BLAIR: Good morning. My name is Jeff Blair. On behalf of ANSI Health Care Informatic Standards Board thank you very much for inviting us to compile and create the inventory of health care informatics standards for the Committee.
Finally, we were able to deliver that. It is in the form of this binder and the diskettes that have been distributed to each of you. Why don't I just go directly to the agenda and Jean Narcisi who has been working very closely with me in compiling this document all the way through is immediately to my right, and she is showing slides for me.
For those of you who don't know me, I am blind. So, I have asked Jean to turn out all of the lights.
(Laughter.)
MR. BLAIR: This is going to be very brief because the essence of what I have to convey is in the document and diskette itself here, but I wanted just to briefly discuss the purpose, what it is and what it is not, the inventory of health care informatic standards, the scope, the profiles or templates that we used to develop each of the standard information that is in the inventory and of course, the acknowledgements.
So, first of all, with respect to the purpose, Jean, I am just assuming that you are in sync with me.
The purpose was to assist the Department of Health and Human Services in its process of selecting health care informatic standards in accordance with the mandate from the HIPA or is it two A's? How do you prefer it H-I-P-A or H-I-P-A-A?
PARTICIPANT: Two A's.
MR. BLAIR: Two A's. Thank you.
In order to do that the first thing that we tried to do was try to understand what might be your selection criteria. So, on our own we kind of did this, and we will show you some of the templates shortly, the profiles and templates that we used to gather the information.
We, also, wound up using the outline of the HIPAA law itself to develop the criteria which we would wind up addressing, and finally we have gone through this last several months in creating, assembling and formatting these profiles and templates for you. It is our hope that this would be a foundation which would be structured input into the actual selection, evaluation and selection process, that you would have comparable information or at least more comparable information than we have had up until now.
In terms of the supporting standards this wasn't really done or intended to be done with templates per se. For the most part these are discussions of those topics. However, within the code section we had a number of folks that voluntarily used the transaction standard templates and submitted information in that format, and those are included in the document as well.
I would add at this point that all submissions are included in this document. We didn't exclude anything from any source. So, although our initial mandate was to have it represent ANSI standards, if a particular developer of a standard or a code set or anyone who had useful information was not ANSI accredited, they, nevertheless, are included within the categories that are relevant for you to be able to use, and lastly we thought it was, also, going to be helpful if we began to introduce the concept of using frameworks, architectures and models as tools to promote the interoperability of standards.
In so doing we did create a separate template for frameworks, architectures and models. They are in the appendix, and there were several different submissions that as we go forward towards defining standards for our computer-based patient record systems, I think that that will become more useful.
Some of you, also, may feel like the health claim attachments, also, that that may be useful there, too. So, that is the purpose.
In terms of the scope, basically the table of contents of the document itself tends to mirror the scope. There is an executive summary, and incidentally, the way I have tailored your handout there is that after each of these transparencies I have gone ahead and inserted, for example, the executive summary follows the purpose.
Now, that we are beginning to discuss the scope, right after that you will see there is two and one-half pages of a detailed table of contents. We decided to make that more detailed so that you could find specific standards right there in the table of contents rather than have it abbreviated.
So, forgive the fact that it is two and one-half pages long there.
It has the second major section, of course, is the transaction standards. The third is the supporting standards and the fourth major section is the appendices. I think you can look through that without having me describe those things to you. We did have 29 submissions of specific standards within the transaction standard category.
Our next section in here is the templates. What we did on this is we created the templates, distributed them for comment, got a lot of comment back, made a lot of edits and essentially came up with a template that No. 1 is key to the category that is in the HIPAA bill, law, and identified the standard development organization or in some cases more liberally the organization that created the particular standard or code set, identified whether or not it is ANSI accredited, gave the name of the standard, the contact so that you can wind up if we need additional information, can identify the author of that particular template.
Then it goes into the more traditional areas of the description of the standard, indicators of market acceptance, and as you can see in the template there is a number of specific questions underneath each of these categories to prompt the author to respond to.
If I am out of sequence, jump in because I do not -- contrary to popular opinion, blind people do not have perfect memories.
Indicators of market acceptance is one major category. The next one, I believe is level of specificity. Is that correct? Okay, the next one after that I think is relationships with other standards, and I am leaving one out. Identifiable costs is the last one, but the readiness of the standard. Thank you, Bill. I think that is Bill. Did I recognize your voice? Okay.
So, basically that is the template. I know that you are going to be going into the process of identifying the criteria for selection. Hopefully this won't be too far from the criteria that you select and that this will be useful to you as you go through the specific selection process, and lastly, I would like to acknowledge there were so many people among the SDOs that are part of ANSI HISB and the other people that volunteered information. As you could tell from the 250 pages that are in the document there was a lot of work that went into this, but I specifically wanted to give acknowledgements to those that either wrote special sections or did coordination work. The names are there alphabetically listed, but in particular I wanted to give special recognition to Jean Narcisi for the hours and time that she spent actually receiving the templates from many of you and pulling that together for us.
So, I hope it is of value to you.
DR. LUMPKIN: Thank you.
Questions?
I know that in reviewing the various drafts of the documents that a number of sacrificial large plants in Washington State gave their lives for this project, but certainly it is worth it. It is truly a major contribution, and for those of us who are not up on every single standard it gives a nice reference source for us to be able to go back and say, "Oh, yes, that is what that coding set is and that is where that standard is," and to remember because contrary to popular belief chairs of work groups don't have perfect memories either, and it gets less perfect as I get older.
Thank you very much.
If there are no further questions, let us go on to the Panel on ANSI SDOs, and we will change the format. Yesterday we went from my right to left, and now we will go from left to right and start off with Jean.
MS. NARCISI: Thank you.
My name is Jean Narcisi, and I am Director of the Department of Dental Informatics for the American Dental Association. It is my pleasure to appear today on behalf of the ADA before the Subcommittee on Health Data Needs, Standards and Security of the National Committee on Vital and Health Statistics.
I would like to thank you for the opportunity to testify. My statement summarizes the views and concerns of the ADA in its standards development activities as it relates to the dental profession and electronic transactions of health information addressed by the Health Insurance Portability and Accountability Act of 1996.
As required under the Administrative Simplification Subtitle of the law, the Secretary of Health and Human Services is required to adopt standards for specified transactions to enable health information to be exchanged electronically. The law requires all health plans, clearinghouses and providers who choose to conduct these transactions electronically to comply with these standards. The dental profession will be among those who generate the information for these electronic transactions.
The following comments will address the questions we were asked to discuss, as well as any other issues that could be of concern to the dental profession.
In response to the first question, what are your organization's expectations of the results of the administrative simplification standards, the ADA expects that the requirements contained in the law will result in the establishment of the framework to make electronic data interchange a reality, to exchange business and health care information in a standardized format.
In addition, we believe that it will establish standardized processing methods associated with the transactions. Currently the percentage of claims submitted electronically by dental offices is very low. We have determined that this is due to the inability of third party payors to accept dental claims electronically. Because dental insurance represents a very small percentage of business for many third party payors, many payors continue to place a lower priority on electronic communications with dental offices than with physicians, hospitals and pharmacies.
Therefore, the results of the administrative simplification legislation should lead to the implementation of electronic solutions in many information problems that exist in dentistry today.
The ADA has been working towards the establishment of electronic solutions through development of standards for the dental profession. We believe that EDI will save costs by reducing handling and processing time. The risk of lost paper documents will be eliminated, and cost savings will be realized through the elimination of redundant functions in both external and internal environments.
One of the ADA's concerns has always been that standards developed for medicine may be adopted and then required for dentistry in a modified form rather than developed specifically for the needs of the dental profession.
The ADA has been actively participating with ANSI's Accredited Standards Committee, X12 for the past several years, and has been responsible for defining the data content as it pertains to dental claims. We strongly believe that data content decisions should be made by the ADA if they pertain to dental transactions.
The ADA has been committed to standards for many years and has sponsored a standards program for dental materials, instruments and equipment since 1928.
The development of standards is accomplished by volunteers under the auspices of the American National Standards Institute's Accredited Standards Committee MD156.
The ASC MD156 is an independent committee of ANSI for which the ADA serves as sponsor and secretariat.
In 1992 there was interest in standardization of clinical information systems. After evaluating current informatics activities, the ADA approved a group of projects relating to clinical activities and a task group of the ASC MD156 was created by the ADA to initiate the development of technical reports, guidelines and standards for administrative and clinical applications used in dental practice.
The primary goals of the ADA's dental informatics activities are to improve patient care and increase dental office administration efficiency. Components of the task group include five working groups for clinical informatics. The working groups were established to promote the concept of a dental computerized clinical work station and allow the integration of different components into one system in order to provide for all of a clinician's information needs.
Clinical information systems include all areas of computer-based information equipment, such as practice management systems, digital radiography and imaging, digital intraoral video cameras, digital voice text image transfer, periodontal probing devices, etc.
By establishing standards for these modules that serve the clinical needs of practicing dentists the need for several stand-alone systems in the dental office will be eliminated. Each ASC MD156 working group has been researching standards already in existence to determine if they could be applicable to dentistry.
Participants are, also, working with other standards developing organizations active in medical informatics in order to coordinate projects. The ADA, also, sponsors participation in ANSI activities of the International Organization for Standardization, ISO Technical Committee 106 on Dentistry and acts as secretariat for ANSI for Working Group 2 of ISO TC106.
Thus, the ADA works both nationally and internationally in the formation of standards for dentistry. In response to Question 2, does your organization have any concerns about the process being undertaken, we are pleased that the ADA along with the National Uniform Claims Committee and the National Uniform Billing Committee and the Work Group for Electronic Data Interchange were specified in the law for a formal consultative role.
The ADA appreciates the opportunity to work with the Department of Health and Human Services in the NCVHS, and we look forward to a continued and productive relationship.
The ADA's concern about the process being undertaken to carry out the administrative simplification requirements is that the decision makers may not fully understand the significance of ANSI standards. The ADA believes that where ANSI standards already exist those standards should be adopted. The ADA is a member and very supportive of the work of the ANSI Health Informatics Standards Board, and we were, also, a member of its predecessor, the ANSI Health Informatics Standards Planning Panel.
The HISB aims to achieve a unified set of non-redundant and non-conflicting standards that will be compatible with national and international standards. The HISB inventory of standards document pertaining to the law that Jeffrey Blair just presented includes some of the ADA's standards activities. However, I would like to further explain some of the projects we have initiated and are coordinating with some of the other SDOs in order to prepare the dental profession for future electronic administrative and clinical applications.
As I mentioned previously, the ADA has been working with X12 in order to define the data content placed in the electronic envelope used to transmit data for dental claims. Because there was no standardized method of implementing the X12 837 transaction for dental claims, the ADA developed an implementation guide based upon the 837 to assist practice management vendors, third-party payors and clearinghouses in the execution of the standard transaction for dental claims.
At the time we developed the guide, X12 had not begun its work on the development of implementation guides for any of the transactions. The ADA was one of the organizations that urged X12 to initiate the process of developing implementation guides for all health care transactions in order to promote uniform implementation of the transactions and obtain widespread acceptance of electronic standards.
Now, that the process of implementation guide development has been initiated within the X12 environment, the ADA will continue to work with the X12 to provide the data content for all dental applications.
The ADA holds a vision of seamless data transfer throughout all facets of health care, independent of profession, discipline or specialty. The ADA further believes that a seamless data interface among systems serving private practice, academia, research, industry and government programs will offer significant benefits to all system users.
Therefore, the ADA has begun the establishment of the basic content elements of a computer-based oral health record, the COHR. The objective is to develop COHR features that offer the greatest utility to the profession as a whole, address issues of open architecture and will be technology independent.
The baseline version 1.0 of the COHR concept model which includes the business process information and data rules was released by the ADA in 1996. While the process and data models described in the COHR were specific to dentistry, the models were developed with the understanding that dentistry is a microcosm representative of the entire health care environment.
The COHR was developed as a progression of analytical models founded on clinical and public health principles. It described the health care environment, the fundamental process of health care delivery and the data needed to support these methods. The COHR concept model was subsequently converted into a logical data model by the ASC MD156 and includes the data management specifications which could then lead to a physical data model, for example, a vendor-specific implementation.
The logical model was expanded and modified through consensus of subject matter experts. This modification evolved the COHR logical model into a generic clinical data architecture for patient health care information independent of health care profession or delivery environment.
The ADA's document which is referred to as the ADA 1000 is a framework for the specification of a clinical data architecture, and it applies to the application data interface of a health care information system. A diagram is attached to the written statement as Appendix A which describes an architecture of the health care information system. The ADA 1000 could be used to guide the development of databases for patient information in computer-based patient records and other applications.
The ADA 1000 has been approved by the ADA and is currently undergoing the consensus process for future approval as an American national standard by ANSI. The draft ADA ANSI 1000 is being coordinated with other SDOs, and no overlap or conflict exists since the relevant standards apply to other levels of the architecture of the health care information system.
Harmonization is currently under way between DICOM, ASTME 31, X12, NCPDP, HL7 and the relevant ISO standards. The result of the ADA's work will be a standard or a blueprint against which commercial vendors can build their databases and interfaces for passing data among various systems.
In response to Question No. 3, what major problems are experienced by the members of your organization with the current transactions, the ADA is very supportive of the intent of the Act and believes that most of the transactions specified under the law are appropriate.
However, the majority of the current electronic dental transactions are being transmitted using proprietary formats while only a very small percentage of electronic dental claims are transmitted using the newly developed X12 standards.
Therefore, the ADA encourages that electronic dental claims transactions continue to be submitted in the current electronic formats with a migration to require X12 formats only.
The X12 837 is the only approved ANSI draft standard for trial use in existence for dental claims at the present time. However, the X12 interactive claims standard will soon be finalized and when approved it will be the preferred standard to be used for dental claims transactions.
The ADA supports the adoption of standards for the financial and administrative transactions listed in the law except for regard to health claims attachments. The ADA believes attachments are not needed in dental claims transactions as only administrative data are necessary to process the claim. Standardization of claims attachment information should be limited to a well-defined set of possible attachments and eventually eliminated as a requirement.
If the claims transactions consisted of uniform data content and the third-party payors were required to standardize their processing methods, attachments could be eliminated. Claims attachments as specified in the law are not synonymous with the patient health records or detailed clinical information. Though some attachment information may be derived from patient's clinical record, while the ADA is fully supportive of the ongoing efforts to develop a computer-based patient record and we are active participants in the development of such standards, we believe this is an issue separate from the insurance transactions currently being considered by NCVHS and beyond the mandates of the law.
With respect to the availability of the information that the generators of data need to provide for transactions and how meaningful the information is from a clinical perspective, dental claims data in its current form does not provide researchers with the ability to study treatment patterns and the outcomes of care.
Only the service provided to the patient and not the condition being treated is reported in a dental claim. Therefore, the ADA is concerned that the administrative simplification legislation will reach beyond its core focus of administrative and financial transactions and seek premature standardization of clinical transactions for the computer-based patient record and supporting code sets.
Although the ADA believes that a comprehensive clinical coding system is essential for the computer based patient record, we do not believe that CPR coding issues should drive the code standards for the claims transactions.
Recognizing the need for standards in clinical terminology and limitations of the current coding systems, the ADA engaged in the difficult task of creating a clinical terminology and coding system which will provide the profession with comprehensiveness and varying degrees of utility.
We are currently developing a micro glossary of the systematized nomenclature of medicine, SNOMED, so that patient history, findings, services and outcomes can be represented accurately. In addition, we are developing a comprehensive glossary of the dental terms.
Standardized terminology must have explicit definitions. A collective guide is important for consistent interpretation of terms by the profession and aggregate data analysts.
This work is being paced accordingly with the other agencies of the ADA involved in the development of standards for the computer-based oral health record and the computer-based patient record.
While standards for administrative transactions are essential to streamline claims processing, electronic patient records need to be developed for optional patient benefit with assurance of confidentiality safeguards.
The ADA recommends that the Secretary move forward with the adoption of current ANSI standards for the specified transactions in the law. However, adoption of standards for clinical transactions and supporting code sets should be deferred until the appropriate frameworks, data dictionaries, cross mappings and harmonization of the current and proposed standards can be fully developed.
Furthermore, the ADA believes that the ANSI HISB should be assigned the responsibility for the coordination of the computer-based patient record and other clinical standards.
In summary, the ADA would like to emphasize its shared commitment to advancing standardization and administrative simplification. The following points summarize our statement and recommendations for achieving the goals intended by administrative simplification. The X12 format should serve as the standardized messaging format or envelope used to transmit data electronically, and the uniform data content should be the responsibility of the ADA, NUCC and NUBC. The association recommends submission of electronic dental claims transactions in the current formats, both proprietary and X12 formats with a migration to mandated X12 formats within a stated period of time.
Uniform implementation of the standards must, also, be required in order to expect favorable outcomes. The health claim attachment information should be limited to a well-defined set of possible attachments and eliminated as a requirement as soon as possible for dental claims.
While the ADA is fully supportive of ongoing efforts to develop a computer-based patient record, and we are active participants in the development of such standards, we believe this is an issue separate from the insurance transactions currently being considered by NCVHS and beyond the mandates of the law, and finally, the ADA recommends that the Secretary move forward with the adoption of current ANSI standards for the specified transactions in the law. However, adoption of the standards for clinical transactions and supporting code sets should be deferred until the appropriate frameworks, data dictionaries, cross mappings and harmonization of the current proposed standards can be fully developed.
Furthermore, the ADA believes that the ANSI HISB should be assigned the responsibility for the coordination of the standards for the computer-based patient record.
Thank you for the opportunity to present our perspectives on issues associated with administrative simplification. The ADA looks forward to a continued and productive relationship with the NCVHS and the Subcommittee on Health Data Needs, Standards and Security.
DR. LUMPKIN: i would like to thank the ADA for their oral testimony. I couldn't pass that up, sorry.
MS. GREENBERG: Bridge over to Edna?
(Laughter.)
DR. LUMPKIN: Yes, please?
MR. HAMMOND: My name is Ed Hammond, and I would, also, like to thank this group for the opportunity of appearing before this Subcommittee as a representative of another ANSI approved standards development organization, Health Level 7. I currently am the chair of Health Level 7.
My virtual job is at Duke University, and there I am the developer of a clinical information system, and I have really been doing that for almost 30 years now, and I, personally, have implemented HL7, ASTM, X12 and NCPDP standards and am involved in implementing a DICOM(?) standard, and I can assure you there is no better way of becoming intimately acquainted with a standard and wishing that the people that wrote the standard had the requirement to implement it than doing it yourself, a new view of what is happening.
Health Level 7 is in its 10th year of developing data interchange standards. The domain of focus is the exchange of clinical data and related areas, and those related areas deal with what we think is necessary to support the industry at large and the members of HL7.
The current membership of HL7 includes approximately 400 organizational members and over 1600 individual members which represent the community of vendors, consultants, health care providers, professional organizations and just interested individuals.
Approximately 90 percent of the vendors in the clinical information system market offer the HL7 interface, and if you look at most hospitals or clinical systems that do any kind of interfacing of data systems you will find HL7 is the standard that is in use.
On the provider side HL7 interfaces are defined in most requests for proposals. The most recent working group meeting that was held in Tampa which might have had some influence on its attendance had over 350 people in attendance.
HL7 has met jointly with and has letters of understanding with ACR NIMA(?) DICOM, ASC X12 and ASTM, IEEE Medics and the MBI, MIB and the NCPDP.
HL7 has established working relations with CORBAMED(?) and the OMG with CPRI, WEDI and others including the ADA and some of the other groups that are beginning to be increasingly interested in standards activities. HL7, also, works internationally. We have join meetings with exchange of members with the European Technical Committee on Medical Informatics.
We currently have a formal process with international affiliates, with affiliates in Australia, Canada, Finland, Germany, the Netherlands and New Zealand and a large number of other countries that are listed that have indicated an interest in HL7. Version 2.2 has been translated into five languages.
Version 2.2 of HL7 standard was the first ANSI accredited American national standard in the health care domain. Version 2.3 has just completed its final balloting cycle, and this version includes a considerably expanded clinical domain including admission, discharge, transfer, patient administration documentation, orders, result reporting, clinical observation, medical records management, transcription, scheduling, clinical trials reporting, adverse event reporting, financial and the standard itself does include UB92 and HCFA 1500, automated waive(?) forms, patient care and other areas.
I would like to address specifically the questions that were sent to me, and I recognize the fact that you have had other groups testifying before you on behalf of HL7 and as best I could I am trying to not repeat some of that information that came to you.
The Health Insurance Portability and Accountability Act of 1996, will potentially have the greatest impact on health care information systems and consequently on what those information systems will do than any other act thus far.
I think it is interesting having been excited about the emphasis in 1992 on health care reform and seeing what that really began, and things have died out just a little bit, and I think that this Act itself has really inspired that increased interest, and I think accelerated the process of dealing with some of the issues that are before us.
Beginning in the mid-1980s, the market alone created an interest in defining standards which would encourage the integration and exchange of data among various systems and organizations and reduce the costs and effort of those interchanges. In HL7 that initial interest was driven by some of the niche or departmental systems, but over the years with users having an influence expanded to include essentially all the vendors in this area. The process was slow. Convincing competitors to work together and to share proprietary information takes time.
Clinical information systems, including hospital information systems, laboratory systems, radiology systems, pharmacy systems and others were largely independent from the accounting system. Driven by a need to solve a specific problem, several standard development organizations were created and developed standards within that area of interest, and at the present many health care provider organizations support the suite of standards as necessary, and I indicated at Duke we are supporting most of the existing standards.
The distinction between clinical and accounting systems is rapidly disappearing. Care must be taken to ensure that the standards recommended by the NCVHS and the DHHES are not limited in vision and accommodate clearly defined clinical data interchange standards as well as the standards which support the business requirement relating to benefits, claims and reimbursements.
I might say that as I listened to Jean make her talk I found that while I was in agreement with almost everything that she said, you are going to hear me say almost the opposite, and I still think I agree with both sides of this. I think these are different interpretations of the same issue and different ways in which you can go, and I can appreciate how challenging that really makes your job of understanding and working through this.
The most effective standards are created by the experts in the field, and I think if you look at the different kinds of standards and see where the efforts are being put in you can appreciate that. Creating image standards is best done by individuals knowledgeable in the technical and in the clinical applications.
Creating clinical data interchange standards, I think, is best accomplished by the vendors' and the health care providers' experience in what is required and how to do it.
HL7 expects NCVHS to be visionary in its recommendations and the broader domain of standards that it recommends in order to meet the requirements defined in Public Law 104191. The attachments mentioned in the bill in the broadest sense will be the clinical record or components thereof, and you are seeing one of the conflicting statements, and it depends, and we probably don't have an accepted definition of a clinical record. Therefore, it is not surprising that we may have a different take on that.
The data required for performance evaluation, the things that NCQA ways and the JCHO and the quality assurance clearly is increasing in its clinical content. An increased interest in decision support and knowledge management, and I think that is one of the more important things of what we are trying to do to contain costs will clearly require the unambiguous exchange of clinical data elements. The NCVHS has an opportunity to cut short the time and cost of identifying and producing these standards by recognizing and acting on this data at the present time.
Finally, we expect NCVHS to anticipate changes in technology and how these changes might affect data interchange standards. HL7 is currently developing an object-oriented reference information model which will be used to develop version 3.0 of the standard.
In 1996, HL7 invested over $100,000 of its own money to complete the definition of the new methodology and to provide a foundation model upon which the organization can build. Already commercial systems are being developed to provide object requests, brokered messages using QUARBA(?) and OLE(?) active 7 in addition to text messages.
HL7 has recently created special interest groups in security, privacy and confidentiality which will define the requirements for authentication for sending HL7 messages, encryption at multiple levels and probably encryption within the message as well as encryption of the outside levels of the messages, digital standards as well as being able to convey the requirements, the confidentiality requirements that the sender needs to convey to the receiver so that the receiver knows how to deal with these levels of confidentiality, secondly, a standard generalized mark-up language. For those of you that SGML is an unfamiliar term, HTML is an instantiation of SGML, and this is a broader approach, and the activities here will support event-driven data sets within HL7 data exchange messages, and another effort that I think has great significance, and this is of a vocabulary effort that is an open effort which will define a UMLS-linked vocabulary set that will be clinically based and finely grained to permit an understandable and unambiguous way the exchange of clinical data in HL7 messages.
In other words what we are proposing to do is to take each of the HL7 messages, look at the data element and define the set of vocabulary that would be appropriate for that case.
Fortunately with the work with the domain information model and the reference information model, the vocabulary effort can be interactively in a bidirectional way be compared with the model and both of these directing the development of both the model and the vocabulary, and we have, also, discovered the fact that a use case is very important in understanding exactly what vocabulary terms need to be.
If you are talking about vocabulary in the absence of how it is going to be used, it is very difficult to define an unambiguous and acceptable and explainable model.
For example, if something as simple as gender, if I am using gender only as an administrative term, then male and female are probably adequate, but if I am using gender to transmit clinical information then there are probably six or seven terms that have clinical importance, and so, you can see the fact that divorcing vocabulary from the use case gives rise to some degree of ambiguity.
I think that it requires little imagination to see that this new technology may well serve the need of financial data exchange as well as clinical data exchange, and we urge this Subcommittee to recognize the importance of other related standards.
Interoperability without negotiation requires that we define the options at all levels. It is likely that most data interchange for whatever purpose by the turn of the century will use the Internet intranet technology. Identified standards must be compatible with this technology, and we think that this Subcommittee needs to look beyond the obvious data interchange standards, but specify standards at other levels as well. An important organization is the Internet Engineering Task Force, and I don't know whether that is on your menu to be invited, but we would suggest that that group might discuss its activities with the Subcommittee as well.
In response to Question No. 2, in general HL7 supports the stated process of carrying out these requirements. We do, however, have concerns that DHHS and NVCHS fully understand the varied set of issues and consequences of the decision, and I suspect that you will find that comment coming from almost every SDO and anybody who has spent lots of time and energy in this area because it is not a simple process, and understanding what is trying to be accomplished by the standards and how you get there I think is very important.
From a market perspective the millions of dollars which have been invested in existing standards and the work in creating those standards which are workable should not be ignored.
The work of the experts which was required to produce those standards should be recognized, and changes to standards contents should be made with caution. Standards, also, require maintenance, updating and distribution. HL7 has worked with a number of organizations to be able to accomplish this including the VA, the CDC and HCFA.
Committees making these recommendations have varied levels of understanding of the standards process. I think the members of the Committee should be educated insofar as possible so that informed decisions can be made, and finally I would stress the importance of easily accessible and freely distributed standards must be appreciated.
What problems, question No. 3. The HL7 standard has evolved over five versions of the standard. The evolution was initially driven by developing the technology of the standard itself and by meeting the immediate needs of the members of HL7. In time HL7 has reached out to address other domains of interest and continued to address the more complex issues of the exchange of data.
In some ways HL7 could be defined as a just-in-time standard. Rather than setting up and designing the perfect system, what we have tried to do is to anticipate the capability that technology affords us in understanding the needs of the marketplace and our members to be able to move the standard along to address those.
Backwards compatibility is an issue which must be fully understood by this Subcommittee. The balance between the economic stability provided by backwards compatibility and taken advantage of new technology, a better understanding of what is required by the standard and experience gained in using the standard is a critical one.
HL7 provides a general framework to exchange most clinical data. Lack of a common reference model, common data elements and a common clinical vocabulary currently mandate negotiations between systems that wish to exchange data, and HL7 is moving ahead as I noted to solve these problems.
HL7 recognizes the importance of unique identifiers for persons and organizations of a comprehensive clinical vocabulary, of a common data model and of acceptable and realizable solutions to security, privacy and confidentiality. We are committed to working within HL7 and with other groups to provide and implement solutions to these problems.
Data quality, an area in which there is neither a method of assuring data quality or metrics for measuring data quality have been defined. It is extremely important in making the data that is exchanged usable and acceptable. If people are going to make decisions based on data that is exchanged from another group, the integrity of that data has to be ensured. We have to learn how to do that, and finally, question 4, the business needs of the stakeholders are best met by having clearly defined standards which are used and supported in the marketplace.
Consensus standards while painful and time consuming to achieve are important in representing and meeting the needs of a broad community. The academician in me has sort of wondered about the question, do consensus standards produce the best standards or the safest standards, and I think that is an interesting question that could be debated sometime.
With consensus standards, health care provider needs are balanced against vendor competitiveness. The interfaces in the marketplace have dropped from tens of thousands of dollars to the thousands of dollars range. I think what we can do and must do is to continue to drop the cost of the interface into the hundreds of dollars range.
Organizations requiring reporting through the use of a standard must comply with a standard. The cost of dealing with state-level variations in the content of a standard, the HCFA 1500 and the UB92, for example, is very costly. One organization estimated the cost on the order of $600,000 a year in simply dealing with variations of a standard, and so, what I urge this Committee to do is to try to put teeth in what is recommended that the standard mean what it says, that it actually accommodates the needs of the users of that standard but make sure that you don't destroy the value of the standard by permitting these local variations.
It is important to note, I think, that no one standard organization at the present time provides the expertise to address all the needs of health care. We recognize the value of the other standards development organizations and have worked very closely with them. In some cases the domains are clearly independent. In other cases the domains seem to have common purposes, but if you look at the understanding motivation for developing that standard, you can see the distinction within the standard itself.
I think that several existing standards will prove to be effective in the marketplace, and finally, I urge this Committee to be very explicit in what its recommendation is.
If you are recommending a standard for one piece of this whole field that I have talked about, then make it very clear that that is what you are doing.
If you deal with the broader issue, then I think it is very important to define what standards you are recommending for what particular types of application.
Thank you very much.
MR. STANIEC: Good morning, Dr. Lumpkin, members of the NCVH Subcommittee. Thank you for this opportunity to present the recommendations of the National Council for Prescription Drug Programs, NCPDP, an ANSI-accredited standards development organization. I am Dan Staniec. I am a registered pharmacist. I am a staff member of NCPDP, unlike Ed here who works for Duke. I am the NCPDP Executive Vice President of External Affairs.
I am a member of several pharmacy organizations, including the American Pharmaceutical Association, National Community Pharmacists' Association, the Academy of Managed Care Pharmacy, as well as ASC X12, HL7, the Work Group for Electronic Data Interchange, WEDI, the Health Informatics Standards Board HISB, and a participant at UNEDIFEC(?) meetings.
I am, also, a board member of the Computerized Patient Record Institute and the University of Arizona College of Pharmacy. Before I begin to address the four questions that you specifically mentioned, I would like to give a brief introduction of whom NCPDP is.
NCPDP is the only ANSI-accredited standards development organization for the pharmacy services sector of the health care industry.
Our ANSI-approved scope statement reads, "The scope of the standards that NCPDP develops are those for information processing for the pharmacy services sector of the health care industry."
Regarding the development of pharmacy standards NCPDP is the forum whereby the pharmacy industry meets four times per year to develop standards. Our 1292 members are employed by organizations in virtually every type of pharmacy organization in the United States.
Some examples of these types of organizations include chain pharmacies, independent pharmacies, drug manufacturers, Blue Cross Blue Shield organizations, federal, state agencies, health maintenance organizations, pharmacy benefit management companies, telecommunication and system vendors and wholesale drug distributors.
Our membership consists of three specific categories, with a fairly equal number of members in each category. These categories are, the first one is the providers and producers of which we have 353 members. The second group is the payors and the processors. We have 497 members, and finally in category No. 3 we have the telecommunications system vendor general interest category with 436 members.
As you can see NCPDP does represent the voice of pharmacy in the standards development arena. Our membership is extremely vocal and assertive which is evident by the fact that NCPDP members' lobbying efforts successfully placed NCPDP in the Health Insurance Portability and Accountability Act of 1996.
NCPDP will be celebrating its 20th anniversary next week during our annual membership conference. Over 800 NCPDP members will be in attendance. It is, also, important to note that over 300 NCPDP members meet three other times throughout the year during our technical work group meetings.
A number of our work groups have over 100 members present to develop standards and not just a few. This is true consensus building. We have submitted NCPDP's version 3.2 to ANSI to become an American national standard and look for this transaction to be one of the first health care transactions being considered by this Committee to be awarded this honor.
Question No. 1, what are your organization's expectations for results of the Administration's simplification standards requirements in HIPAA?
NCPDP's expectations for the results of the Administration's simplification standards requirements in the HIPAA center around the entire health care industry.
The Administration's simplification standards requirements will accomplish five goals for pharmacy. The first goal, the relative cost to the entire health care industry for claims payment will decrease significantly. The pharmacy services sector of the health care industry is the most automated segment of this industry with over 95 percent of all claims filed electronically.
This impact to pharmacy's cost will be minimal because are already there. The second goal, the ability to interconnect with other standard development organizations in the creation of a health care network can become a reality and not just a vision.
NCPDP has had two successful pilot projects with ASC X12,with their 834 and 835 business transaction data sets. Also, NCPDP is working with HL7 by cross mapping two of our standards that connect the physician and the pharmacist electronically.
Rule No. 3, the development and adoption of identifiers by the Secretary will greatly improve the pharmaceutical industry's ability to complete clinical type services such as drug utilization review and professional pharmacy services. A unique identifier for providers will help solve this dilemma. NCPDP fully supports and has already endorsed the HCFA NPI effort. NCPDP, also, has a dedicated work group called work group 3 standard identifiers for this area.
Rule No. 4, the security of the standards is paramount in importance. Currently we are utilizing closed or private networks along with proprietary payor information in order to maintain security. This process has been widely utilized and has been successful. However, we do realize that new security measures will need to be developed as various areas of health care begin to communicate.
Our major concern is the potential cost of implementing these new security standards, and finally, Rule No. 5, the overall quality of health care for the United States' population will increase.
From a historical perspective 15 years ago pharmacy had the same problems that other health care segments are having now. There was a plethora of paper forms that created administrative nightmare for the pharmacist to complete in order to be properly reimbursed for a pharmaceutical claim.
I remember as a pharmacy intern when I was in the College of Pharmacy I would spend all afternoon handling all the third-party rejects with all the different types of forms, and it was very difficult.
NCPDP was created to standardize one form, the pharmacy universal claim form. That resulted in over 1 billion paper claims in the early 1980s.
In 1987 and later on this universal claim form evolved into a standard format for on-line, real-time adjudication of pharmacy claims which has evolved to the current NCPDP's telecommunications claims standard version 3.2.
NCPDP recommends the use of our standardized electronic claim format between pharmacy providers, insurance carriers, third-party administrators and other responsible parties. This standard addresses the data format and content, the transmission protocol and other appropriate telecommunication requirements and was developed to accommodate the eligibility verification process at the point of sale and to provide a consistent format for electronic claims processing.
The standard supports the submission and adjudication of third-party prescription drug claims in an on-line, real-time interactive environment.
NCPDP standard fulfills the unique needs of prescription benefit programs that allow pharmacies to submit the claim during the dispensing process. As a prescription record is being completed in the pharmacy system, the NCPDP standard claim is transmitted to a multitude of payors, and usually within 20 seconds a response is returned with the claim fully adjudicated.
The selection of NCPDP's version 3.2 will allow the state-of-the-art communication standard to continue.
Over 8000 prescription drug benefit plans support on-line, real-time processing and pharmacy systems are engineered to exacting response time standards. A recommendation of this Committee for any standard other than our own standard with NCPDP current on-line interactive claim is counterproductive to the progress of the last 9 years. NCPDP would like to see emphasis in other areas such as drug utilization review, patient education, disease management and electronic communication with other health care providers.
Regarding question No. 2, does your organization have any concerns about the process being undertaken by Department of Health and Human Services to carry out the Administration's simplification requirements of this law, NCPDP is very pleased with the process that the Department of Health and Human Services is making. We hope that they continue the process of open dialogue available through the ANSI Health Informatics Standards Board, other SDOs, WEDI and associations like the National Association of Chain Drugstores, the National Community Pharmacist Association and the American Pharmaceutical Association.
NCPDP hopes that this process continues into the future in order to satisfy the needs of the pharmaceutical industry. Regarding question No. 3, what major problems are experienced, as I mentioned earlier, the NCPDP standard for electronic claims meets pharmacy's current needs.
The NCPDP standard has proven successful for over 9 years by continually changing and growing to accommodate the needs of the pharmaceutical industry. The following highlights the degree of utilization of NCPDP's telecommunication claims standard: Forty-three state Medicaid agencies, 54,000 pharmacies in the United States, 90 payors representing 8000 plans. The total number of on-line transactions in 1996 was well over 1 billion, and prescription claims for over 100 million Americans in 1996 were submitted using this format.
The generators and the users of the data receive the necessary information from the NCPDP standard to fit their business needs. Business needs drive the ever-evolving NCPDP standard.
NCPDP has a dedicated staff that distributes standards to our members.
Final question, question No 4, how can the goal of the Administration's simplification best be achieved while meeting the business needs of all stakeholders? You can obtain this goal by continuing your current process of meeting with the different segments of the health care industry. NCVHS needs to recommend proven tested standards that have wide implementation. Interoperability will allow pharmacies to communicate with other parties. They use other standards and syntaxes if business needs arise.
Standardization should take place at the data content level including data dictionaries where there should be no variability. Conversations have already begun between NCPDP, ASC X12 and HL7 so that translators can inexpensively convert from one standard syntax to another standard syntax ensuring interoperability.
Variability can cost effectively exist between different syntaxes. Interoperability is the key to maximize communication opportunities. ASC X12, HL7 and NCPDP are currently investigating migrating from its current syntax to an object-oriented technology.
In conclusion the vision of Administration's simplification is cost effective communication. It is estimated that forcing pharmacy to move from the NCPDP standard syntax to a UN or X12 interactive standard syntax would cost pharmacy approximately $200 million, and pharmacy would not be buying any additional benefit. NCPDP would like to thank you for this opportunity to present our recommendations, and we would like to offer any assistance to NCVHS at your request.
Thank you.
MR. BARRETT: Thank you, Dr. Lumpkin and to the Committee for the opportunity to speak with you this morning. I have submitted my written testimony answering the questions that have been put forward, and they are there.
What I am going to be doing for the next few minutes to address the Committee is to focus on four key points that I thought were important.
You have heard from a number of different organizations of my peers, as well as others that you have had addressing the issues, and many of them that I am addressing as well in my testimony you have heard, and you are going to continue to hear.
The four points that I wanted to focus on, the first was really to address the Accredited Standards Committee X12 and the American National Standards Institute process or the ANSI process.
As you may already know, ANSI does not develop, itself, standards. However, they accredit other organizations to develop standards through various designations such as Accredited Standards Committees or ASC or Accredited Standards Organizations, ASO and some other designations.
They foster a process of consensus building and private and public sector involvement and a structured process of approvals and quality assurance. So, it is very much a formalized process that they are going through in accrediting different organizations, such as NCPDP, Health Level 7, X12, etc., to develop the actual standards themselves.
Now, X12 itself or Accredited Standards Committee X12 operates under the same principles as do my peers of the other standards development organizations.
What we do is we develop what are called draft standards for trial use. These draft standards for trial use are formalized standards and are used across the industry and are used for some period of time before they are moved forward into the ANSI process to become what are called American National Standards or ANSs.
One thing you can definitely do out of probably this Committee is you have definitely gotten a tremendous education on acronyms. The other thing I can tell you is that the standards development process, at least within X12 can take anywhere from 1 to 3 years to get a standard through the entire process. It depends upon the complexity of the standard, and again, after they have gone through and they have become draft standards for trial use we then move them forward into the formal process of becoming American national standards.
X12 itself has over 800 member companies. It is made up of public, private sectors. It, also, has 11 different subcommittees that make it up representing a broad base of constituencies, government, finance, warehousing, insurance, banking just to name a few.
So, it is very much an overall coalition, and they have been designated to develop specifically by ANSI electronic data interchange standards for those particular industries. Now, going on, I guess in relation to the make-up of X12, what we do in relation to getting our business requirements, many people will ask me, "Well, do you have very much a good constituency where you are able to get business requirements from the industry brought forward, especially in relation to health care?" and the answer is yes. We are working with a number of different organizations, including the Health Care Finance Administration. We work with the National Uniform Claim Committee, National Uniform Building Committee, Work Group for Electronic Data Interchange, the ADA and others, as well as many of the standards development organizations here and as Ed mentioned we do have agreements with several of the organizations, and we are working towards getting even more of those in place, and we found, I think that the informal relationships, the informal agreements that we have forged between the standards development organizations have worked extremely well, as well as working through the Health Care Informatics Standards Board in relation to harmonizing a lot of our activities.
I think a couple of key areas that we are trying to work towards, I think as organizations that many of us talked about is the issue of building a common data dictionary as Ed was talking about, the issue of gender, as well as developing some more common data content among our standards so that in fact, we do get a better, I will say coordinated effort rather than having different definitions.
So, those are some of the areas that we are working through. I think the other thing to try to dispel is the fact that X12N is just not a complete group of technologists that that is all we are doing, but in fact we do have public and private sector involvement from a number of different constituencies that are providing input, feedback into our process so that they can be the best we possibly can, as well as we are going out to those other organizations that I mentioned to gain their business requirements moving forward.
Now, what have we developed? Gary, if you can put up a couple of the overheads, and again, these were in your package. What I wanted to explain to you is that the process that we have within X12N is, in fact what we have been trying to do to develop business models, as my peers are, also, in the process of doing.
In putting together a health care business model, it is kind of tough from up there to see it, but the business model that I am trying to depict here is that we have looked at it across providers, the insurers and payors, as well as sponsors or employers, trying to look at the model in relation to what transactions are going to be needed in between those organizations and trying to develop the business model that defines it and the business requirements that certainly detail it.
Based upon that business model, what we have done is we have developed then a number of transactions that are outlined in the administrative simplification legislation.
Gary, you can go to the next one.
We have transactions ranging from the health claim which is the 837, we have, as well attachments which is the 275; we have enrollment and disenrollment which is the 834, eligibility, the 270, 271, and we, also, have interactive eligibility which is the interactive health care eligibility benefit inquiry and benefit response, and then we, also, have the health care payment and remittance which is the 835, the health plan, the premium payment, the 811 and 820, first report of injury, the 148, the claims status, the 276, 277 and the referral certification and authorization, 278, and you may ask, "How do you come up with these numbers?" We have a tremendous dart board with a variety of numbers, and whichever one is not picked, we used that, but that is the nomenclature that is used within X12 in relation to the numbers. So, we have addressed, based upon the business model that has driven us in relation to the business requirements that we are using to develop those particular standards.
MR. BEATTY: Excuse me, on your attachment, you have health claims attachment 277. Is that an error?
MR. BARRETT: Sorry, it should be 275. Thanks, Gary. The third point that I wanted to make was in the area of EDI globalization and X12.
As I said to you the X12 standards that we are developing which are American national standards and initially draft standards for trial use tested out here. Also, X12 is, also, the conduit for any of the requirements and transactions or messages which get funneled to the United Nations EDIFACT(?) Board, international development of standards.
What we try to do then is X12 is to try to act as a conduit to leverage a lot of the data content in the standards that we are developing here to, in fact, be used in the development of EDIFACT standards, and so we get a lot of the leveraging of the data content as well as a lot of the technology and a lot of the expertise and knowledge base, and that goes two ways, between EDIFACT, the international side, as well as what we are doing here locally, and finally, I would say that the area in which we are trying to work on and we have been working with a number of those organizations I mentioned before, the Work Group for Electronic Data Interchange, WEDI and others, and what we are trying to do is resolve some of the issues that are outstanding.
One of them has to do with, for example, the 837, the claim itself, and what we are doing is we are putting together with a number of different organizations a meeting to take place later in March of major constituencies to address and discuss the issue of the 837 versus that of say the national standard format, and so, we are trying to then out of that reach consensus and to bring those recommendations forward to this Committee as well.
We are, also, discussing out of that Forum that we want to have, the 2-day forum, we want to discuss the pharmacy transaction and as well to try to bring consensus regarding some of the issues surrounding pharmacy to this Committee as well, working with NCPDP and others.
So, really what we are trying to do overall in relation to I will say finally the implementation guide issue which you have heard a lot about is that we have spent significant time and energy on the part of X12N, and we are working with HCFA and a number of different constituencies to try to meet time lines, and we will meet the time lines that are outlined here so that we can bring those implementation guides forward. Those are absolutely key. They are as I looked at last week, and I was reluctant as Chair of X12N, I said that really this is the year of implementation, and really that is our focus, and that is what we are trying to do to support the Committee and the business requirements that you have outlined.
So, with that I thank you very much for X12N to be able to participate here.
Thanks.
DR. LUMPKIN: Thank you.
DR. IEZZONI: Thank you for your presentation, Mr. Barrett. Can I just ask you how you are going about thinking about the clinical content piece that you mentioned? Who is involved in that? What are you thinking?
MR. BARRETT: On some of the clinical content piece what we are doing is, again, we are talking to a number of constituencies. We have got, for example, the, having the NUCC and the NUBC, we are trying to work with EMAY(?) and others. We are working with HL7 on some of the clinical pieces that they are trying to bring forward. We are working with, as I said, AMA, the ADA, as many provider organizations as we can possibly get involved and others. We are working with CPRI, Computer Patient Record Institute, Margaret Imatako(?) to try to get their requirements brought forward. Those are the organizations that we have solicited as well as the other standards development organizations.
DR. IEZZONI: Are you working with any of the end users of the information? I don't know if you were here yesterday, but --
MR. BARRETT: I wasn't, I am sorry.
DR. IEZZONI: That is okay, I understand. We had a panel yesterday morning with people from NCQA, the Joint Commission, people who really rely on these data because they are the only data available now to be able to do the important functions of monitoring quality of care and use of services in the community.
MR. BARRETT: We have had some conversations with them, but I can tell you it has not been probably to the extent that we would like to and would probably want to, would certainly be open to having more discussion because you are right. They have got a lot of that information, and we want to make sure we have in several of the standards put in reporting requirements into the standards, so we have incorporated, but I think what we need to do is have far more of a formal relationship.
DR. LUMPKIN: Jeff, did you have a response to that?
MR. BLAIR: Just one comment, and that is that I believe it was the September meeting of the ANSI Health Care Informatics Standard Board, we did invite representatives of HEDIS to speak to us so that we could begin the process of correlating the data requirements that HEDIS will have its reporting systems to the rest of the standards that are represented right now by ANSI HISB because many of these other standards, in fact, will be conduits for feeding information eventually into the HEDIS reports.
DR. STARFIELD: I like this table really a lot. It simplified things for me, and it was extremely helpful. I don't know about the rest of the panel. Do you have copies?
MR. BARRETT: They don't as yet. I brought them in with me this morning.
DR. STARFIELD: Good. Basically what it does is it lists 10 out of the 11 HIPAA transaction types against the equivalent, accredited equivalent. It would be especially helpful to me and perhaps to others on the Committee to have another column that said, "Other equivalents," you know, the non-accredited equivalents because we have to deal with those as well.
Has anybody done that?
MR. BARRETT: I think HISB, and, Jeff, I won't speak, but I think HISB has done some work in relation to doing, and Ed, you may know. I think we have done some work in doing kind of a cross mapping between the standards development organizations on our standards, and we have done similar charts, I think to that. We certainly could, I think, between us, certainly get you a more broad-based table.
MR. BLAIR: Let me repeat what I think your question was? It was that the categories in a HIPAA bill, you are winding up indicating which standards apply to each of those categories?
DR. STARFIELD: Right. I know the compendium does that, doesn't it?
MR. BLAIR: Yes.
DR. STARFIELD: Actually it takes a lot of study to get it out of there. We will do that. We will study it, but this sort of encapsulates it you know, just on that one page.
MR. MOORE: I think we can do that when we do this. It is in the presentation given to us from HISB. It is just not put in a table format, and we will do that for you, Barbara.
MR. HAMMOND: But there is a table that does exist that HISB did put together. The only thing that I would say is that it is not an easy task because you have different ways in which different groups define standards. HL7 puts its standards all in one book with a number, and others spread them out, and then standards have, a various stages of maturity. So, all of that has to be carefully looked at when you look at the matrix.
DR. STARFIELD: Footnotes.
MR. MOORE: I am assuming the standards you gave us in the book, Ed, were mature standards.
MR. HAMMOND: Yes.
MR. MOORE: We asked you to recognize one, was it developed; was it under development or was it anticipated being developed?
MR. HAMMOND: And, in fact, the report from HISB does have a category that will tell you whether this is something that has been out, for how long and --
MR. BLAIR: Yes, we have, for each template it indicates the readiness of the standard and has about six or eight questions which you could glance at in the template there. Actually the handout that you have has in the section called Scope you will see it is organized basically by the HIPAA categories, and it has following that the table of contents which is, also, organized by the HIPAA categories and then following that is the profiles and templates, and if you look at the readiness of the standards the template is actually included in the handout, and you see, I don't remember now, six or eight or 10 specific questions that would reflect the readiness of the standard, and once again the reason that it cannot be a simplistic answer is because there are different measures of readiness in terms of whether it is in a draft stage, whether it is implemented, if it is implemented, how broadly. You may have different components of a particular SDO which are out there and have been out there for a long time. They may be updating those, and they may be developing new standards for new domains to be added on. So, it is an attempt to try to get a comprehensive and accurate answer.
DR. STARFIELD: HIPAA standards, also, include an eleventh category, coordination of benefits. Neither you, Jeff, nor you, Lee, included that.
MR. BEATTY: The inventory talks about the coordination of benefits as actually defining the data content necessary to accompany the claim transaction to move the claim from payors of different responsibility, and the data model that X12 built for the claim process for coordination of benefits, they built a process where the claim would be submitted by the provider to the primary payor along with an essentially routing list for the various payors, and the claim would travel from payor to payor rather than requiring the provider to resubmit claims back and forth which simplifies the business practices for the provider community, as well as establishing the data content necessary to move the explanation of benefit information as far as how the various payors adjudicated the claim so that the subsequent payors can continue the coordination effort.
So, it is more of a data content issue than a transaction issue.
MR. BRAITHWAITE: I would like to just point out that Jean Narcisi and the ADA spoke to the difficulty of getting implementation because of the various payors inability to accept the standard transactions and to point out that that reflects a lot of what we heard in the previous testimony from a variety of software vendors and clearinghouses, that it seems to be that the payors are, in fact, a major blockade in getting this going, and then Ed Hammond, with apologies to the ADA said that we need to put teeth in the standards so that in fact, we can force the implementation in some way, and I am wondering from all of the panelists if you can suggest mechanisms for putting the teeth in these standards and whether the standards organizations themselves are the groups that should be stepping up to the plate as it were with the reference implementations, the certification methods, the test suites or whatever is required to make sure that the implementations are compatible and then how do we put teeth behind them?
MR. BLAIR: This is probably a controversial suggestion. This is my thought because I heard the testimony yesterday, and I heard about the small vendors which in many cases are small users, providers in many cases, and they wind up going to considerable expense to adopt a standard and seek that information, and payors have tens of thousands, if not hundreds of thousands, if not millions of submissions, and for whatever reasons if they choose to modify the standard where many of these small providers are submitting it, the small providers really don't have the clout to be able to resist. They simply have to go through these accommodations.
You might consider this. This would take some thought. This is a simplistic suggestion. Implementation may be harder. If a payor modifies a standard that is declared by NCVHS during this next year, year and one-half, if they modify it, if we could put the burden of the accommodation expense on the modifier, and actually you don't even have to say payor; it could be payor or provider, whoever chooses to vary from the standard, they have to absorb the cost of the resubmissions, of the tailoring.
Again, we may have to give some thought to how that is applied, but that, I think might help to enforce compliance with the standards, that you probably will, also, need to have something along with that which was suggested yesterday, that they set a standards police, maybe you could call it a compliance board.
MR. MOORE: In answer to that issue, that presents a little bit of a problem because if the Secretary is going to be the one mandating these standards, then that means the Secretary has got possibly to put in money. If the Secretary is making the standard change, then we not only would have to pay all the payors in the country of which we have over 4 million but all the providers in the country.
I am not sure how we would calculate that, you know, would all the bills come into the Secretary?
PARTICIPANT: It would solve the problem.
MR. MOORE: It would solve the problem, I am sure.
MR. BLAIR: Maybe that then becomes the standard that everyone complies with.
DR. LUMPKIN: Does anyone else want to answer?
MS. NARCISI: We have a mechanism at the ADA that we work with the third-party payors directly on various councils and advisory committees, and when we were exploring this whole area of electronic claims, we had a group of the large payors in with us to talk about some of these issues.
One of the barriers that we had determined was this whole issue of attachments, and with dental claims most of the attachments that go to the insurance company are the x-rays and models and things of that sort.
So, the third-party payors that we are really trying to get up and going with this whole process were very honest, and they said, "You know, we explored this whole area of attachments and the main reason that we use the attachments are for fraud detection, and we found out that it costs us more money to handle those attachments than it does to just process and pay for the claim as it comes in."
So, we said, "We need to figure out what we are going to do here." So, the thought that came out of it then is that all dental claims should be accepted without any attachments, electronically, and if there was a problem or a question on something they need to send a message back to the provider asking for additional information. So, we are working on that piece through our vocabulary end of it, so that we can supply that information to them, and I think that will work fairly well. However, those are mostly the large payors that were ready to invest the money to get it moving, but the other problem is that the standards that are developed, particularly for the dental claim were developed based upon the paper method of processing a claim, and those paper methods aren't perfect.
If you think about it, a simple dental claim, the claim form supplies so much information that the third-party payor already has in their system. So, we need to work our those issues, and that is another reason that they have not probably come on board. However, if it is a mandate that they do, I am sure that they will respond.
The other thing that we are trying to do through our Standards Committee, the MD156 is a large majority of the participants are vendors and some payors because they are very interested in trying; they have found that it is more cost effective to have the claims received electronically. So, through this process what we are trying to develop and either it will be done internally or externally is having some type of an accreditation process, and I know that is hard to handle, especially with technology changing so quickly, but if you think about the seal program that the ADA has with the seal on the consumer products that products must go through various guidelines and meet guidelines and go through various testing, it would be similar to that, and that is, I guess compared to what we talked about yesterday with the reference implementation and compliance, I think that needs to be done.
So, that would help the vendors to get up and moving, but it would, also, help the payors so that they could meet those guidelines that were established.
MR. BRAITHWAITE: So, is that something the ADA is considering seriously?
MS. NARCISI: Yes, we are. We are considering that seriously with practice management vendors.
MR. HAMMOND: I have two sets of remarks that I want to make. The first is I think my interpretation of some of the reasons behind this tremendous variation, and I think the first part of that is that we continue to duck the issue of exactly what information or what data we are trying to transmit and why, and I think if we really put all of those cards on the table and understood what was going to be exchanged, and why it was going to be exchanged, if you are dealing with fraud, that is okay, and then let us define what those data elements are.
If we do that, then we ought to be able to accommodate what is required for transmitting. A side comment is that as I continued to deal with this over the years I kept trying to find out why are the standards different, and even in the State of North Carolina if two different vendors provide the Medicare-Medicaid reimbursement, the rules are different, and then I go try to find out why the rules are different, and first of all nobody knows who made the rules different, and nobody really understands why the rules are different. So, I think an awful lot of this is just baggage that has rolled along with this so many years that we really haven't dealt with it, and I think somehow that is the thing that we have got to be bold enough to come to grips.
The second is, I think, convincing that there is some stability and return on what is being invested here. I remember the first time that I had heard that the X12, 835, 837 were going to be used. I believe it was maybe 3 years ago that it was going to be mandated in a relatively short period of time.
My heart beat very rapidly, and then it slowed down as we got closer and closer and nothing happened, and so, I think that --
(Laughter.)
MR. HAMMOND: This is not X12's fault. This is really the industry still isn't convinced that this is what it is willing to do, and convinced that the laws are going to be stated well enough that that is really what is going to happen, and then, finally, I think the issue is convinced that there is going to be benefit to them.
Now, I must confess that I am a naive individual, but I am old enough now that I haven't changed my mind, and I think there may be value in being naive, and I really think that one way we may get this to happen is really bring the people that we are talking about that are going to make these decisions as to whether they comply or not and what they do or not together and try to get a real understanding of what is wrong with what we are trying to do, what it would take to change it, what is not being accommodated, in other words look at the issue in really honest terms and then try to reach a compromise in terms of what they want to do and what the standard permits to get a working set, and then I think that the expectation that this group will go back and carry that out is an expectation that I am willing to believe in, that if an understanding of this solves the problem; let us go do it, then I think it will happen.
Now, in spite of all of that there still needs to be a way of testing whether any particular implementation of the standard works or not, and I think that part of this process requires two things. It requires someplace in which I can test my software against a defined standard, knowing that my software works and then secondly, I think there is a required certification process. Certification obviously requires the removal of ambiguities so that you are able to certify against the standard. I think those are essential components.
MR. STANIEC: Bill, before I answer a question on what type of mechanisms for putting teeth in standards and enforcement, I would like to talk specifically today on what is happening in pharmacy. As you know, standards are voluntary, and business needs drive standards and standards development. Currently in pharmacy the state boards of pharmacy pretty much set up the rules and regulations. There is a National Association of Boards of Pharmacy that puts out regulations, and the state boards can follow them or go their own separate way on how they want to enforce specific standards.
I would like to give an example. We developed a standard called Script(?) which we talked earlier is the physician-pharmacist interface, and we are working very closely with HL7 on the cross mapping of those two documents, but it is kind of like building a super highway. The standard development organization will build the ramp, the foundation and the actual freeway, but as far as the rules, as far as how fast you can go and what direction you go and so forth, that is really up to the state boards of pharmacy to dictate who can use that standard, and it is very difficult for some of the software vendors because maybe one state, I won't mention the state's name may say, "You just cannot do electronic prescriptions." So, you cannot do it. Other states says, "Yes, you can." So, it is a challenge when you have one standard. You have to abide by the rules and regulations of that particular state board of pharmacy.
Again, as I mentioned earlier, standards fit into the business needs. Bob Beckley mentioned yesterday during the software panel that some of our business partners are still using version 1 and not version 3.2. That fits their business needs. They don't need 3.2. To force them into something that they don't really need is again, a cost measure that needs to be considered.
NCPDP standards mentioned earlier are widely implemented. I think that is probably because of the process currently in place at NCPDP. As you know, to have a standard approved requires a 90 percent approval rate. That is difficult to get 90 percent of the people to approve on a particular standard.
As I mentioned earlier, our three specific categories, the payors, the processors, providers and the software all meet at one time, and I mentioned earlier maybe 100, 200 people in a meeting, and there is controversy, and there is a lot of yelling and screaming, but it is best to have that done earlier before the standard is out there, and people realize, hey, I cannot implement it or I don't understand it or it doesn't fit my business needs.
I think the process in place, again, and that is assured by becoming an ANSI-accredited organization, ANSI in itself has a process to avoid the duplication. If we have an interest in doing some work, we fill out a PINS form, Project Identification Numeration System form so that there is no duplication of effort. Maybe another SDO may be doing something along those lines.
I, also, like to recommend as Bob Beckley mentioned yesterday to give some teeth to HISB. If there is a controversy, maybe they should be the one to say, "Yes, you are the area of expertise that should be developing a certain standard.
Currently we are working ongoing discussions, and that works fine, but maybe it gets to the point of controversy. Maybe we should have an organization that can provide that teeth, and, also, again, more cooperation with SDOs, and we are certainly doing that at the present time and to continue that process of cooperating and working together.
MR. BARRETT: Bill, one of the issues you raised on the payor side and why the payors, for example, have not come to the plate, and I used to be on that side for a number of years, and what I can tell you is that there were tremendous efforts that were undergone by several of us that should probably evangelist next to our names on our business cards, that at least there were lots of efforts that were undertaken, and I think the issues today with the administrative simplification legislation, I think a lot of this is going to come down to, as you are looking, and I agree with a lot of what my peers have said, but I think education is going to be key. I would, also, agree with Ed of getting some type of coalition together of the key constituencies to talk over the issues to try to reach consensus, to come up with the issues. WEDI had done that a number of years ago when it first started, and I think based upon the two reports that they came up with, they at least identified many of the issues and tried to come up with some recommendations.
I think to do something similar to that today, given where we are heading now, the fact that we have got the HIPAA legislation in place, and if that is the framework that people look to operate from and to come up with a series of issues and resolutions and recommendations, I believe that the industry will meet that challenge, and I think that is going to be key.
So, I would agree with that on that one. I think that will happen. The fact that we have got it in each of our organizations as an SDO is true, but I think that is certainly going to be where we are, and I think lastly, the issue of testing and the testing tools, I think we need to come up with a couple of things. One, the issue of accreditation I think becomes key, not only from the standpoint of looking at it through certain constituencies but I think you can look at accreditation across value-added networks as well as other translators, etc., because one of the issues that we continue to hear, when you are looking at implementation guides or you are looking at the issue of implementing what people continue to say is, "You know, I have gone to implement this particular standard, but this particular vendor said that they could do something, and I have gone to implement it, and in fact, it doesn't work."
We found with many of the standards that we put in place a lot of it has to do with the fact that what people thought they had as far as capability wasn't, in fact, there. So, I think that and the testing tools and making some recommendations on testing tools for the industry and an ability, I would agree to have a place to go to test those transactions are going to be key to, I think, build credibility overall in the industry.
MR. BRAITHWAITE: Is X12 the right home for a set of testing tools?
DR. LUMPKIN: Let me perhaps just run down because I don't think, we appreciate your answers, but we need to get a little bit more specific, and so, let me start with the ADA, if I hear this correctly. Do you think you see the ADA as being the testing and accrediting entity for the standards that you are developing?
MS. NARCISI: Yes, that is what we are working on.
DR. LUMPKIN: Yes, for both?
MS. NARCISI: Yes.
DR. LUMPKIN: Okay, HL7?
MR. HAMMOND: Yes.
DR. LUMPKIN: NCPDP?
MR. STANIEC: Yes.
DR.LUMPKIN: X12?
MR. BARRETT: Yes.
MR. BRAITHWAITE: So, they are going to do it, right? So, we don't have to worry about creating the standards police?
DR. LUMPKIN: The standards police. It sounds to me -- yes?
MR. BECKLEY: I disagree. The SDOs don't have the power.
DR. LUMPKIN: Can you introduce yourself?
MR. BECKLEY: I am sorry. I am Bob Beckley with PDX. I am a software vendor. The SDOs don't have the power because the payor has the power, and what is the power? I will not pay you for this claim. Okay? And that is what makes it happen. So, you have software, I mean I want to say that you are preaching to the choir here because we all want to be able to do it one way. I have to write software for all the pharmacies, and everyone comes to me and says, "I have got to do business with this third party. They are rejecting my claims. Fix it." I can say until I am blue in the face, "You are not following the standard," and I write letters. I have my customers write letters. Occasionally I will get a little bit of change, but the bottom line is we are not going to pay it. There is where it is, and I think the SDOs can test, but unless the payor is made to follow the guidelines, the payor is going to say, "I don't care," and that is what a lot of them say now. So, I go back to your comment, where are the payors? You have got to get the payors to agree.
DR. LUMPKIN: But I think that what we are here about is a changing paradigm, and what HIPAA says is that the payors have to play, and our concern here is that if you make a recommendation, and we certainly heard this yesterday about the 837 that if you say that there is a standard, then what you have to do is test to see if they are following the standard, and if they are not following the standard, then the penalty clauses of HIPAA would then go into effect. Is that correct?
MR. MOORE: But then would those same rules like X dollars per every transaction per every violation and then the payor could be hit with this is a different variation of that same penalty, we perceive with our OGC that you can be penalized up to $25,000 per transaction or a maximum of $250,000 per year on that. So, it would be a really big hit for a payor to have to pay a fine like that where all the providers who have been putting it in would be coming forth with that.
MR. HAMMOND: Two quick comments, one of which is I think that there are two terms. One is certification which really tests the technical part of the standard itself, and the other is compliance, and I think that compliance is a different issue. So, I don't think this is disagreement as much as to point out that there are two parts of this, and in fact, one of the problems that we have with HL7 is the fact that it may have an interpretation or an implementation of the standard that is technically correct, but then the user will put whatever they wish in that slot which makes the standard not work and therefore be non-compliant. I, also, think that ambiguity is something that is almost impossible to remove. When we looked at the four questions you gave us, you may have thought those were as clear as day, but the question No. 3 we discussed for a long time exactly what that question meant, and I think that you may find that much of the lack of compliance at least early on is really that of understanding and dealing with the issues of ambiguity, and I think that the system itself is going to have to be somewhat tolerant to make this a workable system of simply pointing out and then letting it change over time before the punitive measures take place.
MS. NARCISI: We can deal with the accreditation or certification process with our own standards, for instance, if it would be practice management systems or whatnot, but I think you need another level that the third-party payors are going to have to participate in, and whether that would include all the SDOs and the payors on the standards that apply to them, I don't know what the answer would be, but we are able to do it at our level, but it is that other level, the payor level that you are going to have to try to get them involved in the recommendations.
DR. LUMPKIN: But the question is if as a regulatory agency you need to have a tool to determine compliance, and as a regulated entity the way that they do that is if they are accredited one assumes that they are then in compliance, and if we get a complaint then we have some way of measuring the fact that they are out of compliance.
So, you need both an accreditation and a tool, and they would not come to you asking for you to do the enforcement, but if a standard is adopted, there needs to be a mechanism to enforce that, and that would be the testing and the accreditation, and that really is what would be looked for SDOs or whomever. I mean it doesn't have to be the SDOs. There is no reason to say that because you set the standard that you have to do the testing and accreditation. There may be a third party that would do that.
MR. BEATTY: There are actually two planes of this compliancy check because you can submit a transaction in any of the standards that we are talking about, and it can pass a compliancy test for that defined standard, but it kind of goes back to some of the things that Lisa has some concerns on.
Sunday night I had the opportunity to go out with a primary care physician from George Washington, and we were sitting at the table talking about all of these standards kind of things, and she said, "You know, if I want to submit a claim to payor XYZ, I have to use these defined codes that they have given me as a payor and will reject the claims if they are anything but those codes."
They could submit those transactions in any of these transaction sets, and it will pass the compliancy check, but you take it down to that next level of actually testing against the coding sets, and it touches on a lot of the things that we have heard both at this session and the earlier hearing, that we need the payors to look at the coding and be able to, if a provider codes transactions, we need, also, standards and compliancy checks against those codes which these SDOs may or may not have control over.
MR. MEYER: Chuck Meyer, HBO & Co. The thing that I have trouble with, and it is more of observation than anything else is that those of us in the industry are in a competitive position. It is to our advantage to say, "We are HL7; we are X12; we are NCPDP compliant," and be able to show certification of that. There is no such pressure on the intermediaries. They are monopolistic. They consider themselves to be driving the cart not the horse that is getting whipped, for lack of a better term.
So, I am concerned. I don't see anything substantial that, I mean beyond this penalty clause in the act that enlists these intermediaries in any way, shape or form in buying into and adhering to these standards. That is the critical part.
DR. LUMPKIN: But I think it is important to understand the political process, and the political process is we got to this point because it is my belief that there is a substantial feeling amongst the provider community and others that the payors have or whatever entity is requiring it, have gone beyond the limits of what is acceptable, and the result is that you get legislation passed with a penalty clause.
If, in fact, that penalty clause does not do the trick, and there is documentation, then Congress will say, "Okay, we can go another step further," and historically that has been the way it happens.
So, I think that we need to give the benefit of the doubt. One of the comments that I heard today, and I think it is one that we need to explore is the issue of fraud. That is probably the single most largest reason why we get all these variations in data, and perhaps there is a science of detection of fraud that is missing here, that perhaps we can look at, maybe at the level of the national committee or some other body you recommend that if there is a minimum data set for fraud detection in health care that would eliminate all of these problems that we now have with all the different, because I know how it happens.
You get burned on one thing, and so, now every claim that comes in on removal of the left little toe has to have the following piece of information because we have discovered fraud there, and I know that because we do a significant amount of fraud detection within our own agency in relationship to WICK. We have a motto, and our motto is that we determine those who are high-risk vendors, and then we look for extra information from them. I don't think that exists in health care, but that is the kind of issue that I think we need to get to if we are going to resolve some of these issues from the payor side who have very legitimate concerns because they have been defrauded with significant sums of money.
MR. MEYER: Absolutely correct, and first of all to address your first point, I agree with Ed. I, too, am naive, particularly in the political arena but I am just concerned that we have something substantial to drive that process.
As to your other issue, and I have to agree with the ADA, the discussions that I have had, and I am part of the modeling and methodologies group within X12 as well as within HL7, the discussion that we see on the business modeling side is exactly what the ADA study pointed out. Ofttimes the only rationale behind requesting an attachment is to validate that in fact, a process occurred.
They don't really need the physical entity. They just need assurance that it was performed, and again, it is for fraud, but on the other side, as one of our members brought up, he said, "We should make our software smart enough then that once you request that, we just automatically attach it to every further occurrence," and the response was "Whoa, just because I asked for it this time doesn't mean I want it next time." So, I think we need to default to the industry, that being the payors to beef up their internal audit processes that lets them identify likely areas of fraud and undertake studies of those particular providers, not penalize the entire market.
DR. LUMPKIN: And I think we are there, and I think that is a good point, but I think that the issue of fraud bears a little bit more thought than maybe we have given to it prior to now, if we are going to resolve some of these issues.
If it is a different issue, what I would like to do is we are scheduled to take a break, maybe take a break and then ask the panel to come back after the break. I know we all have a list of questions, and we are scheduled to go to twelve-thirty with this panel, but we do want to take a quick break.
(Brief recess.)
DR. LUMPKIN: Let's get started. We have two additional presentations. We'll start off with a brief presentation from X3.
MR. NGO: I am Phong Ngo, the Chairman of X3L8 Secretariat Information Technology. My committee is dealing with data specification, among other things.
When I was in Amsterdam in a hotel many years back, I looked in the hotel's book, about six or seven columns and across. They have a number and then across they have different languages for each of those items. I didn't speak Dutch, I just showed Number 7 and they gave me the town. So that gave me the inspiration to come up with some international standards to deal with the data itself.
Another point I wanted to make is that the data integration versus data sharing. We have been trying to deal with the data integration, and then we gave up long ago. The failure started at home, when I had two teenagers and we tried to integrate some discipline uniformly for everybody, and it didn't work. You know how it goes.
So we devised a structure to do the data sharing. Here you come together. We set up a rule. You agree on it, and we follow it. It seems to be working okay. So sharing is much better than integration, because we don't believe that integration can be dealt with considering the interests of different parties, and it is sometimes very hard to reconcile.
With that in mind, my committee back in the nineties -- before 1990, we dealt with the concept, but we didn't deal with the health care thing, but we dealt with like human sex is one of the standards we are responsible; the city code, county codes for example. These standards are still maintained by committee.
We took a different approach. We wanted to get above that and say we want to specify standards that everybody can use to specify their concept. So if you follow the same rule, and assuming that you follow the same rule using specifications like we specify in our standard, which happened to become and ISO/IEC 11179 standard, specification of data elements.
The United States contributes five out of six editors to that particular standard, and I am one of them. My part in there is registration of data elements.
Why do we have the registration of data elements? Once we know how to specify the data elements with the objective that everybody will be able, in good faith of course -- you can always find a way to beat the system -- but in good faith, if you have a way to specify the data that you want to talk about, using a certain structure and rules defined by the standard, then the next step would be how are you going to get out there so people can share?
If you specify well, but it's stored somewhere in the cabinet, then nobody would be able to share the information. So we set up rules for registration of data elements with the intention that if you register, whatever you define, however it is specific to your organization, you put in a data registry. Eventually, if you have a common interest, you start using that kind of information, because human nature is lazy; they don't want to define a new thing, so we take advantage of that.
After a while, if you see that you cannot share that piece of information, then that would serve as a forum for people to come together and say, you have this data element. I have this data element. It seems that we are pretty close, but not the same. So why don't we sit down together?
We formulate the registration procedures in such a way that you can go up like a pyramid. Everybody can set up their own registry, and then that can be shared among people sharing the same interests. If that interest happens to be shared by other groups, then they can form another registry, registration authority, where they can negotiation to combine, and put it there so people with the same interests can share.
The 11179 has six parts. Part number 1 is a framework where we describe how things would fit together.
Part number 2 is the classification of concepts for identification of domains. Basically, it's a taxonomy of the terms and concepts and so on and so forth.
Part number 3 is basic attributes for data elements. If you want to define a data element, what you want to use it for, you need to have the obvious identification: you need to have a name; you need to have a definition; you need to know the data type; you need to know the value domain, which basically is the concept; you need to have rules and guidelines.
Part 4 is the rules and guidelines for formulation of data definitions. There are certain rules that you should use. It should not be circular logic -- things like that. We have rather elaborate, but common sense rules for data definitions. So if everybody is sharing the same kind of style guide to define the data, we hope that people will be able to understand one another.
Part 5, which is the naming and identification principles for data elements. To us naming is only one of the few devices for identification. You can use a number. You can use a name. A name is a very tricky thing to talk about because of different cultures, different languages. Something here may be equivalent to that concept and a half in another language for example. So that's why the Amsterdam Hotel list became very handy that we used for identification.
I have certain slides here that if there is time, I would be more than happy to present what our structure is about identification.
Part 6, registration of data elements. We detail the procedures by which participants can define and register their data elements.
Our hope in the whole process is that if people can share the information, someday they can work together, and maybe some other day they can have some small set of integrated data.
That's all I have. Thank you very much.
DR. LUMPKIN: Thank you.
DR. PETERS: I'm Rick Peters. Thanks again for allowing us to fit in at the eleventh hour here. My apologies to Bill for us being hard to get a hold of.
I'm here to represent really two different focuses on security and confidentiality in health care information. On is ASTM, where I am Head of the Division for Security and Confidentiality, which is specifically three subcommittees involved in work which is itemized in the compendium. Also as a coordinator of efforts under ANSI HSB for security and confidentiality.
Just a few quick things I would like to cover in regards to that. One is to itemize what is really a general overview of security and confidentiality from the SDO's perspective, both here and in Europe. Primarily if I put that in a nutshell -- and this is itemized in the compendium as well -- we strongly believe that most issues of security and confidentiality, when you look at it from a technical perspective, are well handled by technologies that are available outside of the health care industry.
I'll have two members from ASTM hand out a set of overview of the various standards and the various efforts within a security framework, such as authentication, digital signature, messaging communications, that sort of thing, where standards exist in other industries, be they financial services, but it in the Internet, or be it in other areas, which we were able to adopt for use in the health care community.
There are only five areas in my work in putting together a compendium that have come up as areas where health care differs in security and confidentiality from technology that we can get from the general industry. One is that multiple signatures are a requirement on health care documents often, or health care transactions. This is not generally a requirement of our industry, specifically, the financial services industry, but is covered by an ASTM digital signature standard, and is covered by CEN-251 digital signature standard in Europe.
One is health care is a domain where confidentiality, and confidentiality even of messages exchanges even in the financial transaction side of it has some play, and this is in two areas. One is in auditing.
Auditing in health care is somewhat different in that auditing of information or audit trails so to speak, have a legal, as well as a procedural implication in health care, primarily in the areas of auditing in regards to quality assurance, where quality assurance in many states, and in fact most states is non-discoverable as data medical malpractice trials.
The other issue, that quality assurance, when it comes to utilization review, is not covered in many states under medical malpractice by medical malpractice carriers, and we don't want audited data then to be considered as discoverable data, because it is now outside the purview of medical malpractice. So these are considerations in security that would need to be considered.
The other side of it is that in health care, we have a general professional level of practice related to the different professional disciplines within health care that really deals with confidentiality issues. Issues of who is allowed to see what, in what situation.
This holds true relatively well across the states from a professional practices point of view, but certainly doesn't hold sway in a legislative perspective. We are assuming that these are issues that will need to be addressed under privacy legislation specifically.
We also see a conflict in our work with Europe. I'll give you just one example of that. For example, in France primary care physicians, their information and their notes are not disclosable to other clinicians. They can keep that private, whereas obviously in the United States that information is exchanged; in fact, it is encouraged to be exchanged for continuity of care.
When we exchange information with providers in France, or when French providers exchange information with us, which will happen on an international sense, then we will have to probably comply with their confidentiality rules.
So these are things that we need to consider. They are somewhat different than the security and confidentiality concerns in general industry.
In a nutshell, we feel very strongly that the work over the next six months in the health care SDOs will very quickly solve these issues that are different. We encourage the subcommittee here and the Department of Health and Human Services and HCFA to consider being relatively stringent in security and confidentiality components of your guidelines.
Then we also feel that most of the work of the technical specifications will be adaptable from the outside computer industry. So there is not going to be a lot of new, untested ground that will need to be covered in terms of digital signatures or message standards, or other things like that.
DR. LUMPKIN: Thank you.
Certainly one of the charges of the subcommittee is to deal with the issue of security. There is another work group that is dealing with the confidentiality component of that. That is something that we'll need to address as we continue on with our work, so thank you, both of you, for coming.
Jim, I think you had a question right before break?
MR. SCANLON: If I could return to the discussion from the panel, and first of all thank everyone on the panel for their excellent discussions, and of course ANSI HISB for that excellent inventory, which will be immensely helpful.
I wonder if I could ask if we could differentiate between accredited standards that are adopted, and then implementation guides, and then the process of implementation and compliance itself, and sort of where one ends and the other takes over.
It appears from the inventory and from Lee's presentation that for most of the transactions outlined in the log, there is for most of them at any rate, an accredited ANSI standard. Yet how far does the standard go in terms of -- where does the standard leave off in essence and the implementation guide picks up?
In the standard itself, how standardized are the data items and code sets and this sort of thing? Where does the implementation guide pick up, so that you really have something that you could implement to speak of?
MR. BLAIR: Let me just begin to answer that. I'll let each of the SDOs go a little bit further.
We do indicate in terms of level of specificity in that particular section in each template. The first question we ask, is this a guideline? If so, what is the intent of the guideline? Is it policy? Is it practice, whatever?
You will find that like for example with data security issues, in many cases like the CPRI, are guidelines that are aimed at policy, and some of them are at practice. Then it goes on down to a little deeper level to say if it is an implementable standard, do you have an implementation guide? Has the implementation guide been reviewed? Do you have conformance and all those other pieces? So you should find those within each one.
The other piece that I might mention, because I was not aware of the fact that some of this was not generally known, there is like six or seven SDOs that are ANSI accredited, that are generally participants in our ANSI HISB.
To make it a little bit easier for you, so you don't have to look down standard by standard, let me just name them off for you, because it just might be a short cut for you: ASCX.12 is ANSI accredited; NCPDP is ANSI accredited; HL7 is ANSI accredited; ADA; ASTM; HIBCC; and IEEE; X3. We didn't happen to have a template in the binder on X3. I was thinking of the ones as they go through. So that might be a short cut for you.
Then in terms of how your question applies to each specific standard, let me just let everyone else answer on the panel.
DR. LUMPKIN: Jim?
MR. STANIEC: I'm like to start with the first part of your question in a clarification of an ANSI accreditation organization versus ANSI standards. There are two separate processes. On August 9, 1996, as Jeff, NCPDP received accreditation from ANSI. That means that the process whereby we approve standards was approved by the American National Standard Institute; however, the process on our standards, that is a completely different process.
Each standard has to be submitted to ANSI, and it goes through a process whereby you have to submit PINs, forums, the BSR8, BSR9 forms. It goes in our standards review action for public comment for 60 days, and that takes about a year or so.
My understanding with the Administration and Simplification at states that the secretary needs to adopt standards that have been actually created in an ANSI developed, standard development organization, and not ANSI accredited standards.
I know we talked about the HISB for quite some time, because there aren't that many out there. So that's just a point of clarification.
Getting into the actual development of the standard versus implementation guide, with NCPDP we have basically two separate processes. We go through the balloting process to be sure all the core data elements, and that the functionality is required, and it goes through the process is approved with a 90 percent approval rating.
Then in turn, we go ahead and develop an implementation guide, again with the same work group, whereby we talk about the specific case studies, business examples, how do you actually use the standard? One work group I mentioned, Work Group 11, actually is working on the implementation guide for a standard, and actually getting feedback from the people who actually created the standard.
MR. BARRETT: Jim, I think your question is a good one. How standardized is the standard?
MR. SCANLON: What is the standard?
MR. BARRETT: That is a good one. I think, to try to answer it, in taking into account all the different constituencies that are coming with their business requirements, we try to create these standards to at least incorporate all the business requirements.
In some cases, you can't get as specific as you would like to, and therefore what you create is a number of for example, optional or conditional elements based upon certain conditions and trigger events that occur.
Although we have tried to incorporate, and make as much of it as mandatory as possible based upon what consensus could be achieved, there is a lot of optional. There is some flexibility built into the standard period.
The way in which we have tried to address it, and this is were the line between the standard and the implementation guide comes into play, is in the implementation guide to get more specific about how and where each of the segments and data elements, et cetera, should in fact be used, and try to add another level of specificity to it, so that we can start minimizing the amount of ambiguity.
So that is where we try to differentiate between the standard and the implementation guide. That is the point of delineation, and that is really where, although we have had implementation guides out for several of these, what we are trying to do I think across the industry now, at least for the standards that we talked about, is to get to a singular set of implementation guides.
I think one of the other problems is you have heard all these numbers. We've got over 400 different just electronic claims standards out there, and then you've got a whole other list of implementations guides of how to implement, which confuses and causes the ambiguity.
What we are trying to do, and I think we have gained consensus across the industry, in getting to a singular set of implementation guides for those transactions. So that is our primary focus now on developing and putting those implementation guides in place. Getting the consensus, and we've got a major review process across all those constituencies: the NUCC, NUBC, ADA and others, WEDI. Anybody is going to have the opportunity to even touch these, so we can get that review process, and get these to a singular set, to be in compliance with what is going to hopefully go out in the Federal Register for June.
So that is what we are trying to do. I don't know if that answers --
MR. SCANLON: That's very good.
DR. IEZZONI: Can I just -- I will explain my complete ignorance here by reading a paragraph from what Jeff gave us, to see whether this kind of addresses what we are talking about.
"ASCX12 maintains over 1,000 internal code sets to support the standards. Along with the internal code sets, the ASCX12 standards reference over 350 external code sources such as," and then there is a list of them. That's a lot of different code sets guys.
Are you saying that you are kind of heading in your implementation guide to take -- there are 1,000s and then there are 350 external. Are you trying to come down to 1?
MR. BARRETT: Not quite. That would be nice, but we're not going to get there.
DR. IEZZONI: Can you just clarify?
MR. BARRETT: The implementation guides are taking in and very specifically trying to state when certain code sets are used, it's different points within transaction sets so that we can minimize the variation.
The internal codes are everything from -- we talked earlier about the gender type of thing. We have standardized codes within the standard for gender, for employment related codes, and so forth. So we have a lot of those types of things that are defined inside.
We also reference a lot of external codes as they are listed. Within the implementation guides we specify exactly where and when we use these codes. If there are certain conditions where they are used or not used, we specifically state the conditions for usage.
DR. IEZZONI: Can I ask a question though? Say you have mental health providers. There are two different diagnostic classifications for mental health conditions, and probably more, DSM4, the Diagnosis and Statistical Manual-4, and ICD-9-CM.
Is your plan for a standard bill submitted by -- sorry, I used the word "bill," but it's because Mr. Barrett keeps referring to the fact that his collaborators are the National Uniform Billing Committee -- so we're kind of still talking bills.
Is your plan that when you come down to the standard code set to be submitted by mental health organizations for encounters, that you would recommend one particular diagnostic set, DSM4 versus ICD-9-CM, or there would still be flexibility in that? How would that play itself out?
MR. BARRETT: Let me try that one out. I think the answer to your question is there will still be flexibility. The reason why there is, is that there is -- until you get down to kind of a trading partner issue between my organization and your organization, you still might want to use a particular code set, a reference to a certain external code set.
What we have done, at least within the standard and the implementation guide is to allow for that to be used, and we tell you where it can be used. As far as which particular code sets, because there are still a lot of code sets that are going to be out there, rather than mandating, to get to the consensus that I'm going to get, I'm going to use one singular code set is very difficult to achieve, if not, I think, impossible right now.
DR. IEZZONI: Oh, no, it's something our committee is going to have to struggle with.
MR. BARRETT: So it is really a struggle. All I can tell you is we have not specifically grappled with that and said we're only going to limit to a singular code set. We have tried to get to the point of specificity as least as possible, at least in the implementation guide. The issue of the code lists, it's still there, and I can't tell you that we have addressed it, other than to get down as much as possible on being specific. It's an issue.
MS. NARCISI: I would like to respond to that. Just take as an example dental claims. What we have done with the implementation guide is we have selected the code sets that can only be used for certain areas. We have even gone one step further. In some of the internal codes sets of X12, we have even specified which codes can be selected. We don't give the entire list. We would say, you have a selection of three.
So we have been able to do that with the specific application. Right now implementation guides are just looking at generically one application for the health claim, so maybe that will come.
DR. LUMPKIN: So you really sink your teeth into that?
MS. NARCISI: We do.
MR. STANIEC: I would like to address that issue too. We have developed the professional pharmacy services codes. Yes, it is one code set whereby a pharmacist, instead of just actually getting paid for dispensing a prescription product, they are getting paid for cognitive services.
Bob Beckley explained very well yesterday where a pharmacist may call a doctor if there is a drug interaction and a side effect, and he may not even dispense the product itself, because it is not the proper care for the patient, the pharmacist is paid. So we do have codes in place specifically where the pharmacist could transmit electronically the reason why there is an interaction, and the result as the doctor changed the drug, changed the dose and so forth. So yes, we have a code set in place.
The struggle now is educating the pharmacists on how to use it. I worked on Saturday and I had an opportunity to do that, and had to go through the book.
DR. LUMPKIN: Are there alternative code sets?
MR. STANIEC: No, that's the only one.
DR. LUMPKIN: There is only one code for each field? There is a code set.
MR. STANIEC: Based on the possible situations available for that particular item, yes.
DR. HAMMOND: I'd like to ultimately reply to both of these, but let me talk about code sets first. I think that there are two things that need to be recognized, one of which is that the problem is not necessarily the fact that there are many coding sets. You probably can deal with that, and in HL7 there is a triplet in which you identify the registration of the coding set itself and some of the things that you talked about, as well as the data elements.
It is a fact that depending on how you are trying to use the coding system, there may be limitations in the fact that what you need for representing data at a certain level may not be reflected in the code set itself. If you look at the drug codes, one of the problems that we have in trying to worry about drug-drug interactions in some of the decisions of what algorithms, is we also need the coding of the compound itself inherent to that.
The NEC code, which is a popular drug code, does not support that. So it needs to go beyond that. That's one of the points that I want to make.
The second point related to the coding set is the fact that even in an ideal world, if there was a single coding set that was completely perfect, I think we need to recognize that the purpose of many coding sets is not atomic representation of data, but really is in terms of groupings of that; DRG being an example of where it is very appropriate.
So the ideal world would be the derivation of those higher level sets from a basic atomic set, which will be able to meet the needs of both groups. I hope that is what really evolves, whether it is for reimbursement or for whatever purpose to that.
I also want to just make a couple remarks related to your question about implementation guides, because it does open some other issues that I think are important to be aware of. In HL7 we really started with the standard itself, and included in the standard, most of the implementation kinds of comments. Examples were given in the standard; some different kind of scenarios were presented in the standard itself, as well as the standard.
Over the years we had conversation about really making the standard a pure item itself of only talking very generically about we were doing, and using the implementation guide to bring in the comments.
The problem that you get into in doing that is the fact that it's like looking at tanker trunk and not recognizing that I can put milk in that truck or I can put gasoline in that truck. So somehow you need those examples well embedded.
Now some of the issues that I wanted to talk about related to the standards itself in terms of implementation guides is first of all, the cost of the standard is a factor. What we had hoped to do is to create a standard that would be free, and an implementation guide that would have value to the members, so that there was income float to that.
That may be an issue, because I think if one is trying to get standards to be used and distributed, they really need to be freely available or close to freely available.
Another issue that really comes up is that of copyright. What you will find is many vendors are interested in taking the standard itself and effectively duplicating part of that standard within their own implementation guides or implementation documentation, which makes it much easier for them to function. So those are some of the issues that really come up with this.
HL7 has really varied over the years as what it really meant by an implementation guide. Our early guides really took sections out of the standard itself and reorganized them, and had sample templates and things of that nature. I think as we are moving on further, we are including in that such things as case reports. These are how-tos. If I want to do a standard, where do I start? What are some of the issues that I have to worry about? So those are, I think, important components in what we are talking about.
I think beyond that there is one other issue, and that really is a conformance document. It's almost impossible to eliminate ambiguity. If you have a conformance guide, this says a group of people that have the intent to use the standard for a specific purpose agree explicitly of how they will fill out all the bytes.
For example, if the CDC was going to use a standard on report of the immunization, a conformance guide would say this is exactly what you have got to fill out, and how you have got to fill it out, and everybody would sign up to that conformance guide. Another group would do a similar kind of thing.
I think you are going to see a family of conformance guides that is the only possibility probably of removing the ambiguity of a broader standard.
Finally, I think that what you are going to continue to see are tool sets that are becoming available, either as the benefit of membership or commercially available, that really takes the standard itself and provides the middleware if you will, or even upperware, as some of this has been called, so that you can take your application program, feed it, and then it provides all the service functionality and utility functionality to deliver that component to another system, and in the process of doing that, can handle many variations within the standard itself.
So I think this whole issue of implementation is very, very important one, and I suspect that most of the standards organizations are somewhat different in where they are, and probably are on a time course in which what we thought we would do once is changing rapidly to what we may do in the future.
DR. LUMPKIN: Thank you. Jeff?
MR. BLAIR: I think related to your question with respect to code sets, if I could draw your attention to the last item under code sets in the inventory, which is -- consider me Simon Cohn right now. He would say this if he were here.
Let me draw your attention to --
DR. LUMPKIN: But we sent him home.
MR. BLAIR: Dr. Chris Chute took a look. They struggled with this, and I think they would have liked to have been able to have done a matrix of code sets across the different standards, and had it in the inventory. It turned out to be a larger work effort than they had realized, so he has just a very brief perspective there as the last item within the code set section, indicating that this is work that probably will need to be done so that there are common code sets among all the SDOs.
DR. LUMPKIN: I think that we're going to spend a whole hearing just on code sets. So we may not want to get too deep into that today.
MR. NGO: I would like to make a comment on the code sets and the ambiguity issue here. In the standard 11179, the ISO standard that we specified, we treat ambiguity in a progressive manner. We are looking at the industry out there, and we cannot ignore the fact that people have been using certain information in a certain way for so long, and it would take a humongous amount of money and time to change over something that everybody -- together. It would have to go through a time.
So we coined the registration status, some kind of quality over time. First of all, only something like incomplete. You may have a code set out there that may not comply with the specifications, the rules of 11179, but we allow you to put in there, we coin them incomplete.
The other level of the senate in terms of registration is the recorded. You may have only the thing in place. You may have a name; you may have a definition; you may have the domain values specified and so on and so forth. It has only the format in there, so it is recorded.
The next level is certified. After you record it, it has all the nuts and bolts in there. We have to go back and look and see whether it complies with the rules for the definition for example. Does it comply with the rules of 11179 at the certified level?
The next level, the highest level in the 11179 is standardized. Standardized means that there is no ambiguity within the same registry shared by participants. So I can have a data element one, you can have data element two. They are almost similar or equivalent. Then they are at the certified level, and each one of you can use them, until a point that you would agree that they should be combined and we call it standardized.
So when you go to a registry and you see that the data element is standardized, you can be sure that it has been uniform across that particular industry or sector.
That's all I have.
MR. ZUBELDIA: I would like to shed a little more light on the issue of code sets, because I think it is very important, at least in X12. There are three different kinds of elements. One type of element will have an internal code set. For instance, we talked about the gender. You have an M, an F and a U. That is the code set for that element. Usually that code set doesn't apply to any other element. So it would be inappropriate to combine it with other code sets.
Then you have another kind of internal code sets that are specific to X12. For instance, the relationship between the patient and the insured. We use two digits to express that code. It doesn't necessary carry that NCPDP is going to have the same two digits to express that relationship between the patient and the insured, or that they may even have two digits to express it; it could be alpha.
Then you have the external code sets. The external code sets is really a pointer to an external organization that maintains the code set. For instance, for the procedure we have a code set that points to the American Medical Association for CPTs. We have a code set that points to ICD-9 codes or to HCFA for HCPX(?) codes.
We put in a qualifier saying what is the code set that follows. So you will see a qualifier of CPT, and then you will see CPT codes that follow, so you know where to look for the external code set. In the cases where there is an overlap between CPT and HCPX, the qualifier may always say HCPX, and then you will get either a CPT or a HCPX per se.
I think that at that point, the implementation guides are very effective in identifying what code set you have to use. The institutional claim specifies that you use ICD-9 procedure codes. The professional claim specifies you use HCPX or CPT procedure codes. The dental claim specifies that you use the ADA dental codes, and they are all external lists.
The problem is with elements that don't have a code set, for instance prior authorization. The prior authorization, when you go from state to state, in some states the Medicaid intermediary will say that the first digit is the year. In another state they will say that the first digit is the specialty. In another state they will say that for pharmacies you have to use the prescribing physician as the first two letters of the prior authorization, and that's where it becomes a nightmare.
You can check the standards for compliance to the implementation guide all you want, but as long as these kind of differences continue to exist, we don't have a standard.
DR. LUMPKIN: I think it's important to recognize that there is a difference between a standard and simplification. Every time you say or, you put another code book in somebody's office, and if you or and a subset of or that's the third code book. That yields standardization, but does not yield simplification.
DR. IEZZONI: Can I just ask one very specific question? Say it was a nursing home submitting one of these claims; 837 I guess is the one we are talking about. Is there anything to prevent them in an 837 format to report both an ICD-9-CM code for stroke, and an ICIDH code, an International Classification of Impairments, Disabilities and Handicaps code to indicate the type of disability?
Is there anything that would prevent you from submitting both of those codes on the -- no? So there is that flexibility.
DR. LUMPKIN: Let me perhaps ask a couple of questions. I just know where we need to be in June. We had some very interesting presentations, and there were a few areas where I heard that NCPDP said that if we adopt 837, they are in trouble.
I heard that the ADA said that maybe X12 might work for them, but there is a migration issue. I can't believe that that is the only difficulty between these code sets. If we were to leave today with the impression that I have, we might make a recommendation to HHS to just adopt them all. Everybody who has been here, they all seem to work together. It's one big happy family, and we just all adopt all of the various code sets, the X12 code set, and the HL7 and NCPDP and the ADA set.
I have a feeling that won't work. No one really has told us why, except for the difficulty between the interactive in NCPDP and the batch standard in X12. I ask that question, and I would some perhaps response to get down to -- I hate to do this, because I think that having all the groups get together is a big advance, but in order for us to make the decisions that have to be made by June, we are going to have to ask you to get down and dirty as to why and what the implications would be of adopting someone else's code set, to the ability to adopt yours.
I don't want to just limit that. I want to encourage you to feel free to write in to us as a committee, to get more specific, because this is something that will have to be decided, and ideally will be decided with you input, rather than without your input.
MR. BEATTY: Just a quick comment on that. As we listened to the testimony for the first set of hearings from the user community, we heard a lot about electronic commerce. The reason we need to focus in on the single set of standards is that all of these transactions put together create an electronic commerce environment, where put together we are trying to move information faster, easier and reduce costs.
As part of that process, we need to develop that common data dictionary, the common flow with HL7, with NCPDP, with X12. We're working on those cross issues where if NCPDP needs to keep their interactive transaction, that we have a data dictionary that crosswalks the data needs of that interactive message versus an ANSI X12 message, or an HL7 area where we need clinical information, be able to work that into, or back and forth between the administrative transactions.
The key to this is that they all have to work together in a common fashion, so that we can very easily create that entire electronic commerce environment.
DR. LUMPKIN: Well, I understand that, but if you can imagine a work of art. You are going to make a piece of wood with inlay. You've got brown pieces and white pieces and red pieces and green pieces. How that inlay looks is going to be dependent on -- all the pieces won't fit in the space that you have. You've got to shave some off.
Now do you shave it off the brown piece or the white piece or the pink piece or the green piece in order to fit that together into that mosaic of a electronic commerce? That's the charge that I think that we have. If they fit in right next to each other, and they are going to work, then that is well and good. I haven't heard what needs to be shaved either from yours or from somebody else's to make all those pieces fit together, and that certainly is our charge to do that.
DR. HAMMOND: I think this is the root of the matter that you have it upon. Using your analogy, I think to some extent it depends on what you are trying to fit all these standards into. If I clearly have an outline that is on my board, and I'm trying to take these different pieces and fit them in, then I may have a lot more constraints on how they fit together, than if I fit the pieces together and then I fill in the rest of the outline, if that point is made.
Again, being very personal in this, and I have implemented all the standards, and it has been very clear to me up until now -- and that's an important caveat to make -- up until now, which standard I was going to use for which thing. It wasn't an overwhelmingly business problem for me to implement all of those standards.
I knew exactly when I wanted to use NCPDP, because I had a situation in which I was getting reimbursement for a drug and that was clear; using HL7 for the clinical data exchange. I'm using DOTCOM for images, and I'm using X12 for doing the 835, 837, all those sorts of things. So at least in my mind this is fairly clear. Now whether it's clear in the future I think is another question.
I also think it's very important to recognize the fact that you are not starting with a clean sheet. You are starting with something that is already on that sheet. In my opinion, that really has to dictate what is going to happen. There is a tremendous amount of dollars that are invested. There are commitments to various standard levels. I personally think that these can fit together.
Now where the future goes I think is a very important issue. I do think that the different SDOs have made amazing progress in terms of working together. There are fundamental things that we can, without interrupting what we are currently doing, work together.
This common data dictionary is something that all of us are in the process of creating, and it is very clear that we can create that together. That solves many, many of the problems and the frustrations that we have now.
The second kind of thing is a common kind of business model if you will, of where there is again, the kind of similarities. To me, to a large extent, content is somewhere in between those issues of defining what I send, when. To me, syntax itself is way down the list in terms of concerns that I have, because there are a finite number of syntaxes that are available to us, and I think not a really big deal to be able to manage several of those syntaxes.
So the damage that would be done by picking one standard versus the other standards, I think may be more than we ought to accept. I think that what scares me as much as anything is a misunderstanding of what this committee recommends, because if you focus on one component of what we need standards for in this data interchange area, restricting it even to that, then whether that gets read correctly, or misread by the industry at large and creates lots of problems, versus recognizing the fact that there are many components and many facets to this.
The business commerce is one piece of this; the clinical piece of this, there are other pieces of this. So what I'm encouraging you to do is really look at least at the broader picture. Whenever you come forth with your report, be very clear as you can in structuring what your recommending in context of the broader picture.
MS. NARCISI: As far as the dental claims go, those are simple. There are only a few pieces of information that need to be transmitted on a claim. There really is only one code set to use, and those are the ADA codes. Those are procedure codes. As I mentioned, we don't submit additional information as far as diagnostic codes currently.
So that's simple. The reason that we were saying that there should be a migration is that the majority of the claims now are sent using proprietary formats, because the X12 standard 837 is not built into the practice management system. The clearinghouses maybe can handle it, and the payers clearly cannot handle it.
So we are saying if you would make that recommendation tomorrow, if there are only 10 percent of offices right now submitting claims electronically, they probably wouldn't invest to continue doing it if they had to put the money to pay for the upgrade. So we need to work with the vendors in between time to the MD156. Those are simple kind of answers for dental claims for the financial transactions.
The other area that you are talking about, the clinical applications, we need to interface with what is going on in medicine. As Dr. Hammond has stated, those pieces aren't there yet. You have to understand that that can involve all of the SDOs working together in some of those other things, the data dictionaries and the crossmappings and so forth to be finalized before your report.
DR. LUMPKIN: Where do the oral surgeons fit in there?
MS. NARCISI: The oral surgeons can fit both in for the dental claims and for medicine. So that's why we need to interface with what is going on.
DR. LUMPKIN: Jeff?
MR. BLAIR: I think that part of the answer in how you reconcile the selection process is conveniently outlined in the bill itself, because it sets forth that we need to make decisions within 18 months on for the most part, the reimbursement transactions. It is those 9 or 10 transaction codes that are outlined there.
It gives a very short runway. I think it is clear that from the testimony of all of the different SDOs, that the problem we have isn't so much overlap, because you can see by NCPDP that it is in the pharmaceutical area, and X12 has payment claims standards -- the whole spectrum of standards. HL7 for the most part, complements the others in terms of clinical transactions, and the ADA fills in where the others don't.
So I don't think our problem in the first 18 months is in terms of a lot of overlap. What happens, however, is that the bill also winds up indicating that I think it is 44 months away we have to create standards for computer-based patient records. There is where a lot of the convergence takes place. I think that whoever set forth that date, set it with the basic understanding that things have not converged. There is a lot of work to be done before standards can converge on that.
I think that maybe you are also beginning to hear from a lot of the testimony is that a lot of the SDOs have begun to work together, because we see that vision coming. It is in the best interests of our users. The vendors know that they have to produce products that can work in this new environment, because the users are demanding it.
The nation as a whole is beginning to wind up saying, when we wind up getting the rising cost of health care under control, the next immediate thing is our ability to be accountable for quality. We can't do that until we have the information to measure and manage quality. We can't do that without a computer-based patient record as the major part of that core component of the health care information infrastructure. So I think we all see that. In a sense, we are all marching to the same drummer.
So getting back to your question, the near-term selection process is more pragmatic. It's in terms of what is out there that is ready, that can work. You may come back to us with requirements that we enhance our implementation guides; that we come up with certification and conformance requirements that are more stringent.
So there may be some finetuning to get ready for mandates, but in the near-term I think you have a great deal that you can kind of work with.
Now the other work effort I probably won't get into at this time, that is a whole different subject; a lot of folks have touched on it in terms of coming up with a common medical vocabulary, interoperability among standards and information, common data models, all of the rest. So I think we'll just leave that to later time.
MR. STANIEC: Dr. Lumpkin, getting back to your statement about creating the lumber or the piece of wood with the different colored segments, the reds, yellows and greens, I would like to offer the suggestion that look at those pieces and the status of them. Are they widely used and implemented?
Basically, what is the status? Is it ready to roll now, or is it basically still in production? Again, with pharmacy there is really only one standard today, and that is the NCPDP standard. The X12 interactive is still in development, and the 837 is really not conducive to pharmacy based on the business needs; that was explained earlier.
MR. BARRETT: It is a very complex issue, Dr. Lumpkin, as you known. I think that there is obviously a lot of information that has been put forward. I think what it's going to come down to -- and I think you have heard from several people here, there is a lot of that information.
I think it's a matter of coming up with a matrix that is going to look at what is being used, looking at the legislation itself, and words employed, implementation guides, and coming up with a matrix of the criteria that is needed, and looking at the existing standards that are out there, and how they apply.
It sounds simplistic; it is complex. There is a lot of criteria there, but I think that a lot of that information is in fact there. I think the only way, if I was to be looking at it from a committee perspective, I think the only way objectively that you can look at it to try to come to the decisions that you need to would be to put together a matrix of the criteria, and then start evaluating the criteria and the standards against it.
I don't know of another way that you can easily do that, because there are just so many different issues that are out there, and I think you need to look at the criteria, come to consensus probably on what that criteria is for the matrix and apply it.
MR. MAYES: Bob Mayes, Health Care Financing Administration.
There seems to be general agreement in all our discussions that certain existing standards fulfill the business needs of particular transactions. The legislation, however, does require that we look at what we are calling supporting standards. These have to do with security, confidentiality, code sets.
I guess my question is, let's assume that we decide to pick a unique patient identifier, or we go with a certain security standard, is that going to cause a problem in applying it to each of your different standards for transactions? That's where we are already going to begin to see this broadening. Even if we go with NCPDP and ADA, if we decide to choose a particular identifier or a particular security standard, will that create a problem?
MR. MOORE: Let me be a little more specific. They already know a lot about a payer and provider that is out there. How will that affect you?
MR. NGO: To follow-up on the suggestion, you need to put together a matrix. I only agree with that. A matrix would be rather complicated, because management should be multi-dimensional. So I would suggest you use the framework put together in the ISO 11179 for data registration, and use that framework to form the different components of the matrix in there.
DR. LUMPKIN: In reference to the last question, I saw when the question was raised, everybody kind of shook their head and said, no, it's not a problem, because that didn't get on the record.
MR. STANIEC: Dr. Lumpkin, I would that at the Work Group for Electronic Data Interchange, WEDI had a meeting in Phoenix several months ago. They basically have started a matrix that you are talking about. Some of the factors they are looking at is they looked at all the possible standards that could fit into those 9 or 10 types of transactions specifically mentioned in K2.
They talked about the ease of implementation. They rated them from 1 being very easy to 10 being not at all easy to implement; the number of electronic claims that would actually be generated if that claim would be chosen; and the amount of implementation and wide use of that particular standard. I believe WEDI is going to present that, if they haven't already to Bill and to this committee.
DR. LUMPKIN: Great, although as I understand it, that's a verboten word, so we're going to refer to them as transaction graceway.
DR. HAMMOND: I would like to ask, Bob, I didn't understand your point.
MR. MOORE: The question was that there are a lot of supporting standards outside of these transaction sets that have to be adopted. Identifiers is going to be one of those. Two of the first regulations out of the box, I think before we even get to transactions later this year, are going to be the identifiers, as well as the payer identifier, employer and provider.
There is a lot of work on the part of everyone to adopt a new identifier. What kind of problems do you perceive from those identifiers? I know I have shared that information with a lot of you as to what is out there, where we are coming from.
DR. HAMMOND: Just a quick comment. One is that I think that there is no such thing a professional developer. All of us really treat the work that we are spitting on standards, as a necessary thing we have to do to get to what we have really been trying to do all along.
In the state of North Carolina we tried to create a statewide physician/provider repository. We were going to put everything in it about that provider, including all the numbers. We found that it was so complicated, we were not able to do it, because there were so many numbers, and we didn't understand how the numbers were to be used, because there were so many parameters.
So the truth is that giving us a single number lets us do something that we were absolutely unable to do otherwise. Now I recognize that adapting to these identifiers is going to cost a lot of money. There is no question about it, everybody is going to have to pay money.
My belief is that again, if we are convinced that the numbers are going to stick, that there are going to be unique and only one that does that representation for us, that most places will be willing to spend the dollars in a one time effort to fix what we spend lots of dollars for trying to get around.
So I think it is good news. I think it is important to recognize that it needs to be ubiquitous; that it really needs to represent all of those people that we have to code within our systems. If you do it, I think we will welcome it with open arms.
MS. NARCISI: With respect to the unique identifiers, we support the NPI. We will be working with HCFA and the department to see how we can coordinate our information. Every dental student that graduates from a dental school and becomes licensed, we have them registered with the ADA, and have current information on them. So we need to work with the department to make that a workable entity.
MR. BEATTY: Within the X12 standards we also support all of the identifiers.
DR. PETERS: If I could take off my SDO hat, and put a vendor hat on for a minute representing two different companies that work in the CPRI area, if you look at the statement that Ed has made and the others have made here in regards to code sets, and that's a secondary standard so to speak, or something that needs to be considered in the process, the biggest investment by the vendors is specifically in code sets, not in interface engines or in mapping.
Mapping is something that I agree with Ed 100 percent, that is not a big deal. We can do it even if you support it for separate standards, and you separated out pharmacy claims from other claims; that's not the issue.
What is very important is that a fair amount of concentration be put on the code sets, which I know is another agenda and another meeting, because the best code sets available and the least argument and discussion about itemized, finite data elements is among the vendors. The best code sets, and the most finite and granular code sets, and the ones that are mapped to more standards than anyone else are the proprietary ones: MEDCEN, Oceania, Datamatic, Health Point.
These companies have invested millions and millions of dollars in building finite code sets just so they can deal with the non-standard world. So again, just to reiterate, I think code sets is a critical thing. I don't think that the different issues in terms of standards for transactions and how you group those transactions, or if you take that code set and make a number out of it, that NCPDP consist in or X12 consists in or HL7 consists in is a big deal in the vendor community.
DR. LUMPKIN: Let me understand what you just said. The development of the code sets within the vendor's product is where the costs are? Or licensing code sets externally is the cost?
DR. PETERS: For the customer, most vendors pass the licensing on to their customers. Or the in-house development, such as Ed and his group at Duke, they will buy those licenses outside. Vendors who are building systems need to have a much more granular set of data just to run their systems, and to collect the data. Then we need to do transactions for sending a claim, or transactions for sending a prescription, or transactions involved in a lab transaction.
DR. HAMMOND: I think it is important to note that in HL7, in building its reference information model, we derived much of this from a number of vendors that contributed their internal data model. I think there were about 18 vendors and institutions that contributed to that single set.
My belief is that we also will find that level of cooperation among the vendors in terms of the vocabulary. The problem is they develop these code sets to exist within their own system, but the model now really makes us talk to somebody else. That is where the time, that's where the cost, that's where the negotiations come. Again, that's a fantastic resource to begin as a starting point. I suspect they would be willing to share.
DR. PETERS: I agree with that.
MR. MANN: I'm Douglas Mann from Battelle(?).
Very often we talk about code sets and things, but there are many underlying standards that are there. For example, one that is rather up in people's minds at the moment is the representation of date. For example, the year 2000 problem which is talked as a multi-billion type of problem.
Having gone through the SDO process of revising the date standard, it is interesting to see some of the commentary that is coming back. There are other SDOs, some of which are represented here today, that are objecting to representation in a consistent form of date and such that in one transaction set, date is represented one way, in another transaction set date is represented in a totally different way.
Some of those have the year 2000 problem, so there are very basic things such as date and time that ripple through everything, and yet need to be addressed to say what direction are we going.
DR. LUMPKIN: Transaction?
DR. BRAITHWAITE: Well, I have a question to full panel about implementation guides. Ed has mentioned that implementation guides have to be available and freely distributed. In fact, the law requires us to provide low cost, easy distribution methods for all of the standards that we produce.
In fact, it seems that everyone agrees that a standard is not a standard unless there is a very precise implementation guide that makes it implementable in a standard way.
Then Ed turns around and says that HL7 seems to want to make some money so that it can continue to maintain its existence and its standard by selling the implementation guides. I look in the description of X12's standards and it says implementation guides are not needed for X12, which I think we have heard here is in fact not true.
There is a problem here. How are we going to provide enough resources for these groups to continue to maintain the standards, and maintain their existence, while providing the implementation guides in a way that they are freely and opening distributed?
MR. BEATTY: The standards as they are defined, up until WEDI started developing implementation guides, trading partners agreed to implement the standards, and an implementation guide, in a black and white world, is not needed between two trading partners.
When you get to the point of doing mass implementation, like what we are talking about here, it is imperative that an implementation guide exist. In the inventory of standards that we submitted for the Health Care Infomatics Standards Board, we stated that fact, that for mass implementation for consistency's sake, that they are necessary.
X12 has taken on that task within the insurance subcommittee, and we have completed the development; they are out for public review. Once we complete that process, we are going to be having those informational forums in April. After that time, we'll do any last minute editing types of checks. They will go out for formal publication June 15.
They will be available free of charge on the Internet to anybody who needs it, and can obtain it from there. If there are people that cannot obtain it from the Internet, they can go to our selected publisher, being Washa(?) Publishing, to obtain paper copies if they so desire to do that.
Then there are other more value-added types of services. If people want the gooey types of things and the pretty pictures and so forth, they can also obtain those. So the X12 and implementation guides will be available free through the Internet, as well as other sources.
DR. LUMPKIN: Let me just see if I understand something about this implementation guide. Is that a consensus document?
MR. BEATTY: That is the consensus document that was developed within X12 and insurance subcommittee. It is voted on and approved within that committee.
DR. LUMPKIN: It has a version number?
MR. BEATTY: Yes, it does.
DR. LUMPKIN: If it changes over time, one understands that one may be dealing with two different documents?
MR. BEATTY: The answer is yes.
DR. LUMPKIN: Did you have a follow-up question?
MS. COLTIN: Yes. Are these implementation guides the specific to different industry sectors? I thought I heard Jean Narcisi saying that the ADA had developed an implementation guide for the dental claims, but I haven't heard whether for instance, if you're a home care provider using the 837, do you know which of those data elements applies to you and how it should be used?
MR. BEATTY: Currently, X12 is in the process of moving forward with I believe 13 or 14 implementation guides. There are a few other ones that deal with some of the attachment types of issues; that's kind of a future type of a process.
Those implementation guides -- for example, I will use the health care claim, which we have talked about now -- there are actually several different implementation guides that focus in. One of those guides was developed along with input from the American Dental Association for dental claims. We have one for professional services, one for hospital services.
Home health care was wrapped into -- the home health care EDI coalition brought their business needs in to the X12 process and their implementation guide. That was incorporated into those implementation guides.
Some of the other transaction sets like claims status has several implementation guides that are unique to just claims status process. They very specifically hone in on a business use of the transaction set. So we do get very granular in how to use these transaction sets within our implementation guides.
MR. BARRETT: So we didn't create just one, and say one size fits all, but in essence we tried to break it down.
DR. HAMMOND: I have to claim my innocence. I didn't mean to say what you thought I said. I think that it is probably semantic. The HL7 standard itself really includes an adequate amount of material in it that would normally be called an implementation guide. That is available on the Web. The latest non-final version is free for looking internationally, and quite a few people pull it down and look at it.
The definition of an implementation guide that I was talking about when I was talking about a value to the membership itself really went beyond what was necessary to implement the standard itself. My belief is the HL7 standard itself includes enough implementation strategy and implementation examples that you can implement the standard with no problem, with just a guide.
I think that is in contrast to some of the other SDOs in which the standard is more generic, and the implementation guide itself is very important in pulling the pieces from that standard to put into a particular environment. In the case of HL7, we have one community across the board, whether it is home health or whether it is a clinic or a hospital, what have you, that basically is built into that.
So the thing that I think that we label an implementation guide is somewhat different than what you had in mind. So I would argue with you first of all that I'll never say that again as a first step, but I think you need to recognize the fact that there are semantics involved in this too.
DR. STARFIELD: I have a question for Dan, and I think a related one for Jean that has to do with coding systems. You may know that the core data elements recommended an item on medications. Do you have any problem with that? The assumption of putting it in there of course is that it is useable in concert with the other elements in the core data element set, what the physician does, what the nurse does, that it all can be translatable.
MR. STANIEC: I don't have a problem with that.
DR. STARFIELD: Jean, do you have any problem with that? You don't use diagnoses. You know physicians do use dental diagnoses; they are in the ICD, but you don't use them, is that right?
MS. NARCISI: Right, they are not expanded enough for the dental claims.
DR. STARFIELD: You do use diagnoses, but not for claims, is that what you are saying?
MS. NARCISI: There are no standardized codes available for dental. So that is what we are working on right now.
MR. STANIEC: Dr. Starfield, again, regarding medication for the core data elements, again, we recommend is the NDC number for pharmacy. There are some limitations with compounds, some of the medical durable device goods and so forth, but the NDC number is good.
DR. STARFIELD: The codes you are likely to come up with will not be compatible with the ICD dental codes?
MS. NARCISI: Yes, what we are doing is developing the system based on the SNOMED system. We are mapping the ICD-9 codes in that system, so that if it is necessary to use an ICD-9 code, that will be available.
DR. LUMPKIN: Well, it is time for us to have lunch.
MR. ZUBELDIA: I tried to do this before, but maybe I'll do it now. It looks like we have heard some sort of very strong consensus between the testimonies of yesterday and today that for the administrative side, as far as the conceptions and standards are concerned, the pharmacy claim is NCPDP; everything else is X12, with the possible exception of the clinical information and the attachments.
Something that hasn't been mentioned, and I think it is worth mentioning is that X12 has a patient information transaction, the 275, that was mentioned in Lee's presentation, that was assigned to carry an HL7 transaction inside of it. It was assigned to convey a digitized x-ray or a word processor file, WordPerfect or Microsoft Word, or whatever you want inside a 275 transaction as a transport mechanism to send those transactions in the X12 environment from one entity to another.
That would take care of the attachments by converging the inter-entity transport in X12 and NCPDP and leaving HL7 for what HL7 was designed to do, which was clinical transactions within one entity.
If we take care of all the standards that way, where each standard is applied for what it is designed for, and without really having to fight off any rough spots, and using some of the grout in between the pieces. The only other issue left is do we have enough time to make these pieces, and let the grout dry before the two years are over?
I think that we have heard that the ADA believes there is not enough time for the migration. There is a very large contingent on HCFA, because there are thousands of the submitters of the proprietary NSF transactions. There may be an issue whether there is enough time to migrate to what seems to be the standard that we all really converge on, which is the combination of HL7, NCPDP and X12.
Sorry, I don't have an answer for that.
DR. LUMPKIN: I thought that was her job to ask questions that don't have answers.
We're going to adjourn for lunch, and then we are going to reconvene with the subcommittee discussions. We're going to do that at 1:30 p.m., as scheduled.
[Whereupon the meeting was recessed for lunch at 12:45 p.m., to reconvene at 1:30 p.m.]
A F T E R N O O N S E S S I O N (1:55 p.m.)
DR. STARFIELD: This is the subcommittee meeting. As I described yesterday, our task includes work group and the health insurance portability and accountability act, but it also is broader.
The first item on the agenda is to set the date for April hearings. These hearings will be on coding systems. I think we have a date.
MS. GREENBERG: April 15.
DR. STARFIELD: We will start, if it's okay with everybody, at 1:00 p.m. on the 15th of April and go through the 16th, ending perhaps at about 4:00 p.m.
The other things that are on the agenda for this hour of our subcommittee meeting are first of all to do the draft charge, which is being copied.
Then also I thought we ought to talk a bit about the relationship between the work group activities and the subcommittee as a whole; whether there are things that the subcommittee has to think about as it has heard about the work group activities and what comes out of that.
The third thing on the agenda is to hear from George Van Amburg about the document that he handed out in November. Why don't we start with that one, George?
MR. VAN AMBURG: Well, as you recall, at the last meeting of the full committee I handed out a document that was a series of recommendations on community health assessment and the related data and statistical support for that, that was the result of about a year and half's worth of hearings by the Subcommittee on Community and State Statistics.
We wanted to get some comments back on that, because I would like to get that through the full committee in March, to send recommendations to the secretary. I have heard from two people, both with favorable comments. So if you can take a look at that and read it, we would like to get that done at the March meeting, and get that out.
DR. STARFIELD: Are those two people here?
MR. VAN AMBURG: One is here. It's Lisa. The other was Elizabeth Ward.
DR. STARFIELD: I read it. It looked fine to me, so you got my comment.
What's the mechanism for getting comments from people who aren't here?
MR. VAN AMBURG: Can we send them an e-mail?
MS. GREENBERG: Yes. This is a subcommittee?
MR. VAN AMBURG: Right.
MS. GREENBERG: And ask them to get you comments with a week at this point. That's reasonable; they've had it a long time. Then we can put it in the agenda book.
MR. VAN AMBURG: The agenda book for the March meeting.
DR. STARFIELD: I wanted to ask you a question, George, about the states. We talked yesterday about having a panel on state examples. We were thinking of that in the context of administrative simplification. Do you see any potential for adding on to that, some of the issues that are in your document, or broader issues that might be related to the administrative simplification?
MR. VAN AMBURG: I think in the long run these two things are going to be very closely tied together. I don't think we want to lose sight of the public health and community assessment issues in this administrative simplification, because there is a lot of energy focused on that right now.
As states -- particularly like our state is reviewing its Medicaid data system, and what we are going to get on an enrollment encounter data set, this ties right into the administration simplification issue. So I think that we ought to bring up some of these issues; that they should not be lost.
DR. STARFIELD: We talked yesterday about four states I think in that context. There probably are others that we might want to include as a part of that -- New York -- particularly as they are working on the core data elements.
MR. VAN AMBURG: Minnesota was one; New York.
MS. GREENBERG: Were you talking about sending something written to these states, and asking them to send something in?
MR. SCANLON: We could actually call them. We have some contacts in those states. So we'll call them and ask them to send in whatever write-ups they have of what they have done, and maybe at the early April meeting actually have the states come in as a panel meeting.
MS. GREENBERG: In April, in addition to the classification stuff?
DR. STARFIELD: We talked about late May or early June, or we talked about the alternative of us getting written material. Maybe we could ask for the written material relatively early, so that we could make decisions in March.
MS. GREENBERG: Gail was staff to the Subcommittee on State and Community Health Statistics. She is willing to work on this in putting it together.
You might get something more consistent from the states if you at least pose a few issues and questions relevant to the --
DR. JANES: Obviously, that dovetails very closely with things CDC is interested in.
DR. STARFIELD: So why doesn't George work with you in identifying the states and the questions, and I will be glad to work with you about core data elements.
DR. JANES: Okay.
DR. STARFIELD: Can we turn now to the charge? I sent to all of you on the 4th of February, a draft charge to the subcommittee. I have heard from only one person. George provided me with some suggestions, and I think, George, that I incorporated them. That's what you are seeing in pencil there.
So the floor is open for discussion.
DR. IEZZONI: Barbara, could we add patients to item number two, when we are talking about health data needs, standards and security.
DR. STARFIELD: The one that starts, "Through a variety of mechanisms?"
DR. IEZZONI: Yes. We have a variety of groups that we want to liaise with and serve as a forum for, but patients aren't among them. I don't know what kind of words we use, because "patients" is not the correct word.
DR. STARFIELD: Consumer groups. Do you want to suggest where we should insert it? How about first?
DR. IEZZONI: First.
DR. STARFIELD: So we'll start with consumer groups, the health industry, and so forth.
MS. GREENBERG: Do you want to refer to professional associations? This could get endless, I guess.
DR. STARFIELD: That's the industry I think, isn't it?
MS. GREENBERG: The subcommittee has been a forum for a number that don't really fall into standards organizations or even the research community.
DR. STARFIELD: Wouldn't it be subsumed under health industry?
MS. GREENBERG: Maybe.
DR. STARFIELD: The more specific we get, the more we are subject to the criticism that we left out something.
MR. VAN AMBURG: I move we adopt.
DR. STARFIELD: Do I hear a second?
MS. COLTIN: Yes.
DR. STARFIELD: Any discussion on the motion? All in favor?
[Whereupon the document was unanimously approved as amended.]
Okay, so we will pass this on then to the full committee.
MS. GREENBERG: We'll put this in the agenda book too. We just added consumer groups?
DR. STARFIELD: And add what I have written in.
Now I think we can turn it over to -- there are really two things we want. First up, maybe follow-up on yesterday's discussion of the survey integration. We ought to have some thinking in the subcommittee about how we want to follow through on the kinds of things that Ed and Ross were saying yesterday. They listed several areas that they would like some input from us on.
Does anybody have any thoughts about that?
MR. SCANLON: One, Barbara, I think specifically the committee could help with, one of the first projects you heard Ross and Ed talk about -- and this is area of sort of the next stage of the development of the survey integration plan. We started a project here in HHS to rethink the way we approach provider surveys and provider data collection, and really redefinitions of entities, given the changing landscape in the health marketplace.
So the committee could actually help quite a bit there in terms of are there other classifications, other ways of approaching the definition and the classification of providers for example, or health care settings? You would need more guidance. What we would have to do is share some of the material with you.
We have a contractor doing some preliminary work on are there any existing classifications? What do people in the industry now think about the traditional ways we have defined entities, and why they no longer apply? Perhaps when we get that first product back, we could share it with the committee, and use it as the basis for discussion.
DR. STARFIELD: There were five things that Ed listed. One is to help keep surveys in the context of other data sources. A second one is thoughts about redesign to fill gaps. The system is moving and the survey's current design may not be right. Three, setting priorities across survey areas. Four was to help keep pressure on free interagency collaboration. The fifth was specific tasks like the details of linking surveys and the providers, that you just raised.
Do you have any thoughts about which one we should pick off right from the beginning? My thought is that perhaps since we are putting so much effort into the other data sources this year, and probably that will be the case over the next couple of years, that maybe we ought to start with them while we are talking about clinical data sets and transactions. Maybe we could think about the surveys in the context of those.
DR. LUMPKIN: I'm wondering -- and perhaps because I'm new to this committee -- I'm not sure I understand the vision for our surveys. What is it that we want to know about people in this country? What is important as a nation in health statistics? Within that context, if we have an understanding of that, then it is easier to prioritize and to identify, and to see to what extent our current actions are meeting those needs, or maybe we ought not to even think about this kind of survey; maybe there is another kind of survey.
Then once we've got a vision, we can begin to look at where the current sources of data now exist. What data is available from states? What is available from the health care arena, versus what we have to actually go out and get? Perhaps we can serve as a forum to hold that kind of discussion, because there is too much of a tendency to just keep on doing things because we have done them before.
DR. STARFIELD: Well, you just came off the IOM committee that just finished, right? What was it called? Does that provide us anything that would help in framing it?
DR. LUMPKIN: No, I think they were looking really at performance measures, and really focusing in at the community. That is a much smaller picture of the puzzle. The data needs at a community level I think are going to be different than the data needs at a national level.
DR. STARFIELD: Do you know of any existing framework?
MR. VAN AMBURG: I missed the question.
DR. STARFIELD: You had something you wanted to say apart from my question?
MR. VAN AMBURG: No.
DR. STARFIELD: Were there existing frameworks that might be helpful to the subcommittee?
MS. GREENBERG: The pyramid that Kathryn and Lisa developed was an attempt to look at the overall, what do you want to know, and going from the broadest questions, down to actually data elements.
Also the transformations work, Jim, under the Data Council, in which it looked at the changes that are happening and anticipated to happen in both health and welfare, and how the current data systems or data capabilities in the department relate to that. I think Bill Raab actually reported twice to the committee on that. I think you have the final report, but that is continuing between Bill and Ed Sandick(?) are continuing that.
MR. SCANLON: Yes, there is no such thing as the grand vision for surveys in a way. We go through reinventions where we rethink what do people want to know. It's a continuing question, and that interacts with mechanisms as well.
In this last iteration with the survey integration plan, clearly the thinking was that there are certain segments you want to focus on -- households, employers, providers, the utilization of health care, expenditures and so on. There is a certain conceptual model that reflected in those. Then there is a broad population-based interest in general.
A lot of what we have been talking about here in terms of administrative data is often numerator data. The surveys are intended to enforce standardization through the research process where it doesn't exist, and you try to fill gaps.
Our biggest challenge I think, is in the provider area now, not only with our providers. What's a plan? What's a provider? Rethinking that area. I guess I would rather see the committee focus on something that is at the right level of focus, where it's a definable problem. The thinking of committee could actually help, rather than going off on what's the meaning of life, and rethinking these broad visions.
The other area is the whole public health area. There is still somewhat of a tendency for public health to go off each on a categorical tack. I hope some of the standardization effort here will preempt at least future attempts at that. How do the standards here interact with public health data needs, and public health data in general?
There are three or four initiatives in the public health data area where they are not really part of the integration plan particularly, but they have arisen in the context of health officers and others like John, coming to the department and asking for some conceptual work. Let me tell you what they are, and see if the committee would be interested in following up.
One of them is basically an attempt to pull together a registry of all of the developments that states are undertaking in integrating health information systems at the state level. We had a contractor go out and try to get information from virtually all of the states. Actually, Bill, I think we have this up on the Web site now for about 30 states.
We wanted to see -- a number of states, as John indicated, were trying to integrate across the health departments in terms of standards and information systems. Some of the cross into the welfare side as well. So we have at least most of the registry done. We could have a presentation on that, and you could see whether -- there are clearly issues there.
States approach things quite differently. They often ran into the same problems, privacy and confidentiality issues, standards issues and others. That is an attempt to look at what states are doing in terms of their own restructuring and integrating information systems. That would be probably worth a presentation. I'm not sure what specific issues the committee would want to follow-up on.
The other is a broader area in one sense, and it really arose out of the lack really of any kind of systematic information on expenditures for public health services across the United States. We have elaborate information on personal health care expenditures; published every year in fact. Our department does a very good job of pulling this together.
Of course the public health part of that is about not even 2 percent. Even in that amount it was very difficult to find out what exactly that investment was being used for. So Dr. Lee asked if we could begin some conceptual work on a strategy for public health infrastructure data.
That is well along now, that project. There is an advisory group. People are trying to look at what might a strategy look like, what data are needed, and how do you get from here to there? So again, that is in the public health data infrastructure area.
John has just come off a panel at the IOM that dealt with how do you use performance measurement at the community to improve health? That report is completed, but as John said, it's focused largely on the community assessment process.
There is another project that is about halfway through that looks at how do you use performance measures and data to support these new grant arrangements between the federal government and the states, performance partnership grants. Clearly there, there are a lot of implications for data sources in the future.
In addition, the department continues with Healthy People 2000. I think all of you are familiar with those objectives. In fact, next week there is a review of the data systems area to support those objectives.
DR. STARFIELD: Tom LaVeist is attending for the National Committee.
MR. SCANLON: I guess I would add a third area. We are doing this --
DR. STARFIELD: I get six.
MR. SCANLON: A seventh area. It is in the area of state data strategies. You could come at this different ways. From the department's point of view, the department would like to be able to put together comparable information on as many states as possible. Now for some areas you can do this. Vital statistics for example, it took a few years to get that to the point where it was standards.
MR. VAN AMBURG: The Cancer Registry is another example.
MR. SCANLON: Obviously, I don't think anyone believes we can afford to do personal interview surveys in all 50 states. So the department is now looking at how can you approach this problem of a need for state level data, when you know you probably can't do actual -- send interviews out to every household.
There are a couple of ways to go at this. One is through a telephone survey, where states and the federal government could kind of agree on certain modules, and then we would use the centralized telephone survey mechanism that we have as part of the immunization survey.
There are other ways. We are also looking at how far can you push the national surveys in terms of state data estimates. Usually the surveys have maybe half a dozen states where if you push for certain variables, you can actually make state estimates. We have a project in that direction as well.
So we could use advice in all of these areas: the provider area, how do you approach state level data area, and understanding that it is more than one mechanism. It's a lot of different ways; the public health data area as well. How do they all interact with what is going on now in administrative.
DR. STARFIELD: What about the CDC effort in linkages with managed care? Can you update us on that? Are there data issues there?
DR. JANES: There are definitely data issues there. Kathy and I are working on a program, a CDC managed care collaborative project right now, looking at low birth weight and the ability of linking/comparing across administrative data sets, and public data sets.
I would say at this point the issues are being explored at CDC, and there are some very preliminary projects which are in the works. The process is very immature.
DR. STARFIELD: Is it mature enough to share?
MS. COLTIN: There are some broader issues that are starting to arise out of that work, and out of a conference that CDC sponsored recently in Atlanta around some of the difficulties involved in trying to share data, as well as linked data between managed care organizations and public health departments, or other departments in states that hold data repositories for various types of data in that state that I think would probably be germane to our discussions around data security and confidentiality issues.
A lot of what we ran up against when we tried to make these linkages are those kinds of policies, and the way various states are administering those policies in different ways. It is easier to do some of this work in some states than it is in other states.
DR. JANES: I would broaden it even beyond that. I think in sitting and listening to the testimony over the last two days, in any number of this issues we talk about, about what these transaction data sets are going to look like, I keep thinking about the interest that I know that is out there in the states of certainly finding out what is in these administrative data sets, and the possibility of using them for public health needs.
As Kathy is alluding to, once you get beyond that conceptualizing stage, there are a host of structural and practical issues -- issues of common identifiers. That you can practically do that linkage confidentially; confidentiality issues, legal issues impact on that.
We were talking a bit about this at lunch. I would love to see at some level, us take a look at some of these issues, as well as consider some of the recommendations that they are going to make.
MS. COLTIN: And to look at some of the work that is going on under K2, and how it will contribute to improving some of those problems. One of the big issues that we had in trying to link our data was even on the hospital ID, that in birth certificate files they use a department of public health facility code, and in the health plans we use the federal tax ID code, and there is no crosswalk between the two. We had to build one.
It's things like that, that I presume will be solved by the MBI. Just thinking about how those kinds of issues might be resolved under some of the provisions.
MS. GREENBERG: I was just thinking with Jim talking about the provider surveys and how they really are under the spotlight now. You mentioned about trying to look at how the surveys interact, or the synergize between them and KK stuff.
I think the provider surveys is where a lot of that is going to happen, because even now the hospital discharge data systems for the national uses are being built from either state level databases such as HCUP(?), or from abstract systems that states have. The potential for that is considerable with this encounter data.
Certain things will make it more or less feasible or desirable, but there is certainly a link there with the provider surveys very much linked to the standardization stuff.
DR. STARFIELD: The whole trouble with what we are doing right now with KK is that it is not the whole population, and it will be a long time before it is approved.
MR. SCANLON: The numerator particularly for encounters.
DR. LUMPKIN: I'm going to try again, because I don't believe it is pie in the sky. I really believe that when you look at successful businesses and industries, they have a clear vision. They have an understanding of who their customer base is, and how to meet their needs.
In the information and data business, we need to better understand that. All of these little pieces that we are putting together, and many of the surveys -- and I think they have all started from very concrete reasons -- but where do they fit?
We don't have unlimited resources. We're certainly in a very scarce resource environment in relationship to information concerning the health of the people of this nation.
If in fact we determine that our need for provider surveys is a fairly well circumscribed thing; we want to describe what is going on in the provider community, it may turn out that there are in fact data sets that exist to meet that need. If we have a different need and different users within government and policy for different kinds of data, then that would prescribe a different kind of data set, and a different kind of survey process.
So I think we need to give advice on individual surveys, but I really don't want to have us discount the need for a broader data vision, because that sometimes is what can sell. You will take somebody in Congress or somebody in a policy level position; they may not understand how this survey fits in with that survey, but if you give them a vision, give them a mission and a goal, and how that fits in with everything else, it becomes comprehensible.
That often is our trouble in the area of information and data, is trying to explain things to the governor's office or to the White House or OMB, how this really fits in with everything else that is going on.
So I think that we need to look at that, but perhaps we need to think of some mechanism to try to put together a bigger picture too.
DR. IEZZONI: I just feel weak hearing what John is saying, because he is absolutely right, but there is just so much lead time in surveys. That is one of the problems. If you read that cute article that appeared in that journal about the -- Ross Hunter's article -- it really talks about how there was kind of a vision in a negative sense, about data because of the health care reform effort, and the absolute gaps in data that became obvious. The policymakers were the ones that were pushing the need for information.
I wanted to say something more concrete. I'm sitting here thinking and listening, and there are all sorts of wonderful ideas running around the table, lots of them. Then I'm thinking, gosh, I committed myself to listening to a conference call every week, the coding and classification group. I just agreed to be in Washington for like five days the week of April 15th.
How are going to manage to fit in a piece of survey integration oversight? We need to bite off a chewable piece. This is one instance where I am going to say something that will probably be extremely inflammatory for my colleagues, but this is one instance where I don't feel as if I have the energy to guide what I think we should be looking at.
I think I would very much take my cues from the people in field, i.e., the two gentlemen we heard from yesterday afternoon, on what they think they need our advice on the most, and maybe just concentrate on that. I just think as a group we are not going to have the time or energy, given all the other commitments that we have, to do much more.
DR. STARFIELD: Perhaps we can agree that we're not going to have hearings on this.
DR. IEZZONI: Yes, I think we would agree on that, absolutely.
DR. STARFIELD: So what we will do will be in the meeting.
DR. IEZZONI: Right, and I think we need to bite off a very chewable piece. I like the notion of thinking about the provider surveys, because I think that that does link to what we are doing on the HIPA(?) stuff. It is a piece that is very discrete and where perhaps since they are thinking about it, they would have explicit questions or areas where input would be useful.
DR. STARFIELD: Can I make the assumption that pretty much everybody on this subcommittee knows about most of the surveys?
DR. IEZZONI: I don't think you should make that assumption, Barbara. Simon yesterday didn't know. The rest of us have had the benefit of sitting through NHANES presentations and HIS presentations -- many of them. Good presentations, but we've seen it before. I don't think that the rest of the folks are kind of up --
DR. STARFIELD: I think there are one or two page descriptions of these surveys.
MR. SCANLON: In terms of the major surveys that are used, really the work horse surveys in terms of monitoring health status and the health system and expenditures and so on, plus the vital statistics. You are probably talking about less than two dozen. These are the monitoring surveys, year in and year out, probably less than two dozen, if even that many.
DR. STARFIELD: Can I suggest that we circulate that, so that everybody looks at that and knows what the surveys are? Then that we ask for some specific questions about provider surveys.
MS. GREENBERG: I have that memo that Ed Sondick(?) and --
MR. SCANLON: We sent to the Data Council?
MS. GREENBERG: Yes. We could have a copy of that made for them.
MR. SCANLON: Yes, actually we could ask the National Committee.
MS. GREENBERG: This initiative on provider surveys; that would at least give you a little flavor.
DR. STARFIELD: Our charge basically is to think about those provider surveys and determine whether they are the most relevant way to get the information we need.
DR. IEZZONI: Or whether there are public/private partnerships we could propose to try to move things along, because it was absolutely painfully obvious that money is a major, major constraint right now.
MR. SCANLON: There is not a real big investment in these basic surveys to monitor the health and health status of the population. There is not a lot of money in these, so that's why there is a fair amount of pressure there. They are hold their own, but it's very difficult to get any new monies.
In a way, John, the kinds of questions that are occurring in the provider/plan area are the fundamental ones. They will relate back to the population. It really has gotten to the point where claims data, to some extent, is disappearing in some managed care areas, where even the definition of what the entity is, is not clear anymore. So you can't use the old terms that you did -- is this managed care? Everything is managed care anymore.
So really a fair amount of conceptual work is needed, and it really would be in fairly basic questions. So that might be something that could actually be -- it is discrete enough so that you can deal with it.
DR. STARFIELD: Is there anything we need to do to proceed on this?
MR. SCANLON: We started by asking the Data Council some basic questions about provider surveys. Let us send the same memo.
DR. STARFIELD: We will talk about it at the March meeting.
MR. SCANLON: Yes.
MS. GREENBERG: During the subcommittee meeting?
MR. SCANLON: Yes, in fact, maybe we'll have a short presentation on where what that project is -- what the framework is, and how it is proceeding. That would be good for the subcommittee.
DR. STARFIELD: The last item has to do with things that the subcommittee as a whole, needs to be considering when we discuss the administrative simplification. I think particularly our concerns about whether all the work that was done on the core data elements is at all going to be incorporated in the thinking about simplification, especially with some comments that will increase complexity, rather than instill simplification.
John, you probably have some thoughts about this. You made a statement this morning that we certainly don't want to -- we want to think carefully before we add anything that is already a standard.
DR. LUMPKIN: My only thought is really to look at this as a process of which the transaction standards that we are talking about in the near frame, fit into the first stage of a process. The real ability to get that kind of core data information out, to the extent that those components that are clinical really are to be tied in to the development of computerized patient record.
That we are still dealing primarily with a manual system. Even in those places where they do electronic transactions, the extraction of the data is still a manual extraction. So that if we create the environment whereby an electronic extraction of data from the clinical record can occur, then I think it is much more realistic to begin looking at collection of a larger core data set.
I just wonder, and perhaps part of what we could do is by taking a look -- and I heard something over lunch that there is a how big, 500,000 record data set extracted from medical records of every element in the core data set.
MS. GREENBERG: Oh, much, much more. You're talking about the uniform clinical data set?
MR. MAYES: [Remarks off mike.]
The Health Care Finance Administration, as part of its quality improvement programs for the peer review organizations do a significant number of clinical record abstractions. In the last 3 years we have done about 500,000. We have built-in capacity to do up to 800,000 a year.
As part of that effort we have been collecting a core data set that we developed, that coincidentally is very, very comparable to the National Committee on Vital and Health Statistics. In fact, I sent a comment into the draft early in the summer.
We have had internal discussions on what to do with these elements, and whether we want to continue to collect them. So it would be interesting perhaps to work with the National Committee and try and perhaps use that data set of some sort of validation activity.
It is primarily fee-for-service inpatients; not 100 percent, and we are moving into other areas, but primarily that. On the plus side, it probably does represent every single fee-for-service inpatient facility in the country, so we certainly look at it.
As I said earlier, when I did a crosswalk, I found that the major of elements are available through our administrative data, which would obviously mean we have many, many, many more records, but we are collecting the clinical elements as well, other than the ones like pediatric things.
DR. STARFIELD: There were a couple of things like that. Reason for visit, which is a big one. I'll bet you don't have that one.
MR. MAYES: We have admitting diagnoses and things like that.
DR. IEZZONI: That's hospitals.
MR. MAYES: Now we are starting in some ambulatory care projects. So at this point our policy is still to collect this data, although as I have said, we have internally had discussions about stopping to collect it. I, personally, would like to see us continue to collect it, because I think there are some good things in there. It gets back to the issue of how much effort do you want to put into it?
DR. LUMPKIN: I think that that certainly is a valid issue, but we have a way of testing that. One of the things that we would like to be able to see is a core data set, realizing that it may in a select group, be able to do. Because there is other information about the settings that exist, whether it be the inpatient or outpatient, some independent assessment of the quality of that setting through either an on-site survey or Joint Commission review.
In the other ones there would be some ways to evaluate the utility of the core data set in certain areas, which would provide some utility to HCFA for instance, if in fact the collection of core data set could be substituted for some of the regulatory action going on.
I'm just sort of throwing out some ideas, but I guess my bottom line in how we got into this was the addition of elements from the core data set into the transaction.
DR. STARFIELD: I think one of assumptions of the core data project was in fact to improve the linkage between the inpatient and the outpatient setting, as well as other related settings. So if we were going to think about this, we wouldn't want to limit it to one of the settings. The basic philosophy of the core data elements is that you would go across settings.
MR. MAYES: Right, and we had no intention to limit it to a setting, it is just that historically the peer review organizations have focused primarily on fee-for-service inpatient. As I said, we are reorganizing HCFA actually, in a very significant way.
At least on the quality of care side of the house, one of the reasons that we are looking to reorganize our part of the business is because we recognize that we need to begin to look at quality of care across settings, and actually in an episode of care type of approach, rather than specific to inpatient or specific to ambulatory or whatever.
As I said, we collected the data because we thought there would be a reason good reason to have it.
DR. IEZZONI: You had a real vision, and you had really thought very hard about it.
MR. MAYES: Yes, but we are revisiting, as usual, and deciding whether or not it is worth our abstraction time to do this. We have specific projects that we abstract this data on. For instance, the Cooperative Cardiovascular Project represents probably about 240,000 of those 500,000.
DR. IEZZONI: Is that still going on?
MR. MAYES: Yes, it is; not at the universe sampling type of level, but we have a lot of other projects. One of the things we had decided was, well, let us try to get a common set of data across all of these, because we think that we could ultimately get some benefit from that.
We are certainly interested if other people have ideas, and obviously the committee has been focused on this issue of figuring out how best we might utilize this information. In fact, I think that before you propose putting it into claims or into other of these standards, you need to be able to present some really good reasons why you are going to do that.
In HCFA we have ongoing discussions internally as to should we add clinical data to claims for reasons of monitoring quality of care? Those of us on the quality of care side of the house have really fought against it, because we have found that the information off the claims, the clinical information particularly, as was noted, it is not on the claim because the clinician wants it on the claim. It is usually on the claim because there is some sort of reimbursement issue.
Even if we mandate that it be put on the claim not to be driven by reimbursement, who is putting it on the claim? A billing clerk in the administrative office is flipping through the chart and deciding this is the number that goes. So there are some real issues.
I would think that some sort of validation -- we would have to look at some actual abstracted medical information that has these core elements, that we can then link back to some other kind of clinical encounter.
DR. IEZZONI: Part of my concern about the core data elements was squashed somewhat by the response to my question about could you have codes for two different kind of dimensions of clinical attributes of patients within 837 that I asked this morning.
I guess I still do not know what 837 is. It sounds like it's just a format for transmitting information, but what is transmitted within the various fields is very kind of open to discussion.
MS. GREENBERG: It's my understanding that the content is supposed to be defined by the NUBC and the NUCC. That is the framework I think of the people who --
DR. IEZZONI: But remember, that is billing committee.
MS. GREENBERG: Yes. Of course the NUCC and NUBC aren't recommending collection of ICIDH. At this point the NUCC isn't even recommending collection of E codes.
Your point is very well taken, I think, and that was a major reason why McData really didn't go any further, and now I guess is in a pilot test, because the feeling was how can we really justify collecting all this information if we haven't got good examples of what we would use it for, although there are many, many examples of what the fee-for-service data has been used for, even with its limitations.
So I don't minimize that all, but you don't need a computerized patient record to get the core data elements that were recommended by this committee. The vast majority of them are already in the administrative data sets, but not in as useful a way as one would like. On those elements there were some recommendations that the committee made with the feeling that it would make them more useful.
The other elements could either be collected on enrollment, or in an encounter probably with not that much additional effort. Where it was apparent that they needed more work, that's what the committee recommended.
They recommended a research agenda. As far as I know, there is nobody undertaking any of that research agenda. It is all really within the context of a core data set. It really didn't -- we stepped into a computer-based patient record. The only was in medication, and that was because you figured you could get it, because that's electronic anyway, as we have heard and heard and heard.
So I think to really get the kind of clinical data that you need to meet that other 50 percent or 60-70 percent that the first panel was talking about yesterday, a lot of that probably will require an electronic patient record, or you are going to be manually collecting it.
This small core of elements that the committee recommended really do not require a computer-based patient record. The question is, is it worth it to try to get some improvement just in the data that is being collected, or is the committee comfortable just taking whatever the NUCC recommends?
DR. STARFIELD: The legislation says that the committee must recommend standards developed, adopted and modified by an accredited standard setting organization; must recommend on the adoption of other existing standards, that is, non-accredited; and recommend on the adoption of new standards.
So for some of these core data elements, we are talking about new standards, but we have a mandate to do that, to include that if we think it should be included. Now the question is, is it part of the transaction, or is it part of the claims attachment? I think, Marjorie, you are making the case that it is part of transaction.
MS. GREENBERG: Not the attachment.
MS. COLTIN: One of the things that we talked about, but didn't resolve as we were developing the core data elements that is where we thought we would get each of the various data elements. We had some discussions, but we didn't for each element say, this is the data element that would be completed at every encounter in an office-based setting, in a facility-based setting, whatever.
This is something that should be collected on enrollment. This is something that only should be collected on enrollment, but should be updated on some frequency schedule, or something like that.
That has, I think, made it difficult for those recommendations sometimes to be examined within the context of the transactions, because it is not clear which transaction type we would have intended that element to come from. If we felt it should come from enrollment, then we should be looking at the enrollment transaction, and saying, does this enrollment transaction include this data element?
DR. STARFIELD: Then that doesn't even include the updating.
MS. COLTIN: Correct, although there are updates periodically and reconciliations using those kinds of transactions as well. That was something that at the NUCC was an issue, because I think they were able to get around the issue of even having to address some of the core data element recommendations by saying, oh, they couldn't possibly mean that this is something they want us to collect on every encounter. So we think this would be collected as part of an enrollment set, so we won't even consider it.
We allowed that kind of escape route by not being clear of where we thought the accountability resided for collecting a particular data element.
DR. STARFIELD: Marjorie told us this morning that one of the implementation teams has to deal with enrollment eligibility. That's the natural place for this, right?
MS. GREENBERG: Right. Actually, I think you're right, you didn't go item per item, but it did say that those first 12 elements or whatever, other than patient identifier, would not be expected to be collected every time, but it didn't get into what frequency.
MS. COLTIN: Or through what vehicle. There are some patient-related data that you do want to have the provider collect, and others that you want to have the insurer or the payer collect, because of just issues in the quality of the data and the timeliness of the data for things that change periodically. Sometimes the provider is the better vehicle, because they have more contact with the patient. We didn't bite that bullet.
DR. IEZZONI: Barbara, I wasn't totally unclear about what we can resolve about including core data element concepts by simply putting in new coding sets within the format of 837 or whatever. We heard this morning about coding sets being actually the most important issue that we're probably going to have to deal with in terms of the simplification and the consistency.
If they have a coding set that allows you to flag which particular nomenclature is being used, be it CPT or HCPX or ICD-9-CM procedural code, why couldn't there be a code set that would allow you to flag the level of certainty of a particular diagnosis? Why wouldn't that be able to fit within -- so I guess what I'm having trouble with is I don't understand what this 837 is, and whether what I just said is actually possible.
I'm not saying that it's necessarily desirable for us to do that, because I do think we don't want to burden people excessively. Should we be talking through now what part of the envelope can we push with the 837 format to get at the concepts that are in the core data elements by simply looking at new code sets? Or would we have to actually change the 837 format in some particular way? Maybe you can help me.
MR. MAYES: I would just like to make one point, and I think Kathryn brought this up before. I know she brought it up at lunch yesterday. It is true that a lot of these transactions may not be around in two years. So I would sort of caution you to hitch too many wagons to that particular star, because with the changes moving towards capitated and that sort of thing.
It may be wiser to focus on some of the issues that we are now sort of calling supporting standards such as the identifiers, the code sets and things like that, and really try to lay the groundwork for ultimately being able to get this information that has been captured during the process of care; not that somebody secondarily has to re-enter or look through a record or try to do that.
DR. IEZZONI: I agree.
MR. MAYES: Not be so worried whether you can stuff it into 837, because it become a less and less important -- you may find that suddenly you are only getting in 3 years, you're only getting 20 percent.
DR. IEZZONI: What I also heard is that people are going to have to have some encounter level data. So I'm using 837 as a catch all term to mean whatever that encounter level format is.
MS. COLTIN: One of the things that has perturbed me is that 837 is labeled claim or equivalent encounter information. Yet the developers are really in a claim mentality, or not the equivalent encounter information, because when you think about what are the circumstances under which the information, the content being transmitted in this transaction is equivalent encounter information, it is generally a capitation circumstance in which that occurs.
Then you have to say, for what purposes is the managed care entity asking for that information? It is not to pay an adjudicated claim. It is to serve a lot of other purposes, including their fiduciary responsibilities in a case where they have given a bundle of money to a provider, and want to be certain that the patients are getting the necessary services under that, because they are sharing accountability for that with the provider in that arrangement.
So there are more purposes to be served with equivalent encounter information than there are to be served with claim information. Yet the development process has really taken the more narrow focus, I believe, in terms of what data elements are in the set, and how they are being defined, and what code sets are being allowed and so forth.
DR. LUMPKIN: But sometimes it seems to me it may be better to start from the beginning, than to try to take an encounter form that was really designed for billing transactions, and try to convert it into an encounter document. That might be a better effort than trying to make a document that might serve one use very well, try to serve two uses, when it may be less functional for that second use.
If you go to a completely capitated environment, the managed care entity or whoever is looking over quality is more concerned about all the kinds of stuff that we would have in the minimum data set, and less about other pieces of the thing that is going into generate a billing, to look for fraud, and those kind of issues.
MS. COLTIN: Well, I don't think so. I think it is additive. I think all of the issues that are germane to a claim are also important, because this information is also used to adjust capitation rates. If services are going into that calculation that shouldn't be in there, then you are going to come up with a capitation rate that is higher than it ought to be.
So you want to be sure that what is represented are services that in fact were necessary and ought to have been provided, so that you are not raising a capitation just because people are delivering things that aren't needed, and they are saying, no, you didn't pay us enough last year. You've got to raise it 20 percent.
So there is a lot of financial analysis that is applied to these data as well, but it is a population-basis aggregated up. It is not at the individual claim level or even the individual patient level the way it is when you adjudicate individual claims. It is information that when you roll it up, tells you something about patterns of care, and how a particular group or a particular provider panel looked.
DR. IEZZONI: Barbara, I'm just wondering, to move this forward so we can decide what we are going to do, could we focus on code sets to address the issues that are raised by the core data elements?
DR. STARFIELD: Yes, that was what I was just about to suggest. I was going to ask you, Bob, if you could identify for us, through the work of the implementation teams, which are the core data elements being considered with regard to standards, and which are not?
MR. MAYES: Yes, we were planning on including the core data set in the master edit. One of the fields in that for each element will be which standards does it show up in.
MR. MOORE: One of the things that the contractor did when they evaluated the core data set was they did a side-by-side of the 837, the UB92, the 1500, the uniform discharge data set, the uniform ambulatory data set, the core data set -- every data set that they could find out there in existence, whether it was in the public health or in HCFA or in any private setting.
They compared the data elements. So you already have that. All we have to do is then go look at the code set that corresponds with that data element. You can tell which one of the existing data sets, and I think even the pharmacy claim was identified in that evaluation.
DR. STARFIELD: When we talk about core data set, we are not only talking about the HCFA one.
MR. MOORE: We're talking about your core data set.
MS. GREENBERG: Bob, that was done at the beginning of the process, so it looked at the UHDDS and UACDS and the updated recommendations for those that the committee had made. All of those got into the core data set. I'm not sure, there might have been a few other elements that the committee recommended that weren't in that analysis. They did this at the beginning of the project, not at the end of the project.
MR. MOORE: I have the analysis that the X12 did when they were evaluating an encounter, and to include that as part of the 837. So I can provide you with what portion of that 837 represents an encounter if you are looking at a managed care setting, or at least what they thought they were doing.
DR. STARFIELD: Jim?
MR. SCANLON: Barbara, turning to, as Don says, the low hanging fruit, some of the early potential standards, the national provider ID for example, I think Don was hoping that the subcommittee would have some sort of report or feedback to the full committee at the March meeting on the proposal.
DR. STARFIELD: We got that on the e-mail last week?
MR. SCANLON: Yes.
DR. STARFIELD: I have my marked up copy. Do you just want me to send you an e-mail of the comments?
MR. SCANLON: How do we want to handle that? Does the subcommittee want to report back to full committee in March, or should we handle it sending comments directly to us?
DR. STARFIELD: Did you send that to everybody on the committee?
MR. SCANLON: On the subcommittee.
DR. IEZZONI: Some of us can't receive one of the attachments. I need it.
MS. GREENBERG: At a minimum the work group would want to look at it, I would think.
DR. STARFIELD: How do you want the comments back? It seems to me that you want them back sooner, rather than later.
MR. SCANLON: Yes. I'll defer to Bob and Bill here. There are different ways to deal with this. This is going to be published most likely for review and public comment at any rate. The National Committee may want to reserve detailed comments for later, or review it concurrently in the same process, or provide comments up front.
DR. STARFIELD: Well, why don't I suggest that each of us get comments back to you, and that you can compile them. Then we can talk about that at our next meeting. Is that soon enough?
DR. DETMER: Yes, and then I guess based on that if you could get back to her, so that if the committee in fact felt good, or didn't really turn up that much, then perhaps we could move this to the full committee.
DR. STARFIELD: In the March meeting?
MS. GREENBERG: The way we have tentatively set up the agenda, the subcommittees are having their break out sessions the first day, and then there will be an opportunity to come back and report on the second day, so that would work.
Bill, I know there are certain issues that are being looked at or being identified. I don't know whether any of those would benefit from some feedback from the committee.
DR. BRAITHWAITE: Well, they might, but I want to get those discussed in the Data Council's Committee on Health Data Standards tomorrow, and negotiate out what are really the issues that are remaining. If there are some issues remaining after that discussion, then we could refer them to the NCVHS for comment.
MR. MOORE: I think some of those issues are department issues, not NCVHS issues. Is the NPI maintained by the government, or do we give it over to some private entity to maintain it? Where do we do the registry? Those kinds of things.
I think what we need some agreement from the committee is, is the concept of a unique identifier worthwhile? Or what pieces of information do we need to use to identify that we have adequately, uniquely identified an entity, et cetera?
If we can do that, then I think we can move the concept forward. Right now we are getting hung up on all of the pieces about it, and who belongs in it, whether the Nurses of America belong in it, or just what groups we are going to enumerate; some of those can be resolved as we go along.
DR. STARFIELD: The issues actually weren't identified in those documents.
MR. MOORE: Some of these just came out. As the department was reviewing the regulation in the last two weeks, they have asked questions.
DR. STARFIELD: Just a clarification. It seems clear to me, and I want to make sure it's true that the location is not part of the identifier. Is that right?
MR. MOORE: When we first started that, we thought the location might need to be a part of it, but as we have met with more and more people in the community, we have changed our mind.
DR. STARFIELD: Okay, so we know what we're going to do with that one.
DR. LUMPKIN: I think it's fair to say, or at least my comment would be that based upon the presentation and documentation that I have seen, I am inclined to go with that. We just need to identify on the committee, if there are major problems that are here, or are we just talking about making changes to the document. I personally don't have problems with the proposal.
DR. STARFIELD: Do you want to identify for us the issues that have arisen since you sent out the stuff to us last week? Maybe you can do it now.
MR. SCANLON: We might just describe the process. I don't know how many of you are familiar with the regulatory process, and the review and public comment kind of a process. The way the standards will be adopted is through a regulation. That way, they have the force of law. I think that is really the only way HHS could adopt standards at any rate, any federal agency.
So in developing, there is a certain process that has to be followed in the development of regulations that allows a lot of open public review and comment. Then all of the comments have to be looked at when it reaches that stage. Then a final rule is established.
So there is a built in time frame here that is considerable in length. If you think of having to have the secretary issue final regulations next February that will go into effect in the year 2000 for most plans, we're probably a little behind.
Bob can describe what the issues were.
MR. MOORE: If we are to have the regulations out -- and this is something I am going to present tomorrow at the Data Council meeting, and I did present it at the WEDI meeting -- we're getting inventory now in February of 1997. This is based upon giving the right kind of spacing to get to next February. So it's not based on being able to do the job, it is based on doing the job in the time available.
By the end of May, we have to have this analysis done on this inventory. Then we have to present findings of what -- this is the implementation team -- to both the NCVHS and the Data Council, so that they understand what we have come up with.
Then we are going to go back and develop the recommendations for standards to be adopted. I don't want to say we're going to adopt a standard if you all have some real driving reasons as to why it shouldn't be. That would be in the September time frame. The recommendations follow almost within weeks, with the draft regulation to the secretary and to OMB.
Then in October we would be publishing that regulation as a draft regulation for everyone to comment on. We'll give 60 days for the comment period to come back. That gives us until the end of December.
Now I expect to get honestly, tens of thousands of comments on all these regulations. We've got different regulations. That could be hundreds of thousands of comments. We don't have enough people to categorize and stack all that stuff together. We don't want it on the e-mail, because I know what I'll get on e-mail. We'll have millions.
Then we have between the end of December and the end of February to get to the secretary, having analyzing all those comments, and give her the impact analysis and things of that nature. An impact analysis means financial. What is it going to cost? Who are the winners and losers in all this?
DR. STARFIELD: You described that pretty well.
MR. MOORE: The questions that are being raised in the department by the regulation that we sent to the department, that hasn't gotten out to everyone. I caught a lot of flack at the WEDI meeting two weeks ago, because we were asking those people -- they have what, 200 there or so -- to comment on it and give us a vote of approval.
They wanted to see what we had written in the regulation, but we can't let them see the regulation, therefore we asked them to vote on something that they don't know about. We, are, for the first time, writing regulations on how industry does business amongst itself, not with the government.
The location is one of the first things to come back out of the department. Requiring providers to identify how we are going pick up those providers, whether it is through plans, Medicare and Medicaid; who is the sponsor of a provider? Would it be associations? Fees for operating it, if there has to be an operating fee. Clarification of what the fee covers.
Whether the registry should be operated by the government versus the private sector. Is the regulation a template for all the following regulations? We are going to have 12 of them.
What this covers to date has been billing, but there is a lot more to be involved in this. A unique identifier -- will it cover all the other conditions that we want to cover with the provider?
Those are about the seven basic questions being asked by the department that we've got to resolve and come up with an answer and redraft that regulation, and then get it back to the department.
DR. STARFIELD: Well, you didn't share the regulations with us either, right?
MR. MOORE: I asked if we could back in the middle of January, and I was told no by the lawyers. Then someone -- they worked that out. We kept shopping around until we got the answer we liked, and we finally found one that would support it and not send us to jail. So we then gave you all the regulations, which is about 78 pages.
MS. GREENBERG: They can read it fairly quickly.
DR. STARFIELD: Seventy-two pages.
MR. MOORE: Payer ID, we would hope to have that by early March. Hopefully, some of the questions that we were asked already by the department, we'll be smart enough that we'll cover those too before we send that one up for a trial. You float it up so high, and see where it catches the flack, and then you know where the opposition is; same thing we do with the public.
MR. SCANLON: If I can return to the point John made. It was the sense of the subcommittee -- John was expressing it -- that in terms of the public hearings and others that we have heard from, the basic concept of the NPI, the unique identifier for NPI was supported to a large extent. I think John was summarizing what the subcommittee was hearing.
DR. STARFIELD: I think that's fair.
MR. SCANLON: There may be details here and there, clarity about the scope and things.
DR. LUMPKIN: So I think we need to look at the details in the individual regulations, but that I think gives some direction for Don of what we're going to probably say when we make our recommendation to the full committee.
DR. STARFIELD: All right, we have actually accomplished a lot.
MS. COLTIN: I haven't gone through the regulation yet. Does it cover both the NPI and payer ID?
DR. STARFIELD: No, just the NPI.
MR. SCANLON: Payer is just a little further behind.
DR. STARFIELD: It doesn't cover the organizations -- oh, yes it does actually, because that's a provider. There are three kinds of providers.
MS. GREENBERG: The committee supported it last year. Certainly we have heard from everybody that people need these unique identifiers.
MR. SCANLON: In the past, Marge, I think this was included in the core data summary report as provider information.
DR. DETMER: I think the implementation calendar is probably more of a concern.
MS. GREENBERG: On the payer ID, has there been any progress on the taxonomy issue?
MR. MOORE: That's in the provider.
MS. GREENBERG: I know there's one in the provider, but there was a question as to whether these payers were also going to be categorized in some way, to make some sense out of them, if that's possible.
MR. MOORE: I think we had a list of something like 18 categories of payers. I'll have to go back and look at that.
MS. GREENBERG: I know some of the comments we have gotten with NCHC on the core data components was some people were very disappointed that the committee did not come up with anything on the expected source of payment area, but that it just fell back on the -- at one point it was going to be free text, at another point it was going to be nothing. Then I think it just turned out to be the UHDDS.
People who are trying to track managed care and different arrangements through surveys would love some guidance there.
DR. STARFIELD: I think we have probably finished what we needed to finish today, so we'll adjourn a little bit early, and let Don get out earlier.
Thank you all.
[Whereupon the meeting was adjourned at 3:15 p.m.]