[This Transcript Is Unedited]
Wilbur Cohen Building
330 Independence Avenue, S.W.
Washington, D.C.
Agenda Item: Call to Order/ Welcome and Introductions
MR. REYNOLDS: Okay, I'd like to welcome everyone to the Standards and Security Subcommittee of the NCVHS, National Committee on Vital and Health Statistics. The NCVHS serves as a statutory public advisory body to the Secretary of Health and Human Services.
Over the next day and a half, we will be hearing testimony on the HIPAA Transaction Revisions Version 5010. Our hearings are recorded and available on the Internet. I will now begin introductions, and I ask members of the Subcommittee to mention any conflicts of interest they may have. I'm Harry Reynolds, Blue Cross Blue Shield of North Carolina, and I have no conflicts. Jeff? I'm sorry, I forgot to say Jeff Blair is my Co-Chair.
MR. BLAIR: Jeff Blair, Director of Health Informatics, Lovelace Clinic Foundation, Co-Chair of the Subcommittee.
MR. REYNOLDS: Lynn, go ahead.
MS. GILBERTSON: Lynn Gilbertson, National Council for Prescription Drug Programs.
MS. WEIKER: Margaret Weiker, EDS.
MS. TRUDEL: Karen Trudel, Centers for Medicare/Medicaid Services, staff to the Subcommittee.
MS. WARREN: Judy Warren, University of Kansas School of Nursing, member of NCVHS and the Subcommittee, no conflicts.
MS. BUENNING: Denise Buenning, CMS lead staff for Subcommittee.
(Introductions around the room.)
MR. REYNOLDS: Okay, over the next day and a half, as I said, we're going to be hearing about the Version 5010 of the HIPAA transactions from a Subcommittee standpoint. Simon Cohn will be joining us shortly. He had another session.
We will, in fact – our goal is to out of this day and a half of hearings is to be able to prepare a letter to go forward to the Department concerning our feelings and discussions on the 5010 for their consideration as they move forward towards possible sending out of a regulation. So with that, the first presenter is – Jeff, did you want to say anything?
MR. BLAIR: Nope, I'm fine.
MR. REYNOLDS: Okay, so our first presenter today is an NPI Overview and update. Karen?
Agenda Item: NPI Overview and Update
MS. TRUDEL: Yes, thank you, Harry, and I'll make this very brief because I know everybody's interested in getting to the main topic of discussion.
We're continuing to see progress both at CMS and in terms of analyzing other industry input. We're seeing more progress continuing to be made toward NPI compliance and implementation.
We're seeing more claims containing NPIs and, at the same time, we're also seeing that there are some issues, there are some confusion in terms of billers regarding the appropriate usage of NPIs. For example, we're seeing that in places on the claim where an individual's NPI should be, the group's NPI is there instead and vice versa.
Medicare is taking very active steps to address some of these points of confusion. A week or so ago, we sent out a very voluminous packet of public information including tips, instructions and we'll continue to do that over time as we see potential areas of confusion. We'll be issuing outreach materials, and we continually update our frequently asked questions.
We are also planning another Medicare NPI Roundtable to address some of these specific billing issues that we're finding almost prevalent. So I think the message is, and this is not surprising for anyone who's been through one of these implementations before, we make progress. And as we make progress and more people attempt to come into compliance, we see areas of confusion that have to be addressed, and we address them and move on, and it's definitely an iterative process.
We have not reached the point in time yet where we will be actually operationalizing Medicare data dissemination policy, I mean, the NPPES data dissemination, so I really can't speak to that, and I think we'll just be moving forward to continue to address these issues as they come up.
MR. REYNOLDS: Could you restate – I'm sorry, I missed the flavor of you MPPS comment. Could you say that one more time.
MS. TRUDEL: The actual communication, the output of the data dissemination notice hasn't occurred yet. So we haven't actually started making files available or making look up tables available. So we don't know how that's going to actually work and what questions might arise once we start into that process.
MR. REYNOLDS: Any questions for Karen? I've got a couple, but I'd like anybody else that has anything, want to make any – Steve?
DR. STEINDEL: Do you have any idea when the NPPES may be released, a target schedule? I think you said you wanted some time to make sure the people cleaned it up for release, and I don't recall if that notice had a date or not.
MS. TRUDEL: At this point, I think it's sometime this week.
DR. STEINDEL: Thank you. That was my impression. I just wanted to get that in the record.
MR. REYNOLDS: This Committee, as we've sent letters on NPI forward to the Department, we said that we would continue to monitor progress. Is there anything of significance or any stumbling block or anything else that is out there that you would feel would be worthwhile us addressing, or would anybody else on the Committee know of anything or is a letter even worthwhile at this date since the progress continues, that probably being maybe a general question.
MS. TRUDEL: I would say at this point the issues that we are seeing are being addressed as they arise. I would like to see what happens in another few weeks to a month as a result of the outreach that we've already done on some of the billing and usage issues. It's already also come to our attention that a couple of clearing houses have some glitches that are causing NPI problems. We're addressing them with the clearinghouses on a one-on-one basis, and they appear to be moving forward with corrections. So I think at this point we're in the see it-fix it loop.
MR. REYNOLDS: Judy, Jeff, Steve, you have a comment. But I really want to understand whether or not we want to – we feel a need to do anything.
DR. STEINDEL: Yes, that's what I was going to comment on, Harry.
MR. REYNOLDS: Please.
DR. STEINDEL: Yes, and my sense from what I heard from Karen just now is it sounds like, as with any complex system, we're seeing the normal introductory type problems that we need to work through. It doesn't – I didn't hear any theme of anything consistent that was a problem with the NPI. It's just individuals and how they have implemented that, and the best thing to do, I think, is what Karen is doing is handling it.
And I think our next step where we might seriously consider thinking about something would be after people start getting and using the NPPES and develop using that for their crosswalks. And it sounds like that's going to be, even if they release it this week, we're probably looking at least a month away or more before we start hearing any real experience with its use.
So I would suggest that we defer consideration of a letter until our September meeting.
MR. REYNOLDS: And – we have in October.
DR. STEINDEL: Well, we have the usual subcommittee session right after the NCVHS session. That's what I meant by the September meeting.
MR. REYNOLDS: Right, right. And Karen, I would think for the Full Committee, you usually give an update anyhow.
MS. TRUDEL: I can. I'm not sure it's on the agenda.
MR. REYNOLDS: Yes, I'm not sure it is either. I'm just saying – so minimally, the next time we hear about it is September. More than likely, we obviously have it as one of our standing agenda items for October session. Jeff, do you or anybody else have a comment? Judy? Judy, go ahead.
MS. WARREN: When you talk about can we hear an update of how NPPES is doing at our small meeting in September so we can then decide what we need to hear, what we need to do in our October meeting?
MR. REYNOLDS: Yes, I think we could. I think one of the things we'll need to do is make sure we give appropriate notice because a lot of times the break-out sessions out of the full Committee, you know, are more the Committee kind of considering what it's going to do, not necessarily a formal because it's really not an official meeting. Well, I guess it is an official meeting. Yes, it is. Okay, but I would want to make we communicated that if we're going to do that so that appropriate industry people or anybody else like the people that are in attendance today that would, because obviously it's an important piece of information, that we would make sure we would document enough so it didn't kind of get hidden under the fact we're having a full Committee and, oh, by the way, Standards and Security's going to touch on this particular subject.
MS. WARREN: I guess I hadn't seen it as quite that formal. I kind of thought that we would get an update of the status so that we would know how much time we would need to put at the October meeting. So I don't know if we can be that informal at September or not. But it was just kind of a do we need more stuff.
MR. REYNOLDS: The only reason I bring it up is this has been a consistent – NPPES has been a consistent thing in our letters ongoing. So that's all I'm saying. Since we are supposed to be a public forum, I want to make sure that we have communicated very clearly that that subject would be there, not – again, not to make it bigger or smaller, but just for the fairness of everybody that's involved in the whole thing to know that that would be a chance for somebody to get an update if they choose to. And then obviously we would probably have – we would obviously most definitely carry on our discussion in October also.
Okay, Karen, anything else?
MS. TRUDEL: No, thank you.
MR. REYNOLDS: Okay, good. Thank you very much. Okay. We have – at one, we were supposed to have, wow, we're early. This is good. So we were going to hear from Maria Ward on the rationale for SDO changes, and then we were going to hear on NCPDP D.0 from Margaret Weiker, and I believe Margaret has volunteered to do both, is that correct?
MS. WEIKER: Yes. Unfortunately, Maria could not be here today, so I'm substituting, pinch hitting, so to speak.
MR. REYNOLDS: Okay, so you have the floor.
Agenda Item: Rationale for SDO Changes
MS. WEIKER: Okay. The purpose of this presentation is kind of to set the stage for the testimony that will be following in regard to NCPDP as well as X12 and kind of give a high level of why an SDO does what it does, so to speak.
A quick overview of the process. X12, NCPDP and we'll throw in HL7 as well, all developed standards and ballot those standards based upon the industry stakeholders business requirements. Those come in many forms in regards to change requests, and each organization has a process that is documented because they're actually accredited, and that's one of the requirements is to have the processes and procedures well documented on how do I make a change, what's the form I fill out, what's the time frame I have to have that form in by before a meeting, and what's the process after that kind of thing.
So each of the organizations have a process in place in order to develop and to meet the business requirements that all of the industry stakeholders have. And this could be in regard to both HIPAA change requests for those standards as well as non-HIPAA requests as well, such as workers compensation modifications needed to the claim or something which is not a HIPPA mandated use.
Our procedures are, as I mentioned earlier, documented. They're a predictable procedure and process. We believe they're timely, though there are some that would say we take too long to make modifications to the standards, especially when there's an urgent business need or a time requirement or a mandate by a federal or state government type of thing where something has to be done fairly quickly.
As we have testified here several times, we would like to see the HIPAA process become more predictable and timely in regard to streamlining and having our proposal in regard to streamlining actually put forward and adopted. We work very closely with OESS and CMS in regard to improving the HIPAA process. We have many discussions on the DSMO phone calls in regard to how to make it better, if we can make it better, how can we cut time out of the process, those type of things.
The SDOs obviously will continue to accommodate the business needs as the industry demands them, as well as improved technologies become available. We also may have to make changes to the standards as well. Examples of these are CHIPs and NRFID and cards and those type of things. So as technology improves or changes, so sometimes must the standards. So that's another reason why we also have to change to keep up with those.
I think I basically covered all of this. We will continue to deploy the standards. We'll get these things done in what we believe to be an acceptable time frame. And in cases like HIPAA, we will continue to work with this body with OESS, CMS, with HHS, with the DSMOs, et cetera, in regard to moving things forward.
Benefits to moving to the new version of the standards. Through the process that each SDO went through as well as this all came through the DSMO process as well in regard to both change requests that were incorporated into these guides as well as the actual adoption of or moving forward these guides, whether they're X12 TR3s or the NCPDP implementation guide. That request to have it move forward to the next version of HIPAA was also put forward to the DSMO as part of its MOU.
We've had significant deliberations in regard to these standards. Through our process, there's been teleconferences, listservs in public, in person meetings, public comments, ballot periods, as I said earlier, and also through the DSMO process.
Each SDO which is accredited has to have an open and consensus based process. WEDI has also conducted surveys for the NCDPD transactions as well as the ‘837 transactions, the IPND, the Institution Professional and Dental, the ‘835. They redid that one, so to speak, as well as the ‘276 and ‘277, and you'll hear more about those later on this afternoon.
The end result, we believe, are improvements in these new versions. Some of the changes or the benefits are new and different data exchange capture requirements that are at the time they were implemented or put in were current with changing business needs. And example of that would be in the NCPDP Standards Medicare Part B. We kind of rickeydooed it into the existing Version 5.1, and in this instance with Version D.0 we no longer had like shoe horned it into where it didn't really belonged.
As I mentioned earlier, keeping up with technology, clarification and further explanations on the how to do something, both in the ‘835 the front matter has changed in regard to providing further clarification which will allow the ‘835s to be “more useable” for the providers to get the automated postings so many of them don't come out and have to have a person actually go through and figure out how to post them.
Prior authorizations in the NCPDP transactions have also had a lot of further explanation put into them based upon some of the industry best practices as well as those that have already implemented them.
Correcting unattended errors – those happen. So those corrections have also been made, and in some instances creating a more efficient transaction. An example is some of the X12 837s have had some structure changes, which allow the transaction to be more efficient. You don't have to repeat the same information just based upon the fact of the structure of the transaction.
So the bottom line, this – today and tomorrow you're going to hear about the Version 5010 of X12 and the NCPDP transactions. But we also need to think about how we can – you know, I know we've been here before, but how we can make this process much more predictable and timely as we go forward to meet both the business needs.
The standards organizations will continue to do their work to meet all of the industry needs. And what we have to do is to figure out a way to keep the HIPAA process in sync with those.
So that's kind of a set the stage type of scenario, and I will be glad to entertain any questions at this point.
MR. REYNOLDS: Yes, even though you're going to do both of them, let's stop there for a second and make sure we don't get too many subjects overlapping.
MS. WEIKER: I agree.
MR. REYNOLDS: Any questions from the floor, comments from the floor. Jeff?
MR. BLAIR: Margaret, I think that it's pretty clear that there are benefits moving to 5010 and to NCPDP D.0, and they're probably overdue in terms of getting federal approval for moving forward on those.
Is there anything – you could see that we're already kind of on a guide path that after the hearings, we're anticipating that we would be writing a letter recommending expedited approval so we could move forward.
In the past, you've noticed that even when we wind up saying there's a compliance time and most of the testimony seems to indicate that the industry would like two years to implement 5010, and that's as fast as we seem to be able to go, two years. But with the history of the fact that many times the industry hasn't made these guidelines, is there any other thing we should consider for our recommendation letter that would help the industry to either become educated on this or to provide support for or tools or methods or any other incentives to make sure that if we do move forward on this that we could adhere – the industry will be able to make and adhere to those deadlines.
MS. WEIKER: That's a big question. I think the first thing is education. The industry has to become educated on these new versions, what's the benefit. There's so much chicken-and-egg so to speak talk there where I'm not going to do anything until there's a final rule.
MR. BLAIR: Yes.
MS. WEIKER: But we have to somehow stop that and have people start looking at these things now, start looking, doing their business analysis right now. They don't necessarily need to start doing the coding. But what are the changes because I've got to go in and do all of my business analysis, and that can be rather, you know, timely to do that and take a lot of time. So I think education is very important.
MR. BLAIR: Okay, let me just focus in on that. Education is important. Education in the past has predominantly happened through SDOs, through WEDI, through professional associations, but we've still been late.
MS. WEIKER: Yes.
MR. BLAIR: So I'm going to ask, do you feel like CMS has a responsibility for education in this case, and, if so, or if not for education, for assisting with the education. Is there something else in terms of education that could make it more effective that we should consider recommending.
MS. WEIKER: Well, I do think CMS needs to assist where appropriate, and that may be getting the word out so to speak through their listservs and that type of thing. I think also some educational materials that could be developed that could be more of a self-paced computer based type of training should also be developed where I don't personally have to go physically to attend training to find out about these things.
If we could come up with something where I could go online and do it and find out more about it, you know, and we could track those type of things and maybe some of the industry organizations can assist with that. But I do think CMS is part of the communication process, getting the word out and assisting perhaps in posting, if it's decided we do develop these type of training, to post these on their websites as well as several other places to where people can easily access them or used to going to CMS' website to find out information especially in regard to like the Medicare changes and MEDGARNs(?) and those type of things.
MR. BLAIR: All right. Let me ask you something. This is part of education, but it blurs into another area. If we wind up taking the industry recommendation of two years to prepare for implementation, in the past we've only found out as we approach a month or two or three before implementation that the industry still hasn't gotten ready. So do you or some of the groups that you work with maybe have some recommendation for interim steps that must be met in order for the industry to make that two-year time frame.
For example, is there certain kind of testing that needs to be done a year before, certain kinds of education that needs to be done at some period before where we could be more specific than just mandating that two years from now is the deadline, but failing to indicate the preparatory steps and guidance for the industry.
MS. WEIKER: Well, I think that goes first into developing a schedule that lays out all of the steps. It doesn't have to be what I would call a national implementation plan because I think that's setting it up for disaster when everybody must march to that.
But I do think we need predictable steps defined. You could say by this time, you know, all vendors should have completed internal testing because the vendors in those types of products must be done first, so then other organizations can take those products and incorporate those into their own systems which then in turn have to be modified and tested.
So I think it's, you know, from high level types of dates that must be defined, tracking of these from a national point of view to where I could go to a spreadsheet or a website or something to where I can look at, you know, maybe my vendors, my trading partners, internal testing, having a robust set of test cases, test data that I could use as well because sometimes I know entities struggle with developing that test data and getting that done because they're waiting for a vendor product where maybe they could take some and run it through their system before they actually get some of that done.
And I know some people advocate pilot testing. But pilot testing tends to, in my mind and I'm sure others will disagree, tends to say I'm going to pilot this and then based upon the results, I'm going to go in and I'm going to make these changes and this change and that type of thing.
And in this instance, pretty much – well, these guides are final guides. So unless we want to go through the addenda process which I know I personally do not want to go through that again, it may be pilot testings, a little late at this point.
MR. BLAIR: I'm going to ask my last question, then, with respect to this. What private sector organization or professional association or trade association or government agency do you feel is best qualified to give us guidelines for the milestones that should be set in addition to the final deadline for compliance.
MS. WEIKER: I don't think it's one organization that can do that. I think it's a – and I'm going to say small group, but that may be 10 to 15 people or organizations representing – that sit down and do that because you have different associations that represent different industry sectors.
So I think it would be important to have, you know, try to get to where all of these industry sectors are represented. There's WEDI. You have the SDOs. You have the associations from both a payer point of view, a provider point of view, a vendor clearinghouse point of view. So to have those, basically a small group or task force or whatever you want to call it sit down and do that. But I don't think it's one group. I don't think CMS can do that by itself in a vacuum is my opinion.
MR. BLAIR: Thank you.
MR. REYNOLDS: Other questions by the committee or anyone.
DR. STEINDEL: I find this a very interesting set of discussions in this area, and I mean, we're not just facing the question here with 5010 and its introduction, but in some of the other hats both this NCVHS wears and looks at and hats that I wear in other areas of the implementation of the President's agenda.
You know, we're facing the exact same questions of when can we implement, and we're looking at all these implementation issues.
And the one thing that strikes me is, as Jeff said, we're probably going to write a letter, and we're probably going to say do 5010, and we're probably going to say expedite it. But I think one thing that we need to sit down and think about is that this has to be the last big bang implementation.
You know, I think we have to think about implementing changes in this process in a much more incremental fashion in the future. And I think that's one thing that we should start focusing on and thinking about. I'm very struck by what you said a few minutes ago when you said 5010 is final. There aren't going to be any changes. I mean, we may see something when we actually start implementing we'll have to do a very quick addendum on. I can't see something as complex as 5010 going in completely clean. But I'm hoping that's extremely rare, and I also hope I'm proven wrong.
But you know, I'm struck by it's final. It's been final for a while. You know, why do we have to wait two years. Why haven't the vendors developed systems, and they're sitting in their backyard, and why don't they want to be the first on the block? You know, why can't we just say one year and force the issue? Maybe we should think about that.
And if we set it today, quite bluntly it's going to take two years before something happened. But if the NCVHS is pushing for a much more rapid implementation, maybe some of these people will start actually saying to people, yes, we do have a version that's available that will do 5010, and we can get it out to meet the time frame when the NPRM comes out or the final rule comes out.
You know, maybe we should think about that, Harry.
MR. REYNOLDS: Okay, I've got a question, and it plays off of both of the previous ones. As you think of the SDOs, as you think of the WEDIs, as you think of the industries, as you think of everybody at the CMS, everybody else involved, play off of both of those, adoption is really the deal in the end because people get ready at different points. And then the people that get ready early sometimes get penalized because if then there's a delay, they're in production a long time.
So, you know, as we obviously have with this streamlining letter that we're messing with along with this and the reason I want to spend – make sure we all spend a little time right here is because then we're going to, as soon as we leave your presentation, we're going to start talking about implementing it.
But I'm probably going to – this is probably my general question for everybody that comes up in the next day and a half. So how do we really make it different than the other ones, because most people in the space that have implemented the other ones don't have a real warm, fuzzy feeling about doing it again, and there are multiple thoughts, even looking at the 5010. It's ready, and we're anxious to hear what it's going to bring to the table.
But you know, if everybody stays separate – the SDOs and the WEDIs, and everybody has their space, but in the end, it's all the same space. You know, the industry has to implement whatever it has to do, and it has to go end to end, covered entities, non-covered entities, whatever term somebody wants to have. You know, and then I harken back every time I sit here. I harken back to e-Prescribing. And I saw an industry that didn't kind of break itself up. I saw the industry show up behind us in the audience, and I saw the industry stand up in unison when they did or didn't want something. And the time frames where everybody making it happen and, playing off Steve's comment, they made it happen before we even said go. I mean, they were really pushing as a group.
So how do we group everybody up so that it's not everybody kind of their own little ballpark. Because when you talk about streamlining, regardless of how fast we put it out, if we remain inadequate to implement it as an entire group, that just means we'll get it out faster, and it probably may take as long or may take longer because of whatever reason.
So anything that you or Lynn, please jump in, or anybody in the audience even, because as we spend the rest of this day listening about 5010 and that constant thing is going to be, okay, we write a letter, and whether we use some of what Steve just said or we do something different, when we say go, what does go mean to the people that are going to go. And that's been – you know, that continues to be the issue.
So as we see the same faces around the table and the same passion that we all have to make a difference with some of these, that's really the issue on the table for me is not just writing letters and just setting times, but, man, you know, and with NPI happening right now which is kind of happening but happening a lot longer and probably will be the simplest of anything that's gone on so far and by far the simplest compared to anything that's coming up soon.
And so, with that I'd love to hear any comments from you or if anybody in the audience wants to come up and make any comments because I want to make sure we have a good discussion here before we just start into the tactics of 5010, and then we just keep going back over the same questions again.
So we're in good shape time wise. We're ahead of schedule. So I don't mind a discussion. So let me have Margaret make a comment, and then anybody else and then Judy, I'll put you on the list. Thank you.
MS. WEIKER: Well, as I kind of mentioned before, it's kind of – and I agree with Steve, you know, maybe we just need to say, hey, this is it. We need to go and kind of push everyone.
But what's happened is any time we set a time line, you know, to write the letter, set the time line, there's always been a delay, and it's always taken years to get final rules out, and those type of things. So I think what we have to do is say, listen, we're all going to meet these dates; we'll all going to move forward; here are the dates.
I think another reason why you may see some of the people waiting and not going ahead and saying, hey, I'm going to go ahead and adopt 5010 and start doing 5010 or D.0 or whatever is there's the HIPAA, and now I have to go through a process that says I need some kind of exception or something to allow me to do that so I'm therefore not going to be out of compliance with the current 4010(a)(1) or 5.1 NCDPD is I have to go through some process to get approval to do this.
And what that process is and how that is documented is non-existent as far as I know. I cannot go out to OESS or CMS or HHS and actually pull down a document that tells me what I have to do to go about doing that. I know there's been at least one entity that's done that with CODSEF(?), but you know it's not well documented to where I'm a vendor and I may say I'm going to get some payers and some providers, and I'm going to go ahead and do X. But I'm not sure how I go about so I can do X.
So that may be part of the problem, too, is if we're going to say this is HIPAA but yet you can go ahead and do exceptions and get these things going, is what's that's process to where I'm not out of compliance, where people aren't filing complaints against me because all of a sudden now I'm doing some 5010 work or D.0 work. That's something else, and I think that's part of the problem with I'm not going to go ahead and do this yet is where e-Prescribing was different. They didn't have that, you know, you must do this. This is HIPAA. If you don't do this version, you'll be out of compliance.
So that's something I think we need to think about is how to go about allowing people to go ahead and start doing some of this work without “getting out of compliance.'
MR. REYNOLDS: Judy?
MS. WARREN: Well, I guess my sort of observation and maybe even leading to a question. You had earlier talked about bringing together a task force to figure out how to go about this. So that made me start wondering, especially after I was reflecting back about the e-Prescribing.
In the e-Prescribing experience, we started having people who came together to provide testimony, and they started listening to each other. And then those discussions automatically started happening in the hallways, during breaks, in between our meetings.
And so I'm wondering in the process of doing 5010, is there a forum for discussions like that, or have you heard of any discussions. Because as I think about people willing to risk to go to 5010, it sounds like part of the problem is, until it becomes a final rule, no one has these discussions.
Are there any forums within WEDI or any of these other places where this is discussed for these kind of conversations to go on.
MS. WEIKER: Well, I know at the last X12 meeting, we actually did have a forum where we did talk about 5010 and took comments from people in regard to their concerns about 5010 and what would need to happen first and, you know, do we track it and who tracked it and how, you know, so we started the dialogue, let me say, in X12 at the last meeting which was in June.
Now NCDPD has a committee called SNIP which was kind of based on the WEDI thing where we do discuss in there about implementing and what needs to happen and how to go about getting these things done and who's doing what and writing instructions and those type of things. So NCPDP has that. In fact, in the presentation later on, you see we've already started actually doing training on D.0 via the web and have webcasts available to actually do that.
So the SDOs, one NCPDP has had this committee since the original HIPAA. X12 is now starting to have these forums where these discussions are taking place. So it's now starting to occur. And perhaps after we go through tomorrow's testimony, we'll see some of these things, you know, kind of maybe the task force type of thing take hold where people say, hey, let's you and me and so and so go over here, and let's start trying to figure this out kind of thing. We may see some of that out of close of business tomorrow. We may have a better idea.
MS. WARREN: Okay. I guess the reason I asked that is one of the phenomena about developing standards, and I experienced this while I was very active in HL7 is you made the comment that vendors aren't ready to do this. And yet vendors are sending their employees to work at the SDOs. And so it's those folks who are creating the standard.
So I get really concerned when the standards are developed, yet the vendors don't want to commit to compliance, but they help develop them. So somewhere we have a very strange process going on that I think is leading us down the path to where we're having difficulty in coming in compliance. And that may be worth a lot of discussion both here at our Subcommittee as well as within the SDOs that are participating in 5010 because I think that's some of our major roadblock. And, of course, we're talking about humans who like to do things in complex ways. So, yes.
MR. REYNOLDS: Lynn?
MS. GILBERTSON: One of the things of interest as we've been talking is, you know, is this a market opportunity or a threat, and aren't those some of the business drivers why people seek to implement new products. And has HIPAA made such a level playing field that you can't find a business opportunity or a marketing opportunity because your competitors are all going to come out with the same thing. And so have we created a problem that way.
Or have we somehow lost the reasons why you want to implement the new standards going forward or whatever do give you that business opportunity. Because one of the things that came through on some of the surveys is, you know, we'll wait until it's mandated.
I don't think businesses are operating by, well, we're only going to do whatever's mandated. So how do we turn that around so that they see that as an opportunity and not as a drudgery that they have to do because it's been handed down from on high.
MS. WARREN: Just to follow up on that, Lynn, because I think it's a good point. In the slide presentation, we were talking about having update standards because new technology is out there. I mean, a major business motivator of new innovative technology, you want to be able to use it. Usually when new technology comes out, it is more effective, efficient or whatever than the old technology. And so we have this conundrum now of new technology's coming out, there are new ways of doing business, and yet there's still people who want to hold on to the old ways.
And so not being a businessperson myself, I don't understand some of that. But I do think it's interesting to take a look at as we have delays. And for people to wait until it's mandated to even get ready is something that I have great difficulty understanding. I mean, it's not the way I run my own shop. So anyway, interesting topic.
And I don't know whether we can parlay this discussion into helping us come up with recommendations for our letter. But it might be interesting to pick up some of these points.
MR. REYNOLDS: Well, yes, because I wrote three words down here: implementation, adoption or embracing.
MR. BLAIR: Could you add to that list incentives as to examine what the incentives might be.
MR. REYNOLDS: Because as you look at this, and I'll tell you, sitting here, it's a real contrast between the NCPDP and we talk about streamlining, and we recommended in a letter to go to a next version of something that it happened. So that's about as fast and streamlined as something can get.
On the other hand, we're sitting and talking and so you've got people that just implemented, okay, it's out, I got to do it. And then you've got people that adopt it and say, okay, we're going to make a difference. And then you've got people that embrace it and say, okay, I can make a difference with it. And then add, huh?
MS. WARREN: Then you've got the small group that says this is something we need, and so we're going to spend time and build it.
MR. REYNOLDS: Right.
MS. WARREN: So it's beyond the embracing.
MR. REYNOLDS: And then the small individual, let's say, practice or anything else, you know, kind of gets almost left out of the discussion at times, and we've heard that through NPI and everything else. And so as we sit here trying to make recommendations, you could use each of those four words, and I could write a letter on each of those four words depending on how we want to approach it because if it's just an implementation, then you say, okay, gather up and do it.
But so if you've got the industry across that whole spectrum of words trying to do something whereas, from what we saw with e-Prescribing sitting here, it just felt a whole lot different.
But this feels like we're dragging, you know, you're dragging people along. So it's streamlining. So, Steve, you had a comment, and then Jeff.
DR. STEINDEL: Yes, I have a comment, and I just touched Jeff's shoulder and said I'm in first because I want him to react to this. But I have a problem with adding the word incentive, and the reason why I have a problem in this process is one thing that we did see in the e-Prescribing process was they were incentivized to do that before Medicare Part D passed. There was a tremendous incentive in the industry, and we felt that from day one of the hearings.
One thing we have never felt in the HIPAA process is an industry incentive to do it. And I don't know how we can – we can't push incentives on them. If they don't feel it's there, the only incentive that they have to do it is because you have to do it.
And if we want to look at incentives in trying to move it out of that process, that's a different story, and that's one reason why I suggested we may want to think about incremental changes. Because when you're starting to talk about something other than a big bank which costs a tremendous amount of money and disrupts everything, and you start looking at incremental changes, then people from the industry would come in to you, and they will say, you know, if we really could do this a little this way and it's a little bit better, maybe we have an incentive to move that way.
But that's changing our look-see at the whole HIPAA process and our way of thinking about it. And if Jeff is thinking about incentives in that mind, I can keep the word.
MR. REYNOLDS: Jeff, it's still on the paper, but I've got my pen in the air trying to cross it off. So I need you to think about what you've said.
MR. BLAIR: Well, I'm going to explain why I think we may need to take a look at incentives. I learned a lot in this last six to nine months, and the experience that I've had, I think, might relate to this. But the experience that I've had is speaking to the laboratory reference institutions, the hospitals, the medical practices, where I live,
And they have supported, for example, and this is the context, but I think it will wind up applying to this as well. They've wound up supporting the idea of creating a health information infrastructure and health information exchange. They've contributed money to the development of a health information exchange network. They've contributed time. But when we get down to the issue of specifics whereby are you willing to upgrade to HL7 2.5 in order to connect for the NHIN trial implementations, you have a lot of the folks that are those like in this room who see the long term vision, who work in SDOs, who work in the professional associations, and they're all for it.
And then they go to their chief executive officers, and the specific I'm going to give here is just one, but there's many, many others because – and the specific is for a chief information officer in a major reference lab who not only is ready to upgrade the versions of HL7 that they use and adopt LOINC and has contributed to these things over time, a steadfast advocate of all the things that we want in this room. Then he goes to his chief executive officer who is measured on maintaining cost controls.
And the fact that this is good a year or two down the road, the fact that they're going to have to do it anyway isn't good enough. They want to know what's going to compensate them this year for investing the $70,000 or $80,000 or $90,000 for upgrading that standard. And if that enthusiastic CIO like all the persons here cannot articulate that there is some incentive that is near term, it doesn't get prioritized high enough, and it gets deferred to “we'll wait until it's mandated.”
So that is my argument that I think if we don't consider – I'm not sure, you know, how well we're going to find it, I'm not sure how compelling the incentives can be. But I think that if we don't consider incentives, if incentives are not on the table, we may miss an opportunity to be able to make a difference. So that's why I put incentives on the table.
MR. REYNOLDS: Steve?
DR. STEINDEL: Jeff, what I'm hearing you saying is that the incentive in this case and in a lot of cases is the mandate. And what I really would like us to try to do, and this is what happened in the e-Prescribing industry, is that the incentive is not the mandate. The incentive is the business case, and that's an entirely different statement than, you know, reacting to the CEO and he's saying how can I justify the expenditure of $90,000 to do this. What is my incentive. And you can walk in and say it's mandated, whether it's mandated from a governmental point of view, or if we're looking at the CCHIT certifications for these standards or the NHIN certification in this area. All those are mandates, and you can say it's mandated, and they say, okay, we'll do it.
But we really, I think, would like to get into a mode where when the CIO goes in and says, okay, what is my incentive, my incentive is we will be in a better position to attract more business.
MR. BLAIR: You're getting close to what I'm saying.
DR. STEINDEL: And that is something that has not existed in the HIPAA process.
MR. BLAIR: Well, you're getting close to what I'm saying. What I'm saying is that if mandates are the – that's not an incentive; that's a hammer. That's not an incentive. And what I'm trying to say is that as we go through this process, if we can find a constructive way, a positive way, a carrot instead of a stick because mandating is a stick, if we can find a carrot to complement the stick, the stick is still going to be there, okay, but it would be much more helpful if we could find some carrots as we go along.
And if we could find some ways to ask the industry to be accountable for the milestones so that the only deadline is not the mandated date but the interim milestones is to getting to that date, I think that we might be able to move towards a smoother, more predictable transition.
MR. REYNOLDS: One other thing I'd like to mention just as we deliberate this is we heard the term CIO and we heard the other terms. A lot of those smaller providers don't have those things. A lot of the smaller providers, you could go out in the DC area and group a lot of them up, they don't know what a 5010 is. And so as we look at adoption and making it happen, we got to make sure we get to the streams, in other words, who represents these people and how do we make it happen.
And the one thing I personally think is exciting about things like CCHIT and other things is, you know, it comes with the package. You know, it's part of what they get automatically and the infrastructure's there. It's not that they have a CIO or a CEO; it's a $20,000 upgrade to a system that might have cost them $20,000 on some of these things.
So I think we got to keep that whole spectrum in place because every time we do something and leave the smaller players behind, we're still not implemented, and it's going to take longer. And NPI is just an absolutely perfect example, to quote some testimony that we had on NPI, they couldn't – they weren't even sure how to contact all the doctors. I mean, that's a quote directly out of the testimony.
And so we've got to keep that in mind as we do this because everybody in this room is very learned on the transactions, but adoption and implementation and making a difference in the industry is probably more of our assignment than whether or not we write a letter saying, you know, here we go with the next change.
MS. WEIKER: Right. Well, and with those providers, I mean, the NPI's a little bit different because those providers had to go do something, they had to go personally out and get a number or somehow manage to get that number where I think a lot of the other, like the transactions 52 and NCPDP HL7, a lot of them are relying on their vendors, you know, and it goes back to hopefully when they looked and did 4010 and their contracts with their vendors in regard to the software and upgrades and those type of things, they thought far enough ahead to say, gee, this isn't a one-time event, but this could happen many times over, and those contracts are written to where they don't get stuck with a whole new big implementation cost that's more of a “upgrade” versus a new type of thing.
And regards to the incentives, I think part of it is people need to be able to track and report what those are. We've heard many times where the 837, which is the claim, had been widely implemented in every kind of form and fashion because that spoke to money transaction. You know, I submit that claim; I got to get paid. And people have done that.
And if you look at the overall electronic weight of submissions and electronic filings, those are up. But then you start looking at some of the other transactions such as eligibility or claim status where a prior authorization, a perfect example, is where's the value to my business of making this an electronic, you know, what's the value of me putting in an automated prior authorization system.
I know I've seen reports where it costs like almost $6 to manually process a prior authorization transaction, where if that was automated, now we're talking no more than 10 cents. Well, there's a savings there based upon, you know, the number of prior auths you do. And if you're in a specialty that requires a lot of those, that's a great time-saving, money-saving effort.
But those things have to be tracked. They have to be reported, widely reported, and there's some of your incentives without, you know, really incentivizing, so to speak.
MR. BLAIR: Yes, and I was surprised to learn, picking this lab example again only as one of many, where the number of times these reference labs don't get paid because they don't get good eligibility information is a staggering financial loss to the labs, and the CIO understood that, and that enabled the CIO to then go back and make the case, and it was a huge financial case and benefit.
So I think the benefits are there, but we just – and I think a lot of us in the informatics industry understand that the benefits are there. But we haven't taken the step to quantify them because we figured, well, if the mandate's there and we know the benefits are there, that's good enough.
But I think we have to go the extra step to quantify this because otherwise the only way to go forward is with mandates, and that may be sufficient but not adequate.
MR. REYNOLDS: Pulling off of Steve's incremental comment, and I know we have Don Bechtel and others going to speak this afternoon. I think what we're all trying to do is get all of our questions and thoughts on the table during this discussion period so that people can address them.
Steve mentioned incremental. Margaret, you just mentioned transactions that aren't being used anywhere near their fullest. Are there plusses in implementing 5010 for 837 and 835 and not the other transactions until they're used more. In other words, when you look at incremental, you look at the cost of doing it. You look at the cost of other things. I don't have a clue what the answer is. I'm throwing it out as a question and a consideration because at some point considering re-doing something that's not getting much attention now is another lot of money, another lot of effort to just remind yourself that you're not where everybody would have hoped everybody would have been, and our ROI letter says that from this Committee.
MS. WEIKER: Well, I think in regard to the incremental and in your question specifically is I think we need to move all of these transactions to 5010. There are a lot of major changes that have happened in each of these transactions to make them “more useable.”
One of the reasons the 278, the prior authorization transaction, is not widely implemented today is because it doesn't allow you to submit the data that's required to do a prior authorization. For example, it didn't support revenue code while in many instances in a hospital where I'm going to do a prior auth for something, I may need that revenue code but there's no place to put it in there. So now I'm doing it via paper, or I'm doing it via phone system or whatever, however the payer allows it besides the ‘78.
Prior authorization from a physician for drugs, I mean, there's a work around because the original guide didn't have a place to put a NDC. So in many instances, those transactions need to move forward so we can go ahead and implement them and get the value out of doing that. And I think maybe once we get this “next big bang,” then maybe we do need to look at now here's a new business need or requirement. For example, Medicare Part D came out. Well, that probably didn't affect or impact every transaction. So do we find a way to where we say, okay, we need to upgrade these because we now have this federal mandate, and it impacts so many people. Let's not try to shoe horn it in to what exists today. Let's go ahead and upgrade it and get those done to where it does make it more usable. There's not so many work arounds where people are spending more money writing work arounds than they would if they would just implement the new version.
MR. REYNOLDS: Good. Any other questions from staff or the Committee? Okay, right on time. Let's move to our next agenda item. Thank you for the discussion because it kind of sets a framework since we are going to try to put a letter – we will put a letter together out of this hearing. I want to make sure that we spend whatever time necessary to discuss this so that we don't wish we had asked some things or done some things when we're trying to put pen to paper after just a day and a half worth of hearings.
So Lynn, were you going to do NCPDP? Okay, good, please continue.
MS. GILBERTSON: Hello. Thank you very much for the opportunity to present today.
In the packet that was sent to the Subcommittee, we included this PowerPoint presentation which we'll be going through today, and then also quite a few page document that gives a little bit more detail in verbiage on what changed in the NCPDP standards coming forward. It's about a seven-page document just to give you a little bit more detail because I understand the Committee was interested in the types of changes that took place. But obviously we're not going to go through every single one, and we tried to summarize what the NCPDP standards, the requests will be for.
Okay, in the January batch that was submitted to the DSMO, there were two change requests that were submitted, approved and then brought forward to the Subcommittee. The first one was Change Request 1055, and that was for the telecommunication and the batch standard implementation guides.
The telecom standard version 5.1 was named in the HIPAA 2000. That request is asking to go from version 5.1 to D.0, and the batch implementation guide, which version 1.1 was named in HIPAA 2000, and this would move to version 1.2.
These two sets of implementation guides are the main set of transactions that are used between pharmacies, payers, pharmacy benefit managers, clearinghouses switches and a new entity we'll discuss in a minute called the facilitator. The second change request that came forward –
MR. REYNOLDS: Lynn, as you go through each one of them, would you say so what. Would you answer the so what.
MS. GILBERTSON: Would I do what?
MR. REYNOLDS: No, so you mentioned 1055, and you mentioned that everybody agreed what they were going to do. Well, what does it do? What difference does it make?
MS. GILBERTSON: That will come a little bit later in the presentation.
MR. REYNOLDS: Thank you. Okay, thank you very much. Okay, got you.
MS. GILBERTSON: Here's the high level intro, and now we'll do the so what.
MR. REYNOLDS: Thank you. I couldn't remember all the questions we had if we had to –
MS. GILBERTSON: Okay, the so what will come just in the piece right here.
MR. REYNOLDS: No, it's great. Thank you.
MS. GILBERTSON: All right, and Change Request 1057 also came forward. This is for a new implementation guide to be named into HIPAA. It's for Medicaid subrogation, and this, for those not familiar with the subrogation process, it enables the Medicaid agencies to be able to collect payment from another payer after they have already paid the claim. So it's to some might have referred to it as the pay and chase model. It's used in coordination benefits when the Medicaid needs to recoup their funds, and this is a request for Version 3.0.
These requests were brought forward to NCVHS in the May session, and now we'll go into the so-whats.
The Telecommunication Standard Version D.0 supports these basic functions at a high level between those entities that I mentioned in the pharmacy industry. The eligibility verification transaction, widely used in the Medicare Part D environment, claim and service billings. Information reporting which is used as kind of a catch all for things that have to be reported that are not part of a claim, for example. They may be based on claim data, but it's not a claim payment.
The prior authorization functionality, all these already exist. They've been in 5.1, have been used quite a bit, and the new transaction that was added into D.0 is a predetermination of benefits. It looks and acts like a claim, but there's no payment that takes place. It allows the pharmacist and the patient to determine if the patient's eligible for this particular prescription, if there's any kind of coverage information they need to know about. This is especially important when there's a high patient financial responsibility for a high cost drug. So it's a claim without a claim, and this function can be done today. But what's happening is you submit a claim, find out how much the payment is, talk to the patient to see if they can do it, and if the patient cannot afford it for whatever reason, then you back out the claim.
So this is just rather than rickeydoit, put it into a transaction that actually says I just want to know predetermination. Okay, so what changed in Telecom from 5.1 to D.0. One of the biggest things that changed was related to the HIPAA privacy regulations which surprised us but came out of nowhere for the pharmacy industry which was an exemption that was stated in the privacy regulations having to do with whether you use mandatory optional required or situational designations on fields and transactions, and whether or not you got the privacy exemption based on that.
So NCPDP members went back and went through all the fields, all the transactions and adhered more to the privacy regulations having to do with requireds and situationals and definitions of that. And what we've done is taken these and put them into chart format which is a little bit more readable than narrative text which allows the implementer to see for each transaction, for each field what the situations would be for the usage of this field or whether it's not used and spells it out much more chart-based which tends to help the implementers.
We also, as Margaret mentioned earlier, have had a lot of enhancements from Medicare Part D. The new entity of a facilitator was brought in as a representative of the Medicare Program to handle coordination of benefit information for eligibility and for TROP(?), true out-of-pocket information, on behalf of the patient. So that entity came into place when Medicare Part D began, and the industry started using the Telecom Version C.1 information reporting transactions to do their business needs of updating the TROP(?) amounts. So that's actively in place today.
Eligibility transactions for Medicare Part D – we had to use free text areas to put a lot of information that was needed for the Part D coordination of benefits, what coverage this patient had, what other payers were involved, things like that. And instead of stuffing it into text as it is in the 5.1 environment now, the D.0 actually splits them into real fields that you can do data manipulation on and things like that.
The long term care pharmacy environment had similar needs related to Part D claims, and we had to go through some hoops to give them some interpretative usage of current 5.1 fields. So in the Version D.0, it's what it is. If you needed a field and you needed it called this, then that is what it is. It isn't an existing field that's been kind of monkeyed with so that you can use it in today's world.
We also had Medicare Part B enhancements that came forward. Medicare brought forward requests for certificate of medical necessity data elements that are included as well as segments for their purposes. And we added new data elements for processing Part B transactions and in crossing over of the Medicare to Medicaid environment. So wherever business needs have been brought forward in the last couple of years, obviously they've become fields rather than monged(?) in wherever you can put them.
Other changes that occurred in Telecom, an inadvertent editorial error was left in the 5.1 standard that supported three ways of doing multi-ingredient compound prescriptions. It was only intended to be one method, but this editorial error left the door open for a recommended and then two alternative solutions. The industries decided they do not want to support the alternatives any more. And especially when you're talking coordination of benefits, you don't want three ways of doing the same thing, especially when you're trying to cross to different payers, and this also helps in the collection of rebates because their multi-ingredient compounds are shown one way and one way throughout the systems.
A lot of work has gone on industry representatives on pricing guidelines and in coordination of benefits. I can't tell you the amount of volunteer effort that's come forward from the industry to help not only because of the Medicare Part D needs that have newly come, but HSAs and HRAs, all the different kinds of new business requirements that have come forward. The industry has really put a lot of work into defining fields for pricing, breakdowns that really reflect getting down to every single piece of the chunk of the claim that you need to know for reporting, and how to report the information correctly when there's coordination of benefits, recognizing that there are different payers and obviously if they have different business needs. A lot of effort has gone into guidance and examples to show all the coordination of benefit support.
It's really come to its own in the last few years. Coordination of benefits was always out there, but it really wasn't as heavily hit as we've seen in the last probably two and a half, three years.
Prior authorization, this has always existed in the telecom implementation guide, but we added more guidance for the vendors, for the implementers of the prior authorization process that the pharmacy is responsible for.
The prescription service reference number, this has been increased to 12 digits. This is a key field throughout the pharmacy industry. It's what some might refer to as the RX number, but more appropriately it describes the prescription or the service. And part of its enhancement was to make the length longer, was to help in the false duplicate processing that goes on, rebates and downstream processing.
There's payer-to-payer processing guidance was added once again for crossover and subrogation needs. And service billings have their own transaction code. This isn't a major deal. We just moved it up to a transaction code level, but it was a change in the telecom standard.
Okay, now we're going to switch gears to the batch standard, and this is the second part of the request to Version 1.2. Batch goes with telecom hand in hand. It's just a wrapper if an entity does not want to do online real time pharmacy claims processing but wants to take all the benefits of not having to write separate parsing routines or different rules. It's just – they go hand in hand.
There were some minor changes made from Version 1.1 to 1.2. We made some editorial changes describing about how the sender and receiver ID was used. We had some editorial errors with the use of the word transaction versus transmission in describing a detail and header record, so we cleaned that up, didn't change the functionality, just made it clearer to read, and we cleaned up some examples that were messed up. So that's that.
The new request – the DSMO Change Request is for the Medicaid Subrogation Standard Implementation Guide Version 3.0, and this is a new – it would be a new implementation guide coming forward through HIPAA. And once again, this is the pay and chase that's used in the Medicaid arena to other payers when they need to recoup funds.
Currently, when the industry is using the Batch 1.1 version for Medicaid subrogation, they've been kludging fields, once again shoving things in to meet the business need so the Medicaid Subrogation Imp Guide Version 3.0 undoes that. It links everything tightly with the Version D.0 so what you're sending on a claim regardless of whether you're pay and chasing or whether you're doing just coordination of benefits or rebate processing or whatever follows through all the way down.
Currently, in the subrogation environment some entities are using the Telecom Version 5.1 in a real time environment, some are using the Batch 1.1 environment, and some are using their own proprietary. So you can imagine the difficulty with coordination of benefits when you've got different formats flying around with different interpretations of pricing fields and meanings. So this was a request to come forward with one version that all of the industry could use for this particular business case.
And what's happened in the subrogation from Version 1.0 to 3.0 have been fairly minor. A couple of these items are editorial. We've included support of our data dictionary external code list. It was a citing to all the values that the NCPDP standards use. We put it in a new standard template document structure. And, once again, I mention we harmonized it with the D.0 so that if you are implementing the D.0 environment and you're doing pay and chase, you can now do subrogation 3.0 and be in sync.
And the last thing Margaret mentioned, there have been webcasts. We had them in January and February for the D.0 while the ballot process was going on. We have created surveys, which WEDI sent out to the industry, that they'll be reporting on later on each of these transactions to hear what the industry wants to say about it. And basically, the call from the members were let's get started; we need to stop kludging and start doing. So and that's it. I'll take any questions you'd like.
MR. REYNOLDS: That's the first time we've heard kludging in a while. With that, I'll open it for staff or memberhood. Judy?
MS. WARREN: Yes, back on your slide number five, you were talking about the changes in the telecom standard. Help me understand the difference between prior auth and the new transaction predetermination of benefits, slide number five.
MS. GILBERTSON: Okay, a predetermination of benefit is basically stating I'm going to dispense this medication, but I need to know (1) is it covered, how much would you pay if I submitted a claim, how much would the patient be a co-pay deductible, whatever.
A prior authorization states I want to have approval to dispense this medication or to perform this service. And if you give me approval, then I put that number on the claim, and you'll pay it. Where, if you deny it, that means you're not going to pay for that drug at all as a payer, and then it's up to the patient to determine if they want to pay for it or not. But predetermination is it doesn't require an authorization or approval to dispense; it's I'm going to dispense, but how much would you pay, is it on the formulary, those type of things.
A predetermination is a claim without payment, so to speak.
MR. REYNOLDS: Okay. Other questions? Steve?
DR. STEINDEL: Yes, Lynn, I was fascinated by, well, and you actually said this on your very, almost your last words. But I was fascinated by the trend that went through this that these seem to be an industry supported, this is an incremental change, this is what we need to do to make the process flow better.
And what you're coming to us is really somewhat of a procedural question. Look, this is what the industry wants to do, and we need blessing to make this happen.
MS. GILBERTSON: Right.
DR. STEINDEL: And that disturbs me. It doesn't disturb me because you're doing it. I'm very happy about that. What disturbs me is the process part of it, you know, that we're facing something that there seems to be this general trend from the industry itself that is asking for these changes and now there is a barrier in the way of these happening to make their processes more efficient.
MS. GILBERTSON: I mean, it's very difficult to group the industry, the health care industry in one bucket.
DR. STEINDEL: If I could clarify, I was speaking about your specific subsegment of it.
MS. GILBERTSON: Right, right. And so it's – and we're kind of schizophrenic. We want to do it fast, but don't make it do it fast. We talked about that in previous sessions and how do you balance that. But we can't stop the folks who do need to move forward and see the business need. And as you said, they have to come and ask for permission to do something that they want to get done.
We've had folks who wanted to do Telecom 5.5 before the 2000 rule came out because they saw a benefit in coordination of benefits that just hadn't come up before then. So I think we're always going to have folks who just do not see the ROI or it's expensive or whatever reason they're not going to be able to move forward as fast. But how do we not punish the folks who do want to move forward for their business case. They've got people behind them who will approve the budget and things like that.
MR. REYNOLDS: Okay, I've got a couple questions. I tried to write down. It appears that the changes in the D.0 would fall into the category of corrections. You had a few corrections up there, things you wanted corrected.
New requirements, I saw a lot of Medicare D, and I saw a lot of things that you would want changes before because it's new things that are there.
MS. GILBERTSON: That have been shoe horned into the current version.
MR. REYNOLDS: Yes, right, right. And then I saw some called better business, for example, where you had verbiage buried in a field, you've now made it accessible. You've given it a clear definition and made it accessible so it could be used in a better way. Is that fair?
MS. GILBERTSON: That is very fair. And we've learned, too, because in the past couple of years we have an editorial document that we have come up with, with questions from the industry, typos we found, things like that. And we've learned, too, that the more beef we put in based on those questions, the better the guides become.
MR. REYNOLDS: And is it fair, playing off of your conversation back and forth just briefly with Steve and then some of the earlier stuff we talked about, when we talk about the industry that's focused around some of the NCPDP, it appears to PVMs, switches, vendors, but it doesn't necessarily have to bring along the individual practitioner or others because most of this is done in a way that a lot of this data that goes back and forth is either from a pharmacy and others rather than back to the individual doctor.
If you look at these changes, individual practitioners and others may not actually have to even be involved for these things to happen whether you went to a new version or didn't. So is that maybe a difference between that part of the industry and the other part of the industry.
MS. WEIKER: Well, there will be a few things that a prescriber might have to implement, so to speak, such as certain things or situations in regards to a diagnosis code. Now of a sudden, they may need to put a diagnosis code on the prescription or the piece of paper or those type of things. But the majority of it do not happen back at the prescriber. It happens from the pharmacy provider who is very involved both organizationally as well as through associations at NCPDP through their vendors to the switches to the PVMs. I mean, in regard to NCPDP, you have what I'm going to say the entire process sitting around the table discussing and, at many times, arguing very passionately about those changes.
MR. REYNOLDS: But all in is the key term?
MS. WEIKER: Yes.
MR. REYNOLDS: All in. Okay, good, thank you. Any other comments or questions from anybody on the Committee? Thank you. Both of you were – if there aren't any, then one thing I want to do before we would take a break as scheduled would be to go ahead and let Simon and Marjorie and Steve introduce themselves so that we have that on the record that they were in fact here, and that would be a good thing.
DR. COHN: This is Simon Cohn. I'm a member of the Committee from Kaiser Permanente, the Chair of the Committee and member of the Subcommittee.
MS. GREENBERG: Good afternoon. I'm Marjorie Greenberg, National Center for Health Statistics, CDC and Executive Secretary to the Committee.
DR. STEINDEL: And I'm Steve Steindel from Centers for Disease Control and Prevention, Staff of the Subcommittee and liaison to the full Committee.
MR. REYNOLDS: And do we have questions from them? Yes, Stanley, please step up to where there's a microphone, if you would, please.
MR. NOCHIMSON: I'm Stanley Nochimson. You talked in this presentation, Lynn, about the Medicaid Subrogation Guide and recommending it be adopted as a HIPAA standard. Do you consider it a new standard for a transaction that we do not have a standard for already, and do you really feel that we need to adopt it as a HIPAA standard and it sort of goes to some of the earlier discussions. What if it was not adopted as a HIPAA standard, but just put out there for the industry to take on as soon as they wanted to?
MS. WEIKER: In regard to the survey results, we actually surveyed about Medicaid subrogation, and what we found was 50 percent of our respondents were Medicaid agencies which was a good thing because they're one of the entities that are lacking implement, and that's where we found that some of them are using a previous version of subrogation. Others are using a proprietary format, but more than likely they're using paper.
And some of the issues or concerns they had in regard to cost was if we go to D.0, then the cost for me to do Subrogation Version 3.0 is very small because it's basically a wrapper as much as the bat, something around it where there's fields, you know, five or six fields now that I would use where previously, if it's just a regular claim, so to speak, I don't use.
So you could say, well, if we go to D.0, then the intention to move to Medicaid Subrogation Version 3 is much higher because now we have “one way to do it,” the fields aren't kludged, which I know a lot of people have trouble with doing that.
And is it really a new standard? There's rules, new rules, so to speak, in regard to some of these fields. But when NCPDP as an organization discussed this about do we move this through HIPAA, do we not move it through HIPAA and just let the industry decide to implement or not, the industry said no, let's go ahead and move it through the HIPAA process, believe it or not. Somebody wanted to move something through the HIPAA process
Tape 2
MS. WEIKER: Let's go ahead and move it through the process, and I think it goes into now we all will have to do it versus letting us determine what to do at some – and Medicaid maybe they see it as a way to say I have to do this now, so you have to give me the extra $20,000 which I think was the average to implement – once they implemented D.0 and those type of things.
MR. NOCHIMSON: I think there'll be sort of a timing problem because if it is a new standard, we'll have to give 24 months to implement it.
MS. WEIKER: Right, and that may not really be a problem where if we get D.0 out there, get it implemented first, get it done, then to actually implement the Medicaid subrogation shouldn't take that long from once I get D.0 done to actually code around the new fields and exchanging of the data between the payers. So I hope we get D.0 done and then do subrogation and plus it takes money as well, too, on that back end.
MR. NOCHIMSON: Sure, and then unfortunately the Medicaid subrogation standard then has all of the good things about the international standard, plus it has the bad things whenever you want to change it.
MS. WEIKER: Right.
MR. REYNOLDS: Simon and then Karen.
DR. COHN: And I do want to apologize for my tardy behavior. Also, you could hear me conferring with one of my colleagues to make sure that I was not asking a question that had been previously addressed.
You obviously caught my attention when you were talking about diagnoses being submitted, and I couldn't tell exactly in which authorizations were – in which of these pieces we're talking about, but I want to hear a little more about that only because historically what you're really talking is diagnosis medication association.
And generally, at least to my understanding, most requirements out in the industry there's really not a requirement for that sort of association to occur, and I'm actually wondering if this is sort of opening the way for all medications to have a reason that it gets submitted to the pharmacist that then gets submitted to a PBM or otherwise. Where – can you clarify this one for me a little bit?
MS. WEIKER: Well, there's certain classes of drugs that a payer would want to know what the diagnosis is before that drug is approved, and, you know, I'm not a pharmacist, so right off the top of my head I can't think of any.
But I do know there are plans that have certain classes of drugs that say you have to get a prior auth. And in order to do that, I need to know that the diagnosis for that particular patient is X before you can do that. So there are some of those type of instances where it's by classification.
Some of the services billing, there is certain diagnosis codes that are needed in order to say, yes, I'm going to approve or pay that service billing based upon the diagnosis code. For example, if the pharmacist is providing education in regard to diabetes and testing their blood sugar and those type of things. But if I don't know, I mean why would they do it if they weren't a diabetic, you know, is another story. But yet I do want to see that there's a diagnosis code of diabetes or something like that.
So and I do not know payers and processors that would love to get the diagnosis on every claim that came through the door, so to speak, so they could do some of the reporting and business intelligence and those type of things. But right now until that becomes a common practice, it's more the exception than the rule.
DR. COHN: So just to make sure I understand about this one, is this a new feature of the –
MS. WEIKER: No, no, no. Diagnosis code has always been there, and it was optional. And what we now have made it into a situation and defined the situation a bit more clearly to where the pharmacy understands when they have to submit that diagnosis code versus when they don't because a lot of times it was a drug that needed a diagnosis code and it wasn't submitted, and then it gets rejected, and then it goes through prior auth and, you know, you've got to have a diagnosis code, and they didn't submit it on the prior auth. I mean it goes kind of around and around.
So it's not a new field added to the standard. It has always been there. We just provided some clarification around the use of the field.
MS. GILBERTSON: And Judy asked the difference between the new predetermination of benefits transaction and the prior auth, and what was the difference in business case, and diagnosis code can be one of the key fields in a prior auth of why is this trying to be dispensed versus approval for the dispensing.
DR. COHN: So is it required in both potentially, at least in the situation or not?
MS. GILBERTSON: No, it's not required.
MS. WEIKER: No.
DR. COHN: Well, in this situation all I wanted. Sounds like situational for prior authorization. Is it situational under predetermination of benefits as potentially to identify clinical relevant information?
MS. WEIKER: Yes, correct.
DR. COHN: Okay.
MS. WEIKER: It's hauled around just about everywhere.
DR. COHN: I just want to better understand this one only because I think that obviously you've talked a lot to the pharmacists. I'm not sure that you've talked with the physician community probably on some of this stuff, and so obviously this has to be a question of well, how does e-Prescribing occur or how do all of these other things connect together in just sort of in contra distinction to Harry's comment that this doesn't touch physician practitioners at all.
So describe to me the – there are different ways of describing situations in situational, and you can sort of say now this is required, and you will submit it whenever a payer determines that it is necessary to adjudicate the claim. That's one way of describing a situation.
You can also say this will be situational whenever somebody has cancer diagnoses and the ICD XXX YYY routine areas and back pain and these certain ICD ranges having – what does this look like, and can you clarify this one for me.
MS. GILBERTSON: The former versus the latter. I mean, the standard's not doing the clinical type of questions being asked, but required when it's necessary for as part of the service performed or, you know, it's technical and business versus clinical situations are defined because obviously the payers, the plans, the health care entities determine what ICD, LOINC or whatever kind of determination they decide the standard does not go to that level of specificity.
DR. COHN: Can I ask one final question here before you were wondering what happened to your early break. So currently in the industry, what is the percentage of, I mean, given that you were telling me that diagnoses have been a field that was an optional field previously, and now you're providing greater guidance, what is your vision of where it is now in terms of the requirement? Where do you see it moving to? No comment? No knowledge? Okay.
MS. GILBERTSON: Until you start seeing it on the prescription pad or on the e-Prescribing transaction, I mean, the pharmacist is not going to submit it as pharmacy inferred which is one of the values it can have versus the prescriber actually wrote it down. You see them on situations where there's a prior authorization case known that's documented that that's got to be part of the claim. But you know, how many diagnoses are written on even prescription pads. So the pharmacist has no knowledge of it.
DR. COHN: I see. So the current process is that a pharmacist actually calls the provider to find out so that the prescription can be filled.
MS. WEIKER: Yes, most of the time that's what's happening today versus there are instances where a particular prescriber would know that, hey, I'm writing this drug. It's for a particular payer, and every time I write this prescription for this drug, I get a call that says what's the diagnosis. Well, I'm going to write it on the pad this time, you know, kind of thing to where there is some of that learned behavior. But as far as it becoming the practice, it's not. What are you two laughing about?
DR. COHN: She was actually clarifying for me the physicians actually are cleanable, so –
[Laughter]
MS. WEIKER: It is hard to believe, isn't it, Judy.
MR. REYNOLDS: We will add that to the letter.
DR. COHN: This will teach me to show up during this conversation. But is the next step that we should then be expecting here is a conversation around the NCPDP script standard to have it start including, or is it already there, and it's just optional?
MS. WEIKER: It's already there in script. I mean, that's already there in script.
MS. GILBERTSON: The tracks are built, it's just when they're going to put the train on the tracks.
DR. COHN: Okay.
MS. WEIKER: In tomorrow's testimony, you will see that there are people scattered throughout the testimony that represent the different industry sectors as well. So you will have those tomorrow.
DR. COHN: Okay, thank you.
MR. REYNOLDS: Simon, I think another thing that affects the percentages – I'm not a doctor, but I have been watching e-Prescribing, is that the number of actual drugs on there is usually small. However, for example, in North Carolina, Celebrex ended up on that category as a prior auth at one point. So you can – the number was small, but all of a sudden if one of the key drugs for any one reason shows up on that list, then the number of these kind of situations goes up. So that also – so you've got to look at both numbers to really understand how much it does –
MS. GILBERTSON: And there are prior authorizations that don't need diagnosis code. They're based on other criteria.
MR. REYNOLDS: Right. Karen. Good, okay. Anything else from anybody on the Committee, staff, panel or – if not, it's five minutes to two, we will break until 2:15. Thank you very much.
(Break)
MR. REYNOLDS: Our presenter is Don Bechtel, and he's going to give us an overview of the 5010 issues, benefits, business case and everything else we would ever want to know, right, Don?
MR. BECHTEL: That would be the goal.
MR. REYNOLDS: Okay, thank you.
Agenda Item: Overview of 5010 Issues/Benefits/Business Case
MR. BECHTEL: All right, well, thank you, and I guess you know who I am at this point.
I would like to qualify that I am an IT architect and standards regulatory manager who works for Siemens Medical Solutions. But I'm also here speaking today primarily as an ASC X12 Co-Chair of the Healthcare Task Group that primarily is that.
The presentation that I'd like to go through today is kind of discuss a number of key elements primarily why we are asking for 5010 to be adopted for replacing Version 4010(a)(1), and I would like to highlight today some pretty much by transaction some of the more significant changes that are in these transactions.
And some of these changes are rather cosmetic, and I'll highlight where the cosmetic nature of these are, while others are fixes to 4010(a)(1), and then others present new function to the transaction standards, and in some cases we're even removing functions. So we have a gamut of different changes here.
So why do we want to consider Version 5010 now? And to be begin, Version 5010 was adopted by a final rule on August 17, 2000, and on May 31, 2002, HHS adopted addenda changes for Version 4010 that are now referred to as 4010(a)(1).
These addenda changes were critical fixes only. In other words, they were to ensure that 4010 was going to work. So when we got the addenda changes, we didn't get all the new functions that had been added to the standards since 4010 was issued. We got only the critical fixes.
So simply stated, the Version 4010(a)(1) transactions today in our opinion are out of date. They're more than six years old since they were first adopted, and one could argue that to go back even further because when we brought 4010 forward, we were bringing actually Version 3070 forward, and we had to modify Version 3070 to include century dates. So we had sort of little incremental changes that we were making, and these standards really go back to probably the late ‘90s.
Since then, we've had hundreds of industry requests –- you're not going to jump ahead of me, right?
MS. WEIKER: No.
MR. BECHTEL: Okay. We've had hundreds of requests that we received from the DSMO to make additions or modifications to the initial standards, and nearly 500 of these have been addressed in later versions.
At X12 additional industry requests have been made by industry stakeholders which were also addressed in later versions. So these changes improve the functionality of the transactions and correct many of the problems that we encountered when we first implemented 4010. But we couldn't make any changes to them prior to now.
The longer we wait to make these implementation changes, the more significant the change becomes. So we feel it's becoming urgent for us to get this done so that the magnitude of the change is not so great.
To this day, we continue to rely on companion guides to address areas where the implementation specifications were not specific enough to do the required work. And so we had to write work arounds or have other ways of addressing those shortfalls. And so consequently we still have a variety of different implementations as a result of that.
And so some of the problems we want to prevent that from going forward. And some of the problems that we had also prevented implementation of some of the standards such as the 278 transaction where we have not seen very wide implementation of that due to the fact that it didn't have the necessary information to meet some of the request requirements to support an authorization request.
So continuing, the transaction improvements have been made to all the transactions. There's not any that didn't have some change to it. We also expect that there will be future regulation changes for the need to have ICD 10 where today we're only able to support ICD 9. So if we have to support a regulation change for ICD 10, we have to move forward to a newer version of the transactions. 4010(a)(1) does not support this.
The first transaction version that does is 5010. We could wait for a later version if we needed to, but hopefully 5010 is what we want to adopt. We were requested to put 5010 into this transaction set by the Center for Disease Control, the National Center for Health Statistics, the American Health Information Management Association and CMS all requested that this be added.
The parent 4010(a)(1) guides also have some shortfalls in guidance on implementing NPI. Since the 4010(a)(1) implementation guides were written, we have learned a great deal more about NPI and the requirements. And so the implementation guides in 5010 provide much better instructions to alleviate some potential problems that we think we'll have in particular with the claim transaction.
The updates should not be characterized as a do-over. ACS X12 believes that it is important to note that this version or upgrade of HIPAA standard transactions should not be characterized this way. Although it is very true that the analysis step to determine the differences between 4010(a)(1) and 5010 will require that each entity conduct a thorough review of each transaction's implementation guide and how they have implemented 4010(a)(1) versus what 5010 will require, and this could be different for each entity, especially in the area where we have situational rules.
But the actual changes would not be 100 percent changed, and in fact some of the transactions have not changed very much at all, and some have had moderate and a few have had some significant changes such as the claim of the 278 transaction for authorization referrals.
Further, the HIPAA implementation Version 4010(a)(1) we are comparing changes – when we were implementing Version (a)(1), we were comparing changes between proprietary formats and other implementation standards from a wide range of things where in this case, we're only talking about X12 transactions moving from one version to the next. So we think legally this is a far less complicated change than what we experienced when we first did 4010.
But again, on the other hand, it is equally important for us to understand that these changes to add new functions, they do change other functions, and in some ways codes have been added or removed, and so careful analysis is needed. We believe that the industry will need adequate time to complete their analysis and do the work, to complete their application coding, to conduct the internal testing for the changes required, and then have adequate time for external testing with their trading partners before they can begin to complete the implementation.
Although it is not a do-over, we do realize this is going to be a significant effort and take significant time.
Types of changes, there are four basic kinds of changes that we have described in our review of the transactions. Basically, they are in the area of structure changes or front matter changes or technical improvements or data content. The restructuring of the front matter is where we have reorganized content to make sure that technical reports or the implementation guides cover the same topics in the same location of the documents, and we consider this kind of reorganization, if you will, to be rather cosmetic but also important.
But we also want to highlight, although it may seem cosmetic to change the way we present the information,, the information that's in these guides in these sections has potentially changed, and these we would not consider to be cosmetic but rather substantive changes. So when we say something's cosmetic, there was a lot of concern at X12 that we don't overlook the fact that there are serious changes in here that we have to look at carefully.
The primary changes are found in Section 1 of the implementation guides which are now called ASC X12 Technical Reports Type 3 or TR3 documents. So if you hear me speak of a TR3 or a technical report or an implementation guide, they're all kind of the same thing, if you will.
ASC X12 has worked to standardize how the information is presented, an improvement that will help to make our implementation specifications more consistent where information is located which will allow implementers to more easily find specific types of information from one TR3 to another.
Section 1 provides narrative information on how certain business functions are performed or defines business rules that may be associated with various functions described.
So looking at Section 1 on this slide, this is a list of the standard subtopics, if you will, or subsections that you would find in Section 1 with all the TR3s addressed in one way or another.
But each TR3 will address it from the transactions point of view for the business topics and functions that are specific to that transaction. So looking at the claims transaction, for example, we would find discussions under the business usage that would cover such things as coordination of benefits, property and casualty implications, data overview, balancing or allowed or approved amount calculations.
So, again, the format changes described here are related to X12 end's standard content and format. But in addition to the standardization of topics, in most of the TR3s there were changes made to the substance of the front matter and the content to make it clearer, more instructional, more informative, more accurate than it was before, and this should not be considered cosmetic.
Technical improvements, we can liken these to architectural design improvements that will allow the transactions to more efficiently or effectively and technically better accommodate the data being collected and transmitted to make the information more logical and understandable.
In the claim transaction, for example, multifunctional segments with multiple qualifiers giving different meaning to different things such as referral or prior authorization reference segments. By splitting the information guide view of these two segments into succinct rules, to describe each element rather than having very generic descriptions to describe the multiple purposes, we think this will be a better approach to understanding what is required. And in the past, this has led to many implementation misinterpretations by implementers.
Loop and segment repeat counts were not always logical either, and sometimes they were excessive. This usually occurred where there were more than one qualifier or a number of other repeats would vary from one qualifier to another.
So in an effort or reduce this, we tried to remove those kind of situations. The X12 new guidelines or developed new guidelines, if you will, for all implementation guide offers to follow that further ensures that each TR3 consistently uses the same data representations for the same data purposes across guides. We believe that this will improve the overall understanding of TR3 and will reduce ambiguities that have resulted from the same data being used with multiple codes or qualifiers or from appearing in different segments with the same purpose.
Most of the improvements that were identified as technical improvements were not necessarily changes we got from the DSMO, but were typically changes that were found by the X12 work groups themselves. But we believe these changes will improve the quality of these transactions.
Structure changes are talking about modifications to the physical components of the transactions. That is, we have either added new data elements that were not previously included or have physically been modified to be longer, shorter or different data types, or the data element might no longer be required and was removed.
Similarly, composite elements which are made up of several data elements but are not considered segments, may have also seen some more changes. And in some cases, new segments have been added. Segments are normally a collection of data elements or composite or both elements that are related to the same business subject such as a name segment which would contain first name, last name, middle name, prefixes, et cetera.
Segments, composites, data elements are typically added when new business functions are being supported by a transaction or removed when the business function is no longer needed, or it has been replaced by something else. In some cases, transactions were restructured in the way that information is captured or reported such as the 837 change to report subscriber and patient information. Implementers need to be careful when reviewing these changes to make sure that their applications collect this information and populate the transactions properly.
It is important to note that the changes from the X12 transaction can also occur by other industries using the X12 transactions that might share these same data elements, composites or segments where X12 control structures that are commonly used across industries such as the finance industry, supply chain or transportation industries.
Data content was reviewed and clarified, and the ASC X12 Claims Work Group in particular worked closely with the content committees named under the HIPAA legislation which were also part of the DSMO that was defined by the HIPAA transaction final rule.
To improve the content of the transactions in particular, namely the NUBC or the National Uniform Billing Committee, the National Uniform Claim Committee and the Dell Content Committees were involved in this process with X12. All ASC X12 work groups have worked hard over the past six years to obtain industry input on these transactions from both the named committees and from other industry experts who bring forward information and requests for modification to X12 process directly.
All business cases associated with a request are brought before the ASC X12 whether from the DSMO or from an industry expert are carefully considered by the affected work groups to determine whether there is consensus on the business case and industry need to accept such changes. In some cases, the request can change multiple transactions and then each of the affected transaction work groups is asked to review the requested changes. Once it has been ensured that there is consensus that such changes are appropriate, they are then incorporated into the transaction and voted on by each of the work groups, the healthcare task group and the Insurance Subcommittee. Again, the primary goal of these content reviews was to remove redundant unnecessary information, to address minimum necessary privacy concerns or to add new information required by the industry.
We have reviewed implementation guide notes in an effort to ensure that the instructions are not ambiguous, and that we have consistently defined and used data across all transactions. As each technical report or TR3 was completed and approved following the X12 approval process, the documents were then made available for public review and comment.
All comments are reviewed and resolved by the X12 work groups, and either changes were made or an explanation as to why the change was not provided. After public comments were fully addressed, then we hold an open forum, which is scheduled for a final public and personal review of the changes. At this time, additional changes could be made if the work group accepted the changes on the floor. Once an open forum is complete and the documented changes are made, the TR3 is then sent to the publisher for final printing. Again, when that is done, a work group, task group, an insurance subcommittee reviews and approvals are required as are technical assessment work groups by X12 itself.
If the document is approved, it is then made ready for publication. Excuse me for a moment. My blackberry is making funny sounds. Apparently, it's not mine. I thought it was mine because mine was buzzing every time I heard that sound, but it's not mine now. Okay.
All right, transactions affected. Those transactions previously adopted by HIPAA, the 834 Health Plan Enrollment, the 820 Premium Payments, the 270, 271 Eligibility Inquiry Response, the 278 Healthcare Services for Requested Authorizations, the 837 for In-patient, Professional and Dental Healthcare Claims and Encounters, the 276, 277 for Healthcare Claim Status and Response, and the 835 for the Healthcare Claim Payment and Remittance Advice are all affected by this change.
The new transactions – there are some new transactions that ASC X12 is considering for adoption under HIPAA. And I bring these to your attention only to give you a heads up that we would like to bring these forward sometime in the future as additional transactions for adoption under HIPAA. Several of these – and I guess I should really just go through this a little more carefully. Although these are transactions not currently adopted by HIPAA, some members of ASC X12 do believe that these should be required with Version 5010. Further discussions still need to occur to ensure that we have consensus on these future recommendations.
Each of the above transactions offer significant benefits to the industry. The 278 transaction shown here will allow a provider to inquire a health plan to determine if authorization was received and to permit planned treatment to continue or go forward.
The 278 Notification Transaction is used to notify a health plan about changes in the patient's status or to inform them a patient has been admitted so that they can begin case management. Many in the industry believe that these will save time for both the providers and the health plans and resources as well.
The lack of acknowledgment requirements has also created industry problems. Today, most entities send some kind of acknowledgment, but not always an X12 transaction, and they're not always consistently implemented as documented, and in some cases they're not even electronic.
The TA1 and the TA3 acknowledgment is used primarily to convey system availability errors. So when submitting a transaction, if you cannot get it to your destination, you can get an error report that would tell you what your issue is.
The 999 transaction provides new functionality that will allow trading partners to report implementation guide constrained edits as well as edits against the X12 based standard with their front end editors. Where the 997 today can only be used to report some tactical errors on the base transaction standards, this is an important distinction and a new function provided with Version 5010 X12 transactions.
The 999 acknowledgment will allow transaction receivers to more quickly notify submitters when they have implementation guide errors, thus allowing a submitter the ability to correct and resubmit errant transactions sooner than waiting for further application processing to occur.
The 277 claim acknowledgment also the preferred transaction to acknowledge the validity and acceptability of claims at the preprocessing stage. And the 824 is the application reporting transaction that can inform the submitter about application processing issues for various X12 transactions reporting both successful and errant conditions.
The next couple slides I'm going to go through a more careful review, if you will, of the specific changes, transaction by transaction. I would like to point out that this is not a complete list of all the changes by any means. But it should give you a fairly good understanding of what to expect, and it does highlight the more significant changes that we've made.
I'd also like to point out before I move on that there is in each of the TR3s a change log that's available so that you can see the complete list of everything that has happened in that transaction since the last version. Unfortunately, the last version is 4050, and our last implementation under HIPAA was 4010(a)(1). So the Washington Publishing Company who publishes our standards has also made available a companion document to these that will show all the highlighted changes since 4010(a)(1) to 5010, and that's available from Washington Publishing.
To kind of summarize some of the general changes, let me reiterate some key points here. All the X12 implementation guides or TR3s for healthcare have been developed following common guidelines. One of the objectives for 5010 TR3s was to ensure that the front matter was more standardized. We've also worked to ensure that ambiguity has been eliminated, that the language and rules for establishing situational data are well defined, so the industry can clearly understand when situations exist that would require such data to be used or populated in a transaction.
Additional attention was paid to privacy issues around minimum necessary rule to be sure that we were not requiring personal health information data that was not essential to the business purpose of the transaction. And every TR3 worked to eliminate unnecessary or redundant data qualifiers or codes to ensure more consistent use of information and to eliminate any ambiguities that might arise from similar codes without a distinct difference.
And another key point to consider is that the need for version changes is a fact of life in X12. Just as it was with NSF or UB or any other standards we've used in the past, you have to keep moving forward.
The 834 Health Plan Enrollment Transaction has seen a number of improvements in the semantic notes to eliminate confusion of when to use different values for such things as using date ranges for coverage dates, the two versus through or when to send maintenance effective dates and others.
The front matter clarifies the different types of updates, their purpose and when to use change updates versus full file replacements or full file audits. There has been confusion and inconsistent use of these by different implementers with 4010(a)(1).
The ability to report new control totals for employee, dependent and transaction totals were also added as product controls to this transaction. A number of qualifiers were added to support new maintenance reason codes. For example, when adding or deleting dependents because their student status changed, limiting age of a dependent or other coverage limitations, life partner changes, late enrollment affecting premiums or benefits and non-payment causing termination.
Additionally, the ICD 10 support was added to this transaction to report pre-existing conditions and to report other additional disease classifications. Changes to allow more codes and additional loops to permit reporting not previously accommodated where codes were added to allow for class of contracts, service contract numbers, medical assistance category and program identification numbers.
We've also added the ability to allow designation of confidentiality where access to member information can be restricted, and we've added support for drop off locations for other than home residence to protect patients who are in at-risk situations.
The 820 Premium Payment Transaction was also modified where we have added receivers remittance delivery method to allow the health plan sponsors to indicate what remittance methods will be used, that is, by mail, by file transfer or online or other.
We've added an outer adjustment loop that will permit health plan sponsors to adjust the entire transaction for previous payments without having to tie the adjustment to a specific individual member record. The service, promotion, allowance or change information loop was added to the organizational summary table that will allow a place for health plan sponsors to report additional deductions to payment.
Changes to the member account loop from allowing a number of occurrences from being reported that will now only allow three as there are only three really valid values. We had previously had a greater than attribute here which really didn't make any sense.
Changing the individual premium remittance detail from situational to required was done to eliminate confusion that occurred with the segment note indicating that it was required when related to HIPAA when in fact this is a transaction used for health plan premium payments, and the segment is always required. So the stated HIPAA requirement had created some confusion.
On the 278 eligibility request, the front matter has also been expanded to identify the different relationships of the subscriber versus the dependent and when to use them for the patient. I should point out that the provider community worked very hard with the payer community at X12 to define required alternate search options. When providers are unable to find member eligibility information using all the required elements of a primary search option, the health plan must now support alternate inquiries, and the alternate inquiry that we have come up with is a member ID with last name only and date of birth to help eliminate situations where we're getting false negative returns for members who actually are there but some of the information might be reported differently.
The required alternate search options were a somewhat controversial requirement, and as late as our last June trimester meeting, we were still making modifications to this. And so even though we have published the 270, 271 implementation guide, we will be reissuing that guide with modifications. We expect to reissue that sometime late this year.
The industry has also called for supportive additional 38 patient service type codes for things such as burn care, brand name prescription drugs, coronary care, screening for X-rays and laboratory work, et cetera.
The 271 eligibility response transaction has had significant implementation problems with 4010(a)(1) with a wide range of reporting deficiencies caused by implementer interpretation issues resulting from, for the most part, too much optionality in the transaction. So the way the 271 transaction had been set up, it really left too much opportunity for implementers to decide they were or were not going to report information for whatever reason. We did not provide very clear guidance. So we have done a lot to tighten up the guidelines on what information must be reported.
So some of those things, the requirements were added that when a payer requires subsequent X12 transactions to be sent with patients specifically at a subscriber or dependent level, then the payer must indicate this by reporting the patient information on a 271 response at the level they will be required.
Additionally, when the patient has active benefit coverage, the health plan must report beginning effective eligibility date, plan name, the benefit effective dates if they are different from the overall coverage. Also, all demographic information that is needed by the health plan on subsequent transactions must be reported along with primary care providers, if available, and other payers if known.
New health plan requirements were added to the 271 eligibility response expanding the standard group of information that must be returned. This information is the same information that CAQH Core has adopted as required for use with 4010(a)(1). The new required information will significantly improve the value of this transaction to the provider community and will no longer leave this kind of information as optional.
Basically, nine categories of benefits must be reported if available to a patient. They include medical care, chiropractic, dental care, hospital, emergency services, pharmacy, professional office visits, vision, mental health and urgent care.
A more complete explanation of how up to 99 service types can be requested on a single 270 transaction and how the corresponding 271 can support as many benefit loops as are required to answer the request. This provides for a more efficient response that was possible with the 4010(a)(1), and we've done this by adding a repeating data element which was something of a structure change.
The addition of 38 service type codes are supported on the 271 response transaction in response to 270 requests and would clarify the relationship between the member's coverage status indicator which indicates active or inactive coverage with the number of variations and the covered beneficiary whose benefits are being identified in the transaction response.
The service type code is used to identify the types of service the benefits apply to. For example, medical benefits, surgical benefits, vision care and so on. A value code of 30 is used generically to request health plan benefit coverage and should report all the information described in the previous slide that would apply to an active member for the nine categories of information plus the demographics, NPCP and so on.
When reporting on co-insurance, co-payment, deductibles, out-of-pocket stop loss, cost containment and spin down, it is now explicitly required that the health plan report the patient's responsibility to be reflected either in the monetary amount or percentage amount. This requirement was not explicitly stated in the previous version of 4010(a)(1) and some health plans currently don't report the amounts but only report that there is payment. But they don't give the provider any indication what the payment amount is. These changes, we think, will significantly improve the value of the 271 response to the provider community.
The 278 health care services had significant restructuring done where the patient level service reviews enabled the requester to group information about the patient event such as diagnosis, category of service, and providers of service are hierarchically above the individual services and procedures requested.
In Version 4010, the implementation structure required that the requester repeat the service and procedure detail for all providers involved with the service. Changes to the 278 standard enabled the service level to report institutional, professional and dental service detail consistent with what is reported in the 837 transaction. This new structure is also more consistent with the header detail that is found in the claim.
In the 5010, the event loop is required for the request and notification. But the service loop is only required to identify specific procedures which is much more efficient and less redundant than the 4010(a)(1). Procedures moved from the health care information code segment to the professional, institutional or dental service segments that describe the category of service and support more specific detail and services and procedures requested consistent with the claim transactions.
Dental service detail incorporates additional dental related segments including the tooth segment to provide fuller support for dental services requested. Work arounds necessary for the 4010(a)(1) have been resolved, and the restructure of the 5010 such as ordering provider work around and procedure code modifiers and dental, request for drug authorizations and patient state of residence have all been corrected with this new version.
They also support ambulance transport requests to align with business need to capture multiple address locations for multiple trips.
The 278 health care transaction has also clarified the use of patient condition segment by adding separate implementation segments and rules for ambulance certification information, chiropractic certification, durable medical equipment information, oxygen therapy certification information, functional limitation information and activities permitted information and mental status information.
A number of new functions were added to the 278 health care services, namely the medical services reservation which enables the requester to reserve limited number of occurrences of a service within a defined timeframe, support for ICD 10. The response transaction was modified to eliminate the need to return subordinate loops valued on a request if the request failed at a higher level. It is often impossible to report these subsequent loops when a transaction error has occurred at this point.
Reject reason codes were moved to an external code set which will allow ongoing maintenance without having to change the ASC X12 standard. The reject reason code data element was changed to be a repeating data element to allow multiple reject codes to be reported. This eliminates the situation of resubmitting corrected transactions only to find that there are more errors that weren't previously reported.
The 837 health care claim transaction greatly improves and enhances the instructions and data content for submission of subordination of benefit claims. Specific instructions have been added for claim balancing creating the 837 COB claim when the prior payer's remittance information did not come from the provider in a 835 format, and how a receiver can calculate the prior payer's allowed amount.
Duplicate information amounts that can be calculated have been removed, and the ability to accurately report the order of payer responsibility has been greatly expanded. The crosswalk table provides assistance to providers in creating an electronic COB transaction from a remittance file. Also added a COB crosswalk for paper remittances to 837 COB, and explanations have been provided to create a secondary and tertiary COB claim form on a paper remittance.
These improvements should also help to expedite COB processing. Subscriber and patient information hierarchical change such that the subscriber is not reported if the patient information can be uniquely identified. This change makes the claim structure consistent with the eligibility transaction and eliminates the requirement for information that is not needed. Line item control for providers is added to better support provider assistance, and provider types redefine in conjunction with the NUBC code set ensuring consistent implementations and requirements that are in line with nationally accepted guidelines with NUBC.
The 837 health care claims also added clearly defined rules as to how NPI subparts are to be reported structurally. These rules ensure consistent representation of a provider entity regardless of who the receiver is. Submitters are sent the same organizational NPI to all payers in the same position in order to promote coordination of benefits.
One of the major deficiencies in versions prior to 5010 was the lack of provider definition and structure. Clear and precise rules have been developed to ensure provider information as reported in the same position with the same meaning regardless of who the receiver is. Further changes were made to clarify how and when the NPI is to be reported within the claim. The 5010 guide will support both proprietary identifiers and the NPI during the transition and accommodate atypical providers after NPI is mandated.
The billing providers payers specific proprietary identifiers were moved to the destination and non-destination payer loops. This change enables non-ambiguous reporting of proprietary provider identifiers by implicitly associating the identifier with the payer. For COB, the applicable billing provider identifier can now be clearly delineated for each payer in the claim.
Also multifunctional segments were separated to allow reporting provider types such as referring, rendering and other operating providers instead of just other providers. And the diagnosis codes for principal, admitting and external cause of injury and patient reason for visit were all separated. A separate element was also added to the 837 to report tax numbers.
Some new functions were added to the 837 as well such as ICD 10 support. Additionally, we've added present on admission indicator, ambulance pick up and drop off locations, remaining patient liability, the National Health Plan identifier were all added by industry request. Version 5010 of the 837 transactions have eliminated the ability to report billing service clearinghouses or other non-provider entities as billing provider, eliminating the ability to use a billing provider loop to identify clearinghouses and billing services for other non-provider entity aids in providing a consistent structure that ensures that only providers are identified as such.
We've also deleted functions from the 837 for responsible party, credit and debit cardholder, home health purchase service provider, and referring provider specialty as these are now handled either by other means in the industry or they are no longer needed, or they're duplicated in other transactions.
The 276, 277 health care claim status. Subscriber and dependent loops were changed to ensure the situational looping rules and qualifiers are more consistent between the two levels of reporting. Sensitive patient information was removed from the implementation guide requirements that were not needed for the transaction business purpose.
We also added pharmacy information at the claim level for the 276 transaction that can now be used to identify prescription numbers to be inquired about and the 277 response transaction can report the prescription numbers were paid or not paid at the claim level. This level of reporting was not available on the 4010 transaction.
We also added the NCPDP reject payment codes for reporting pharmacy claim status information. We've added tracking mechanisms. Specific trace numbers can now be recorded for the individual request and response by the provider and the payer. We've added patient control numbers, a claim ID for clearinghouse and other intermediaries and corrected the situational usage of payer claim number.
The 835 claims payment and remittance transaction today we have many industry wide problems with the 835 transaction, but have made automation of the remittance transaction either difficult or impossible, and many of the 5010 transaction changes that were made remedy this problem.
Tighter business rules to eliminate options and eliminating code values that had been marked not advised will result in improved standardization and clarity of the guide making for more consistent implementation and interpretations by the implementers.
New health care medical policy segment was added to the 5010 that reduces inquiries to payers and helps providers in locating related, published or encoded medical policies used in benefit determinations. A new iteration of the contact information segment was added to supply a payer's URL when applicable to reference their medical policies online.
A remittance delivery method segment was added to facilitate communication between payers and providers by indicating the provider delivery preferences when payment is sent separately from the 835. The claims status has also been further defined to give clear guidance to the industry of when to use primary, secondary and tertiary indicators, and the 5010 limits usage of the denial code status to specific business cases.
The 5010 implementation guide provides expanded instructions that better allows providers to negate the original payment without human intervention and post corrections. Definitive guidelines on how to handle reversals and corrections of interest payments and prompt pay discounts have been added to this version. Interest and prompt pay discount amounts are shown separately and are no longer combined with the claim level reversal amounts.
The next couple slides talk about the transactions that are not currently included in HIPAA. And since I have kind of given you a broad overview of those, I'm going to skip over the next couple slides until they come to the acknowledgment slide on page 33 or slide 33.
ASC X12 has discussed at some levels of the organization inclusion of the acknowledgment transactions with the HIPAA required transactions. Although this discussion has not been fully conducted or debated within X12 at this time, we wanted to let NCVHS know that we are considering this and may make such a request at a future time.
We expect to begin a broader discussion on the inclusion of acknowledgments during our next trimester meeting in September, and we will not be bringing forward these changes unless we do have consensus of ASC X12 that we should.
But as you know, acknowledgments were not included in Version 4010 HIPAA transactions, and their absences created significant problems for the industry when implementing HIPAA in the first round. It will be of great benefit to the industry if all the transactions defined by the acknowledgment reference model were to be implemented by trading partners. Acknowledgments are what complete the cycle of the transaction transmission and informs the submitter that the receiver has the transactions and whether or not there were problems with the transactions. There are different levels of transaction acknowledgments, which are explained here and illustrated on the subsequent slide.
And if we go to the next slide, there is the acknowledgment reference model, which is probably hard to read unless you have a fairly large print out. But the diagram basically illustrates the different levels of how these different acknowledgments are used. So there is an interchange level, which is where the TA1 and TA3 are used. There's a conformance level, which is where the 997 or 999 would be used, and the implementation guide level where only the 999 would be used, and an application level where the 824 would be used.
So some closing thoughts. To summarize the key points moving from 4010 to 5010 will take time, and resources from all entities, providers, health plans, clearinghouses and software vendors. Certainly this effort will not be as complicated as we experienced with the first round, but the effort will still require significant time as there is much to be done to identify the changes that will be necessary in each entity's systems to capture and handle the new data, changes in business rules, thoroughly test internal applications, then test to migrate these new transactions with all our various trading partners. We should not underestimate the time that will be required to complete this work. But the benefits of making this change are significant.
And I hope that the information I've shared with you today provides you some sense of the benefits that can be realized. X12 further recommends that entities look carefully at these transactions and the change logs that are available from Washington Publishing. Each of the technical TR3 documents as well as the supplemental document that I described earlier.
ASC X12 would like to make one more important consideration about implementing 5010. There is general agreement that within ASC X12 that implementing Version 5010 should be done independently of ICD 10. We should not try to implement both 5010 and ICD 10 code sets at the same time or even within a few months of each other. Both implementations will require significant time to complete, and we recommend that adequate time is allowed for Version 5010 issues to settle before we start moving to the ICD 10, at least as much as practical.
At this point, I would like to thank the Committee for letting me read to you my presentation, and I'd be more than happy to take any comments, along with my associates here who come up to support me.
MR. REYNOLDS: Well, I'd like to commend everybody that worked on that. That's exactly what we were looking for. I mean, there is no question now what you did and the extent of it and the categories you found. So that's exactly what we needed as we do our deliberations. So with that, I'll start with Jeff and then –
MR. BLAIR: Thank you, Don. Obviously, I didn't get a chance to see it. But since you made that – oh, thank you. I may not have seen it, but you were nice enough to have made the presentation available last week, along with all the others, so I had a chance to read it over the weekend. So very helpful. I appreciate that.
One of the things that you commented on was the process to accept an enhancement in the X12 to any of the X12 standards, and part of that process, you indicated, is that a business case needed to be submitted to justify the enhancement. Can you tell us what those business cases look like.
MR. BECHTEL: Sure. There's two ways this happens, one, if they submit their requests through the DSMO site. The DSMO site requires that the submitter provide a business case or reason for why they're asking for the specific change.
It's not a significant discussion. It's usually a paragraph or two, but sometimes it can get longer depending on how complicated the issue is. But they are required to give us some reason why they feel this change is required. That reason is then taken to the X12 work groups or to HL7 or NCPDP. It's not just X12 at that point, and we review and discuss those requests as documented.
It's not uncommon for us to go back to the submitter and ask for additional information if their business case was not clear. We've even invited them to come and talk to us at X12 meetings to help us better understand their business case.
In other situations where business cases are presented to X12 without using the DSMO process which does occur, people who come to attend the X12 meetings can bring requests to the X12 process and ask to make modifications.
Similarly, a business case or reason has to be provided. Typically, it's written on a data maintenance request form what the business purpose of that change is. Again, it's not usually a very long explanation, clear and succinct. But if it's not understood, it gets questioned, and sometimes if you're into the voting process, they don't get approved and they have to go back and revise the information. Sometimes it doesn't get approved at all. That's how it works.
MR. BLAIR: Does the business case include any quantification of either expenses or benefits?
MS. WEIKER: Some of them do, and some of them don't. It all depends upon what the request is. It's not a requirement that I put in that field how much money this might save, or what's the – how many providers would be impacted or that type of thing. So it's not a requirement. In instances where it's known, it is provided, but it's not a requirement that that be present.
MR. BLAIR: Okay. So it's not there in all cases, but it is there in some.
MR. BECHTEL: I would add to that remark just a little bit. When it comes to the work group, even though it may not have been documented –
MR. BLAIR: I'm sorry, say aloud –
MR. BECHTEL: When it comes to the various work groups that might have to respond to that change, that often enters the discussion, you know, how much benefit is there to this, what will it cost. We don't always have the answers, but it does often come up in the discussions when they're being reviewed.
MR. BLAIR: Okay. So I gather from what you're saying, what I was – I was hoping you'd give me a slightly different answer. So it's turning out to be a partial quantification. So given the fact that it's partial, not complete quantification for all of the benefits, and I understand that's – sometimes it's hard because to quantify.
Do you feel like with the information that you do have that it is possible or that it's really not possible to be able to aggregate the benefits in a quantified manner for the enhancements to 837, for example, and to give an estimated cost for a hospital to go from 4010 to 5010 for the 837 to justify the statement you made, Don, at the end. You wound up saying there's going to be a significant investment of time and resources to make the enhancement. However, you also said that there's significant benefits.
MR. BECHTEL: YES.
MR. BLAIR: Well, is it possible with the data you have – I'm not asking for a whole lot of research and churning the oceans. Is it possible with the data that you have to be able to show ballpark or estimated benefits that would far exceed the cost of upgrading for either a hospital or a group practice or whatever.
MR. BECHTEL: Right. I think the best way to answer this question is within X12 we probably don't always have that information available to us. So we have worked with WEDI in trying to put together these surveys which you're going to hear about later today from Lisa that describes the benefits that we've put in place or the changes we've put in place and what we believe the benefits to be, and we've asked the industry to respond is this really useful, and how much is it going in your opinion cost you to change this.
The cost can be measured in many different ways, unfortunately, and it's very hard to anticipate how some are going to evaluate that. But I think that the best way for us to get a feel for it is through these surveys, and we think the work we're doing really is helping us get a better handle on that.
Again, I will go back to the work groups when they talk about these changes, it is part of their consideration, you know, is the change we're making going to create severe hardship, or is it going to be very complicated, or do we think the systems can even do what we're asking them to do in terms of finding provider information and so on. So they did deliberate on these points. But I don't think we always have real good concrete information about what it's going to cost.
MR. BLAIR: One of the aspects of this whether any significant benefits which may also be difficult to quantify is the synergies that when you wind up doing the 835 and the 837 and the 270 and the 271, and you wind up doing all of these together, you get additional benefits because you're doing them all, and the incremental cost to do them all may not be that much. So it's hard to do.
But obviously the reason that I was asking the question was that if that data is available, maybe it could enable us to move away from the threat of a mandate and more towards a positive business case, a positive incentive.
MR. BECHTEL: Yes, I definitely listened to that part of your discussion earlier today. The more we can find good incentives to moving forward, the better it will be for the industry.
MR. BLAIR: Well, mandates, you know, we're seeing in the last few years that the industry has been failing to adhere to the mandates. It's becoming a weaker and weaker club. And I think that maybe we have to examine some carrots as well as a stick in order to move forward.
MR. REYNOLDS: Okay, Simon and then Judy and then Steve and then me.
DR. COHN: well, Don, first of all, thanks for what I think is some great testimony, and I do particularly want to thank you for providing the speaker notes as one who actually does much better looking at the testimony rather than always listening to it. I think the combination was, I think, very powerful.
I guess I am reminded based on Jeff's comments as you certainly commented that actually HIPAA was initially passed as administrative simplification to save money and therefore I don't think any of us have necessarily thought about it as a mandate quite in the way that Jeff has described, though, of course, if you can't submit a bill, you can't get a payment either. I guess there is that final bit of mandate and cost benefit.
Now I did want to ask a question, and just looking at your testimony and obviously I'm very interested in seeing the updates to the HIPAA regs. I was also finding myself very interested in the new standards that you were bringing forward. I couldn't decide where they were in the process, whether these are actually even pre-adjudication within X12 or they're getting ready to do to the DSMOs, or where they are only in the sense that I think if the industry is making a change, probably you try to at least bundle as many standards together as possible.
And so maybe you could maybe clarify for us exactly where those standards are as well as, I think, your sense of the value of the new transactions as opposed to the changes to the current transactions. I know there must have been a reason why you brought both of them forward at least to inform us about them today.
MR. BECHTEL: I'd be glad to. All of the transactions I described as under consideration are completed. The work is done. The implementation guides are written. They've all been approved within ASC X12. What we have not done is put in a DSMO request to consider adoption of those new standards.
We still need to have, I think, a little more discussion at X12 to make sure that we all really want to do this because any time you have a required transaction, that puts a burden on the industry. So we want to make sure the burden we're asking to put on the industry is appropriate and whether or not we think voluntary adoption is going to work, okay.
So our sense right now is voluntary adoption doesn't do the job, but we haven't had that discussion more fully, and we need to. So I'm not – I shouldn't say I – X12N is not putting these forward until we have that discussion. And I'm hopeful that we can complete the discussion at the next trimester meeting, take a vote on it and make a decision to do it or not.
All of the work groups that created these transactions want to move them forward. So the people from the industry who are involved in creating them feel there's industry value and that they should be adopted under HIPAA because they're concerned that voluntary adoption will not be successful. But we haven't had the broader discussion.
As for the value of all of them, I think they all bring value. We actually had the 278 transactions, the two that we're talking about bringing forward, available in 4010, but we didn't have them quite ready enough for adoption the first time. So they were not included. I wish they had been.
I know my organization uses the notification transaction today with several of our payers. They find it very useful. The providers like it. But, again, it's not widely adopted by the health plans. So there's only a few instances where it's working. That's just my own personal experience with it. But I do know that it brings benefit in the providers, and the health plans that are using it find it helpful.
On the acknowledgment transactions, there's no doubt in my mind this is going to be helpful to the industry. It's just whether or not we can get voluntary adoption or mandate which way to go. I feel very strongly from my own experience in my company that the lack of acknowledgments or the lack of consistently applied acknowledgments has been a real headache, and this would really make a big improvement.
MR. REYNOLDS: Judy.
MS. WARREN: Yes, Don, I also appreciate the notes section. That helped a lot, especially the level of detail that you put in there.
What I'd like for you to do is just give a little bit more discussion about your last recommendation of not to implement ICD 10 along with 5010. So what kinds of discussions went on that led to that recommendation, and just start there.
MR. BECHTEL: Excuse me while I collect my thoughts on that. I won't say that we've had extensive discussions on that either. It was kind of like the new transactions coming forward. We need to have a broader discussion on this.
But when we put this out, when I put this presentation together and circulated it for review, these were the comments that came back from the people that were reviewing it, and I'll tell you the document was reviewed more broadly than just at X12. It was shared with WEDI. We had a small task group of people at WEDI to review these presentations, and this comment came back to me both from WEDI and from members of X12 that they're concerned about trying to implement both at the same time.
I felt from conversations I've had with people in addition to the comments coming back that this was a comment I've heard more than just in passing and thought it was appropriate to put in the presentation. And when I put it in, no one objected. This was reviewed by a large number of people in ASC X12 as well as the WEDI folks. So they've all had a chance when I put it in to say no, that's not the right thing to say, and no one did.
MS. WARREN: Is it the amount of new learning that has to occur to use a new code set with these claims attachments that is causing some concern?
MR. BECHTEL: I don't want to speak for the payers, but I think it's the payers who are most concerned about this, and I may be wrong in that assumption, but that's my understanding that how they do their adjudication today is largely based on ICD 9 codes. And to go to the ICD 10 coding system is going to restructure how they do their adjudications, and they're going to have, just like we did in B10 when we eliminated local codes and all the other code sets that went away that created lots of problems for the health plans to get that work done, I think they have that same concern going forward with ICD 10, that this is going to be a lot of work for them. I know even CMS is concerned about it. I probably shouldn't elaborate on that very much. But I know there's some more concerns there as well. So it's not limited to the commercial plans. I think CMS has this issue.
MS. WARREN: That helps to know that they're worried about just adding new code sets, so it's not so much – I mean, it is a lot about ICD 10, but it's seen in that same kind of light of what you do when you have new code sets or change code sets. So I appreciate that. Thank you.
MS. WEIKER: Right. Plus in addition when you start looking at the analysis of adopting an ICD 10, you have to add because there are a lot of payers that do base adjudication on those codes. You have to start even by looking at your current contracts with your providers, and you literally have to start at the beginning of your process of my network providers who negotiate and raise contract networks all through the entire process. I mean, it touches so many little points within an organization that it's a massive undertaking just to do the analysis piece of it.
And in fact, I've seen some estimates where some people have considered this bigger than Y2K. Now right, wrong or indifferent, and that may just be more of the shock value, so to speak, of it, but some have said this is bigger than Y2K in our systems because it's just so much based on those codes.
MS. WARREN: Well, I guess what prompted me to ask is that there's always change, and it's kind of like if we go and focus on 5010 or I can only focus on ICD 10 and if I can only focus on this. Well, reality doesn't let you choose what you're going to focus on. And so is the concern the overlap of resources required to do the two of them together, or is the concern really about ICD 10 implementation and not so much about 5010.
MR. BECHTEL: No, I think it's -- well, I think there are two different problems that you're trying to solve. You know, implementing the transactions is very system oriented. Implementing the codes is really in the heart of how business is done. These are really significantly different tasks in my mind.
MR. REYNOLDS: Steve?
DR. STEINDEL: Thank you for the segue, Judy, and we didn't set it up. Yes, actually there was a couple of things that caused me, and it's a little bit in regard to this ICD 10/5010 issue which you brought up so well. I thank you like everyone else has with the detail level that you presented to this. Harry actually did request that information, and this is very, very helpful to us, and I believe that we're going to be hearing tomorrow about the business cases for a lot of these details and how they affected people.
In response to Jeff's question, having sat on NUCC and being involved in DSMO process, I do know that these business cases are laboriously looked at, debated. And if there is a change that's in 5010, it was put in after very careful deliberation. I may not necessarily say for good reasons, but after very careful deliberation.
But one thing that did disturb me going through all this detail, and this gets back to my comment earlier about incremental changes. What I heard was a lot of response changes. You know, we change this part of the transaction because we heard from the industry that they need it. You know, there was a lot of that hidden in this. And what I didn't hear was that we made structural type changes in 5010 so we don't have to go to 6010 to meet the future needs of industry.
And I'll preface that by saying I don't feel six years is a valid reason to change standards. I mean, you can use a standard for 20 years if it's a very flexible standard and can accommodate things. So what I'd like to hear in the first question is what did you do in 5010 to make it more flexible. I heard one – actually, just from my point of view, I just heard one change. We moved this to an external code set so we can accommodate future expansion. I didn't hear that very much going through in the rest of it, and I'm concerned.
MR. BECHTEL: I don't know that I can respond to that with any significant detail. You know, whenever we do standards development, and I'm sure you're aware of this from your other activities, we try to look at things in general terms, not just to solve a simple problem, but how can I make a change that I can re-use in different ways. I think that's kind of built in the grain of how standards developers think.
But all we can do, as far as I can tell, is look at the problems we're experiencing and try to determine how we can make the standards solve the problems that we're having better and work on making the necessary improvements to allow the standard to do the job we want it to do.
I think two years from now somebody's going to come forward with a new business requirement that we don't have enough the necessary data for because we never knew we would need to have it, and it's not going to be there, and that will probably require another structure change. This happens all the time.
DR. STEINDEL: Yes, and if I can respond, I mean if you put mechanisms where you could make those types of changes in the future in a much more surgical fashion, you know, that is what would be good. You know, I know there's some movement within HL7 to create that type of surgical manipulation within the standards.
MR. BECHTEL: I have another point that Margaret wants to make.
MS. WEIKER: Well, as an example in the 837 today, there are those two segments which can be used for “future type of use.” The NTE and the FRN segments where basically if there's a business need, and I think the situation is more specifically around a government mandate type of thing versus a general business need, that you could put this data in this area and let X12, go to X12 so the whole industry knows this is how we're going to meet this business need because right now there's no other way to do it. So there is some of that in there, but it's not anything where you could so dynamically define it as you go type of thing. They're just not created and written that way.
MR. BECHTEL: I guess the other point I wanted to make is typically when we're adding new data fields or new segments to these transactions, it's normally added to the end of the transaction so that we're not changing the way the prior transaction operates as much as adding a new function to the end of it.
So extending the length of a segment or extending the length of a transaction is not really the kind of problem that you have if you start embedding changes in the middle. So from a design perspective, we do try to implement those changes in this fashion, which does make for some amount of backward compatibility as you move forward.
DR. STEINDEL: Yes, I think those were some types of magical words that I was looking for, backwards compatibility, et cetera. The NET segment, the work arounds like that in HL7 disease segment, yes, we could probably introduce every change that you've made in 5010 in 4010(a) by putting out a whole set of specifications on using the NTE, and nobody would like it. I can assure you. I wouldn't like it. So that's not really a valid work around. I think we all realize that.
Just to comment before I get into the 5010. I was curious about your work on acknowledgments because we're now finding that that's a big problem, and it has to be addressed in HL7 as well. It's been a very bad weakness in the implementation of EDI in this industry is that people have not paid much attention to the acknowledgment process, and I really applaud you for starting to look at it.
MR. BECHTEL: Thank you.
DR. STEINDEL: Now with regard to 5010 and ICD 10, and I'm going to try to forstall Marjorie from reacting in any way in this area. But if we look at realistically speaking, if we look at any type of time span, and we really did what you said, and we did not start to implement ICD 10 until significant time passed after 5010 was implemented, we probably would not be looking at introducing ICD 10 until around 2012.
I think there are a tremendous number of people in this country who, if you really ask them which one of the two things we should implement first, they will say ICD 10, and I don't think we can wait until 2012. So I have a feeling that if you really want to garner support for the introduction of 5010, you're going to have to figure out how to either do the implementation processes together or do 5010 a lot faster.
MR. BECHTEL: I concur with your comment that it could take that long. I also know that I've been working in the past year several house bills trying to get adoption of 5010 and ICD 10 through, and we were looking at trying to find ways to get ICD 10 done quickly but still have the 5010 work done first. And yet I guess what kind of comes out is I see there's a practical way to get ICD 10 up and running by 2011, but I don't think it can be any sooner than that, given my proposal that I think you have to do 5010 first. And I still stand behind that. I really think you have to do 5010 first. 3010 just won't do it. So we can't do ICD 10 without the upgrade.
So the only other option you have is to do them together, and I just think it introduces too much change to the industry to try to do those both at the same time. That's my personal opinion, but I think others would agree with me.
MR. REYNOLDS: Do you have a comment on this?
MS. GREENBERG: I don't think I saw any dates here, at least not at the end. And so is that – what kind of timeline are you recommending?
MR. BECHTEL: I'm not recommending the timeline. I'm trying to in this presentation recommend there are steps, and I think the industry has to figure out what – how much time each of those steps needs. And I would suggest that this is something WEDI might want to do. I also know that AFEC(?) is interested in doing that, and you're probably going to hear about that tomorrow, hence AFEC(?).
But looking at the work that I've done and trying to put some timelines together for some of the legislation that's gone forward, we were looking at having, if I remember this correctly, we would have 5010 implemented by October 2010 roughly, and then a year later have ICD 10 done by 2011. And I think those are still somewhat reasonable timelines, but we really do need to sit down and get the industry to start looking at this now to figure out how much time do I need for the analysis phase, how much time do I need to get coding done, how much time do I need as vendors to roll this out to the communities so that they can start doing their testing.
So I think if we could start putting this timeline together of all the steps that all the entities need to go through, we'd have a better view of it. But that's kind of where I am.
MR. REYNOLDS: Simon, do you have a comment on this?
DR. COHN: Yes, I have just a question. It was just a question, and obviously thank you for these issues. I'm sort of reminded, I guess, that those of us who have been on the committee for a while remember the many hearings we went through discussing the implementation of ICD 10. And I think if people in the room or otherwise had known that we were getting into these conversations, we might have had maybe a supporting hearing.
On a more simplistic question – and none of these questions are simple, but I knew that we tend to create actual dates that, for example, 5010 should be in by X, and then something else may follow. Given the vagaries of the federal regulatory process, are we as well off or better off talking about times after an NPRM or after promulgation of a final rule, and does that make more sense in terms of all of this? I mean, do you have any – I mean, you've been living with HIPAA for the last ten years, as have many of us.
MR. BECHTEL: If I understand your question correctly, I think we ought to start looking at the timeline now before the final rule or even before a proposed rule. There's no reason we shouldn't start to figure this out as an industry. We need to get the industry stakeholders to sit down and try to figure this out as soon as we can.
I would hope that we would have that figured out before a final rule is issued so that it could be incorporated in the final rule if HHS agreed with what the industry proposes. There has been some question as to legally what we can do, and this has come up rather recently. But if we – if the proposed rule comes out and we didn't specify any target dates for this work of scheduling milestones, and then in the final rule we issue that, would that require more public comment to that. So it almost seems like it has to get into the proposed rule for it to really work, and I'm sure we don't want to delay the proposed rule. But maybe that's an incentive to get the industry people together sooner to get this figured out.
The other concern that I know has come up is part of the timeline discussions that I've had with people and in fact this Committee and I spoke to for AFEC(?) is we would like to see maybe various stakeholders have a certain status of readiness as well as milestones.
So, you know, vendors have to have their stuff ready by a certain time, and the health plans have to have their systems ready to start receiving transactions from some set of providers so that there's the transition to get implemented.
But where there's a question as we looked at the HIPAA rule or the HIPAA law – not the rule, but the law says that we can't require health plans to be ready any sooner than the completion date which immediately says how am I going to make this milestone thing work. So I don't know how that's going to play out, but it is something that has come up, and it is a concern.
MR. REYNOLDS: Okay, I've got a couple questions. Size wise, would you put 5010 somewhere between NPI and the original transaction implementation, or where would you put it size wise?
MR. BECHTEL: Size wise?
MR. REYNOLDS: Amount of work.
MR. BECHTEL: Amount of work?
MS. WEIKER: In dollars? FTEs? Because I think it depends on what entity you are. If you're a provider, it's going to be a different amount of time and money than if you're a health plan or a clearinghouse or something, and I know just looking at the WEDI survey results, I mean you see where a payer says, oh, it's going to cost me over a million dollars. But the vendors will maybe say $500,000, and a provider will go I'm really unsure because I'm relying on my vendor, but yet I'll give you kind of an estimate.
MR. REYNOLDS: I know, but you guys have been in this space long enough to – I mean, just going through Don's list, I mean roughly, it's either smaller than, I mean, just look at the amount of work. It's either smaller than NPI, not the same. Just roughly, where does it fit?
MR. BECHTEL: I think from my own organization's point of view, and I'm not speaking for Siemens on this point, but I think it's bigger than NPI. How much bigger, I'm not sure. But it's going to take significant resources. It touches a lot of different systems, and so, yes, it's under there.
MR. REYNOLDS: No, again, just as we're – go ahead.
MS. MILLER: I want to just comment on this one. At my role at WEDI, one of the things we discussed while doing the survey were that the committee members of the task group, and one of the vendors commented that it actually took them longer to implement the business rules for the 5010 healthcare claim than it did when they originally did the business rules for the 4010.
And the reasoning behind that was that we've gotten more specific, and we've taken out the ambiguity. So now they definitely have a little bit more work to do. It's also going from one version to another where they're making some changes, some structural changes whether or not you have that pay to billing loop in there any more. So there are changes that could make this, depending on your implementation and your original implementation of HIPAA, you know, did you do it the right way, did you do just enough to get by, did you wrap, what did you do that may make it actually larger, especially if you're planning for 5010.
So if you did a wrapper, you were doing just mapping, and now you're looking at a complete rewrite of those rules. And what Margaret talked about for adjudication, that's no longer throwing a wrapper around things. That's really looking at business process. Whenever you impact business process, it is a significant impact to the organization and everyone they do business with.
MR. REYNOLDS: Right. I mean, obviously having looked at – listening to your presentation, just not to underestimate the size of this, it is complex.
Second, you mentioned that there was some improvements or changes to NPI. Now obviously NPI is near and dear to our hearts as this Committee. When you said that, that perked my interest immensely. So could you give me a little more words on that.
MR. BECHTEL: Sure, or least I'll try to. Well, the way NPI is described in the 4010 implementation guides, we know there are some issues in that. And so I think we've tried to document those work arounds, if you will, through work that we've done at WEDI and other organizations.
But the 5010 guides have really looked at the NPI issue much more carefully, now that we understand all the requirements that we didn't totally understand at the beginning. And so we do provide better instruction on where to put NPI information, when to put it, where to put the proprietary numbers that may still need to be used especially for atypical providers. So there is better guidelines and guidance on how to do this. Also, it will carry the coordination of benefit functions better. So all of this was in my speaking points. But to get more detailed than that, I'm probably –
MR. REYNOLDS: No, no, that's fine. Again, you know, to be in the middle of the implementation and –
MR. BECHTEL: I know someone in the room who is very informed on this topic if you would like to get more information.
MR. REYNOLDS: Okay, and the last question I have, you obviously, as we mentioned earlier, we have streamlining that we kind of keep an eye on, too, and up and working. You mentioned public comment, and, as we deal with this whole SDO process and everything related to it in streamlining, when you say public comment, is that the public that knows X12, or is that kind of an open forum?
MR. BECHTEL: Is it the public, not just X12. However, I'm sure that people that participated in it are mostly the people familiar with X12. But it is open to anyone. And you know, we do have people that are not X12 members participate in the commenting. It would be great if we could get broader participation in those commenting periods. We would certainly welcome that, and in fact in our streamlining testimony, we talk about getting federal notices to enhance that opportunity. So, yes, it is open to anyone. But I would say it's probably a select few that are really aware of it. We do make very public notices. We put it out on news releases. I'm not sure who all we circulate this to. But it does get circulated to a very wide audience of organizations to publish the fact that we're having public comments. It's not just off our X12 listserv.
MR. REYNOLDS: I'd like to thank all of you, a really, really good panel, excellent from the standpoint of really giving us a picture of what this is now. So with that, speaking of surveys, Lisa, let's move right into yours. Thank you.
Agenda Item: Overview of WEDI Survey Results
MS. MILLER: Absolutely. Hopefully, as we go through my presentation, I'll answer some of the questions that you were asking earlier.
Chairpersons and members of the subcommittee, I am Lisa Miller. I'm Healthcare CTO and Senior Vice President of Standards Subject Matter Experts for Payformance Corporation.
Payformance Corporation offers remittance/EFT solutions for payer's provider population. I currently serve on the WEDI Board of Directors as the X12 Representative. I am the X12 Liaison to WEDI. I serve as the Chair of the WEDI ROI Task Group. My responsibilities for Payformance include the implementation of the HIPAA regulations and identification of business process improvements for our payer and provider community.
So I'm actually going to go to highlight. I'm not planning to read this entire document, and I will let you know that behind this entire document is about 900 pages of data that I did not choose to print and bring with us today. So we will certainly give you the foundational documentation that goes with this.
But across the surveys that we have completed, I think I totaled up just under a thousand pages of data that we have collected. So with that said, at the request of the designated standards maintenance organizations, WEDI is currently conducting our cost benefit surveys concerning the migration from the current Health Insurance Portability and Accountability Act mandated version of the X12 standards 4010(a)(1) to the proposed next Version 5010 and the NCPDP Subrogation 3.0 and Telecommunications Standards D.0.
One of the primary objectives of our group is to create surveys to pool the industry, identify potential benefits to the industry prior to the implementation of a new process, transaction or regulation.
The information today that I will share will focus on the surveys. It is not within the scope of this body of work to make any leaps or assumptions outside of the survey information.
The surveys I will be reporting on today were conducted from May 8th through July 16th of 2007. So forgive me for not getting this to you sooner. That might have been the reason that we closed things on July 16th.
The survey, Survey Number One was the 276/277 Healthcare Claim Status Request and Response. Survey Number Two, the 837 Health Care Claim. Survey Number Three, Health Care Payment, and the fourth survey were the NCPDP Surveys mentioned earlier.
Special note of thanks to NCPDP. They were a great help in collecting that information and then putting the survey analysis together.
Participation in the surveys was entirely voluntary and was solicited through email invitations on various media listservs as well as other organizations such as X12. We reached out to AMA, AHA. We also utilized through the publisher the actual list of people that downloaded guides. So we really did try to reach out as widely as possible to get an increased response rate.
The respondents are not a random sample, and it may not accurately represent the views of the industry as a whole. They were, however, interested enough to provide responses to the survey. As such, they probably represent a knowledgeable group of industry participants. The results should still be considered preliminary as knowledge of these new X12 transactions are not widespread. WEDI previously had provided similar testimony to you in December 2005 with the 835 4010 to 4050 Cost Benefit Analysis. The current survey followed the same form and structure as the initial CBA document. The survey documents are considered in final draft. We have held them open until after this testimony so that if there are any changes that need to be made, we can certainly do that. We also have a couple other recommendations around the surveys for you as well.
The task groups chose to keep these open and incorporate any feedback that you might have. These documents are going to become final over the next few weeks.
The structure of the survey documents follows the following format. First we have the payer interpretation and findings, then the provider interpretation and findings, and then the vendor interpretation and findings. We then give you a survey summary, and that's really what I'm presenting to you today, which are the summaries within that material.
We actually then attached the actual data of the survey, and, again, in the payer, provider and vendor. Then our appendix is actually the X12 Analysis Reports, the BARs. So we worked very closely with X12. They gave us what they felt were the benefits to the changes, and we brought those forward to the industries. So these were not done in a vacuum; we worked very closely with the X12 work groups. We invited them at each survey to come in and work with us. So to the one question that we had earlier, if X12 wasn't able to do that, we actually act as an extension and arm to help get some of that quantitative information for them.
I will present the findings and then the potential benefits of each of the surveys focusing on, again, the payer, provider and vendor respectively. We did not, of course, print these, and I explained why earlier. So I figured we would start with the biggest, baddest, meanest transaction of them all which would be the 837.
For this particular survey, we had a total of 168 respondents. I'll start with our payer finding. As we went through 90 percent of both institutional payers said they take institutional professional 837s. Dental was, of course, much smaller.
There was a representation from all sectors. Of note in this particular survey and our list of payers, we excluded Medicaid. We did remedy that on the next survey that we did. The majority of payers utilize in-house staff for their 837 implementation. We did ask about COB. There was a split in the payers responding with the ability to auto adjudicate COB claims. The majority of COB claims appeared not to be electronic. It seems that most of them are still paper.
Average cost for implementing the 837 from the payer was from no cost to greater than a million dollars. When asked about the FTE count, most of the organizations said they have not done an in-depth analysis of the 5010. So we really did not get a great response there.
When asked if they saw a benefit, the majority of payers did see some benefit in the migration. One open comment, and there were not many open comments in this particular survey, stated that they felt there was a lack of representation on X12 communities, and they were insufficient to adequately represent the broad base of users.
Of benefit opportunities, when polled, the majority of payers felt that there was indeed a benefit. 5010 provides additional rules and requirements that may benefit the industry, specifically for coordination of benefits.
We'll move on to the provider. Most provider organizations are able to conduct the 837 transactions in order of percentage used, professional, institutional and dental. Only 33 percent of those providers reported that they would be able to utilize concurrent versions of the X12 standard.
Coordination of benefit claims volume range from 10 to 50 percent of total claims volume. Forty-two point six percent of providers could not submit COB claims utilizing data received in the 835 Healthcare Remittance Advice.
Cost of upgrading software, no cost to greater than a million dollars. Open comments, they didn't have a chance to look at the 5010 and how it impacts them as a provider, and one person felt WEDI had ignored the most glaring problem with EDI implementation, and that is the complete inconsistency in EDI envelopes and EDI addressing and transmission protocols. I would equate that directly to acknowledgments.
So of benefit opportunities when polled, the majority of providers said that they were unsure if there were benefits to migrate to the 5010 837. This, we felt, may be due to the lack of exposure to that documentation. When asked about the proposed changes, however, the majority of providers agreed with the modification with the exception of technical improvement. Again, we felt that since we really weren't seeing enough comments back to tell us that they had really looked at the 5010 documentation that this was due to a lack of exposure.
Again, the 5010 837 provides additional rules and requirements that may benefit.
The vendor survey, 96 percent of the vendor's software said that they can do the 837. Average cost for creating a new version of the 837 range from unsure to $500,000. The majority of the vendors were not able to answer the investment their company would make to address the migration. Two vendors did list a significant investment of $1 million to $5 million.
Interestingly enough, 51.6 percent of the vendors will not charge for the upgrade from 4010 to 5010. Vendors listed customer demand as the number one reason to add this to their product, secondary to regulatory mandate. Sixty-two point nine percent of the vendors stated that there would be some benefit to migrate from 4010 to 5010.
Open comments, in all honesty, we were hoping the gray areas that exist today in the 4010 versions would be eliminated or the door would be closed a little more. Unfortunately, the 5010 does neither. Other comments, it's too late to fix the NPI fiasco. Kill companion guides and provide validation suites that yield only two answers – complies and does not comply.
One other comment, surveys done this early should not include requests for cost/implementation estimates as a surveyor will not have the detail needed to answer the questions. Forty-one percent, when polled, saw some level of benefit of migration from 4010 to 5010. The benefit for vendors is minimal without customer demand, whether driven by the industry or federal mandate.
I'm going to skip over some of this just in the interest of a little bit of time. We'll move to the 835, bottom of page seven. The 835 was probably our most disappointing. We only had 34 respondents, and that's in total.
In the payer findings, 100 percent of our payers state they are able to exchange the 835. This survey did do one thing slightly differently than all the others. We expanded the transaction list to ask questions about acknowledgments. So for this survey and this survey only, and those moving forward, you'll have this information. When asked payers about the acknowledgment transaction, 100 percent stated that they were able to use the 997, which is the functional acknowledgment, while only 50 percent were able to utilize the TA1 which is your transmission acknowledgment.
There was representation from all sectors, the majority being Medicaid. We corrected this survey and added Medicaid to the list of payers. When asked about benefit, the payers were split. A third, a third, a third between not sure, slight benefit, and no benefit. The majority of the respondents agreed with the modification described by the survey with the exception of new wording of situational rules. Fifty percent of the payers disagreed.
A hundred percent of these payers still utilize paper to communicate remittance advice. When polled, the majority of payer respondents did not agree there was a benefit to moving to Version 5010. The task group feels strongly that there are not enough responders to make this as a final conclusion. We did not feel a total of 34 – and that's across payer, provider and lender was enough for us to say that definitively yet.
Findings for the provider, 43.8 percent of the providers stated that they were able to utilize concurrent versions of the X12 standard. Coordination of benefit claims volume range from less than 10 to 25 percent of total claims volume.
Most providers were able to auto post 50 percent or more of claims payments from the 835. Sixty-two point five percent of providers could not submit COB claims utilizing data received in the 835. The cost of upgrading the software can be significant ranging from no cost to greater than a million dollars for a provider organization. There were no open comments.
When polled, the majority of providers stated they were unsure if there were benefits to migrate to the 5010 837. From the responses of the survey, providers appeared to be paper based for coordination of benefit. The 5010 does provide additional rules and requirements that may benefit the industry specifically to increase the use of the 835 for electronic coordination of benefits claims.
Moving on to the vendor for the 835, again a very small amount of vendors responded. We did have representation from all sectors. When asked about acknowledgments, 75 percent were capable of the 997, while only 58 percent utilized the TA1.
When asked, 80 percent of the vendor's customers had implemented an automated AR posting utilizing the 835. Interestingly enough, when asked what the driver would be for implementation of the 5010 835, 100 percent of the vendors listed federal/state regulatory mandate followed by customer demand.
Seventy-five percent stated they would not charge for the upgrade from 4010 to 5010. The majority of vendors were not able, again, to answer to the investment of their company. Two vendors did list a significant investment of more than $5 million.
Overwhelmingly, the vendors agreed with most changes proposed in Version 5010 835. One open comment, one of the best things would be to provide examples of each 837 and resulting 835 combination. We still have not run across every possible 837/835 combination and have no real way to ensure our software will do “the right thing.”
Benefit opportunities, 58.4 percent when polled saw some level of benefit of migration from 4010 to 5010. The benefit per vendor is minimal without customer demand, whether driven by industry or by federal mandate.
The vendors agreed with suggested modification. It appeared that these respondents may have been more exposed to the information.
We'll move on to one other comment. Due to lack of responses and the short timeframe of this particular survey, this survey was out for one week. It may be beneficial to open the survey to the public for a longer period of time.
276/277 survey, we had a total of 130 respondents to the survey. The overwhelming – we're going to start with payer, pardon me. The overwhelmingly majority of the payers responded are capable of the 276/277 today. They said their unidentified cost that will raise the implementation for the payer community, companion guide creation, provider communication.
The majority of the respondents agreed with the modifications described by the survey. We felt that there may be room for potential benefit for the health plan. The 5010 276/277 provides clear instructions providing consistency that may lead to further utilization of the 276/277 by the trading partners.
Of note, they really did feel that there were very few issues in implementing the transaction from a data content perspective, and it was also noted that the adoption of content for some payers may be an alternative delivery mechanism such as DDE rather than the actual EDI transactions.
Provider findings, most of the provider organizations conducting the 276/277 were larger. The 276/277 is not as widely adopted as the 837 transaction. Only 36 percent of the respondents stated that they were transacting these particular transactions.
Average development cost, between one to six person months, and the cost of upgrading software ranged from no cost to $500,000. Only 26 percent of the members found it benefit with 50 percent not sure. This may have more to do with the exposure to the 4010 276/277 and the 5010 enhancements.
There was recognized benefit for the improvements including Front Matter sections and enhanced business functionality.
Our vendor community reports that their software is capable of receiving and sending the 276/277 today. Sixty-six percent of the vendor software is capable of the transaction where they're saying only 44 percent of their trading partners are actually doing it. The investment for this transaction appears to be low, the majority stating that they were unsure at the time of the survey the cost associated with the migration from 4010 to 5010. The vendors listed customer demand as the number one reason to add this to their product second to regulatory mandate.
The concept of claim status codes were not addressed in this survey. A respondent stated that this is the most significant barrier to utilizing the transaction. Sixty-two point nine percent of the vendors stated there would be some form of benefit to migrating from 4010 to 5010. The benefit for vendors is minimal without customer demand, whether driven by the industry or federal mandate.
The 5010 provides clear instructions providing consistency that will potentially lead to further utilization of the 276/277 by the trading partners.
We'll move on to NCPDP Subrogation survey summary. This was not done by just payer, provider and vendor. This was just one survey. There were 18 respondents to the survey, predominantly the payer community.
A small number of health plans responded overall. Medicaid, the primary user of the transaction, comprised 50 percent of the respondents. Fifty-four percent of the providers responding are using NCPDP standard for Medicaid Subrogation claims. Approximately a third of the payers are using a proprietary transaction for subrogation claims. Of the payers using NCPDP subrogation implementation guide, a majority, three-quarters, are able to maintain concurrent versions.
Approximately a third of the payers anticipate implementing the NCPDP subrogation implementation guide with more than 85 percent of their trading partners. The overwhelming majority responded estimated the cost of implementing at $20,000 or less. The majority of payers estimated an implementation timeframe of less than one year.
Benefits, ability to move to high volume transaction from paper to electronic; use of a single format for claims processing and Medicaid subrogation; use of a standard format for Medicaid subrogation; enhanced subrogation processing; enhanced coordination of benefits processing; faster payment and avoidance of federal penalties.
Moving forward to the NCPDP Telecommunication Standard Version D.0 and Batch Standard Version 1.2, this follows our standard of payer and provider and vendor. We'll start with payer.
The overwhelming majority of the payers responded are utilizing the Version 5.1 today. More than half, 57.5 percent of the payers, estimate the implementation timeframe to be less than 365 days. The planned investment costs range from $25,000 to more than $5 million.
The major factor in the decision to upgrade is federal/state regulatory mandate. Benefits, supports the Medicaid Subrogation Implementation Guide 3.0, better guidance for coordination of benefits, better support for Medicare Part D, enhancements for pricing field usage, enhancements for prior authorization, enhancements for long care processing and response messaging, reduction in staff time, and requirements for use of the Compound Segment.
Moving on to provider, 100 percent of the provider organizations are currently submitting Version 5.1. The majority, 82.4 percent of the providers, estimated the implementation timeframe to be less than 365 days. The planned investment cost for implementation of the new standards range from less than $25,000 to $1 million to $5 million.
A major factor in the decision to upgrade is for coordination of benefit. Benefit opportunities included better support for the Medicare Part D needs, enhancement for pricing fields usage, and enhancements for prior authorization.
The vendor findings, a majority of vendors currently receive, transmit and/or process Version 5.1. A majority, 79.3 percent of the vendors, estimated the implementation timeframe to be less than 365 days, and the cost, $25,000 to more than $5 million.
A major factor in the decision to upgrade is federal/state regulatory mandates. Benefit opportunities, better support for Medicare Part D needs, enhancements for pricing field usage, enhancements for prior authorization, requirement for the use of the Compound Segment and defined situations.
In conclusion, the surveys have a very low response rate compared to the number of representative organizations within the nation. This leads to a concern of whether or not the surveys represent the industry perspective. The task group moved forward the work effort even with the low response rate since there was a healthy cross section represented within the respondents.
There is a concern organizations responding to the survey did not have access to the X12 5010 documentation as they did with the 4010 implementation. The task group reached out to the X12 publisher, Washington Publishing Company, for additional information concerning the number of downloads during the survey period, basically over the last 90 days. The publisher was kind enough to provide the following information: 50 837s were downloaded; 25 835s and 15 276/277s. This may be due to cost, lack of awareness, or lack of immediate federal mandate. It is noted, however, that the cost of the documentation is consistent with other related standards documentation costs.
Since these surveys were completed on a volunteer basis, increased participation will not occur without increasing communication to the industry at large concerning the possibility of migration to a new version of the HIPAA transaction standard.
Increasing the response to the surveys will provide the data to allow a more thorough assessment of the industry's concerns, needs and provide a truer benefit analysis document indicative of the nation's healthcare stakeholder organizations.
It is highly recommended that the survey for the 835 be reopened and extended to increase response to a similar level and consistent with the other surveys. This can be accomplished while surveys are pursued on the remaining transaction.
The results of these surveys are a key step on the path for appropriate legislation regarding the HIPAA mandates. I'd like to thank you for the opportunity to provide the testimony on behalf of WEDI.
MR. REYNOLDS: Lisa, thank you. Very well done. Very comprehensive. Questions, comments. Karen?
MS. TRUDEL: One comment and two questions, actually. I'm thinking about the seeming dichotomy between the responses on the NCPDP transactions and the X12. It sounds from the NCPDP that although the respondents were fairly low in numbers, there was a consensus across the board that there was some benefit in adopting the transactions. Whereas, from the X12 perspective, that didn't seem to be the case. And in fact, none of the respondents appeared to think that there was any benefit at all to any of the technical changes which leads me to wonder whether there is a disconnect between the people who are participating in the process and the business owners at their own organizations.
The two questions were, do you have any information about whether NCPDP vendors will be charging for the upgrades.
MS. WEIKER: I don't believe that that was a question in the NCPDP. We didn't ask that question.
MS. MILLER: We allowed them to come forth with it. That was a specific question that we asked of the X12 transactions.
MS. TRUDEL: Okay, okay, thank you. And from the perspective of X12, it seems that a fairly significant percentage of them can't carry concurrent versions, and what does this say to the complexity of the implementation process?
MS. MILLER: We asked that question specifically to find out what kind of burden might be out there. It really felt like with the providers they were able to do concurrent versions, whereas our provider community is certainly not prepared to do that. And I would have to look at the vendors.
If you look, though, at the vendors' responses, they typically said they could do concurrent. So there is an extrapolation there. Perhaps your providers don't know they're capable of doing that. A lot of times your practice management systems are more of a black box to them, and they learn how to use what is useful to them.
So the data is what it is. It's a little bit different across those areas. But looking at it just from an analytical point of view, the group discussed a little around is it possible our providers just aren't that educated about what they're using.
Karen, of one note. There was a real concern in the group when we started seeing some of the results around the technical side of things. And reading through and looking at the documents which we've offered to you, I'll be interested in seeing what your thoughts are when you see the raw data concerning that agreement or disagreement. But with the results from the publisher, I think it's more access to the information, and they just couldn't answer. You know, if you ask about technical changes and you don't know what they are, you'll probably say no.
MR. REYNOLDS: Steve.
DR. STEINDEL: I actually observed a lot of what Karen made and had many of the same observations and the same comments. But what really concerned me throughout your whole talk was the low response rate. I mean, I think all of us get bombarded with surveys, and I know I tend to answer the surveys that I care about.
And so when I see something with a low response rate today, I start to think maybe the response rate is low because they don't care, and that's like saying maybe we don't need this.
MS. MILLER: That I couldn't answer.
DR. STEINDEL: I know, you can't answer that question. I mean, it's always very difficult in the world of surveys to extrapolate what a low response rate means. And so I'm very concerned about drawing any inferences from the survey. And then when you add that to what Karen observed which a lot of the inferences that we did observe, especially from the X12 community, I would fall into the same category as maybe not today. I don't think this is what I want to move on.
MS. MILLER: Not to put a nail in the coffin here, but I do need to share with you that for the 837 and 835, this was our second attempt to raise the respondents, and we did get slightly higher. The first round we had approximately 80 respondents. We did significantly better on the second round.
DR. STEINDEL: And to comment on that, just from this group, we know the 837 is widely implemented. It's widely used. We also know from what we've heard in this group to really derive any full benefit that was anticipated from the HIPAA process, we have to implement the other transactions, and there doesn't seem to be a groundswell in this survey that 5010 is going to be the path to implement those more widely.
MS. MILLER: One concern we did have is that this was for many of the people that we went out to perhaps the first time that they had heard move from 4010 to 5010. So whether they care about it, is it mandated, do they feel it's really coming down the pike, if you're within this circle, I think you know. But I'm not sure if you're at the general public if you walk into your physician's office and ask that question that they would have any idea what this means.
MR. REYNOLDS: Jeff?
MR. BLAIR: Clearly, the folks that came to X12 and NCPDP to ask for these additional enhancements felt as if they were justified. And when they went through the process of the business case, I'm sorry – when they went through the process of trying to justify it by the business case, they were successful. So those individuals that are part of X12 and NCPDP understand the benefits maybe better than the people who took the survey.
Maybe that's the best source to go back to, to say we need to quantify the benefits because they may be the only source that can. Is that something that is a reasonable thing to ask, or is that something that – what is your thought? Is that a useful idea or not?
MS. MILLER: As my compatriots over here are chuckling at me, I'm going to pass this one to Don because it looks like he might be the best person to answer that question.
MR. REYNOLDS: We can't hear your comment.
MS. WEIKER: She's passing the buck to Don.
MR. REYNOLDS: Okay, now we hear it. Now we hear it.
MR. BECHTEL: Quantifying it at X12, is that the question? Would it be worth doing that?
MR. BLAIR: The individuals that came to X12 and NCPDP have wound up saying these enhancements are justified. Maybe they would be the best individuals to quantify the benefit.
MR. BECHTEL: I agree in part. I'm not sure how we're going to go about quantifying it. I think it's going to be very difficult, as I said before. But I do agree that we need to do some education.
MR. BLAIR: A little louder, please.
MR. BECHTEL: I agree that we do need to do a lot of education, I should probably say it that way. It was clear to me when I read these survey results that we have not done a very good job of communicating to the industry what changes are being made and why it's a benefit to them. And you know, just from the fact that so few people have downloaded these implementation guides, I don't even know how they're responding to the survey. You had more respondents than you had guides out there, so how can that happen. So they're responding in the dark or from hearsay or I don't know what.
But I think we have to do a lot of education, and I really think that's got to be one of our primary goals both at X12 and outreach into organizations like WEDI and AFEHCT and HIMSS or wherever we can go to try to communicate what it is we're doing and why it's of importance and get more feedback, more educated feedback.
MR. BLAIR: well, let me express something that I feel sad, I'm very sad to express is I worry that the folks that are saying that it's going to cost a million or $5 million to make the enhancement, what if those are the folks that understand the cost of enhancing it best. And, the corollary is that for those folks that ask for the enhancements, if they couldn't quantify the benefits, does that mean that the benefits are marginal.
I hope that that's not the right conclusion. I hope it's not the right conclusion. But those are the questions that I'm left with.
MR. BECHTEL: I think in terms of quantifying, I'm sure the organizations that brought forward the request could quantify from their own organizational perspective what the benefits would be or quantify what they think the improvements would be.
MR. BLAIR: I hope so.
MR. BECHTEL: And the cost benefits to that. But I'm not sure they could speak for the industry.
MR. BLAIR: They may not have to. You know, maybe if they could just indicate that various scenarios that for a small hospital or for a large hospital or for this group practice, it's our estimate here. Just enough that if they go through the exercise of doing that. Sometimes going through the exercise of doing that yields benefits and savings that are more significant than you thought of just superficially.
And the other piece is that sometimes if you wind up going through that process and then you think of the synergies between having multiple standards upgraded at the same time, you find other benefits in addition to the one that you might be focusing on.
So I'd like to believe that if we go through that process that we will find sufficient justification.
MR. REYNOLDS: Simon? Margaret, did you have a comment?
MS. WEIKER: Yes, I have a comment. I agree with Don that we need to educate the industry on the changes, on the enhancements to the guides. I think it is impractical at this point in time to go back to each of the requesters of a DSMO change request which are five years old as well as data maintenance requests in X12 and data element request forums and DOEs(?) and NCPDP and ask that party to give their estimates. As Don mentioned, they might be able to give it to their organization. But if I'm not a hospital, I'm not going to know how much it's going to cost a hospital to make a change like that. The hospital's going to have to look at it because some of it may be how did they implement.
And I think it was Lisa that mentioned, you know, did they wrap something around it and then changed their back end system, or did they just do a total revac, total replacement. All of those different variations which is probably why you see estimates from, you know, it's going to cost me $20,000 to $5 million, and it would depend upon how each entity.
So I think it's impractical to “go back,” but if that is a requirement now of this committee that every DSMO request give a dollar estimate which makes no sense, and lot of people wouldn't want to do that for competitive reasons, it just doesn't make sense to go back and do that. I think we need the industry education and however we can do that the best to say here are the changes and get that education so people can understand what the changes are and then they can go and say, okay, now I can put some dollar amounts, now I can put some FTEs around that.
MR. BLAIR: Okay. So maybe the education needs to come first. One of the things is since we've been through this process a few times, at some point, especially if it's going to be a mandate, there's going to be people who are going to be concerned about the costs. And if the folks that believe that this should be done don't come up with the benefit, then the folks that don't want to do it probably will do their own survey to show that the benefits don't justify the costs.
So I think it may not be a pleasant or desirable situation that we're in, but I think that may be the reality.
MR. REYNOLDS: Lisa, did you have a comment?
MS. MILLER: I did. In listening to some of the discussion and as someone very involved in the questions and the way they were asked, I wonder if you look at the actual questions, we did a grid approach to the changes and maybe I should explain this, how we came up with some of what we gave you.
But what we did is we took from X12 and we specifically asked them for what they felt the significant benefits were, where would the industry get benefit, and give it to us from a high enough level that a decision maker within the organization could answer it.
What we did not ask is what we thought the impact for each of the changes would be. So I think, Jeff, maybe one of the things you're asking for – we asked for a blanket what do you think this will cost, and we got no cost to very great.
Perhaps what we need to do from a WEDI perspective is go back and now ask the discreet question of here are the changes, what impact to your organization would this have, and is there a cost around more specific.
MR. BLAIR: Is that getting back to Margaret's point of the folks taking the survey need to be educated on the benefits?
MS. MILLER: It is, and I think part of it is we came at it from a higher level looking for that more of a senior level decision maker taking the survey that we need (1) more education; (2) I honestly believe we need access to that documentation for the people taking the survey, whether it's temporary access, whether it's somehow to get that information into their hands.
I truly believe if we had access to information for the industry, they would have answered differently. And then the third thing is asking our questions more discreetly around those changes so that we're not giving you a broad swag at a number from zero to $1 million to $5 million which is very difficult, I think, to look at from your perspective and listening to your comments.
We certainly have the ability to open these. We have the ability to make them more discreet and, with more education, take those back out. I don't know your timeframe, and I don't know when you're looking for these to be done.
DR. COHN: Well, one thing I did want to add is you took the initiative to pull together this survey. The results, you saw them before you shared them with us, and I wanted to commend you. I wanted to thank you for taking initiative to do the survey and sharing the results with us the way they fell. Thank you.
MR. REYNOLDS: Simon?
MS. MILLER: You're welcome. Again, it is not our intent to show you anything other than what the voices coming back through the survey were, good, bad or indifferent. From a personal perspective, I was disappointed.
MR. REYNOLDS: Simon.
MS. MILLER: But I have to say from what the industry's saying, unfortunately the voices need to be heard, and there are, I think, things screaming at us. And I really do think the last page, when you look at how few people have this documentation is frightening.
MR. REYNOLDS: Simon?
DR. STEINDEL: Well, Lisa, first I really want to thank you for the work that you did. I mean, it's herculean, and I would say it's unprecedented, but it certainly is Herculean, and I really appreciate it.
Obviously, I'm not quite as douered(?) necessarily as Jeff is, only in the sense that we have, part of the reason why we have two days of hearings is to actually hear from specific entities tomorrow getting actual real comments about how all of this comes together.
The other piece is I reflected on your work was sort of the recognition that, at least I suspect as a subcommittee, we are not going to be recommending where you go forward with the 837 but not the 835, and you hold this and you hold that, but it's really more sort of a corpus of changes, at least I think. Now as I say, we obviously have to talk about that tomorrow to see what makes sense.
And obviously the question in all of this which I think Jeff alluded to really wasn't asked which was, you know, taken all together, is there a greater benefit than cost or whatever.
But having said that, I do agree with you that there clearly is a public education piece around all of this. I will apologize because I actually was one of the people who received the survey, and you can imagine what didn't happen there. I'm actually hoping other people within my organization did complete the survey.
But I think that when all of us – and I look at myself, I look at everyone else, that when you're at 140 emails a day, the thought of looking at – that's all, okay. But I imagine that many listening fall into the same category here that the thought of opening up an email with an attachment that then you have to look at is certainly not something that, let's say, fills you with joy. I think Harry's responds to that one also.
You know, having said that, I also am struck that as a leader in an organization, I don't know what I would do looking at the actual implementation guide anyway. I mean, what I need is a distillation that tells me about the important differences, what difference it's going to make to my organization, how I might be able to use something which I want to thank Don earlier today for beginning to get to that level. But, you know, that's once again part of the public education.
So you know, I'm neither here nor there on what's happening. But I just think that we're learning things about all of this, and we obviously need to be, we'll be more informed tomorrow after we've done some of the testimony. So thank you.
MR. REYNOLDS: I think another thing I would say along the same lines as Simon is a lot of people – everybody in this room says HIPAA and other things have been around a long time. HIPAA's actually been implemented for about 24 months. I mean, full speed implemented with a lot of people. I mean, there's still people coming on the transactions. So that's not – even though the 5010's six years old, I would play off of Simon's comment. I think, Don, your document is the first time I get 5010, and I do this as a day job. I mean, I think it's really finally laid it out, and I think that this, along with the mechanism that WEDI already has in place and everything we've heard from you, builds a new ability to go forward. And so I think we get kind of ahead of ourselves because we hear about it so much. But I think the real world out there is still implementing NPI and still in day-to-day hand-to-hand combat putting that in place, you know, as far as what's going on.
So I think there's a bit of a – you can also look at an overload. But I commend all of you. I think you've done a great job, and why this hearing is important to us. You've done a great job in summarizing, all of you. You've done a great job in setting together a survey that marks a point in time. It doesn't – I'm where Simon is. I'm neither sad or happy or anything else. It's fact. It's a point of time, and it's a point of time based on a reality that a lot of us knows going on in the world right now. And so I commend you for that because the mechanisms you put in place, the discussions, the thoughts you put in place can be used as this discussion continues quite nicely.
So I think, you know, the educational material you were talking about, I think, I'm never going to let go of Don's document again as I go out of here. Somebody has to take it from me. But I think that's a very important, and that collateral as we all go forward, that collateral of taking it and making it real. You know, you can download from Washington Publisher all day, but it takes somebody really astute which all of you have been to make that something that Simon or myself or Jeff or anybody could walk back to my company, matter of fact, let's say, okay, now this is me. I don't know if we answered the survey, but okay now I know what it is and what it's going to take to do it. That's cool. So thank you very much because I think you have stepped everybody forward significantly in that.
Now obviously we have deliberations to make. But I really mean that.
MS. MILLER: Well, one comment back to you. It's interesting we asked people to respond to a survey. Yet, we just educated you today. So I have to say and go back to that original gut feeling of the committee that worked on this that people just don't know, and they don't get it. Now you do. But we haven't done the same thing with the industry.
So the one comment that I did read to you that they felt this was too early, are we too early because we haven't really elevated this change to the industry.
MR. REYNOLDS: But if we're looking at any kind of the dates that have been discussed here, nobody committed anything, but the dates that are being discussed here, it's maybe not too early. So we need to keep that in mind also. Steve?
DR. STEINDEL: Yes, this is a very specific question to Don wearing your co-chair hat at X12. It's a technical X12 question that's based on a distillation of all that I've heard today, including timeframes, timeframes to implement ICD 10 which I'm very concerned about, et cetera. Are there highly specific surgical changes that can be made in the present 4010 transactions that will allow us to carry ICD 10 codes without going through the full weight of the changes required for 5010?
MR. BECHTEL: We have discussed this many times – not here -- at X12 and in other venues, and I believe the answer is we can't do it in 4010, and we just have to move forward to 5010.
DR. STEINDEL: I'm going to ask then, I'm going to have to follow it up and answer for an explanation because from what I have heard, the reason why you can't carry ICD 10 codes – I'm not saying use, I'm saying carry, ICD 10 codes in 4010 is because of field restrictions.
MR. BECHTEL: In part, that's true.
DR. STEINDEL: And that would seem to me that if you just changed the field restrictions in very specific parts of fields and very specific segments, you can now carry ICD 10 codes.
MR. BECHTEL: Yes, in part, that is a correct answer, I disagree that you can do it. If we need to provide specific details on that, we would be glad to come back and do that.
DR. STEINDEL: That depends on how deliberations, et cetera go.
MR. REYNOLDS: Okay. Seeing no other questions, again, excellent job, excellent job for everyone to move forward. No, I mean that very much. Sometimes as an individual it's hard to come in here with your findings, but you made it. I think you made a great impact on everybody today.
We're right on schedule. Why don't we take five minutes. We've been sitting here for two and a half hours or so. Why don't we take five minutes and come back and then do some deliberations.
(Break.)
Agenda Item: Subcommittee Discussion
MR. REYNOLDS: Okay, all I want to do starting out, Simon will be back in a minute. But I know Judy has to go take a call is just to see over the next few minutes if anybody's got any comments or anything else that we want to discuss today or any further questions or anything because obviously the exciting part of this is we have tomorrow, and so we've heard half of what we're going to hear at best. And so I think that will be good. So I'll open it for anybody that have any comments, and Judy you get to go first if you have any since you're going to be going.
MS. WARREN: No, I don't have any comments at this point.
MR. REYNOLDS: Is it too early in your survey process or what.
MS. WARREN: I'm going to be like Simon and get an email and not answer it.
MR. REYNOLDS: Okay, good, all right, you got one, okay. Steve or Jeff or Simon?
DR. STEINDEL: Harry, you're staring at me.
MR. REYNOLDS: No, I'm just looking down there.
DR. STEINDEL: I'm going to have to – I have some comments forming, but I want to hear what the discussions are tomorrow. Yes, basically because, you know, there may be some testimony presented tomorrow that, from the people who are actually down in the trenches, that can help formulate more solid opinions. I think we all have expressed our angst at the survey, and we all have expressed a better understanding of the technical capabilities of 5010.
Now what that means, I think we're going to have to hear from the people tomorrow.
MR. REYNOLDS: Okay. Jeff, do you have any comments?
MR. BLAIR: I echo what Steve says. I want to reserve judgment until we've heard all the testifiers tomorrow. And you can tell that I'm trying to look for a way to move forward here, and so we'll see what happens tomorrow.
MR. REYNOLDS: Okay. I'm not going to add any comments either except to say that we had set these hearings up to get to the bottom line of what's going on with 5010, and I think we've gone a long way towards that goal in less than half a day.
Denise, thank you for putting it together. And to all of you that presented, thank you very much. And I think looking forward to tomorrow this will give us plenty to think about, plenty to evaluate.
I think the other thing is what I do appreciate is a number of the presenters for tomorrow have been in the audience today. So they will also have the benefit of having heard the testimony today to be able to hear the discussion as well as be able to play off that tomorrow during their presentations. Whether they consider that a positive or negative event, we'll find out tomorrow. But at least everybody did get to hear what they did.
So unless there's any further business, I don't see any reason to keep anybody any longer, and I appreciate everybody's attentiveness, and we'll see you in the morning, and we start at nine o'clock. Thank you very much.
(Whereupon, the meeting adjourned at 5:30 p.m.)